Gettext and QT4?
Dear Lazyweb,
do you know how to translate QT4 applications with gettext? Looks like QT4 now uses it’s own mechanism (lupdate -> .ts -> linguist -> .ts -> lrelease -> .qm) for translating strings, which makes things a bit complicated if the rest of your application (the non GUI part) still uses gettext.
The background is — as some of you may have noticed — that rng’s GUI isn’t properly translated anymore since the switch from QT3 to QT4. I don’t know if I just should adopt QT4’s translation mechanism, but for now it would be very nice if I just could use my .po files for the QT4 stuff.
Tags: lazyweb, reportbug-ng
September 14th, 2008 at 2:45 pm
I then suggest you to switch to the Qt4 translation system. I know, it is not gettext (thus could look “weird”), but at least the application can be translated as a whole.
QObject.tr() is your friend
September 14th, 2008 at 3:13 pm
WTH are Qt devs smoking. I agree with pinotree though, take that bonghit too.
September 14th, 2008 at 4:30 pm
If your application is only on Qt4, I think it’ll make sense to be wholly with the qt system.
If Qt is only a part of the app, it’s doable. For example in VLC, we translate the qt gui with gettext. You’ll still need to load the qt4_*.qm to have the dialogs provided by qt translated.
September 14th, 2008 at 4:32 pm
The system is in Qt for quite some time - Qt3 certainly already had it. Nevertheless KDE 3 did use gettext and I believe still does. So I suggest looking what KDE does and doing the same.
Basically it boils down to using an option to uic (-tr) to call your method instead of tr for translating and than implementing that method on your base classes.
September 14th, 2008 at 4:48 pm
On the other hand, the Qt localization system works basically the same way as gettext. It has a function used to mark translatable strings in code, tool to extract the strings and a tool to manipulate the catalogs. The difference is format of the catalogs, but it would be easy to write a convertor if it does not exist already and the fact, that all translatable strings get name of the class they appear in as context by default (contexts are supported in newest gettext, but there is no implict context).
So if you are programming with pure Qt (rather than KDE, where you would have gettext) and aim for portability to Windows or Mac, you can consider to use the Qt system to reduce dependencies.
September 15th, 2008 at 9:11 am
My 2cts: sse Qt translation mechanism for a GUI application.
September 21st, 2008 at 4:51 am
“QT” is Quicktime by Apple, “Qt” is Qt by Trolltech.
April 25th, 2009 at 12:01 pm
gettext is better than Qt’s system - for one reason: perfect support for plural forms. I have yet to find any other translation system othet than gettext that supports plural in such perfect way (some languages have more than one plural form - so having 2 strings - singular and plural variant - to workaround this in Qt’s (and other’s) system does not work).
June 4th, 2009 at 8:16 pm
Qt l18n framework sucks ass. It has no equivalent of “dgettext” function, so it’s impossible to associate a string with a translation file. Instead it has a global list of “catalogs” (message files) that it searches in order. You have to install the catalogs explicitly at program startup. This is difficult to do in libraries since they have no entry point. And this whole idea of searching multiple files for translations is just bad because the results of the search depends on what catalogs are currently installed, which may be determined what libraries you are linked with (depending on how you do this).
KDE is only marginally better — it uses Qt API, but overloads its message lookup functions to search .mo (from gettext) files, rather than .qm (Qt Translator) files.
KDE’s translation project is a big mess in no small part due to the design of Qt API — it’s not granular, instead *all* translations for *all* KDE programs are stored/managed in one separate source package (kde-l10n or some such). So to update anything (i.e., sync PO files with source code) using their tools you have to run them on the entire KDE source tree and there’s no easy way of telling what PO file belongs to what project, etc.
Using gettext in Qt projects is problematic, too, when your project contains UI files. The code generated by UI compiler “likes” to call Qt’s translation functions for message lookups. OTOH UIC’s “-tr” parameter omits contexts in generated code. I have yet to find a good way to do this.