[rkward-devel] i18n of plugins in rkwarddev

[Thomas Friedrichsmeier]

Hi!

On Tuesday 02 September 2014 12:58:15 meik michalke wrote:
> we discussed some plans for i18n in the past, but to my knowledge we didn't
> actually implement anything yet.

There is an absolutely minimal, not yet usable start in svn...

[not quoting all detail]

> what do you think? worth a try?

For rkwarddev-based plugins, I guess this is a very interesting option. But I 
don't think it can become "the" approach to translation in the long run. Quite 
possibly worth a try for the time being, though.

I see two basic problems:
1. Ok, when a single developer creates a bi-lingual plugin, inlining 
translations in the code may actually be a very straight-forward approach. 
When developers and translators are different persons, and/or translators are 
not too familiar with programming and programming tools, things can easily get 
messy, e.g.:
- Developer makes a change in English and German translations, but forgets to 
remove now out-dated Polish.
- Translator does not dare to touch the file, but sends list of translated 
terms to Developer. Developer screws it up, confusing some strings.

Having a message catalog separate from the code sounds like a good idea, here. 
If it's in a standard format (xgettext), this also allows to use existing 
translation tools and translation infrastructure (such as launchpad).

This may or may not be easy enough to change/add?

2. On the level of "hand-made" (non rkwarddev) plugins, having separate files 
means, any fix to a plugin would require fixing all localized versions, 
diligently. Obviously, that's just asking for trouble... For this reason, 
RKWard really needs to be able to load and use (compiled) message-catalogs at 
runtime. This _will_ happen, but of course you'll be well advised not to hold 
your breath. So your current approach may be a very useful interim solution. 
However, once I do manage to add proper i18n support inside RKWard, most of 
your code will become obsolete (work done on translations would not be wasted, 
though). So that makes it a question of how much more work you'd have to put 
in to it.

Regards
Thomas