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.
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------
_______________________________________________ RKWard-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rkward-devel
