[etoys-dev] Re: [squeak-dev] Localization for Squeak products
yoshiki at vpri.org
Tue Jan 19 01:44:37 EST 2010
At Mon, 18 Jan 2010 21:59:55 -0800,
Andreas Raab wrote:
> Hi -
> We're looking into localizing our products at Teleplace and I'm looking
> around for options in this area. If I understand it correctly, Etoys
> have been localized in many languages. What I'm curious about is what
> the localization process looks like in practice:
> * What needs to be done to support localization in Etoys when writing
> code? I.e., historically all that was needed was a call to #translated,
> but I'm not sure if that's still the case with the move to "standard"
We used #translated for string literals, and that does the
translation at runtime. But the way the system collects these
literals is different from the past. GetTextExporter2 scanns the
image and collects all senders of #translated, and another selector
called #translatedNoop that is attached to a collection of strings.
As the name suggests, GetTextExporter2 creates the de-facto standard
gettext pot file.
(BTW, above and below work were mostly done by Korakurider. Big
thanks to him!)
> * What are the tools to create new localizations of Etoys? I.e., what
> does a translator start with as input and what is created as the result?
> What tools are used to create one from the other? How do you check for
The created .pot file is uploaded to an online translation site that
uses Pootle. The volunteers provides the translation and at the
release build time, we collect the translation, compile them to the
.mo files. GetTextTranslator, a subclass of
NaturalLanguageTranslator, opens the .mo file and looks up the
translation of given string from it.
The upside of this is that the volunteer translators don't have to
know the context of how these phrases are used, but just look at the
web site and translate them all. And Pootle is what Sugar and OLPC
people used so being able to use the same mechanism was a big plus.
The downside is that they translate them without the context; so a
phrase with multiple meanings may not get translated properly.
Also, a phrase is used in different way and not being able to
translate it differently is a problem. We thought of several ways to
solve this problem... One was to modify these words in the source
code (e.g. a phrase like "start" to "start (verb)" and "start (noun)")
but it would have resulted in invalidating a lot of volunteer work and
having to provide the English translation. If Pootle was flexible, we
could have an annotation to each phrase to indicate its use (still
would have required source change), but didn't happen. Splitting the
phrases into different text domains was another possibility and it is
good for other reason (korakurider has the code even) but didn't
happen for various reasons.
(I thought we started out from 4,000 or such phrases for Etoys, but
now it appears to have 27,000 or such. Not sure what it means...)
> * How does localized deployment work with Etoys? I.e., what are the
> options for providing localized downloads vs. downloading all supported
> locales and switching dynamically upon startup?
In general, we bundle these .mo files in the single release. Upon
startup, GetTextTranslator scans the specified directory for available
languages and show them in the menu. (And trys to switch to the
> * Generally speaking, how do people feel about localization in Etoys? Is
> it considered to work well, or is it considered to be a painful process?
> Are there any obvious alternatives one should look at?
This is subjective, but I thought the process overall worked pretty
good, given that volunteers all over the place.
There were some things that didn't go as nicely as one'd hope. For
some languages, even the translation was provided, the work is
unfortunately wasted as the text rendering was only available on Unix
(on XO, it is kind of okay but still the UI layout for RTL languages
is not there). Many languages, where not many Etoys users and
translators are not actually using Etoys, I would have to think that
the quality of translation may not be optimal. Pootle was quite slow
and required a lot of manual intervention and merging huge translation
files for Etoys was indeed pain (I don't know much of the behind scene
thing here but it took often weeks to get it done.)
At the bottom line, I'd think that going through the gettext
mechanism, possibly with nicely annotated strings in the code would be
okay. One would want to go for the "system resource strings"-ish
convention where you only write string IDs in the source code and
separate strings from the source code, but it looks just annotations
to me. For a company work, the people can edit .po files by some
existing editor and there you can embed comment to show the usage.
More information about the etoys-dev