Translation in Qt5

[John Layt]

Hi,

This is the third email in the series of three looking at KLocale in 
Frameworks 5.  This email covers Translation.  This is a repost of a mail to 
the Qt5 list with added context for KDE.

This email is a summary of the session on Translation held at the Qt 
Contributors summit.  The session was lead by Oswald Buddenhagen (Ossi) from 
Qt.  Please note I've just retyped my rough notes, my lack of knowledge may 
lead to my misreporting important points or things Ossi said, so please check 
with him first on anything important.

* Ossi knows what needs improvement but no time to implement it.  He is 
flexible on the exact details, if someone implements it he will review it.

* Qt Linguist is in "maintenace mode", no planned updates, other tools are 
better, but does now support gettext file formats.

* In Qt5 should remove forced context from Qt to restore compatability with 
all other translation systems.

* Qt file conversion tools are now good enough to do 100% reliable 
conversions.

* Might be willing to accept .mo binary format but little real point either 
way as all available binary formats 'suck'.  Could design a new format but not 
really necessary unless worried about high performance/efficiency, and would 
just be another non-standard format. Probably best to stick with current 
format and use conversion tools to/from Gettext.

* Is XLIFF an option? v1 not really suited to software translation, v2 
currently in draft, but financial costs to get involved in standardization 
process and unlikely to be ready in time.

* New QTranslator implementation, new qtr() function in global?

* Will require old tr() and QTranslator with forced context to still be 
supported for source compatability?

* Instantiate QTranslator in QApplication, protect against mixed translations 
in case of failed load.  KDE to investigate and implement as part of 
KApplication => QApplication effort?

* New QStringFormatter to solve tr() args problem.  Community to code? [I 
don't understand the problem or solution here :-)]

* Semantic markup wanted: copy KUIT from KDE, inline markup do rewrite to 
Chusselove's revised design.

* Not yet willing to consider KDE's Transcript scripting, would prefer other 
industry solutions to be investigated first.

* Ossi to do a high-level write-up of the changes so others know what he 
wants.

* KDE to see if we have people willing to work on this

My understanding is that the outcome of all this would be that the Qt and 
Gettext workflows will become largely interchangable, with the build system 
automating any required conversions.  Normal KDE apps and libraries would keep 
our existing translation support as-is, but KDE hosted Qt-Addon libraries can 
use the Qt qtr() methods but still plug into the KDE translators without 
changing their workflow.

The big question is whether anyone has the time and interest in working on 
this?

Cheers!

John.