[rkward-devel] i18n of plugins in rkwarddev

[Thomas Friedrichsmeier]

Hi!

On Tuesday 02 September 2014 17:29:15 meik michalke wrote:
> not neccessarily -- it depends on what file formats and structures you'd
> like to have then. i can likely tweak i18n() and the other functions into
> producing something totally different instead, so the same scripts would
> still kind of work. you'd just have to run them again.

True. I was talking about the code for generating the pluginmaps.

> i take it
> translatable strings would still need to be tagged, so some sort of i18n()
> function should to be i place there anyway.

Yes, although for the majority strings i18n would be implicit. Importantly all 
UI-labels and documentation (at some places it may make sense to allow custom 
control whether a string should be treated as translatable or not, but that's 
a detail to worry about, later). The main place to find explicit i18n() markup 
will be inside the .js-files.

_If_ you find a good way to change your approach to a separate catalog file, 
you could actually pioneer a bunch of work in this area, too. One thing that 
would remain useful, for instance, would be a function to extract 
translateable strings (in useful chunks) from .xml and .rkh files. Be sure to 
look at the work Yuri Chornoivan has already done on this: 
http://sourceforge.net/p/rkward/feature-requests/121/ .

> actually, i'm finished for the moment. the only thing missing would be
> implementing a check for the "lang"/"xml:lang" attributes in conflicting
> pluginmaps, but that would need to be done in RKWard, so i won't attempt
> that anyway ;-) even without it, you can now produce plugins in different
> languages in static format, easily.

Thinking about how to implement this, it would be rather helpful, if RKWard 
could determine the language of a pluginmap without having to parse it (both 
much easier to implement, and much faster, if there are many localizations). 
So we'd need a way to tell RKWard that a some pluginmap-files for a set of 
localized maps.

Here's a first idea for the process:
- hide the localized pluginmaps in a subdirectory
- these files would follow some specific naming convention. Easiest would be 
to have the lanuage code either at the start or at the end of the filename.
- English version (or default language version) will not include the language 
code in the filename.
- add one top-level .pluginmap, which includes the proper localized version as 
follows:
  <require localized="true" file="po/xyz.pluginmap"/>
- RKWard looks for files matching that name, and loads the one matching the 
current language, if available, or the default one.
- Earlier versions of RKWard will simply overlook the "localized"-attribute 
and thus load the default language .pluginmap, as before.

Regards
Thomas