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

[meik michalke]

hi,

Am Montag, 27. Oktober 2014, 16:58:38 schrieb Thomas Friedrichsmeier:
> On Monday 27 October 2014 15:07:42 meik michalke wrote:
> > 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).

yes, i was aware of that, toyed around with kbabel a long time ago... ;-)

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

i'll sure have a good look then. getting the desired attributes or child nodes 
out of the code is probably not so difficult, as both rk.JS.scan() and 
rk.rkh.scan() do exactly that already, only for different tasks. dealing with 
the JavaScript stuff later will be much more difficult, i guess.

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

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.

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

sure, that's a fallback.

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

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

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.

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

ok, that will be amongst the first things added to rkwarddev.

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

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

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

so it's "noi18n_title" there? good to know.

> i18n for internationalization, which is a word with 18 characters between i
> and n.

yeah, i knew that ;-)

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


viele grüße :: m.eik

-- 
  dipl. psych. meik michalke
  institut f"ur experimentelle psychologie
  abt. f"ur diagnostik und differentielle psychologie
  heinrich-heine-universit"at d-40204 d"usseldorf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20141027/5f83fe6a/attachment.sig>