[rkward-devel] New French translation

[Thomas Friedrichsmeier]

Hi,

On Sunday 27 November 2011, Milan Bouchet-Valat wrote:
> Le vendredi 18 novembre 2011 à 17:03 +0100, Thomas Friedrichsmeier a
> écrit :
> > 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.

ok, I've added corresponding cmake logic (which was surprisingly difficult to 
accomplish).
 
> 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>

Well, if I were to design the XML format for RKWard plugins from scratch, then 
in fact, I would make it look more like this. But changing this now would mean 
a *lot* of work, and I don't think it is anywhere near worth it.

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

Well, true, to some degree (I have not checked on the context extraction, 
yet). RKWard uses a bunch of specialized widgets (varslots, etc.), which do 
not directly correspond to Qt widget names. And also, there is extractattr, 
which extracts strings from attributes. This takes a parameter --context. So 
thinking about it, it should be quite possible to write a script which 
extracts the strings with enough context information. Ideally, I think the 
context information should contain
1. The menu label of the plugin (so translators have a clue, which stats this 
refers to).
2. A description of the role (e.g. "option label", "tab label") of the string.

2 is a bit of work, but rather trivial. 1 will mean parsing information from 
the pluginmap file. Also, strings in <include>d files will need to be handled, 
somehow, which probably means the individual xml files will have to be scanned, 
too, for includes.

Any volunteers willing to work on an initial draft of such a script? (Note: 
The script does not have to be portable, since only maintainers will need to 
run it).

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20111201/b66ceef5/attachment.sig>