[ckan-discuss] [ckan-dev] New i18n guidelines for CKAN

Tue Apr 8 10:32:43 UTC 2014

> One thing I always wondered (I'm not sure if this has already been
> discussed) is the usage of English as the base language in the templates.
> There is a special handling for English in the code to prevent translations
> from being loaded. First of all this is ugly if you try to provide your own
> translation for English (to change expressions etc.).
> 
> I'm a big fan of using placeholder text (instead of having {{ _('Terms of
> Use') }} use {{ _('footer.legal_requirements') }}). This mitigates the
> issue of people making assumptions about the language that is used (like
> your person/people example).
> It would make CKAN really more versatile if you would treat the English
> translation just like any other.
> 
> So for the example above you would simply provide an English translation
> with
> 
> msgid "footer.legal_requirements"
> msgstr "Terms of Use"

I like this idea. It might also give devs more of a clue about what it's
like for translators, if we have to do the English translation
ourselves.

It does seem kind of annoying that you have to come up with a unique ID
for every string though (and the possibiliy of collisions).

Sadly I think it's far too late to adopt this practice for CKAN core now
(we would have to change every string in CKAN), but for future
extensions and other projects it might be an idea.

The i18n guide has been merged now:

http://docs.ckan.org/en/latest/contributing/string-i18n.html

Changes can still be made, so any more feedback still welcome