[rkward-devel] Some minor issues in the plugin translation implementation

2014-12-06 Thread Yuri Chornoivan
Hi,

First of all, many thanks for making plugins translatable.

Just some minor issues that spoiled the initial implementation a bit:

1. Due to Gettext implementation, all translations with i18n_context  
cannot be loaded. Maybe it is worth to remove the context as it adds  
nothing to the translator interpretation of the messages. Examples:  
Moments submenu in the Analysis menu with context Statistics,  
against (optional) in Wilcoxon/Mann-Whitney tests window.

2. id's of radio tags translations cannot be loaded. Example: using  
test hypothesis in Wilcoxon/Mann-Whitney tests window.

Many thanks in advance for paying some attention to these issues.

Best regards,
Yuri

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
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

2014-10-27 Thread Yuri Chornoivan
написане 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] translation for rkward plugins

2014-09-24 Thread Yuri Chornoivan
написане Thu, 25 Sep 2014 04:27:35 +0300, 白杨 baiyangby...@163.com:

 Hi
 I want to do some translations for the rkward plugins, for example  
 the .pluginmap-files, the  .xml-files, the .js-files. But
 I do not how to start. Please tell me what to do and how to do. Thank  
 you.

Hi,

Please read this message:

http://sourceforge.net/p/rkward/mailman/message/32830978/

Now the translations are unsustainable, error-prone and very uncommon. I  
guess the translations should be sent as patches to the SF repo.

So I'd not recommend to translate plugins until some more sane system will  
be implemented, but it is up to you to decide.

Best regards,
Yuri

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
RKWard-devel mailing list
RKWard-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rkward-devel


[rkward-devel] On RKWard help localization

2013-10-13 Thread Yuri Chornoivan

Hi,

Attached are some scripts to extract, update and merge the translations of  
RKWard help files. The scripts need po4a installed.


./makepot.sh
   produces POT template file in locales subfolder of the /pages  
folder with rkh files.


./update.sh locale
   updates PO file in /locales or all PO files if run without argument.

./makedoc.sh locale
   produces ready to use localized docs for the given locale or for  
all available locales if run without arguments.


Proof of concept (RKWard welcome page in Ukrainian):

https://dl.dropboxusercontent.com/u/55247264/rkward_welcome_uk.png

A patch to fix typos in help is also attached.

Hope that it helps someone.

Best regards,
Yuri

makepot.sh
Description: Binary data


update.sh
Description: Binary data


makedoc.sh
Description: Binary data


typo_fix.patch
Description: Binary data
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk___
RKWard-devel mailing list
RKWard-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rkward-devel


Re: [rkward-devel] On RKWard help localization

2013-10-13 Thread Yuri Chornoivan
написане Sun, 13 Oct 2013 16:28:02 +0300, Thomas Friedrichsmeier  
thomas.friedrichsme...@ruhr-uni-bochum.de:

 Hi!

 On Sunday 13 October 2013 11:18:44 Yuri Chornoivan wrote:
 Attached are some scripts to extract, update and merge the translations  
 of
 RKWard help files. The scripts need po4a installed.

 Many thanks for this! I will definitely look into merging this into our
 sources / build process. However, I'm still terribly busy with real world
 affairs, and I'm not sure, when I will have time for this. Could you  
 open an
 RFE-ticket in our tracker, and attach your scripts, there, to make sure  
 they
 don't get lost?

 Regards
 Thomas

 P.S.: I have started working on making plugins translatable in SVN, but  
 this
 is nowhere near functional, so far. I'll keep you posted.

Hi!

Thanks for looking into this.

The ticket (sorry for the mess in the name):

https://sourceforge.net/p/rkward/feature-requests/121/

Hope this helps.

Best regards,
Yuri

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk
___
RKWard-devel mailing list
RKWard-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rkward-devel


Re: [rkward-devel] Question about plugin's translations

2013-05-24 Thread Yuri Chornoivan
написане Fri, 24 May 2013 11:09:54 +0300, Thomas Friedrichsmeier  
thomas.friedrichsme...@ruhr-uni-bochum.de:



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. Are
these 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, or

perhaps 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  
will

internally become part of the message string. If we change it, later on,
message ids will become invalid. Of course, if modern translation tools  
will

handle 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.pot


Thanks 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 in
i18n(c/p), one by one. This will be a bunch of work, but I don't expect  
any

difficult 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.  
This

is 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  
scripts

like 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


Re: [rkward-devel] Question about plugin's translations

2013-05-23 Thread Yuri Chornoivan
написане Thu, 23 May 2013 20:51:34 +0300, Thomas Friedrichsmeier  
thomas.friedrichsme...@ruhr-uni-bochum.de:



Hi,

On Thursday 23 May 2013 15:47:41 Yuri Chornoivan wrote:

Thu, 23 May 2013 15:36:05 +0300 було написано meik michalke
 RKWard plugins define their UI in XML and generate output with
 JavaScript, do
 these methods cover that as well?


 viele grüße :: m.eik

I hope they should. Most of KDE Applications define UI in XML and many  
has
translatable JS parts now. So it should be feasible for RKWard. There  
were

very hard localization cases in KDE but they had found good solutions
until now.

It may happen that even minimal changes can work [1].


well, this really is a neglected area. Basically, what it comes down to  
is

- for the xml-files (and .rkh-file) gather a list of which attributes and
contents need to be translated (mostly labels). Turn that into a script
using extractrc or other techniques.
- for the js-files: define a function i18n() in common.js, and use it  
around

translatable strings.

After that, some - moderate - work will be needed on the C++-side to  
actually

look up and show the translated strings.

The somewhat more difficult questions are:
- How to make sure that the extracted .pot-file contains enough context  
to
make a usable translation possible? What should be extracted? Element  
names,

name of plugin, etc.? Is further markup needed to provide context info,
manually?
- What's the translation unit (for which a .pot-file should be created)?
Single plugins? One .pluginmap? How will the translation workflow be  
managed?


Guessing on the catalog sizes and their numbers, it would better to have  
one catalog for every pluginmap.


The structure of the translation palette can be similar to Scilab [1].

Most of this can be adjusted later on. However, any changes to the  
extracted
context information will invalidate any translations. So at least this  
step
will require some careful thinking, preferrably by an experienced  
translator.


I guess you are talking about Rossetta feature to invalidate translations  
for one-letter changes, right? This can be mitigated by the fact that  
RKWard is likely translated by the people that are experienced in computer  
sciences and have some knowledge in translation memory and its usage. ;)



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.pot

Can we just skip js as a first step?

Thanks for your answer.

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


Re: [rkward-devel] RKWard error at the start

2013-05-09 Thread Yuri Chornoivan
написане Thu, 09 May 2013 12:34:24 +0300, Roberto Di Mari  
roberto.dim...@gmail.com:

 Hi everybody

 I have just launched R and hereafter I paste the error R displayed to me.
 My system data is: R 3.0.0, RKWard 0.5.7-2build1, all of it on Ubuntu  
 12.04.

 Connection closed unexpectedly. Last error was: QLocalSocket: Remote  
 closed

 The R backend will be shut down immediately. This means, you can not use
 any more functions that rely on it. I.e. you can do hardly anything at  
 all,
 not even save the workspace (but if you're lucky, R already did that).  
 What
 you can do, however, is save any open command-files, the output, or copy
 data out of open data editors. Quit RKWard after that.

 Since this should never happen, please write a mail to
 rkward-devel@lists.sourceforge.net, and tell us, what you were trying to
 do, when this happened. Sorry!


 No command works. I tried to fix it removing and re-installing RKWard but
 didn't work. Any help would be greatly appreciated.


 Thank you so much in advance,
 Roberto

Hi,

RKWard 0.5.7 cannot work with R 3.0.0. Please install an appropriate  
package of RKWard 0.6.1:

https://launchpad.net/~rkward-devel/+archive/rkward-stable

Best regards,
Yuri

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
___
RKWard-devel mailing list
RKWard-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rkward-devel