Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Pros and cons of using gettext instead of QObject.tr() for localization of PyQt4 application?

I have couple of application written in PyQt4 where I've used standard Python gettext library for internationalization and localization of GUI. It works good for me. But I've selected gettext just because I've already had knowledge and experience of gettext usage, and zero of experience with Qt4 tr() approach.

Now I'd like to better compare both approaches and understand what I'm missing by using gettext instead of QObject.tr, and does there any serious reason why I should not use gettext for Qt4/PyQt4 applications?

In my understanding advantages of using gettext are:

  • GNU gettext is mature and it seems to be standard de-facto in GNU/Linux world.
  • There is enough special editors for PO files to simplify translators work, although textual nature of PO templates makes it not strictly necessary.
  • There is even web services available which can be used for collaborative translations.
  • gettext is standard Python library, so I don't need to install anything special to use it in runtime.
  • It has very good support for singular/plural forms selection via ngettext().

What I see as advantages of QObject.tr():

  • This is native technology for Qt4/PyQt4 so maybe it will work better/faster (although I have no data to prove).
  • The messages to translate may have additional context information which will help translators to choose the best variants for homonym words, e.g. the english word "Letter" can be translates as "Character", "Mail" or even kind of "Paper size" depending on the actual context.

What I see as disadvantages of QObject.tr() vs gettext:

  • I did not found in the Qt documentation how's supported singular/plural selection there.
  • Qt4 TS translation template is in XML format and therefore more complex to edit without special editor (QT Linguist) and it seems there is no other third-party solutions or web services. So it would require for translators to learn new tool (if they are already familiar with PO tools).

But all the items above are not critical enough to clearly say that any tool is better of other. And I don't want to start flame war about what is better because it's very subjective. I just want to know what I missing as pros and cons of QObject.tr() vs gettext.

like image 716
bialix Avatar asked Jan 07 '10 15:01

bialix


3 Answers

One simple reason to use QObject.tr() is:

It saves you the need to install gettext on Windows, making cross-platform work a bit easier. I try to have as little binary dependencies as possible on Windows.

like image 183
Christian Tismer Avatar answered Nov 08 '22 15:11

Christian Tismer


All have their pros and cons, but to define them more clearly you would have to define first if you're targeting a mobile environment or a desktop environment.

Within our company we use different methods simply because the ideal solution does not exist yet. For desktop development we're using PO files simply because the buttons are not scaled and therefore text will fit. For mobile development, the translation of a string depends on the button size which could be different on landscape and portrait devices. So this complicates it a little because a PO file can just have 1 translation of a certain word. So we selected XLIFF for this, so we could assign unique ID's to a string. This is not an easy task as well, because there are no good solutions to convert .RC files to XLIFF files. (Because current tools convert ALL strings between "" which is of course unwanted behavior). So I wrote a converter for this task.

However, when thinking of localization, then plural forms are very important so not having this is not a good localization solution. Therefore, I would say to go for PO gettext.

Greetings, Floris.

like image 2
user1813575 Avatar answered Nov 08 '22 16:11

user1813575


At the current time, Qt does not handle plural forms when you're making use of QT_TRANSLATE_NOOP

like image 2
Floris van den Hoeven Avatar answered Nov 08 '22 14:11

Floris van den Hoeven