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