Hi!
<--snip--->
What I am worried about is stuff like this (from your .pot file): #. i18n: tag option attribute label #. i18n: file: analysis/ansari_bradley/ansari_bradley_exact_test.xml:20 #. i18n: tag option attribute label #. i18n: file: analysis/ansari_bradley/ansari_bradley_test.xml:20 #. i18n: tag option attribute label #. i18n: file: analysis/variances/F_test.xml:16 #. i18n: tag option attribute label #. i18n: file: analysis/moments/bonett_test.xml:15 #. i18n: tag option attribute label #. i18n: file: analysis/moments/anscombe_test.xml:15 #. i18n: tag option attribute label #. i18n: file: analysis/moments/agostino_test.xml:15 #. i18n: tag option attribute label #. i18n: file: analysis/TESTS/mood_test.xml:14#: rc.cpp:1166 rc.cpp:1190 rc.cpp:1622 rc.cpp:1658 rc.cpp:1670 rc.cpp:1682#: rc.cpp:1721 msgid "greater" msgstr "" But also a few other short strings like "Never", "Start values", etc. Arethese clear enough on their own to allow a correct translation? Should each instance be translated the same (as xgettext assumes)? If not, would it help any to add context like the type of containing element, id of the element, orperhaps the title of the containing dialog as context? Should "label"- attributes be accompanied by something like an (optional) "i18ncomment"- attribute, or is this overkill?
I think it's too much overkill. Context adding is easy (as you have mentioned in 2011, it's just to add --context to the extraction command) but it is hard to use this context from the code. Let it be as is.
The problem, here, is that, as far as I am aware(!), any such context willinternally become part of the message string. If we change it, later on,message ids will become invalid. Of course, if modern translation tools willhandle this situation gracefully, it is much less of a problem.
This is not a problem at all. All modern tools has fuzzy translation mode and the context is needed for the short messages only.
> 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.potThanks a lot!
A better version of the script with almost full extraction (I hope) is attached.
A patch with fixes of typos found while inspecting the POTs can be found here:
https://dl.dropboxusercontent.com/u/55247264/typo_fix.patch Many thanks for reviewing it.
Can we just skip js as a first step?Absolutely. This should be almost entirely orthogonal to the xml-strings. For.js, I guess we'll have to look into marking up translatable strings ini18n(c/p), one by one. This will be a bunch of work, but I don't expect anydifficult questions, there.Note that there is a good deal of real-life distraction coming up ahead for me. Also I have a few started-but-unfinished development items in queue. Thisis to let you know, that if I won't start working on the C++-side,immediately, it's not for a lack of interest. Just in case, I have created a ticket to keep track of relevant bits of discussion, and of course scriptslike you provided: http://sourceforge.net/p/rkward/feature-requests/119/
Many thanks for your work. RKWard rocks! Best regards, Yuri
Messages.sh
Description: Binary data
------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
_______________________________________________ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
