[rkward-devel] Question about plugin's translations

[Yuri Chornoivan]

написане Fri, 24 May 2013 11:09:54 +0300, Thomas Friedrichsmeier  
<thomas.friedrichsmeier at ruhr-uni-bochum.de>:

> Hi!
>

<--snip--->

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

I think it's too much overkill. Context adding is easy (as you have  
mentioned in 2011, it's just to add --context to the extraction command)  
but it is hard to use this context from the code. Let it be as is.

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

This is not a problem at all. All modern tools has fuzzy translation mode  
and the context is needed for the short messages only.

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

A better version of the script with almost full extraction (I hope) is  
attached.

A patch with fixes of typos found while inspecting the POTs can be found  
here:

https://dl.dropboxusercontent.com/u/55247264/typo_fix.patch

Many thanks for reviewing it.

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

Many thanks for your work. RKWard rocks!

Best regards,
Yuri
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Messages.sh
Type: application/octet-stream
Size: 1357 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20130524/a301bd18/attachment.obj>