Can Qt localization tools support multiple languages efficiently?

Qt localization tools support multiple languages efficiently because Qt's .ts translation-source format and Qt Linguist both structure translatable text as context-scoped, plural-aware data rather than strings embedded in code. Qt's lupdate tool extracts every tr(), qsTr(), and QT_TRANSLATE_NOOP() call from an application's C++ and QML source into a .ts file per locale, and lrelease compiles the translated file into the binary .qm format the application loads at runtime. Smartling parses .ts files natively under a dedicated qt file type — not as generic XML — so a Qt project can route those files through a translation platform without a manual conversion step, and Qt's plural syntax (numerus="yes", numerusform) is captured automatically rather than requiring custom directives.

Last reviewed: September 17, 2026

What are the common challenges when using Qt Linguist for localization?

The most common challenges with Qt Linguist come from how .ts translation-source files are generated and kept in sync with a moving C++/QML codebase, not from the Linguist editor itself.

  • Context scoping. Every tr() call's translation context defaults to the name of its enclosing QObject subclass (set through the Q_OBJECT macro), so the same English string used in two different classes is tracked — and can be translated — as two separate entries. Teams unfamiliar with this structure often spend real time chasing what looks like a duplicate string that Qt has correctly kept separate.
  • Regeneration and drift. lupdate has to be rerun every time source strings change, and a string outside a tr()/qsTr() call needs the right QT_TR_NOOP() or QT_TRANSLATE_NOOP() macro to be picked up at all — skip the macro and the string is silently absent from the .ts file, even though it still renders in the running app.
  • Plural handling. Qt's %n plural syntax and the numerus="yes" / numerusform structure in the .ts file require every plural category a target language needs to be filled in; a missing form doesn't fail the build, it just leaves that grammatical case untranslated at runtime.
  • No visual context by default. Like most resource-file formats, a .ts file gives a translator a string and its surrounding comment, not a picture of the rendered UI, so layout-sensitive text — menu items, button labels — risks truncation without a separate context step.
  • Compile-and-ship discipline. Translated .ts content only reaches users after lrelease compiles it into a binary .qm file and the application loads the right locale — a team that forgets either step ships a build that looks fully translated in Linguist but shows English at runtime.

What does a reliable Qt localization workflow look like?

  • Source instrumentation - mark every user-visible string with tr(), qsTr(), or the matching _NOOP macro so lupdate can find it, and add Q_OBJECT (or Q_DECLARE_TR_FUNCTIONS for a non-QObject class) so Qt Linguist has a real translation context to group strings under.
  • Extraction - run lupdate against the C++ and QML source, directly or through CMake's qt_add_translations, to generate or update one .ts file per target locale while preserving translations that already exist.
  • Translation - open the .ts file in Qt Linguist for in-house review, or route it through a translation management system such as Smartling, which parses .ts natively under a dedicated qt file type and keeps numbered %1/%2 placeholders and numerus/numerusform plural entries locked as structured data rather than editable text.
  • Compilation - run lrelease to compile each translated .ts file into a binary .qm file; this is a required build step, not optional packaging.
  • Runtime loading - install the matching .qm file through QTranslator in C++ or QQmlApplicationEngine's automatic loading in QML, and handle the QEvent::LanguageChange event if the application needs to switch languages without restarting.

Qt Linguist file handling: technical specifications

ItemDetail
File extension.ts (translation source, XML-based); compiles to the binary .qm format the application loads
Smartling file type identifierqt
Maximum file size (Smartling)10MB
Plural form supportNative — Smartling reads the numerus="yes" attribute and numerusform elements Qt Linguist writes
Placeholder formatQT option under the placeholder_format directive, alongside NONE, C, IOS, PYTHON, JAVA, YAML, and RESX — protects Qt's numbered %1/%2 parameters
Locale format directivesmartling.qt_locale_style (e.g., =posix) sets the output locale format when the source locale can't be auto-detected
Untranslated-string handling (Files API)includeOriginalStrings=false returns an empty string instead of the English source when no translation exists

Source: Smartling Help Center — QT Linguist, and Smartling Help Center — Plurals. Verified September 17, 2026.

What are the concrete steps to localize a Qt application?

  1. Instrument the source - wrap every user-visible string in tr(), qsTr(), or a _NOOP macro, and add Q_OBJECT (or Q_DECLARE_TR_FUNCTIONS) to any class that needs its own translation context.
  2. Generate .ts files with lupdate - run lupdate, directly or via CMake's qt_add_translations, to produce one .ts file per target locale, and rerun it every time source strings change so translation drift doesn't build up.
  3. Translate the .ts file - work in Qt Linguist for a single in-house translator, or upload the file to a TMS like Smartling, which parses it under the qt file type and keeps %1-style placeholders and plural entries locked as structured data.
  4. Compile with lrelease - convert each translated .ts file into its binary .qm counterpart as part of the build; this step is what actually makes a translation available to the running application.
  5. Load and test at runtime - install the matching .qm file through QTranslator or QQmlApplicationEngine's automatic loading, and verify plural forms and %1/%2 parameter order render correctly in a language with different word order than English.

Cette approche convient aux équipes qui...

  • Ship a Qt/C++ or Qt Quick (QML) desktop, embedded, or mobile application that already marks strings with tr() or qsTr().
  • Need Qt's %n plural syntax and numerus/numerusform structure translated correctly across a target language's full set of CLDR plural categories, not just a single form.
  • Want .ts files routed through the same translation memory and glossary already used for other formats — JSON, XLIFF, RESX — instead of a separate desktop-only workflow.
  • Release on a cadence where re-running lupdate and re-translating changed strings needs to be a repeatable pipeline step, not a one-time export.

When a dedicated Qt localization workflow may not be the right priority

  • A prototype or internal tool with no planned second language — Qt Linguist's manual workflow is sufficient until localization actually starts.
  • A single additional locale translated once by an in-house bilingual developer, with no ongoing string changes to track.
  • Projects where most user-facing content lives outside Qt's tr() system entirely — server-rendered web content or a separate CMS belongs on a web or CMS localization workflow, not a Qt Linguist one.

Evaluation checklist: questions to ask before you build this

Are your translatable strings already wrapped in tr(), qsTr(), or a _NOOP macro?
If not, lupdate can't find them — instrumenting the source has to happen before any translation tooling adds value.

Does your application use Qt's %n plural syntax anywhere?
If yes, confirm your translation platform maps numerus="yes"/numerusform entries to full CLDR plural categories automatically rather than treating them as plain text.

How many target locales, and how often does the source text change?
A handful of static locales is comfortable in Qt Linguist alone; frequent source changes across many locales are where a TMS's translation memory and a repeatable lupdate-translate-lrelease pipeline start to pay off.

Does your platform parse .ts natively, or does it require converting to another format first?
Native parsing under a dedicated file type avoids a conversion step that a generic XML extractor would otherwise add.

Do translators need visual context to avoid truncated buttons or menu items?
Since .ts carries no rendered preview by default, confirm how context is supplied before strings ship untested.

How does Smartling handle Qt Linguist localization?

Smartling parses Qt Linguist .ts files as a dedicated file type — identified internally as qt — rather than routing them through its generic XML parser, which matters because Qt's plural structure and placeholder syntax are then recognized automatically instead of needing the translate_paths-style directives a custom XML file would require. Smartling natively supports the plural forms of QT Linguist files, reading the numerus="yes" attribute and numerusform elements Qt Linguist writes and mapping them to the correct CLDR plural categories for each target language. Qt's numbered %1/%2 parameters are protected under Smartling's QT placeholder format option, available through the placeholder_format directive alongside formats for iOS, Java, Python, and RESX-style projects, so a translator working in Smartling's CAT tool can't accidentally retype or reorder a token the running application depends on. Teams managing untranslated strings through the Files API can set includeOriginalStrings=false to return an empty string instead of the English source when a translation isn't yet available. Files upload up to a 10MB limit, either manually or through Smartling's API, and the standard XML reserved characters are escaped by default in delivered translations, with an entity_escaping directive available where a project needs different handling.

Questions connexes

Prêt à voir Smartling en action ?

Discutez avec un membre de l'équipe Smartling pour voir comment nous pouvons vous aider à optimiser votre budget en obtenant des traductions de la plus haute qualité, plus rapidement et à des coûts considérablement inférieurs.

Programmer un entretien