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

[Thomas Friedrichsmeier]

Hi,

On Monday 27 October 2014 19:22:47 meik michalke wrote:
> i think i will definitely try to write my own .pot generating functions;
> looks like it's doable. the only thing i couldn't clearly find out yet is
> how i have to deal with whitepsace used for code formatting. if every tab
> must exactly match the input file, then this could be problematic, because
> you can't guess that from the XiMpLe objects -- they are only added when
> the full document tree is pasted, and that can be changed via the
> "indent.by" argument. this is only relevant to a limited number of strings
> (like values of <text> nodes), though.

Well, the good news is that most whitespace is irrelevant inside text-nodes, 
anyway. Thus, the python scripts chops away most of that in the normalize() 
function. You'd have to do the same.

(And the C++-code will have to do the same, too; it does not, yet, and so this 
is entirely untested, so far).

> would adding a pseudo function like _() be enough for gettext to get those
> strings out?

Yes, that's going to be the approach, in essence. Though I kind of like the 
i18n(), i18nc(), i18np(), i18ncp() naming scheme, more. The tougher part is 
again adding the relevant context information, making translations actually 
work, and of course adding the i18n()-markup whereever needed in the existing 
plugins.
 
> here's a JS implementation of gettext:
>  http://code.google.com/p/gettext-js/source/browse/trunk/js/gettext.js
> it uses the function _() to denote translatable strings, if i get it
> correctly.

Well, the basic paradigm is the same, but the implementation will be different 
(and rather easier): Translation lookup will be done inside the C++-code. The 
latter already knows how to deal with message catalogs, so all that's missing 
is a bit of interfacing code.

> i'll start with implementing it for pluginmaps. is there a name scheme?
> e.g., the "rkward__" with two underscores have special meaning?

Essentially just to make sure we don't interfere with any other message 
catalog that might be loaded. From the point of view of plugin developers, the 
"rkward__" is a fixed part. It is prepended to the po_id you specify.

I'd suggest the regular naming scheme for external plugins should be po_id==id 
of pluginmap.

> > 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/
> 
> where PLUGINDIR/po is the same directory with rkward__POID.pot, right?

rkward__POID.pot could be anywhere, technically, it is not used by the code. 
But yes, placing it in PLUGINDIR/po, too, makes a whole lot of sense for 
external plugins.

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/c1179788/attachment.sig>