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:
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_LANGUAGESvariables 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
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
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
Differences between TS and QM files
The TS file format is a simple human-readable XML format that can be used with version control systems if required
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.
Internationalization settings: Enable/disable I18N support
Settings panel is available under Edit -> Settings -> Internationalization
Corresponding settings key used in Slicer settings file is
- language combobox could be moved in the Internationalization settings panel
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:
- Update macro used to build Slicer modules (e.g SlicerMacroBuildModuleQtLibrary.cmake) to also make use of