Opened 13 years ago

Closed 13 years ago

#945 closed defect (fixed)

not translated parts in admin Javascript

Reported by: radek Owned by: hugo
Component: Translations Version:
Severity: normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:


These are not translated parts in admin:

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

Attachments (1)

jsi18n.diff (5.7 KB) - added by hugo 13 years ago.
first take at gettext functionality for JavaScript

Download all attachments as: .zip

Change History (13)

comment:1 Changed 13 years ago by 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.

comment:2 Changed 13 years ago by hugo

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

comment:3 Changed 13 years ago by radek

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

Eg. in fckeditor there are these files:

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).

comment:4 Changed 13 years ago by 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.

comment:5 Changed 13 years ago by radek

Summary: not translated parts in adminnot translated parts in admin Javascript

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

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

comment:6 Changed 13 years ago by Nebojša Đorđević - nesh <nesh@…>

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

comment:7 Changed 13 years ago by hugo

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

comment:8 Changed 13 years ago by 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?

comment:9 Changed 13 years ago by 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.

comment:10 Changed 13 years ago by hugo

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

Changed 13 years ago by hugo

Attachment: jsi18n.diff added

first take at gettext functionality for JavaScript

comment:11 Changed 13 years ago by 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.

comment:12 Changed 13 years ago by hugo

Resolution: fixed
Status: newclosed

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

Note: See TracTickets for help on using tickets.
Back to Top