Home | All Classes | Main Classes | Annotated | Grouped Classes | Functions |

[Prev: Introduction] [Home] [Next: Translators]

## Release Manager

Two tools are provided for the release manager, lupdate and lrelease. These tools depend on qmake project files. You don't have to use qmake, though.

### Qt Project Files

lupdate and lrelease depend on information in the application's `.pro` Qt project file. There must be an entry in the `TRANSLATIONS` section of the project file for each language that is additional to the native language. A typical entry looks like this:

        TRANSLATIONS    = tt2_fr.ts \
                          tt2_nl.ts

Using a locale within the translation file name is useful for determining which language to load at runtime. This is explained in Chapter 4: Programmers.

An example of a complete `.pro` file with four translation source files:

        HEADERS         = main-dlg.h \
    		      options-dlg.h
        SOURCES         = main-dlg.cpp \
    		      options-dlg.cpp \
    		      main.cpp
        FORMS           = search-dlg.ui
        TRANSLATIONS    = superapp_dk.ts \
    		      superapp_fi.ts \
    		      superapp_no.ts \
    		      superapp_se.ts

QApplication::setDefaultCodec() makes it possible to choose a 8-bit encoding for literal strings that appear within `tr()` calls. If no encoding is set, `tr()` uses Latin-1.

If you use the QApplication::defaultCodec() mechanism in your application, Qt Linguist needs you to set the `DEFAULTCODEC` entry in the `.pro` file as well. For example:

        DEFAULTCODEC    = ISO-8859-5

### lupdate

Usage: `lupdate myproject.pro`

This is a simple command line tool. lupdate reads a Qt `.pro` project file and produces or updates the `.ts` translation source files listed in the project file. The translation files are given to the translator who uses Qt Linguist to read the files and insert the translations.

Companies that have their own translators in-house may find it useful to run lupdate regularly, perhaps monthly, as the application develops. This will lead to a fairly low volume of translation work spread evenly over the life of the project and will allow the translators to support a number of projects simultaneously.

Companies that hire in translators as required may prefer to run lupdate only a few times in the application's life cycle, the first time might be just before the first test phase. This will provide the translator with a substantial single block of work and any bugs that the translator detects may easily be included with those found during the initial test phase. The second and any subsequent lupdate runs would probably take place during the final beta phase.

The `.ts` file format is a simple human-readable XML format that can be used with version control systems if required.

### lrelease

Usage: `lrelease myproject.pro`

This is another simple command line tool. It reads a Qt `.pro` project file and produces the `.qm` files used by the application, one for each `.ts` translation source file listed in the project file. The `.qm` file format is a compact binary format that provides extremely fast lookups for translations.

This tool is run whenever a release of the application is to be made, from initial test version through to final release version. If the `.qm` files are not created, e.g. because an alpha release is required before any translation has been undertaken, the application will run perfectly well using the text the programmers placed in the source files. Once the `.qm` files are available the application will detect them and use them automatically.

Note that lrelease will only incorporate translations that are marked as "done". If a translation is missing, or has failed validation, the original text will be used instead.

### Missing Translations

Both lupdate and lrelease may be used with `.ts` translation source files which are incomplete. Missing translations will be replaced with the native language phrases at runtime.

[Prev: Introduction] [Home] [Next: Translators]