[RFC] Future of Qt translations in KDE4

[Nicolas Goutte]

Currently for KDE4 (in tradition of KDE3), mosts of Qt's translatable messages 
are extracted (manually) for KDE and put by Scripty into the translation 
template kdelibs.pot, so that the translators can translate those messages in 
their respective kdelibs.po translation file (which is then compile in the 
respective binary (GNU MO) format kdelibs.gmo).

On the other side, Qt4 (as Qt3 does too) expects the translation in the Qt 
Linguist format and its respective binary format (which is of course not GNU 
MO). In Qt4's source, there are a few translations, however in much less 
languages than KDE has languages.

Therefore we have currently an hybrid situation: Qt expects its translation in 
its format but when KDE needs translation from a message from Qt it gets it 
from its own translation.

So the question is how we are do it in KDE4?

A few possible solutions:
- we force Qt's format and point translators to Trolltech for not-yet-existing 
translations. (This is not a translator-friendly situation).
- we force Qt's format, however KDE translators can add a translation file for 
Qt in Qt format inside KDE in case the language is not supported by KDE.
(Question: how KDE compiles this file into binary format. How is Qt going to 
find that file?)
- we use a hook in Qt to force translations in KDE's format. Question:does Qt 
support such a thing? Probably not!
- we keep the current hybrid situation, with risk of untranslated messages for 
language not supported in Qt4's source.

Notes:
- KBabel is supposed to support editing Qt Linguist files. However it was 
probably not tested in reality.
- Also other PO file editor have no Qt Linguist mode and therefore translators 
using such editors would need to use the original Qt Linguist to translate a 
Qt Linguist file.

Have a nice day!