Opened 19 years ago
Closed 19 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: | no | UI/UX: | no |
Description
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
Attachments (1)
Change History (13)
comment:1 by , 19 years ago
comment:3 by , 19 years ago
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).
comment:4 by , 19 years ago
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 by , 19 years ago
Summary: | not translated parts in admin → not 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 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).
comment:7 by , 19 years ago
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 by , 19 years ago
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 by , 19 years ago
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:11 by , 19 years ago
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 by , 19 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
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.