[etoys-dev] Special cases to decide translation domain

[Bert Freudenberg]

On 11.05.2010, at 03:05, Korakurider wrote:
> 
> Hi there.
> With Ricardo's great work we are thinking to split translation domains based on
> package that method belongs to.
> This seems basically good, but there are cases we should look into carefully:
> How do you think?
> 
> (1) sugar activity based on etoys.
> Old examples are Karl's FreeCell and Bert's DiceWars and Stef's BotInc
> that I experimented L10n.
> The code is just a changeset dynamically loaded on startup of the activity.
> In initialization code register mapping to TextDomain dynamically.
> (You could review Current DrGeoII that is localized by this scheme)
> 
> Old legacy TextDomainManager works well for this purpose.
> I think that stuff will be still needed even if we implement splitting
> of text domain based on package.

As far as I am aware, the DrGeoII activity is the only one actually containing translations. And since we will include Dr Geo, it is not needed anymore.

Do you think it is necessary to retain the old classes-based protocol? IMHO it was only there because it was the most efficient one to implement, the packages approach is much better. Setting the text domain by class allows more control, but do we really need that? If you think we need it, we should look up the package only if the class was not registered.

> (2) #translatedNoop sent and #translated in different place (package)
> Example:
>      wordings and help message for tiles are declared in each morph's
> slot definition code.
>     (WsWorldSthethoscopeMorph>>(class)additionsToViewerCategories for
> instances)
> 
>      Strings for tiles that belongs various package will be
> translated in some central place.
>      So #translated can't decide correct text domain based on
> sender's method property.
> 
> There are about 200-300 instances that we will need to review.

We talked about putting all tile translations in a separate text domain (e.g. "Etoys-Tiles"). #additionsToViewerCategories does not have a translatedNoop send, the phrases are exported separately anyway, so that should be easy. And they are translated in a central place - there we could use #translatedInDomain: instead of #translated.

But there are more places like this - menus, flaps, parts bin descriptions, service entries. You are right that we need to figure out a good way to deal with this. I think it is better to fix the senders of #translated, rather then touching the #translatedNoop sends.

So here is a crazy idea:

Take, for example, Morph>>innocuousName. It sends #defaultNameStemForInstances, and most of its implementors use #translatedNoop. Now, instead of using a plain #translated call, it could use 

		translatedFrom: #defaultNameStemForInstances in: self

And #translatedFrom:in: would then look up the translation domain for #defaultNameStemForInstances.

And here is an even crazier idea:

Instead of #translated, use #translatedInAllDomains for these. That would simply search the string in, well, all domains (starting with the sender's domain). That would be roughly equivalent to what we have now.

In fact, that is so simple, it might even work ;)

- Bert -