Re: [rkward-devel] Call for feedback: Translating RKWard plugins
Am Montag, 27. Oktober 2014, 19:46:38 schrieb Thomas Friedrichsmeier: > Well, thinking this a bit further, that would not get us very far, either. from my perspective, it does: > After extracting messages (xgettext) comes merging updated strings with > existing translations (msgmerge), and after that comes compiling message > catalogs (msgfmt). i do not intend to re-write all of those tools. but when i am done, rkwarddev can generate a .pot file along with all the rest, without additional dependencies. at least a start for potential translators. viele grüße :: m.eik -- dipl. psych. meik michalke institut f"ur experimentelle psychologie abt. f"ur diagnostik und differentielle psychologie heinrich-heine-universit"at d-40204 d"usseldorf 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 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
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
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, 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 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 ... 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 f"ur experimentelle psychologie abt. f"ur diagnostik und differentielle psychologie heinrich-heine-universit"at d-40204 d"usseldorf 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 : > 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
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
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 . 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
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. -- dipl. psych. meik michalke institut f"ur experimentelle psychologie abt. f"ur diagnostik und differentielle psychologie heinrich-heine-universit"at d-40204 d"usseldorf 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, 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 , 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 f"ur experimentelle psychologie abt. f"ur diagnostik und differentielle psychologie heinrich-heine-universit"at d-40204 d"usseldorf 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
[rkward-devel] Call for feedback: Translating RKWard plugins
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 , 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: . - 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: 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 mu
