Localisation, internationalisation

[dittaeva]

I do not know if you have thought about this, but it seems not.

Not all voters are comfortable with Norwegian bokmål, there will thus be a need to translate the interface to English, Norwegian nynorsk, and perhaps Northern Sami.

Internationalisation will also make HDO more portable to other countries.

I suggest you use Transifex to translate to these languages from an English or Norwegian bokmål original. Ruby on rails supports i18n, and Transifex supports Ruby on rails. Transifex is also free software (GPL) and a free service.

Tasks:

• [x] UI translation
• [x] Translation platform (Transifex)
• [x] Detect user language
• [?] User language chooser
• [?] Content i18n
• [ ] Developer documentation

[jarib]

We are using Rails' i18n support (mostly) so far. Thanks for the Transifex tip!

[dittaeva]

Cool, I expect I'll look into it later on. Thanks for the chat at Goopen, I was obviously wrong about you not having thought about internationalisation as interface messages are already available in [where was it again?]

[jarib]

The file lives here. However, before starting a translation effort we should check if the organisation of translation keys actually make sense. Apart from the ActiveRecord model translations, they're quite arbitrary at the moment. I believe Rails also supports splitting these into multiple files if necessary.

[dittaeva]

Yeah. More files would probably mean more "resources" in Transifex, which complicates the translation process for the translator, though.

'time' and 'datetime' (and other localisation stuff that don't involve translating words) would normally (with django f.ex.) get pulled from some central resource, because they're the same for all projects. Perhaps RoR has something similar?

The first part of 'app' looks like it belongs in a settings file.

You should probably also try to move from using 'no' to 'nb', since 'no' is "unspecified Norwegian", while 'nb' is Norwegian bokmål and is normally what is meant. 'no' should then redirect to 'nb'. Should perhaps also think about the possibility of content language differing from interface language, though I suppose there's not that much language specific content being presented (news, updated, blog, text of promises, etc.?).

[dittaeva]

Maybe the CLDR could be helpful for 'time' and 'datetime' and such.

[jarib]

We could use Twitter's CLDR gem for that if need be.

[dittaeva]

I've set up a preliminary test project on Transifex, cloned 'no' to 'nb', 'no' to 'nn', and then did adjustments to 'nn'.

Norwegian is set up as source language, and it seems all missing english translations were pulled in from 'no', and perhaps 'en.yml' wasn't quite up to date?

You can see the changes in my fork, where you can also see the simple Transifex config. The Transifex project is currently open for anyone to translate, so you need only sign up to try it out.

[jarib]

Very nice!

You're right that en.yml hasn't been maintained.

Does this mean that we should never make changes in the .yml files directly, but always make changes in Transifex? Is there some automated way of pulling down the most recent translations?

[dittaeva]

Maintenance is easy:

1. Install the transifex client Settings are stored in .tx
2. The template should be automatically updated from git, but can also be pushed with: tx push -s
3. Push new translations (should be an exception): tx push
4. Get new translations from transifex: tx pull

Yes, translation should be kept on Transifex, or you risk overwriting. Transifex will use what it detects as the newest translation (per string), so if someone fixes a translation on Transifex on the 1st, and you make modifications to the same translations string on the 2nd, the fix from the 1st will be overwritten next time you push to Transifex. At least this is how I understand it, haven't really maintained a project on Transifex yet.

Another issue with the translation is that there are a lot of identical strings. With gettext (.po) strings are reused if they are identical, seems odd that this isn't the case here.

[dittaeva]

Just bump this thread if you'd like something to be done on this.