Qt Translations

Current State

Qt uses its own native translation format. This is because back in the day gettext was not multi-platform and missed important features such as plural support. Since then gettext has gained such features but there has been no compelling reason for Qt to change to gettext.

However within free software development generally almost everyone uses gettext. Having a common format allows for sharing tools and methods.

This has led to a percieved problem that Qt isn't localisable in the same way as the bulk of other free software applications.

The Problem

There isn't a problem here. All notable applications use gettext. KDE does. PyQt applications such as our Language Selector do. C++ Qt applications such as Quassel do too. Unity-Qt is expected to use the same gettext translations as the original Unity, which makes sense since it's a reimplementation of the same UI. Scribus is the only notable application in our archive which uses Qt's translation format.

Recommendation

Implementing Launchpad support for Qt translations seems like a lot of work for one application, it's hard enough maintaining the packaging support for Launchpad Translations for gettext in KDE.

Making Qt applications use gettext is not hard, it's about 5 lines of code in PyQt and a few more in C++ (requires a QTranslator reimplementation and a call to QCoreApplication::installTranslator(). Having a page on developer.ubuntu.com with the sample code for how to use gettext in Qt would be the most practical way forward.

JonathanRiddell 2011-01-20