Slicer Internationalization

Development
1

Overview

Following conversation with @marilola that took place during the 25th Slicer project week, I am summarizing here the current state of the Slicer internationalization framework.

Prior discussion and description of the I18N framework can be found here:

Technology

Since most of the user facing strings to translate are associated with user interface components implemented using Qt, we standardized on the internationalization framework offered by Qt.

Doing so will allow to:

  • easily manage translation of strings found in Slicer code base and also the strings internally used by Qt widgets.
  • easily decouple code from translation.
  • make use of Qt linguist tooling to allow translator to easily provide translation

Relevant Qt documentation:

  • Overview: Qt4, Qt5
  • Writing Source Code for Translation: Qt4, Qt5
  • Qt Linguist Manual: Qt4, Qt5
  • Support for layout direction. See here

Considering that we actively working to use Qt5 in Slicer instead of Qt4, links for both are available.

Worth noting that Qt can also work with Localization Interchange File Format (XLIFF).

Enabling the framework

Back in 2014, we added a CMake option named Slicer_BUILD_I18N_SUPPORT allowing to build Slicer with internationalization.

When enabled, the following happen:

  • a combo box allowing to select current language will be available in the General settings
  • if not already found, translation files for languages associated with Slicer_LANGUAGES variables are generated
  • if found, translation file associated with the current language are loaded
  • a new Internalization settings panel allowing to enable/disable internalization will be available

Known limitations

Because of limitation in VTK/ITK/teem associated with the handling of locals, internationalization was disabled.

To get the full context, consider reading:

To mitigate the issue, we added the following to qSlicerCoreApplication:

https://github.com/Slicer/Slicer/blob/7914527ee7e2e434f1af98b95b17f64d3d668b57/Base/QTCore/qSlicerCoreApplication.cxx#L176-L189

In order to re-enable internationalization, we should setup dashboard on machine with different languages are confirm images are properly read.

Re-generating translation files

Once translation files exists, they can be re-generated (to capture changes in the UI) by enabling the CMake option Slicer_UPDATE_TRANSLATION.

Differences between TS and QM files

TS files

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

QM files

Qt message QM files are generated at build time based on the translation files and are the files distributed with the application and loaded at runtime.

Slicer internationalization settings

General settings: Language combo box

A combo box allowing to select the current language is available under Edit → Settings → General.

See http://www.commontk.org/docs/html/classctkLanguageComboBox.html

Internationalization settings: Enable/disable I18N support

Settings panel is available under Edit → Settings → Internationalization

Corresponding settings key used in Slicer settings file is Internationalization/Enabled.

The panel is implemented in qSlicerSettingsInternationalizationPanel.cxx and qSlicerSettingsInternationalizationPanel.ui

Suggested improvements

  • language combobox could be moved in the Internationalization settings panel

Build infrastructure

Slicer build system includes the SlicerMacroTranslation.cmake CMake module.

This module provides the following CMake macro:

SlicerMacroTranslation(
  QM_OUTPUT_DIR_VAR
  TS_DIR
  TS_BASEFILENAME
  SRCS
  UI_SRCS
  TS_LANGUAGES
  QM_OUTPUT_FILES_VAR
)

# Parameters :
#
#   SRCS ..................: All sources witch need to be translated
#
#   UI_SRCS ...............: All ui_sources witch need to be translated
#
#   TS_DIR.................: Path to the TS files
#
#   TS_BASEFILENAME........: Name of the librairi
#
#   TS_LANGUAGES...........: Variable with all the languages
#
#   QM_OUTPUT_DIR_VAR .....: Translation's dirs generated by the macro
#
#   QM_OUTPUT_FILES_VAR....: Translation's files generated by the macro
#

The macro is not used directly by module developers, instead it is indirectly used in more general Slicer CMake function used to build Slicer components (Slicer Application, Slicer library, Slicer modules, …).

Currently it is used in the following macros:

Suggested improvements

3 Likes
2

Thanks for the update and summary @jcfr.

As I have mentioned before, I think a more modest, related, but distinct task is coming up with a “how-to”/“best practices” document for module internationalization. It would be interesting to know how much we can avoid the more risky internationalization of the underlying I18N-naive C++ code and make more progress by first focusing on the UI, Qt, and Python pieces of modules.

Having a good, solid best practices guide for module development is critically important for maintaining code quality and consistency across the extended Slicer code base. Internationalization is clearly a forward-looking piece of that picture that we would like every module developer to embrace. It’s just happens to be a bonus that I18N is likely a more tractable problem at the module level than addressing and testing it across all of Slicer.

–Mike

3

Is there any solution for translation of CLIs?

Can/do we want to handle translation without first switching to Unicode? (Qt and Python has excellent Unicode support and ITK, VTK has some Unicode support, too)

Do we want to do only translation or other internationalization aspects (number format, date&time format, units, etc.) are in the scope as well?

4

Thanks for the information @jcfr

I have compiled the slicer with Slicer_BUILD_I18N_SUPPORT enabled in cmake gui but cannot see the language combobox and international panel in general settings, do I miss something to make it works?

cmake settings
image

I also check with visual studo, seems Slicer_BUILD_I18N_SUPPORT is not really enable in codes?

image
image701Ă—340 16.1 KB

Ted

5

To move forward, would be nice to review https://github.com/Slicer/SlicerGitSVNArchive/pull/898 and integrate the code allowing to streamline i18n support for python module.

Cc: @carlos-luque

1 Like