JavaScripts and WTForms messages are not translated

[Jakob Kramer]

The strings in the JavaScripts (e. g. show_password.js) and the !WTForms messages (e. g. “Invalid Input”) cannot be translated right now.

[Jakob Kramer]

The problem with WTForms can be solved easily by translating our own strings with our own function and by ​using an own “Form” class.

[Emily O'Leary]

I added the appropriate translation tags where I had text displayed in what I was working on for in #492.

See: ​https://gitorious.org/~lotusecho/mediagoblin/lotusechos-mediagoblin/commit/1e2720a25acc7408ab6eb0d498fc389a1fc73e6b

[Christopher Allan Webber]

I've looked at the work done for #453; as said there, the javascript stuff isn't really translated via that method, since it doesn't pass through jinja2.

I think this requires some extra thinking about how to do translations for javascript. One option is that the browser can pull down .mo files and read and parse them in-browser, but that seems kind of strange.

Some suggestions:

• We can try to avoid using translatable strings as much possible in JS, and use hidden fields that are translated in the browser, etc.
• We can have an additional page that serves up a big ol json document with all the relevant strings translated at a path like /i18n-es.js ... but this is actually served (and cached) by the mediagoblin application. (It would actually be really nice if this could be rendered once and served via apache for each language somewhere, but I don't know how to do that.)

[Amirouche]

Current command that generate the strings to be translated should also take care of javascript files using something like ​http://jsgettext.berlios.de/ and/or ​https://github.com/wikimedia/jquery.i18n. This process should generate two file client.po and server.po (for instance) and merge them in app.po. app.po will be submitted for translation.

Another command will take care of splitting the translated files into two .po per language one for client side consumption another for server side consumtion.