[Etoys] Translations

[Bert Freudenberg]

On Jul 2, 2007, at 13:37 , Michael Rueger wrote:

> Takashi Yamamiya wrote:
>
>> Hilaire Fernandes wrote:
>>> The problem using Gettext with Squeak, is that Gettext is not its
>>> native system for translation. When using Gettext with GNU  
>>> application
>>> you benefice from the its tool suite: when messages are updated,  
>>> it is
>>> able to mark changed messages as fuzzy and/or to propose a closer
>>> match. I don't know if it is applicable to Squeak, and what is
>>> necessary to do to make the best use of the whole gettext tool  
>>> suite.
>>
>> That's interesting. We should have those feature.
>>
>>> Regarding translation, another stuff it will be nice is language
>>> catalogue per Squeak Application. It is not unrealistic
>>> people/organisation/vendor will develop Squeak application (applet,
>>> extension or whatever it should be nammed) for the OLPC.
>>> In this case this organisation will also need to ship language
>>> catalogue with their Squeak Application. It is also what Gettext
>>> provides.
>>
>> That's a good idea. What's your definition of Squeak Application? I
>> think a .pr whould be a good unit.
>
> Bert and I just had a chat about this :-)
>
> Our thoughts were:
> - separate the translations into chunks by SystemCategory
> - generate an initial set of gettext files from the current language
> editor files
> - use the comments in gettext to add class>>selector>>line nr
> - on a new release write out a new set of templates
> - then use gettext tools, diff etc to maintain the translation files
>
> (Bert please correct/add where necessary)

That's the general idea, yes.

We need a way to generate current .pot files by scraping the image  
(which should be called by ReleaseBuilder). This way they will be up- 
to-date unlike the current translation files which contain many  
unreferenced entries.

Translators then produce .po files from the templates, using a simple  
text editor or one of the special .po tools.

Then we need a way to load translations from files, preferably on  
demand as to not unnecessarily slow down the startup. Breaking  
translations into several files (based on class category) should help  
with this. We will want to read the compiled .mo format which is a  
binary sorted and hashed table of the strings:

	http://www.gnu.org/software/gettext/manual/gettext.html#MO-Files

This is emulating gettext (which is also the approach used by  
Python). Alternatively a plugin could be written that uses the  
gettext library to lookup translations, though I'd prefer the former.  
An interim solution would be translating .po or .mo files to our old  
translation file format.

Btw, the gettext manual linked above is quite interesting to read, it  
covers a lot of special cases due to its wide usage.

- Bert -

> This is a pretty well defined chunk of work, that could be handed  
> off to
> somebody.
>
> Michael
> _______________________________________________
> Etoys mailing list
> Etoys at lists.laptop.org
> http://lists.laptop.org/listinfo/etoys