[etoys-dev] Special cases to decide translation domain

[Korakurider]

I will reply only about the first case at this time. (I need to go to
bed now...)

On Wed, May 12, 2010 at 1:44 AM, Bert Freudenberg <bert at freudenbergs.de> wrote:
> 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.
      Yes, but I believe L10n stuff is still in to-do list for Milan's
"Using Etoys to Develop XO Sugar Activities".   Or do you give up that
feature?

> 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.
        Well, base image would be developed with package approach, yes.
        My point is about how to translate custom activities developed
based on etoys image, not about existing protocol.  (and I haven't
understood method property idea very well...)

/Korakurider