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

[Stefan Oderbolz]

> 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.
>

Good point, this can help detect problems with the handling etc.


> 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).
>

Well it shouldn't be too hard, this is something you have to do for many
different things like CSS ids or classes.
Some rules would help, but I think this is manageable.


> 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.
>

I don't think it's too late. We could simply start to do this. It doesn't
mean that it has to be adapted throughout the whole code immediately.
When there is no translation available the original string is displayed
anyway. I'd vote for not treating English different.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.okfn.org/pipermail/ckan-discuss/attachments/20140409/d8087eaa/attachment.html>