[rkward-devel] Call for feedback: Translating RKWard plugins

[Thomas Friedrichsmeier]

Hi,

On Monday 27 October 2014 15:07:42 meik michalke wrote:
> Am Montag, 27. Oktober 2014, 13:11:40 schrieb Thomas Friedrichsmeier:
> > please take a look at
> > 
> >   http://rkward.sourceforge.net/temp/rkward__analysis.pot
> 
> so, is that basically the desired format we'd like to have for external
> plugins as well?

yes. It is what translation tools like lokalize work with (try opening the 
file, there). Note that all those lines starting with "#." are in fact 
comments, and do not affect the technical part of the translation process. So 
you would not really need character-by-character equivalence. They are 
important for providing translators with enough context to make sense of the 
strings, though.

> i could start something like rk.i18n.scan(), then.

I'd suggest to wait a little while longer, until we have some feedback from 
actual experienced translators. Then, basically, you could take 
extract_plugin_messages.py as a template. Note that extract_plugin_messages.py 
uses a two-step approach: First, messages are gathered into a pseudo-source 
file, then xgettext is called on that file to create the .pot file.

Now the .pot syntax does not look too complex, so it might be possible to do 
this in one pass (and without the xgettext requirement), but I was not sure 
enough of exactly what tricks xgettext might apply e.g. to special characters.

Of course as a quick-and-dirty shortcut to getting rkwarddev prepared, you 
could simply call "python extract_plugin_messages.py ..." from R...

> apart
> from the .pot file and the new arguments to XML elements, what parts else
> will need changes?

Well
- we will need commands to mark up translatable strings in the .js-files 
(including scripted plugin logic). I simply haven't worried about that, yet.
- .pluginmaps (in particular external ones) will need to specify an id / name 
for the message catalog to use, and - optionally - a location where to find 
it. Look at analysis.pluginmap, which currently specifies <document ... 
po_id="analysis">.

That's all.

> not entirely sure how to do it yet. but things will fall in place.
> 
> > 2) The framework for plugin translations allows us to split translations
> > into pretty much as many message catalogs as we like. For external
> > plugins,
> > this will always have to be small catalogs, covering only the plugin(s) in
> > the package.
> 
> yes, that would be my guess. from an rkwarddev perspective, the best way
> would be to split by .pluginmap here.

Yes, probably, and you can simply do that. In fact, you can split pretty much 
any way you like, as the "po_id" attribute is read on any xml file, not just 
.pluginmaps. Not that I expect that to make much sense, though.

> so "label" is omitted when "no18n_" is used? is it "no18n_" or "noi18n_"?

The other way around: If a label attribute is not found, RKWard will look for 
a noi18n_label attribute, next, and this won't be fed through translation. 
Works the same for "title", BTW, on those elements that have that attribute.

i18n for internationalization, which is a word with 18 characters between i 
and n. Sorry 'bout the typo.
 
> i'm thinking about the best way to get the new arguments into the rkwarddev
> functions; i think the relevant functions will get a new "i18n" argument,
> which takes a list with named elements "context" and "comment", and if it is
> simply set to FALSE, "label" will be set to "no18n_label" or
> "noi18n_label", whatever it is.

Sounds reasonable.

> > (*) Meik: I can see you worrying about installing translations for
> > external
> > plugins. No need to worry too much: Plugin translations are installed to a
> > path relative to the other plugin files. So they can simply be packed into
> > the inst-directory.
> 
> will we keep using the folder structure introduced to get my first clumsy
> approach going (i.e., the "po" directory)?

Yes for the "po" directory (which is the default relative path from the 
pluginmap), no for everything below that. The full workflow in short:

1. Extract messages to rkward__POID.pot
2. Translate that, save as rkward__POID.de.po
3. msgfmt rkward__POID.de.po -o rkward__POID.mo
4. mv rkward__POID.mo PLUGINDIR/po/de/LC_MESSAGES/

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20141027/9ee42949/attachment.sig>