Home/ Questions/Q 8634829
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-12T09:48:59+00:00

This question is about best practices. I am currently sticking my head into the

  • 0

This question is about best practices. I am currently sticking my head into the Qt internationalization system.

What do you use as source text in your Qt application?

  1. Do you write english text in your application code and use that one as the final language?
  2. Or do you write english text, but still setup a dedicated translation file for the english language version, so that the text in your code is never shown to a customer?
  3. Or do you use IDs in your code (e.g. “ID_ABOUT_US”), so that the language files will never “lose” translations when changing the english text?

Background: Let’s say I use english as source language and have 5 more translation files for my application. Now it turns out that the english text is not well formulated and needs to be changed. Will I run into the problem that the other 5 translations “lose” this translation then after the change, due to the heuristic approach lupdate uses? Or do you typically see this as a benefit since the translations should then be reviewed as well?

Very interested in your experiences!

Greetings,

Fabian

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    1. Yes english even if it is not your native. It’s AFAIK the only language in the world which is fully expressible with only 7-bit ASCII, hence not requiring you to juggle with source code encoding. It is also the universally understood language for human translators. However "writing" in source code means enclosing everything in tr(""), hence enabling prospective translations. In case there is no translation (no installTranslator() call), tr() is a no-op so the text will be displayed. The same applies for a missing translation of installed translator. So your translation doesn’t need to be finished, untranslated texts will be displayed in your "source code" english.

    2. "English translation" is good for one little used feature: instead of stupid "1 message(s) received" you can have correct texts for ANY plural and Qt will do it for you without any coding. Just use tr() overload with using the last numeric parameter and provide all pluralized variants in your TS file, per parameter n. No more endless if-else spaghetti and ternary operators.

      If you aim for multiple languages (i.e. not only english and something else) then setting up an "english translation" is also good for code consistency. English is treated just as another language and you switch to it the same way as any other language. If you won’t have an english translation, you would need to uninstall translator to fall back to it, and then install again for any other language. Not that it is a big problem for Qt, it’s only about the code consistency. You can do a map of [language,translator] and don’t need to treat english specially.

    3. No ids. You will find yourself developing naming conventions just to not overlap your own translations from different parts of the code. You will need to provide the mapping of ids to the readable strings to your human translators anyway. Regarding the fear of "losing the translation". If the original text changes significantly, then forcing a retranslation is a good thing. If it does not change that much, then Linguist will most probably retain it because TS file keeps a source file line too.

    When in doubt, read Qt’s internationalization guide

    • 0