Localization, Internationalization
Chroma
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:
https://github.com/hossein/dkobo/compare/mi18n?expand=1
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.
Cheers;
Hossein.
Alex Dorey
Hossein,
This looks great. I havent had a chance to look through the full PR but it sounds like you did a lot of work towards our eventual i18n support. For the css issue, i think we can work around the need for separate files by moving that text into a data attribute and using a css rule like "content: attr(data-text);" then using gettext in the html markup (<div data-text="#{gettext('something')}" />). This might get tricky with select2 boxes but at least we would not have to maintain css files for all translations.
For all future javascript work, we have been wrapping translatable strings in a function call to avoid the future problem of breaking them out of ugly multi line strings.
Thats great that you got rtl working! I look forward to seeing it in action and including your persian support when we take on language switching.
Regards,
Alex
--
You received this message because you are subscribed to the Google Groups "KoBo Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kobo-develope...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.