![]() |
Home · Examples |
[Previous: Qt Linguist Manual: Translators][Qt Linguist Manual][Next: Qt Linguist Manual: TS File Format]
Support for multiple languages is extremely simple in Qt applications, and adds little overhead to the programmer's workload.
Qt minimizes the performance cost of using translations by translating the phrases for each window as they are created. In most applications the main window is created just once. Dialogs are often created once and then shown and hidden as required. Once the initial translation has taken place there is no further runtime overhead for the translated windows. Only those windows that are created, destroyed and subsequently created will have a translation performance cost.
Creating applications that can switch language at runtime is possible with Qt, but requires a certain amount of programmer intervention and will of course incur some runtime performance cost. Each piece of text that requires translating requires context to help the translator identify where in the program the text occurs. In the case of multiple identical texts that require different translations, the translator also requires some information to disambiguate the source texts. Marking text for translation will automatically cause the class name to be used as basic context information. In some cases the programmer may be required to add additional information to help the translator. If there is no translation file for the current locale the application will fall back to using the original source text. Note that if you need to programmatically add translations at runtime, you can reimplement QTranslator::translate(). During the project all the programmer must do is wrap any user-visible text in tr() calls. They should also use the two argument form for Ctrl key accelerators, or when asked by the translator for the cases where the same text translates into two different forms in the same context. The programmer should also include TRANSLATION comments to help the translator navigate the application.Making the Application Translation-Aware
Programmers should make their application look for and load the appropriate translation file and mark user-visible text and Ctrl keyboard accelerators as targets for translation. Creating Translation Files
Translation files consist of all the user-visible text and Ctrl key accelerators in an application and translations of that text. Translation files are created as follows:
For lupdate to work successfully, it must know which translation files to produce. These are listed on the command-line. See the lupdate and lrelease sections.Loading Translations
setWindowTitle(String.format(tr("Language: %1$s"), tr("English")));
Loading a new .pm file is stright-forward. For a translation-aware application a translator object is created, a translation is loaded and the translator object installed into the application.
setWindowTitle(String.format(tr("Language: %1$s"), tr("English")));
In production applications a more flexible approach, for example, loading translations according to locale, might be more appropriate. If the .ts files are all named according to a convention such as appname_locale, e.g. myapp_fr.qm, myapp_de.qm etc, then the code above will load the current locale's translation at runtime. Making the Application Translate User-Visible Strings
User-visible strings are marked as translation targets by wrapping them in a tr() call, for example:
button = new QPushButton("&Quit", this);
would become
button = new QPushButton(tr("&Quit"), this);
QtJambiObject implements the tr() function, so all QtJambiObject subclasses can contain translated strings.Distinguishing Identical Strings That Require Different Translations
The lupdate program automatically provides a context for every source text. This context is the class name of the class that contains the tr() call. This is sufficient in the vast majority of cases. Sometimes however, the translator will need further information to uniquely identify a source text; for example, a dialog that contained two separate frames, each of which contained an "Enabled" option would need each identified because in some languages the translation would differ between the two. This is easily achieved using the two argument form of the tr() call, e.g.
rbc = new QRadioButton(tr("Enabled", "Color frame"), this);
and
rbh = new QRadioButton(tr("Enabled", "Hue frame"), this);
Ctrl key accelerators are also translatable:
exitAct = new QAction(tr("E&xit"), this);
exitAct.setShortcut(tr("Ctrl+Q", "Quit"));
It is strongly recommended that the two argument form of tr() is used for Ctrl key accelerators. The second argument is the only clue the translator has as to the function performed by the accelerator.Helping the Translator with Navigation Information
In large complex applications it may be difficult for the translator to see where a particular source text comes from. This problem can be solved by adding a comment using the keyword TRANSLATOR which describes the navigation steps to reach the text in question; e.g.
TRANSLATOR FindDialog
Choose Edit|Find from the menu bar or press Ctrl+F to pop up the
Find dialog.
...
These comments are particularly useful for widget classes.Summary
At the beginning of a project add the translation source files to be used to the project file and add calls to lupdate and lrelease to the makefile.
Copyright © 2008 Trolltech
Trademarks