Mark all user-visible strings as translatable in C++

[lassoan]

Summary

Many strings that are specified in C++ source files have not been marked as translatable (e.g., by using the QObject::tr method). Slicer core, CTK library, and Slicer extensions source code needs to be improved so that all translatable strings are marked as such.

Evolution of modules marking tasks

• Mark translatable strings in EventBroker module
• Mark translatable strings in Data module
• Mark translatable strings in DataProbe module
• Mark translatable strings in BaseQTGUI
• Mark translatable strings in BaseQTCore
• Mark translatable strings in BaseQTApp
• Mark translatable strings in BaseQTCli
• Mark translatable strings in Cameras module
  • remaining issues are now tracked in Combobox extra items cannot be translated #65 and Node type cannot be translated #64
• Mark translatable strings in Colors module
  • Color table names are not translatable #59
  • Help&Acknowledgement is not translated for many modules #69
• Mark translatable strings in CropVolume module
  • remaining issues are now tracked in Combobox extra items cannot be translated #65 and Node type cannot be translated #64
• Mark translatable strings in Markups module - now tracked in Mark translatable strings in Markups module #37
• Mark translatable strings in Models module - remaining issue is tracked in Help&Acknowledgement is not translated for many modules #69
• Mark translatable strings in Plots module - remaining issue is tracked in Help&Acknowledgement is not translated for many modules #69
• Mark translatable strings in Reformat module - remaining issues
  • Slice view names cannot be translated #66
  • Help&Acknowledgement is not translated for many modules #69
• Mark translatable strings in SceneViews module => now tracked in Translate Scene Views module #70
• Mark translatable strings in Segmentations module
• Mark translatable strings in SlicerWelcome module
• Mark translatable strings in SubjectHierarchy module - now tracked in Translate SubjectHierarchy module #71
• Mark translatable strings in Terminologies module
  • Help&Acknowledgement is not translated for many modules #69
  • Terminology items are not translatable #67
• Mark translatable strings in Texts module - remaining issue is tracked in Help&Acknowledgement is not translated for many modules #69
• Mark translatable strings in Transforms module
  • Help&Acknowledgement is not translated for many modules #69
  • Combobox extra items cannot be translated #65
• Mark translatable strings in Units module - remaining issue is tracked in Quantity names are not translated in application settings #68
• Mark translatable strings in ViewControllers module
  • Help&Acknowledgement is not translated for many modules #69
  • Slice view names cannot be translated #66
• Mark translatable strings in VolumeRendering module
  • remaining issue: Combobox extra items cannot be translated #65
• Mark translatable strings in Volumes module

[lassoan]

Qt seems to recommend two approaches for making tr() function available in non-QObject-based classes:

• Option A: Use Q_DECLARE_TR_FUNCTIONS(MyClass) macro (see https://doc-snapshots.qt.io/qt6-6.2/i18n-source-translation.html#translating-non-qt-classes)
• Option B: Use QSomeWidget::tr() (see https://doc-snapshots.qt.io/qt6-6.2/i18n-source-translation.html#using-tr-for-all-literal-text)

Probably option A is more clear and consistent - we can use tr() everywhere and only need to add a single line to the non-QObject-based class declaration. Of course, it would need to be tested if it indeed works as we expect.

[mhdiop]

I was wondering which approach we should use when it's about dealing with numbered arguments present on translatable strings. For example, when we have the following string :

QString("An update is available. Installed: %1. Available : %2.")
        .arg(installedVersion)
        .arg(onServerVersion);

Which translation approach should we consider ?

Option A

tr("An update is available. Installed: %1. Available: %2.")
        .arg(installedVersion)
        .arg(onServerVersion);

Option B

tr("%1 %2 %3. %4 %5.")
        .arg(tr("An update is available."))
        .arg(tr("Installed:"))
        .arg(installedVersion)
        .arg(tr("Available:"))
        .arg(onServerVersion);

Option C

tr("%1 %2. %3 %4.")
        .arg(tr("An update is available. Installed:"))
        .arg(installedVersion)
        .arg(tr("Available:"))
        .arg(onServerVersion);

The first option may be simpler and may offer more flexibility at translation time. It also offers a better context to the translation since the whole sentence is visible. However, the presence of arguments in translatable strings may not be understood by "non-tech" translators and may be mishandled.

For this, I think that, as with the & character, we can specify in the ongoing translation guide what they represent and how to handle them.

Here is another example of such strings where the text in the HTML code has numbered arguments and needs to be translated.

[lassoan]

All problems are fixed or tracked in specific issues.