Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

Translations - No way to change language in runtime except with a blank string?



  • Using Qt 5.15.0, I need to create an application which supports several languages and locales. One important constraint is that these languages should be changed in runtime, without having to restart the application.

    I searched several days on the internet, and the only solution I found was to add an extra blank string on the end of each translated strings, as described in this article: https://wiki.qt.io/How_to_do_dynamic_translation_in_QML

    To be honest, I'm a little puzzled: There is no more elegant solution, even at least a macro in the qml code, to handle a such situation? Is the empty string workaround really the ONLY way to achieve a dynamic language handling? If it's the case, it's weak, because this solution causes several side effects on my interface!

    Also, what is the REAL usage of the QT_TR_NOOP serie of macros in the qml code? They are described in the documentation as macros helping to change the language dynamically, but they does nothing useful in my code. Worst, the QT_TR_N_NOOP just breaks my strings (i.e it always return an empty string and it is completely ignored when exported to the Linguist app). I assume I probably not understood something about these macros, but until now I cannot explain their real functions.

    Finally, will this situation change in future versions of Qt? Will Qt provide a real solution to change the interface language dynamically, and in runtime?


  • Moderators

    Is the empty string workaround really the ONLY way to achieve a dynamic language handling?

    No! You can retranslate whole UI without using the empty string hack: just call retranslate() on your QML engine. It is available since Qt 5.10.

    This refreshes all bindings. though (not only texts), which might be suboptimal (using empty string hack will have better performance). But best test this in your app and decide for yourself.


  • Moderators

    Is the empty string workaround really the ONLY way to achieve a dynamic language handling?

    No! You can retranslate whole UI without using the empty string hack: just call retranslate() on your QML engine. It is available since Qt 5.10.

    This refreshes all bindings. though (not only texts), which might be suboptimal (using empty string hack will have better performance). But best test this in your app and decide for yourself.



  • @sierdzio said in Translations - No way to change language in runtime except with a blank string?:

    No! You can retranslate whole UI without using the empty string hack: just call retranslate() on your QML engine. It is available since Qt 5.10.

    Wow, excellent! That's exactly what I needed. Thank you very much for this info.

    This refreshes all bindings. though (not only texts), which might be suboptimal (using empty string hack will have better performance). But best test this in your app and decide for yourself.

    On another side, using the string hack may be more complicated to maintain in a huge project (e.g easy to forget empty strings on several translations), in addition to generate several side effects in my project (e.g I see qsTr("MyCaption") + WTranslation.emptyString in every component on my designer instead of just MyCaption). So if the performance isn't too bad, I will clearly favorise this option over the string hack.


  • Moderators

    @jeanmilost said in Translations - No way to change language in runtime except with a blank string?:

    This refreshes all bindings. though (not only texts), which might be suboptimal (using empty string hack will have better performance). But best test this in your app and decide for yourself.

    On another side, using the string hack may be more complicated to maintain in a huge project (e.g easy to forget empty strings on several translations), in addition to generate several side effects in my project (e.g I see qsTr("MyCaption") + WTranslation.emptyString in every component on my designer instead of just MyCaption). So if the performance isn't too bad, I will clearly favorise this option over the string hack.

    Of course, these are good arguments.

    I don't know your project, of course, but in a general case users would not be unhappy even if language switch was slow (1-3 seconds), it should be enough to add a loading popup or something. How it will be in practice, depends of course. Depending on how screens are loaded and general app architecture, there can be thousands of active bindings, or just a few dozen. In an optimistic case reevaluation of them all will take mere miliseconds.


Log in to reply