Wouldn't that be a sane thing anyway? I never really understood why Qt needs
to have its own, completely incompatible translation system while the rest of
the world happily uses gettext. In Quassel, this has hurt us a lot because we
cannot easily tap into existing translation teams and resources. As it turns
out (and understandably so), translation teams like that of KDE have their
established workflows centered around gettext, and are not too willing to
start using Linguist or other tools to translate an application that is Qt-
A while ago, we have tweaked Quassel's build system to accept .po files and
generate .qm files at build time from those. But this is error-prone and
requires tools (e.g. lrelease) that are not found on all systems by default.
Still, offering gettext translations has significantly increased translator
contributions for us...
This whole situation is such a mess that we actually looked into taking KDE's
i18n stuff and friends, and port it over to Qt (by way of deriving
QTranslator), just to be able to reap the benefits of KDE's translation
resources. Turned out that i18n() depends on too much of other kdelibs stuff
to make that a feasible, maintainable option though.
I really think one should look into the opportunity given to us by the move to
Qt5 to bring native gettext support to Qt, and retire the old tr() system, or
at least make it just another option. This would tremendously help Qt-based
apps to get good localization support, and even more so applications like
Quassel that can be built with and without KDE support.