not translated parts in admin Javascript

[radek]

These are not translated parts in admin:

Filter
result
button Go

Show, Hide - for colapsing

For Datefields - Date:, Time:, Today, Now, All strings in JS calendar

month names when in yearly or monthly filter

[anonymous]

JavaScript isn't translateable, as it runs on the client - and we don't have gettext and po/mo files on the client :-)

This could be solved by either using AJAX to pull the stuff to show in the JavaScript from the server (and so be able to translate there) or to route the full JavaScript download through the server, so that the whole JavaScript can be translated. So the JavaScript calendar and the show/hide stuff are out for now.

The search button was in a template and so I added a translation hook. The month names I could find in the source already have translation hooks. The only month names I could find without translation tags were in JavaScript, too.

[hugo]

Oop. See me forgetting to login before commenting ;-)

[radek]

Javascript: as in other JS tools the translation is separated from the code via lang folder

Eg. in fckeditor there are these files:
./lang
./lang/en.js
./lang/de.js
./lang/cs.js

This is a snippet from the fckeditor's en.js:

var FCKLang =
{

Language direction : "ltr" (left to right) or "rtl" (right to left).

Dir : "ltr",

Toolbar Items and Context Menu

Save : "Save",

NewPage : "New Page",

Preview : "Preview",

Cut : "Cut",

I believe we could use the similar approach. It is performance better than to route it through the server (directly or using AJAX).

[hugo]

I think it could be done by providing tools that "populate" the language versions of JavaScript, though. In that case the JavaScript itself would be written using gettext tags and there would be a tool that just runs the javascript files with tags through the translation engine and stores the results in language-named folders. Then there would still be the need to get the right JavaScript version out to the client based on his language (might be done in the templates that link in the javascript libraries).

That way we would keep the gettext infrastructure even with the provided javascript, only the need for the tool would come up.

What I don't like about dynamic translations in JavaScript: JavaScript isn't the fastest of all languages, so I try to avoid running more complicated code in there ...

But this should be discussed a bit more, I think.

[radek]

Offline tools I believe. Yes, that way such tool could check, that all texts are translated and eventually mark untraslated texts in the target language with #translate me# prefix (and fuzzy with #check me# prefix). This is the very neat behaviour done by FreeMind java application ​http://freemind.sourceforge.net/wiki/index.php/Main_Page.

Moreover we would not need any fallback code in JS for translations (when trans texts are missing).

[Nebojša Đorđević - nesh <nesh@…>]

Or we can simply use django template language for JavaScript files.

[hugo]

If it's done with an offline tool, we should use the django template language, because all the translation support is already available.

[radek]

Use templates? Just remember, that there is not only one process (generating lang files): 1. gather text to translate from the javascript code, 2. create .po files, 3. generate lang files.

Or did you mean to generate (offline) using templates even all javascript files?

[hugo]

Generate language-specific javascript via template language via offline tool. So you start with one JavaScript file where all strings are marked with template tags for translation and run this file through the template engine to produce translated javascript for each language supported in Django.

This will put a bit of a burdon on those writing the JavaScript, though, so that's why I say this should be discussed more. I am not really comfortable with that, yet (and not really comfortable with other solutions that come to mind).

A completely different way could be to write something like a gettext implementation for JavaScript - it could be done by creating a dynamic javascript for the current message catalog and fetch that in admin pages. JavaScript libraries are cached, so it won't be fetched too often. Then you could use an approach like with other languages where this library just provides gettext and ngettext - that way you would have to write your own pluralization code. But that way you actually have a chance to get correct pluralization.

[hugo]

Discussion should take place in django-dev. I open up a topic there.

[hugo]

first take at gettext functionality for JavaScript

[hugo]

I added the code I have up to now for gettext in JS to the ticket. See the django-devel discussion for it's status.

[hugo]

[1529] and [1530] implement JavaScript translations via a JavaScript gettext implementation and dynamically createsd JavaScript catalogs (via generic view).