Making I18n support easier

[GoogleCodeExporter]

Hey Michael,

I'd somehow like to tackle this issue as this is currently quite a pain point 
for me. Right now, I'm using several defines for messages and I need to 
manually maintain them in the config file.

I already had a cursory look at the code base. It looks like you have already 
implemented some support for extracting messages from Soy templates. I've also 
found the JsMessageExtractor in the Google Closure Compiler source which can 
extract messages from JSSourceFiles.

There is also the JsMessage.IdGenerator interface. In my application, I use 
more abstract translation messages like "form.label.firstname", basically my 
message is the id, but reading the comments in the source it seems like Google 
Closure uses a different scheme.

Perhaps, you also have already thought about the general workflow? I could 
imagine an additional config option where you could specify a translation file, 
or also inlining the translation map in the configuration (basically what I'm 
doing with my defines at the moment).

A lot of questions, maybe you can help me on some of them.

Thanks,
Johannes

Original issue reported on code.google.com by johannes...@gmail.com on 25 Sep 2011 at 8:59

[GoogleCodeExporter]

Hi Johannes, this is certainly an important feature, but unfortunately, I don't 
have the bandwidth to give it the attention that it deserves right now.

Ultimately, yes, you are supposed to specify a translation file for each locale 
such that a unique compiled JS file is produced for each locale that you want 
to support. I haven't played with the open-source version of this code very 
much, as at Google, it was tied to an internal translation system.

Whatever system you end up with, it is best if the English (or whatever your 
primary language is) versions of the translations are in the source code itself 
so that you can develop quickly, but it's also important to have build 
processes to determine when new strings that need to be translated are 
introduced, to send them out for translation somehow, and then to integrate the 
translations back in.

Original comment by bolinf...@gmail.com on 27 Sep 2011 at 3:08

[GoogleCodeExporter]

For what it's worth, we managed to get a production-capable system working 
using the javascript implementation of gettext available at:
http://jsgettext.berlios.de/

To extract the strings, we used xgetext. Unfortunately, xgettext doesn't work 
right off the bat with javascript, it needs to be modified. Luckily, someone 
has already made these changes in the form of a branch of the main gnu gettext 
project, available at:
https://github.com/AndyStricker/gettext-javascript

Finally, in our project we implemented our own templating system which puts a 
bit of javascript in the template HTML itself (for configuring the templates). 
In our case, some of this javascript needed to be translated. This presents a 
problem: there is no HTML support in xgettext and the modified js-xgettext 
didn't work. We had to implement an intermediate process which stripped the 
javascript from our templates and passed the resulting temporary file into 
js-xgettext.

The final application uses cookies or search params to determine the users 
locale selection (let's assume en-US) and grabs the appropriate l18n file from 
"projectroot/locale/en-US/messages.po" with a synchronous-ajax call at the 
start of our i18n.js file. Any other file can "require(name.space.i18n)" which 
kicks all of this magic off.

This all took about 1 week of grunt work learning how to use the tools and 
setting up the scripts, but now that it's all working things are sweet!

Original comment by jp...@lmitechnologies.com on 23 Nov 2011 at 12:11

[GoogleCodeExporter]

of course, by l18n I meant l10n ;)

Original comment by jp...@lmitechnologies.com on 23 Nov 2011 at 12:12