[Etoys] How do we want to translate project?

Bert Freudenberg bert at freudenbergs.de
Mon Dec 3 05:10:10 EST 2007


On Dec 3, 2007, at 3:00 , Korakurider wrote:

> --- Bert Freudenberg <bert at freudenbergs.de> wrote:
>> We don't need to split I think (unless translators
>> want us to), but
>> we will have additional pots (for projects,
>> quickguides, add-on apps
>> like BotsInc, DrGeo2 etc)
>   I am confused here:  You implemented so that TextMorph can have
> translated labels as properties and user can edit them, right?  I have
> been assuming the functionality will be used for translating project
> by communities and for preloaded contents.

Hopefully, yes. But, once we get a project translated in two  
different languages, what do we do to migrate the two translations  
into one project? My thought was to export to po and reimport in the  
other project.

> So what problem do we want
> to solve by implementing another one, and what road map are you
> thinking?

It's for solving the visibility problem. Translators often seem to  
work on their own, without even running or understanding the program.  
That is bad, but even a bad translation is better than no translation  
IMHO. So to cater to these folks who only will translate what shows  
up in pootle, I'd like to provide a gettext-compatible way of  
translating.

Additionally, we might be able to allow project translation without  
even changing the project file, at runtime, just like for code.

> And I am not sure whether gettext-based translator is good for base of
> contents translation:
> + Gettext looks up translation by original text and "context" where
> the text is used in code.
>    The context is actually class category or method category and both
> don't fit well for
>    Morph instances in project.

This mechanism is only used for literal #translated sends.  
Translating the contents of TextMorph can easily provide a different  
context, for example the project title sans version number.

> + I think translation for contents should be able to be dynamically
> and easily modified by users.  Your tweak on TextMorph is great for
> this.  Compiled MO format seems too static and rigid.

Agreed, but you breathe and live in the dynamic world of Squeak,  
which is still a very strange concept to others ;-)

So anyway, I'm not talking about replacing that direct translation,  
but augmenting and extending it by gettext.

- Bert -




More information about the Etoys mailing list