Re: [rkward-devel] Call for feedback: Translating RKWard plugins
hi, Am Montag, 27. Oktober 2014, 13:11:40 schrieb Thomas Friedrichsmeier: please take a look at http://rkward.sourceforge.net/temp/rkward__analysis.pot so, is that basically the desired format we'd like to have for external plugins as well? i could start something like rk.i18n.scan(), then. apart from the .pot file and the new arguments to XML elements, what parts else will need changes? not entirely sure how to do it yet. but things will fall in place. 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. yes, that would be my guess. from an rkwarddev perspective, the best way would be to split by .pluginmap here. - 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. so label is omitted when no18n_ is used? is it no18n_ or noi18n_? i'm thinking about the best way to get the new arguments into the rkwarddev functions; i think the relevant functions will get a new i18n argument, which takes a list with named elements context and comment, and if it is simply set to FALSE, label will be set to no18n_label or noi18n_label, whatever it is. (*) 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. will we keep using the folder structure introduced to get my first clumsy approach going (i.e., the po directory)? viele grüße :: m.eik -- dipl. psych. meik michalke institut fur experimentelle psychologie abt. fur diagnostik und differentielle psychologie heinrich-heine-universitat d-40204 dusseldorf signature.asc Description: This is a digitally signed message part. -- ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] Call for feedback: Translating RKWard plugins
Hi, On Monday 27 October 2014 15:07:42 meik michalke wrote: Am Montag, 27. Oktober 2014, 13:11:40 schrieb Thomas Friedrichsmeier: please take a look at http://rkward.sourceforge.net/temp/rkward__analysis.pot so, is that basically the desired format we'd like to have for external plugins as well? yes. It is what translation tools like lokalize work with (try opening the file, there). Note that all those lines starting with #. are in fact comments, and do not affect the technical part of the translation process. So you would not really need character-by-character equivalence. They are important for providing translators with enough context to make sense of the strings, though. i could start something like rk.i18n.scan(), then. I'd suggest to wait a little while longer, until we have some feedback from actual experienced translators. Then, basically, you could take extract_plugin_messages.py as a template. Note that extract_plugin_messages.py uses a two-step approach: First, messages are gathered into a pseudo-source file, then xgettext is called on that file to create the .pot file. Now the .pot syntax does not look too complex, so it might be possible to do this in one pass (and without the xgettext requirement), but I was not sure enough of exactly what tricks xgettext might apply e.g. to special characters. Of course as a quick-and-dirty shortcut to getting rkwarddev prepared, you could simply call python extract_plugin_messages.py ... from R... apart from the .pot file and the new arguments to XML elements, what parts else will need changes? Well - we will need commands to mark up translatable strings in the .js-files (including scripted plugin logic). I simply haven't worried about that, yet. - .pluginmaps (in particular external ones) will need to specify an id / name for the message catalog to use, and - optionally - a location where to find it. Look at analysis.pluginmap, which currently specifies document ... po_id=analysis. That's all. not entirely sure how to do it yet. but things will fall in place. 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. yes, that would be my guess. from an rkwarddev perspective, the best way would be to split by .pluginmap here. Yes, probably, and you can simply do that. In fact, you can split pretty much any way you like, as the po_id attribute is read on any xml file, not just .pluginmaps. Not that I expect that to make much sense, though. so label is omitted when no18n_ is used? is it no18n_ or noi18n_? The other way around: If a label attribute is not found, RKWard will look for a noi18n_label attribute, next, and this won't be fed through translation. Works the same for title, BTW, on those elements that have that attribute. i18n for internationalization, which is a word with 18 characters between i and n. Sorry 'bout the typo. i'm thinking about the best way to get the new arguments into the rkwarddev functions; i think the relevant functions will get a new i18n argument, which takes a list with named elements context and comment, and if it is simply set to FALSE, label will be set to no18n_label or noi18n_label, whatever it is. Sounds reasonable. (*) 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. will we keep using the folder structure introduced to get my first clumsy approach going (i.e., the po directory)? Yes for the po directory (which is the default relative path from the pluginmap), no for everything below that. The full workflow in short: 1. Extract messages to rkward__POID.pot 2. Translate that, save as rkward__POID.de.po 3. msgfmt rkward__POID.de.po -o rkward__POID.mo 4. mv rkward__POID.mo PLUGINDIR/po/de/LC_MESSAGES/ Regards Thomas signature.asc Description: This is a digitally signed message part. -- ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] Call for feedback: Translating RKWard plugins
On Monday 27 October 2014 16:05:47 meik michalke wrote: Am Montag, 27. Oktober 2014, 13:11:40 schrieb Thomas Friedrichsmeier: The following questions / items are primarily addressed at plugin developers i have one, too ;-) how would i apply your script to an external plugin? :: m. - scripts/extract_plugin_messages.py topmost.pluginmap or - scripts/extract_plugin_messages.py *.pluginmap Note that this usage will only work if topmost.pluginmap already declares a po_id to use (which external plugins will have to do, so rkward will know which catalog to use). For testing purposes you can simply use - scripts/extract_plugin_messages.py --default_po=testing topmost.pluginmap For better integration with scripts / R commands, extract_plugin_messages.py will also accept a parameter --outdir=somewhere Regards Thomas signature.asc Description: This is a digitally signed message part. -- ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] Call for feedback: Translating RKWard plugins
написане Mon, 27 Oct 2014 14:11:40 +0200, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de: 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? Hi, Yes, it is readable for me (Lokalize and Virtaal). The hints are very useful and complete. 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? Both are good for me. Most of the current CATs have translation memory capabilities so it would be better to have translations split into separate catalogs from translation POV. On the other hand, it can make packaging harder. 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 . (*) Many thanks for your work. Does not work for me this way (even with manually copied rkward__analysis.mo), but I'm sure it should work later. Best regards, Yuri -- ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] Call for feedback: Translating RKWard plugins
hi, Am Montag, 27. Oktober 2014, 16:58:38 schrieb Thomas Friedrichsmeier: On Monday 27 October 2014 15:07:42 meik michalke wrote: so, is that basically the desired format we'd like to have for external plugins as well? yes. It is what translation tools like lokalize work with (try opening the file, there). yes, i was aware of that, toyed around with kbabel a long time ago... ;-) i could start something like rk.i18n.scan(), then. I'd suggest to wait a little while longer, until we have some feedback from actual experienced translators. Then, basically, you could take extract_plugin_messages.py as a template. i'll sure have a good look then. getting the desired attributes or child nodes out of the code is probably not so difficult, as both rk.JS.scan() and rk.rkh.scan() do exactly that already, only for different tasks. dealing with the JavaScript stuff later will be much more difficult, i guess. Now the .pot syntax does not look too complex, so it might be possible to do this in one pass (and without the xgettext requirement), but I was not sure enough of exactly what tricks xgettext might apply e.g. to special characters. i think i will definitely try to write my own .pot generating functions; looks like it's doable. the only thing i couldn't clearly find out yet is how i have to deal with whitepsace used for code formatting. if every tab must exactly match the input file, then this could be problematic, because you can't guess that from the XiMpLe objects -- they are only added when the full document tree is pasted, and that can be changed via the indent.by argument. this is only relevant to a limited number of strings (like values of text nodes), though. Of course as a quick-and-dirty shortcut to getting rkwarddev prepared, you could simply call python extract_plugin_messages.py ... from R... sure, that's a fallback. - we will need commands to mark up translatable strings in the .js-files (including scripted plugin logic). I simply haven't worried about that, yet. would adding a pseudo function like _() be enough for gettext to get those strings out? here's a JS implementation of gettext: http://code.google.com/p/gettext-js/source/browse/trunk/js/gettext.js it uses the function _() to denote translatable strings, if i get it correctly. - .pluginmaps (in particular external ones) will need to specify an id / name for the message catalog to use, and - optionally - a location where to find it. Look at analysis.pluginmap, which currently specifies document ... po_id=analysis. ok, that will be amongst the first things added to rkwarddev. yes, that would be my guess. from an rkwarddev perspective, the best way would be to split by .pluginmap here. Yes, probably, and you can simply do that. In fact, you can split pretty much any way you like, as the po_id attribute is read on any xml file, not just .pluginmaps. Not that I expect that to make much sense, though. i'll start with implementing it for pluginmaps. is there a name scheme? e.g., the rkward__ with two underscores have special meaning? so label is omitted when no18n_ is used? is it no18n_ or noi18n_? The other way around: If a label attribute is not found, RKWard will look for a noi18n_label attribute, next, and this won't be fed through translation. Works the same for title, BTW, on those elements that have that attribute. so it's noi18n_title there? good to know. i18n for internationalization, which is a word with 18 characters between i and n. yeah, i knew that ;-) 1. Extract messages to rkward__POID.pot 2. Translate that, save as rkward__POID.de.po 3. msgfmt rkward__POID.de.po -o rkward__POID.mo 4. mv rkward__POID.mo PLUGINDIR/po/de/LC_MESSAGES/ where PLUGINDIR/po is the same directory with rkward__POID.pot, right? viele grüße :: m.eik -- dipl. psych. meik michalke institut fur experimentelle psychologie abt. fur diagnostik und differentielle psychologie heinrich-heine-universitat d-40204 dusseldorf signature.asc Description: This is a digitally signed message part. -- ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] Call for feedback: Translating RKWard plugins
On Monday 27 October 2014 16:58:38 Thomas Friedrichsmeier wrote: Now the .pot syntax does not look too complex, so it might be possible to do this in one pass (and without the xgettext requirement), but I was not sure enough of exactly what tricks xgettext might apply e.g. to special characters. Well, thinking this a bit further, that would not get us very far, either. After extracting messages (xgettext) comes merging updated strings with existing translations (msgmerge), and after that comes compiling message catalogs (msgfmt). Short of replacing _all_ of these, plugin maintainers will simply have to have GNU gettext utils installed in order to provide translated / translatable plugins. So when the other day I wrote, there is no R-only solution to be had, that still stands. Regards Thomas signature.asc Description: This is a digitally signed message part. -- ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] Call for feedback: Translating RKWard plugins
Hi, thanks for your feedback! Sounds encouraging, so far. On Monday 27 October 2014 19:58:22 Yuri Chornoivan wrote: Many thanks for your work. Does not work for me this way (even with manually copied rkward__analysis.mo), but I'm sure it should work later. Oh, seems I only tested strings shown in the menu, so far. With r4966, you should see translated strings also in the dialogs (but not yet in the help pages). I'll let you know when (I think) translations are fully functional. Regards Thomas signature.asc Description: This is a digitally signed message part. -- ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] Call for feedback: Translating RKWard plugins
Hi, On Monday 27 October 2014 19:22:47 meik michalke wrote: i think i will definitely try to write my own .pot generating functions; looks like it's doable. the only thing i couldn't clearly find out yet is how i have to deal with whitepsace used for code formatting. if every tab must exactly match the input file, then this could be problematic, because you can't guess that from the XiMpLe objects -- they are only added when the full document tree is pasted, and that can be changed via the indent.by argument. this is only relevant to a limited number of strings (like values of text nodes), though. Well, the good news is that most whitespace is irrelevant inside text-nodes, anyway. Thus, the python scripts chops away most of that in the normalize() function. You'd have to do the same. (And the C++-code will have to do the same, too; it does not, yet, and so this is entirely untested, so far). would adding a pseudo function like _() be enough for gettext to get those strings out? Yes, that's going to be the approach, in essence. Though I kind of like the i18n(), i18nc(), i18np(), i18ncp() naming scheme, more. The tougher part is again adding the relevant context information, making translations actually work, and of course adding the i18n()-markup whereever needed in the existing plugins. here's a JS implementation of gettext: http://code.google.com/p/gettext-js/source/browse/trunk/js/gettext.js it uses the function _() to denote translatable strings, if i get it correctly. Well, the basic paradigm is the same, but the implementation will be different (and rather easier): Translation lookup will be done inside the C++-code. The latter already knows how to deal with message catalogs, so all that's missing is a bit of interfacing code. i'll start with implementing it for pluginmaps. is there a name scheme? e.g., the rkward__ with two underscores have special meaning? Essentially just to make sure we don't interfere with any other message catalog that might be loaded. From the point of view of plugin developers, the rkward__ is a fixed part. It is prepended to the po_id you specify. I'd suggest the regular naming scheme for external plugins should be po_id==id of pluginmap. 1. Extract messages to rkward__POID.pot 2. Translate that, save as rkward__POID.de.po 3. msgfmt rkward__POID.de.po -o rkward__POID.mo 4. mv rkward__POID.mo PLUGINDIR/po/de/LC_MESSAGES/ where PLUGINDIR/po is the same directory with rkward__POID.pot, right? rkward__POID.pot could be anywhere, technically, it is not used by the code. But yes, placing it in PLUGINDIR/po, too, makes a whole lot of sense for external plugins. Regards Thomas signature.asc Description: This is a digitally signed message part. -- ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
