Thanks Alex for already informing that a major dkobo rewrite is in progress; however here is what we’ve done for localization of the current dkobo project anyway:
So could you take a look and let us know how much you are interested in this and whether this fits your standards or you’ll prefer to do it your way instead maybe?
Here is what we did:
- Use Django’s own i18n system to translate dkobo/koboform/templates.
- Annotate jsapp/xlform_model_view coffee files with gettext function of using Django’s own i18n system for js files; the strings are extracted from dkobo_xlform.js after the coffee files are compiled to it.
- For jsapp/kobo, we used angular-gettext (I personally thought it is more friendly with Grunt automation than angular-translate; now I’m not an expert on neither of those).
- For the “content:” attributes in css files in jsapp/kobo/stylesheets, we overrided those attributes in dkobo/koboform/static/css/i18n_LANGUAGENAME.css which are included from the template files.
- Initially we wanted to have one single .po file for all the parts, but since Django’s JS translation and angular-gettext both use client-side java scripts for translation, I preferred separate files like they are now.
- We speak Persian which is written right-to-left, so welcome dkobo/koboform/static/css/rtl.css! It can be used for all RTL locales as well. We use django templates’ get_current_language_bidi to include it automatically into the templates if the used language is right-to-left.
- Grunt manages the creation and compiling of translation files, so translation process is as automatic as possible.
Now we’ve tried my best to make everything work, nevertheless some parts needed hacks or tricks to work, ESPECIALLY in the xlform_model_view part. Some of them as well as some notable things that I can remind now are:
- There are “content:” attributes in jsapp’s css files. To translate them we either needed to use Django templates in the css files, or just override the “content:” values in another css file. We chose the latter which resulted in i18n_LANGUAGENAME.css files mentioned above.
- In xlform_model_view coffee files, there were entire blocks of Angular templates put into string variables. Whenever those templates had strings to translate, I used manual %1, %2, %3, etc string substitution in code.
- Sometimes there are long and/or ugly lines among xlform_model_view coffee files.
- There is no localization for numbers, date, etc right now; we haven’t still looked into ita.
- Question Library is still not finished btw.
- We didn’t use Django’s locale middleware, so there is no language detection. Only settings.py’ LANGUAGE_CODE can be used to set the language.
If you’re interested, let’s discuss and make it perfect.