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

[Thomas Friedrichsmeier]

Hi all!

(I've put several people in BCC who have worked on RKWard translations during 
the past year, or so; apologies if you receive this mail twice).

As most of you are aware, RKWard's plugins and help pages were not 
translatable, so far. This is finally about to change. Not everything is in 
place, yet, and it probably does not make sense to actually start translating 
anyhting, yet, but we're definitely making progress, and I'd like to ask you 
for feedback before things are finalized.

Here are my questions. First the ones where I'm hoping for feedback from 
translators, specifically:
1) I have written a custom script to extract messages from plugins and plugin 
help pages (not the .js-files, yet). This adds quite a bit of context 
information (hopefully useful) to the translated strings. Could you please 
take a look at
  http://rkward.sourceforge.net/temp/rkward__analysis.pot
? These are the messages extracted from the "analysis" plugin-map (roughly 
corresponding to the "Analysis" top-level menu). Don't start translating 
anything, yet, but please scan over the strings: Is the given context 
information readable to you? Would you like to see anything more / different / 
less?

1b) The above does not yet contain any manually added context information, 
except for two small bits that I added for testing. Naturally, at some points 
it will be necessary to add comments and contexts, manually. Little point in 
searching for all those, systematically, yet, but please do report those 
ambigous strings that come to your attention.

2) The framework for plugin translations allows us to split translations into 
pretty much as many message catalogs as we like. For external plugins, this 
will always have to be small catalogs, covering only the plugin(s) in the 
package. For the "official" plugins, we could split by .pluginmap (leading to 
seven separate catalogs + rkward.pot), or we could include everything in a 
single catalog (i.e. two catalogs in total, counting rkward.pot). More 
catalogs probably mean some more bureaucracy, and some strings will be 
duplicate across .pluginmaps. On the other hand, a split up should lead to a 
more uniform context for the strings inside, and may make it easier to make a 
useful start e.g. on translating plotting plugins, without having to be an 
expert on IRT terminology, for instance. Any preferences?

3) So you actually want to test a translation, already? Well, I told you not 
to start translating, yet. And also, not all translated strings will be shown 
translated, yet. I'm still working on that.
But here you go: Use an SVN checkout for building. Save your translated .po as 
po/plugins/rkward__analysis.xy.po (where "xy" is your language code; and yes, 
that is a double underscore, just as in the .pot file name). make && sudo make 
install . (*)

The following questions / items are primarily addressed at plugin developers:
4) For the most part, you don't have to worry much about i18n in your 
.pluginmap, .xml, and .rkh-files, as almost all relevant strings will be 
marked for translation, automatically (you will need to mark up strings 
manually in the .js files, though; more on that another time). There are some 
items that you should be aware of, though:
- In some - rare - cases, you may want to exclude a label from translation. In 
this case, write <option value="mood" no18n_label="Mood">, if that is to 
signify Mood's two sample test, for instance, rather than the state of mind. 
Note the no18n_label="XYZ", instead of label="XYZ".
- In some cases, strings - especially short ones - may be ambiguous. Consider 
two checkboxes labelled "Scale". In one case that might mean: "Show the 
scale". In another it might mean "Scale the plot". The two will probably need 
two distinct translations in some languages, but without some help from your 
side, it will be impossible to define two different translations. That help is 
that you need to add a "context" like this: <checkbox label="Scale" 
i18n_context="Scale the plot">.
- In some cases, the string is not really ambiguous, but may need an extra 
comment to make sure it is translated, correctly. You can add a message to the 
translators like this:
  <component label="Scree plot">
    <!-- i18n: No, this is _not_ a typo for screeN plot! -->
  </component>
Note that the comment is given within the XML-element holding the string in 
question, and the comment starts with "i18n:".

The difference between comment and context is that two identical strings will 
share a translation is they have different comments, but will have different 
translations, is they have a different context. If in doubt, use i18n_context.

5) There are some - hopefully rare - cases, where i18n could _break_ your 
plugin. Most importantly some controls allow you to read out the label e.g. of 
a radio option. That's ok to use, if you want to print the label in the 
output. But don't ever compare the label against a string constant in an if()-
statement or a logic control. Always use the value.

Sounds manageable so far?

Regards
Thomas

(*) Meik: I can see you worrying about installing translations for external 
plugins. No need to worry too much: Plugin translations are installed to a 
path relative to the other plugin files. So they can simply be packed into the 
inst-directory.
-------------- 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/93f4614f/attachment.sig>