[rkward-devel] Question about plugin's translations

[Yuri Chornoivan]

написане Thu, 23 May 2013 20:51:34 +0300, Thomas Friedrichsmeier  
<thomas.friedrichsmeier at ruhr-uni-bochum.de>:

> Hi,
>
> On Thursday 23 May 2013 15:47:41 Yuri Chornoivan wrote:
>> Thu, 23 May 2013 15:36:05 +0300 було написано meik michalke
>> > RKWard plugins define their UI in XML and generate output with
>> > JavaScript, do
>> > these methods cover that as well?
>> >
>> >
>> > viele grüße :: m.eik
>>
>> I hope they should. Most of KDE Applications define UI in XML and many  
>> has
>> translatable JS parts now. So it should be feasible for RKWard. There  
>> were
>> very hard localization cases in KDE but they had found good solutions
>> until now.
>>
>> It may happen that even minimal changes can work [1].
>
> well, this really is a neglected area. Basically, what it comes down to  
> is
> - for the xml-files (and .rkh-file) gather a list of which attributes and
> contents need to be translated (mostly "label"s). Turn that into a script
> using extractrc or other techniques.
> - for the js-files: define a function i18n() in common.js, and use it  
> around
> translatable strings.
>
> After that, some - moderate - work will be needed on the C++-side to  
> actually
> look up and show the translated strings.
>
> The somewhat more difficult questions are:
> - How to make sure that the extracted .pot-file contains enough context  
> to
> make a usable translation possible? What should be extracted? Element  
> names,
> name of plugin, etc.? Is further markup needed to provide context info,
> manually?
> - What's the translation unit (for which a .pot-file should be created)?
> Single plugins? One .pluginmap? How will the translation workflow be  
> managed?

Guessing on the catalog sizes and their numbers, it would better to have  
one catalog for every pluginmap.

The structure of the translation palette can be similar to Scilab [1].

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

> 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

Can we just skip js as a first step?

Thanks for your answer.

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