Internationalization with Qt The internationalization of an application is the process of making
the application usable by people in countries other than one's own.
In some cases internationalization is simple, for example, making a US
application accessible to Australian or British users may require
little more than a few spelling corrections. But to make a US
application usable by Japanese users, or a Korean application usable
by German users, will require that the software operate not only in
different languages, but use different input techniques, character
encodings and presentation conventions.
Qt tries to make internationalization as painless as possible for
developers. All input widgets and text drawing methods in Qt offer
built-in support for all supported languages. The built-in font engine
is capable of correctly and attractively rendering text that contains
characters from a variety of different writing systems at the same
time.
Qt supports most languages in use today, in particular:
On Windows NT/2000/XP and Unix/X11 with Xft (client side font support)
the following languages are also supported:
Many of these writing systems exhibit special features:
Qt tries to take care of all the special features listed above. You
usually don't have to worry about these features so long as you use
Qt's input widgets (e.g. QLineEdit, QTextEdit, and derived classes)
and Qt's display widgets (e.g. QLabel).
Support for these writing systems is transparent to the programmer
and completely encapsulated in Qt's text engine. This means that you
don't need to have any knowledge about the writing system used in a
particular language, except for the following small points:
The following sections give some information on the status
of the internationalization (i18n) support in Qt.
See also the Qt Linguist manual.
Writing multi-platform international software with Qt is a gentle,
incremental process. Your software can become internationalized in
the following stages:
Since QString uses the Unicode encoding internally, every
language in the world can be processed transparently using
familiar text processing operations. Also, since all Qt
functions that present text to the user take a QString as a
parameter, there is no char* to QString conversion overhead.
Strings that are in "programmer space" (such as QObject names
and file format texts) need not use QString; the traditional
char* or the QCString class will suffice.
You're unlikely to notice that you are using Unicode;
QString, and QChar are just like easier versions of the crude
const char* and char from traditional C.
Wherever your program uses "quoted text" for text that will
be presented to the user, ensure that it is processed by the QApplication::translate() function. Essentially all that is necessary
to achieve this is to use QObject::tr(). For example, assuming the
LoginWidget is a subclass of QWidget:
This accounts for 99% of the user-visible strings you're likely to
write.
If the quoted text is not in a member function of a
QObject subclass, use either the tr() function of an
appropriate class, or the QApplication::translate() function
directly:
If you need to have translatable text completely
outside a function, there are two macros to help: QT_TR_NOOP()
and QT_TRANSLATE_NOOP(). They merely mark the text for
extraction by the lupdate utility described below.
The macros expand to just the text (without the context).
Example of QT_TR_NOOP():
Example of QT_TRANSLATE_NOOP():
If you disable the const char* to QString automatic conversion
by compiling your software with the macro QT_NO_CAST_ASCII
defined, you'll be very likely to catch any strings you are
missing. See QString::fromLatin1() for more information.
Disabling the conversion can make programming a bit cumbersome.
If your source language uses characters outside Latin-1, you
might find QObject::trUtf8() more convenient than
QObject::tr(), as tr() depends on the
QApplication::defaultCodec(), which makes it more fragile than
QObject::trUtf8().
Accelerator values such as Ctrl+Q or Alt+F need to be
translated too. If you hardcode CTRL+Key_Q for "Quit" in
your application, translators won't be able to override
it. The correct idiom is
The QString::arg() functions offer a simple means for substituting
arguments:
In some languages the order of arguments may need to change, and this
can easily be achieved by changing the order of the % arguments. For
example:
produces the correct output in English and Norwegian:
Once you are using tr() throughout an application, you can start
producing translations of the user-visible text in your program.
Qt Linguist's manual provides
further information about Qt's translation tools, Qt Linguist, lupdate and lrelease.
Translation of a Qt application is a three-step process:
Typically, you will repeat these steps for every release of your
application. The lupdate utility does its best to reuse the
translations from previous releases.
Before you run lupdate, you should prepare a project file. Here's
an example project file (.pro file):
When you run lupdate or lrelease, you must give the name of the
project file as a command-line argument.
In this example, four exotic languages are supported: Danish, Finnish,
Norwegian and Swedish. If you use qmake, you usually don't need an extra project
file for lupdate; your qmake project file will work fine once
you add the TRANSLATIONS entry.
In your application, you must QTranslator::load() the translation
files appropriate for the user's language, and install them using QApplication::installTranslator().
If you have been using the old Qt tools (findtr, msg2qm and mergetr), you can use qm2ts to convert your old .qm files.
linguist, lupdate and lrelease are installed in the bin
subdirectory of the base directory Qt is installed into. Click Help|Manual
in Qt Linguist to access the user's manual; it contains a tutorial
to get you started.
While these utilities offer a convenient way to create .qm files,
any system that writes .qm files is sufficient. You could make an
application that adds translations to a QTranslator with
QTranslator::insert() and then writes a .qm file with
QTranslator::save(). This way the translations can come from any
source you choose.
Typically, your application's main() function will look like this:
The QTextCodec class and the facilities in QTextStream make it easy to
support many input and output encodings for your users' data. When an
application starts, the locale of the machine will determine the 8-bit
encoding used when dealing with 8-bit data: such as for font
selection, text display, 8-bit text I/O and character input.
The application may occasionally require encodings other than the
default local 8-bit encoding. For example, an application in a
Cyrillic KOI8-R locale (the de-facto standard locale in Russia) might
need to output Cyrillic in the ISO 8859-5 encoding. Code for this
would be:
For converting Unicode to local 8-bit encodings, a shortcut is
available: the local8Bit() method
of QString returns such 8-bit data. Another useful shortcut is the
utf8() method, which returns text in the
8-bit UTF-8 encoding: this perfectly preserves Unicode information
while looking like plain US-ASCII if the text is wholly US-ASCII.
For converting the other way, there are the QString::fromUtf8() and
QString::fromLocal8Bit() convenience functions, or the general code,
demonstrated by this conversion from ISO 8859-5 Cyrillic to Unicode
conversion:
Ideally Unicode I/O should be used as this maximizes the portability
of documents between users around the world, but in reality it is
useful to support all the appropriate encodings that your users will
need to process existing documents. In general, Unicode (UTF-16 or
UTF-8) is best for information transferred between arbitrary people,
while within a language or national group, a local standard is often
more appropriate. The most important encoding to support is the one
returned by QTextCodec::codecForLocale(), as this is the one the user
is most likely to need for communicating with other people and
applications (this is the codec used by local8Bit()).
Qt supports most of the more frequently used encodings natively. For a
complete list of supported encodings see the QTextCodec
documentation.
In some cases and for less frequently used encodings it may be
necessary to write your own QTextCodec subclass. Depending on the
urgency, it may be useful to contact Trolltech technical support or
ask on the qt-interest mailing list to see if someone else is
already working on supporting the encoding. A useful interim measure
can be to use the QTextCodec::loadCharmapFile() function to build a
data-driven codec, although this approach has a memory and speed
penalty, especially with dynamically loaded libraries. For details of
writing your own QTextCodec, see the main QTextCodec class
documentation.
Localization is the process of adapting to local conventions, for
example presenting dates and times using the locally preferred
formats. Such localizations can be accomplished using appropriate tr()
strings.
In the example, for the US we would leave the translation of "AMPM" as
it is and thereby use the 12-hour clock branch; but in Europe we would
translate it as something else (anything else, e.g. "EU") and this
will make the code use the 24-hour clock branch.
Localizing images is not recommended. Choose clear icons that are
appropriate for all localities, rather than relying on local puns or
stretched metaphors.
Some of the operating systems and windowing systems that Qt runs on
only have limited support for Unicode. The level of support available
in the underlying system has some influence on the support that Qt can
provide on those platforms, although in general Qt applications need
not be too concerned with platform-specific limitations.
Many Unix distributions contain only partial support for some locales.
For example, if you have a /usr/share/locale/ja_JP.EUC directory,
this does not necessarily mean you can display Japanese text; you also
need JIS encoded fonts (or Unicode fonts), and the /usr/share/locale/ja_JP.EUC directory needs to be complete. For best
results, use complete locales from your system vendor.
These classes are relevant to internationalizing Qt applications.
|
Publicité
Best OfActualités les plus luesSemaine
Mois
Année
Le blog Digia au hasardDéploiement d'applications Qt Commercial sur les tablettes Windows 8Le blog Digia est l'endroit privilégié pour la communication sur l'édition commerciale de Qt, où des réponses publiques sont apportées aux questions les plus posées au support. Lire l'article.
CommunautéRessources
Liens utilesContact
Qt dans le magazine |
Cette page est une traduction d'une page de la documentation de Qt, écrite par Nokia Corporation and/or its subsidiary(-ies). Les éventuels problèmes résultant d'une mauvaise traduction ne sont pas imputables à Nokia. | Qt 3.2 | |
Copyright © 2012 Developpez LLC. Tous droits réservés Developpez LLC. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents et images sans l'autorisation expresse de Developpez LLC. Sinon, vous encourez selon la loi jusqu'à 3 ans de prison et jusqu'à 300 000 E de dommages et intérêts. Cette page est déposée à la SACD. | ||
Vous avez déniché une erreur ? Un bug ? Une redirection cassée ? Ou tout autre problème, quel qu'il soit ? Ou bien vous désirez participer à ce projet de traduction ? N'hésitez pas à nous contacter ou par MP ! |
Copyright © 2000-2012 - www.developpez.com