[rkward-devel] New French translation

[Milan Bouchet-Valat]

Le vendredi 18 novembre 2011 à 17:03 +0100, Thomas Friedrichsmeier a
écrit :
> Hi,
> 
> On Friday 18 November 2011, Milan Bouchet-Valat wrote:
> > I've just finished translating RKWard to French, attached is the
> > resulting PO file. I hope that way I'll be able to suggest RKWard to
> > French R users more easily.
> 
> thanks! I have just committed this to our repository. Should be imported to 
> launchpad within a few days.
Thanks! Sorry for the late response - but I hope to give a more informed
reply that way.

> > The current French translation for RKWard was very bad, to the point I
> > think it made more harm than good to have it: very few strings were
> > translated, often with language mistakes and even a few incorrect
> > translations. Maybe it would be a good idea to avoid shipping a PO file
> > until it's known to be good enough: for having participated in the
> > French translation of Ubuntu, I know Launchpad Translations is a very
> > dangerous tool when no approved team checks for the quality of the
> > translation. Often, people come up, translate a few strings without
> > context in a very approximate way, and the aggregation of these random
> > contributions makes up a very bad PO file. Probably, the KDE translation
> > team, if willing to help, would really improve the situation - anyway,
> > that's my piece of advice. ;-)
> 
> I don't feel terribly qualified in this area. I do see your point, and in fact, 
> personally, I prefer an English desktop. One reason for that is that I tend to 
> be unsatisfied with translation quality across the board.
> 
> Anyway, for RKWard, the vast majority of translations was provided by actual 
> users of RKWard at some point of time, and in general I would think that's 
> probably the best warrant that translations will be at least mostly ok. Of 
> course, having a formal quality control would be much better - if we can get 
> that.
> 
> Perhaps as an interim solution, we could work on the assumption that any 
> translation which is very incomplete is not well-maintained, either. I.e. 
> perhaps we would only install translations which are at least 80% complete or 
> so.
> 
> Comments?
I think that's a reasonable position. Half-translated UIs can't be of
good quality anyway. And the existing translations are preserved in case
somebody wants to improve the situation for a given language.


> > Another area in which I'd be interested: is there any plan to allow
> > translating plugins? Would the gettext support present in R packages be
> > enough? Currently, the GUI is half-untranslated even with a full PO file
> > for the main app, which feels a little weird.
> 
> Overall, this would be feasible to add, and of course, it should be added, 
> eventually. The translations would actually happen in the frontend, but that's 
> merely a detail. The biggest challenge will be creating a suitable .pot file. 
> In particular:
> - Translatable strings need to be extracted for the plugin .xml, .rkh, and .js 
> files (for the .js files, translatable strings would need to be marked up by the 
> plugin developer; for the other two, it's implicit).
> - In particular for the .xml-files, it will be essential to include enough 
> context in the extracted strings to enable an adequate translation. Strings 
> there are often very short fragments.
> - Probably, one .pot file should be created per .pluginmap.
> 
> If you can provide (parts of) a solution for this, then I can probably take 
> care of implementing message lookup in the GUI within a relatively short 
> amount of time.
Indeed, the biggest part is to create proper .pot files.

For JS, it's quite easy. GNOME Shell uses gettext and it works well:
xgettext treats .js files as C files, so the only need is to use "
instead of ' for translatable strings, and to surround them with _().
Then, you need to define this function so that it calls gettext(), but
I'm not sure how you can do that in RKWard (defining this from the C++
code?). You can also somewhat create a i18n() function in JS, and tell
xgettext to detect it.

For XML, it looks like it would be more complex. As I understand it, the
current XML format for RKWard plugins wouldn't work correctly with
strings extractors. It seems that Qt's .rc and .ui files, and GTK's .ui
files use the same pattern, which is that translatable strings are
always in a tag, and never in an attribute. ATM, RKWard plugin UIs are
defined using attributes, which are not supported by intltool and
extractrc.

So I think the XML format would need to be changed so that e.g. a
dialog's title isn't defined with:
<dialog label="Two Variable t-Test">
but with:
<dialog>
  <label>"Two Variable t-Test"</label>
</dialog>

The advantage is that the syntax would be very close to what UI toolkits
do. The drawback is, well, that files have to be rewritten. ;-)

If you do this, you may gain context extraction for free, since
extractrc seems to detect common widget types and names. That would be
something to investigate, but if RKWard used standard Qt widget names in
its syntax, there would be no problem. (You can also often provide
translator comments stored in attributes, but I've not checked whether
extractrc handles this.)

But maybe there's a reason why you didn't adopt this syntax from the
start? Is it just because it's more concise?


Cheers