[Babel] Looking for more translators

Yoshiki Ohshima Yoshiki.Ohshima at acm.org
Fri Sep 26 07:31:06 UTC 2003


  Diego,

> >> The biggest risk in my eyes is if  Babel get not included in Squeak.
> >> Babel is an almost trivial piece of code but it impacts all over
> >> Squeak. Basically each "visible" string has to received the
> >> #translated message and, as you can imagine, it means changes all over
> >> the image.
> >
> >  I was thinking to put an extra argument to a UI widget creation
> > method that specifies the dictionary to be used for the translation.
> > This would not going to be collective, but would help a lot to reduce
> > the number of places to put the #translated message.
> 
> We considered this alternative but the solution is not so easy becouse some
> ui widgets receive string concatenation of a translatable part and a
> non-translatable part.

  Exactly.

> Take ButtonPropertiesMorph>>rebuild as an example, there you can see a
> StringMorph that receive:
> 
>     'Button Properties for ',myTarget name
> 
> As you can guess we will need some extra support in StringMorph (and other)
> to handle this case.  In the Spanish translation using babel we choose this
> option:
> 
>    'Button Properties for {1}' translated format: {myTarget name}

  Ah, yes.  I don't claim we can *eliminate* the #translated sending.
As I wrote, we could *reduce* the number, which would be helpful to
manage the changes.  A 'printf()' like mechanism is also nice to have.

> >  Also, I'd imagine it would be nice if the dictionaries for a
> > language are organized hierachical.  Most of the applications want to
> > have the basic vocabulary like "Yes", "No", "Close", "Cancel", etc. but
> > also they need to have the application specific dictionary(ies). If the
> > translation look up is done by consulting chained dictionaries, we can
> > avoid the huge single dictionary.
> 
> We also talk about this and we decided to go first with the simplest
> possible solution and just see.  In the Spanish translation we found only a
> small set of examples where the same word need to be translated different
> because of the context, but the context is the original meaning in English
> and not where it's used.

  I was rather talking about how to manage the size of the dictionary.
'Yes' or 'No' would be required by most of the applications, but
'Escape Browser', etc. are EToy specific.  But I wasn't aware of this
problem you have in Spanish, so it is interesting.

> Example: The English word 'start' means the 'start (noun)' and also 'to
> start (verb)' and in Spanish we have different words for each case.  This
> example can be easily fixed just using:
> 
> 'start (noun)' translated.
>    or
> 'start (verb)' translated.
> 
> And using the English language instance to translate 'start (noun)' and
> 'start (verb)' to just 'start'.
> 
> The other option is to provide some hints to Babel like.
> 
> 'start' noun translated.
> 
> Or (the third option) is that Babel recognize some hints inside the string,
> like:
> 
> 'start {{noun}}' translated.
> 
> In this case Babel can look for 'start (noun)' translation and if's not
> available it can look for 'start' translation.

  With decomposed dictionaries, it could be *just a bit* easier.

  I see that the right option ('start' as verb or 'start' as noun)
are only known by the programmer, there should be a
flag/annotation/extra argument to distinguish it.

-- Yoshiki



More information about the Squeak-dev mailing list