[rkward-devel] Question about plugin's translations

[Thomas Friedrichsmeier]

Hi!

On Thursday 23 May 2013 23:33:03 Yuri Chornoivan wrote:
> Guessing on the catalog sizes and their numbers, it would better to have
> one catalog for every pluginmap.

Yes, I think so, too. I guess it would be really helpful to have a script that 
will extract all files used by a given .pluginmap. This could well be an R 
script using XiMpLe. Meik, I'm not sure just how much of this task you have 
already scripted in XiMpLe adn/or rkwarddev. Is this trivial, already?

> > Most of this can be adjusted later on. However, any changes to the
> > extracted
> > context information will invalidate any translations. So at least this
> > step
> > will require some careful thinking, preferrably by an experienced
> > translator.
> 
> I guess you are talking about Rossetta feature to invalidate translations
> for one-letter changes, right? This can be mitigated by the fact that
> RKWard is likely translated by the people that are experienced in computer
> sciences and have some knowledge in translation memory and its usage. ;)

What I am worried about is stuff like this (from your .pot file):

#. i18n: tag option attribute label
#. i18n: file: analysis/ansari_bradley/ansari_bradley_exact_test.xml:20
#. i18n: tag option attribute label
#. i18n: file: analysis/ansari_bradley/ansari_bradley_test.xml:20
#. i18n: tag option attribute label
#. i18n: file: analysis/variances/F_test.xml:16
#. i18n: tag option attribute label
#. i18n: file: analysis/moments/bonett_test.xml:15
#. i18n: tag option attribute label
#. i18n: file: analysis/moments/anscombe_test.xml:15
#. i18n: tag option attribute label
#. i18n: file: analysis/moments/agostino_test.xml:15
#. i18n: tag option attribute label
#. i18n: file: analysis/TESTS/mood_test.xml:14
#: rc.cpp:1166 rc.cpp:1190 rc.cpp:1622 rc.cpp:1658 rc.cpp:1670 rc.cpp:1682
#: rc.cpp:1721
msgid "greater"
msgstr ""

But also a few other short strings like "Never", "Start values", etc. Are 
these clear enough on their own to allow a correct translation? Should each 
instance be translated the same (as xgettext assumes)? If not, would it help 
any to add context like the type of containing element, id of the element, or 
perhaps the title of the containing dialog as context? Should "label"-
attributes be accompanied by something like an (optional) "i18ncomment"-
attribute, or is this overkill?

The problem, here, is that, as far as I am aware(!), any such context will 
internally become part of the message string. If we change it, later on, 
message ids will become invalid. Of course, if modern translation tools will 
handle this situation gracefully, it is much less of a problem.

> > So - if e.g. you could provide a sample .pot-file for one or two actual
> > plugins, that would be very valuable as a basis for further discussion /
> > implementation.
> 
> A test script for analysis.pluginmap is attached (has some troubles with
> extracting from .js). The results are uploaded to this file:
> 
> https://dl.dropboxusercontent.com/u/55247264/plugin_analysis.pot

Thanks a lot!

> Can we just skip js as a first step?

Absolutely. This should be almost entirely orthogonal to the xml-strings. For 
.js, I guess we'll have to look into marking up translatable strings in 
i18n(c/p), one by one. This will be a bunch of work, but I don't expect any 
difficult questions, there.

Note that there is a good deal of real-life distraction coming up ahead for 
me. Also I have a few started-but-unfinished development items in queue. This 
is to let you know, that if I won't start working on the C++-side, 
immediately, it's not for a lack of interest. Just in case, I have created a 
ticket to keep track of relevant bits of discussion, and of course scripts 
like you provided: http://sourceforge.net/p/rkward/feature-requests/119/ .

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