Diego and Stef,

> 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.

> The translations are hold in each language instance in a dictionary and we
> have support for merging dictionaries, etc. so the risk is not at this part.

  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.

> One time Babel got included in Squeak every package maintainer can make the
> package "translatable" just sending #translated to the gui's
> strings.
> 
> I'd like to know which type of opportunity (if any) Babel has to be included
> for 3.7.  What the guides think about? What the other potential translators
> do?

  I would imagine the above two changes would make a stable basis for
such translation framework.

  Nice work, Diego!

-- Yoshiki