Bert Freudenberg wrote:

A help to potential translators would be if the generated POT file would include comments explaining the context in which the original phrase appeared.

I think Squeak's translation system and LanguageEditor was designed strongly influenced by gettext at first (am I correct, Diego?). But folloing people including me have implemented it worse. I regret so many bad decisions in LanguageEditor. One example is, we use

"Hello world!" translated

instead of _("Hello world!"). That's good. But if we use a variable as the receiver like:

someVariable translated

We can't extract keywords by a program. That's nonsense. The first step would be fix those. Basic import / export mechanism have been already on Squeak. (Another bad decision was to invent an original file-out style export format. I should have taken only gettext format from the beginning).

Any volunteer? Should we ask the broader Squeak community for help?

It is very worthwhile task.

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.

Cheers, - Takashi

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@lists.laptop.org http://lists.laptop.org/listinfo/etoys

On Jul 4, 2007, at 9:30 , Hilaire Fernandes wrote:

2007/7/1, Takashi Yamamiya tak@metatoys.org:

...

That's a good idea. What's your definition of Squeak Application? I think a .pr whould be a good unit.

Hum, I was thinking about a Monticello source package as a good unit place to integrate language catalogs. This is at least the unit I am using to distribute DrGeoII source code.

Right - see my previous message. We want to have a separate .po file for each class category, which is roughly equivalent to a Monticello package.

- Bert -

Yes, that's what I meant. So for a string in a method of a class in category "Foo-Bar" we would look at "Foo.mo". Or, for even more sophistication, look for "Foo-Bar.mo" first, and if that does not exist look in "Foo.mo".

- Bert -

On Jul 4, 2007, at 12:19 , Hilaire Fernandes wrote:

Don't you think a .po file per class category is a too small unit? Or do you mean the 'MyPackage' of MyPackage-catagory?

Hilaire

2007/7/4, Bert Freudenberg bert@freudenbergs.de:

...

On Jul 4, 2007, at 9:30 , Hilaire Fernandes wrote:

...

2007/7/1, Takashi Yamamiya tak@metatoys.org:

...

That's a good idea. What's your definition of Squeak Application? I think a .pr whould be a good unit.

Hum, I was thinking about a Monticello source package as a good unit place to integrate language catalogs. This is at least the unit I am using to distribute DrGeoII source code.

Right - see my previous message. We want to have a separate .po file for each class category, which is roughly equivalent to a Monticello package.

• Bert -

That sounds good!

Anyway, a friend of mine kindly offered me his spare time to help about translation stuff. Which part is good to start? He understands both Squeak programming and gettext architecture. I think separating the translations into chunks is what we have to try at first (I myself haven't read gettext documentation in detail yet though).

Cheers, - Takashi

Hilaire Fernandes wrote:

That would be really great !!

Hilaire

2007/7/4, Bert Freudenberg bert@freudenbergs.de:

...

Yes, that's what I meant. So for a string in a method of a class in category "Foo-Bar" we would look at "Foo.mo". Or, for even more sophistication, look for "Foo-Bar.mo" first, and if that does not exist look in "Foo.mo".

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

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

Actually, making .pot files is in progress by Korakurider.. http://d.hatena.ne.jp/korakurider/20070710/p2

Cheers, - Takashi

Bert Freudenberg wrote:

There are two initial steps that could be pursued independently. On is gathering translatable strings from the image into .pot files, the other would be to write a parser for .mo files. The first requires knowledge of Smalltalk parsing, the second familiarity with gettext. So I'd suggest starting with the second.

Yet another step would be to re-implement #translated to take into account the location of the sender. This could be performance- critical, as "thisContext sender" gets you only the compiled method but not the class or selector of the method. Probably the translator should have a cache keyed by compiled method and string, but the details might be tricky.

And work on making the language switching faster by not simply re- building everything would certainly be useful, too.

On Jul 15, 2007, at 4:09 , Yoshiki Ohshima wrote:

...

Yet another step would be to re-implement #translated to take into account the location of the sender. This could be performance- critical, as "thisContext sender" gets you only the compiled method but not the class or selector of the method. Probably the translator should have a cache keyed by compiled method and string, but the details might be tricky.

Just an idea, but a Compiler hack that compiles:

'abc' translated

to:

'abc' translatedFor: aClass

might work. The aClass may be a Symbol, or a class category.

I don't think we need that much magic ;)

We do not need the actual class and selector of the method that sent #translated. Class category is sufficient for the lookup, right?

We know thisContext sender's class already, so the right class category must be the category of the sender's class, or one of its superclasses. That should be sufficient and reasonably fast, since I doubt there would be more than two or three different class categories involved in a given superclass chain.

- Bert -