-
Notifications
You must be signed in to change notification settings - Fork 183
Description
Is your feature request related to an existing module?
The candidate_parameters
module should be updated for multi-lingual support in PHP and Javascript. The module does not need to be translated immediately, but should have the infrastructure updated in such a way that it is ready to be translated.
In the future, SQL components of the module (if relevant) should also support multi-lingual.
Describe the solution you'd like
Before making a PR for multilingual support, please review
- The infrastructure changes & php examples made in [i18n] Add support for 日本語 #9747
- The Javascript code example in [candidate_list] Translate candidate_list module #9797
- The PHP code example in [i18n] Dashboard -- My Tasks #9750
PHP Info:
In PHP, any user-facing labels should be translated using the gettext library & .po files. The module should have it's own textdomain created for module-specific strings in modules/candidate_parameters/locale. For strings that are general to LORIS and used in many modules, the loris textdomain can be used which is in locale/.
Strings passed to the error log and any labels that are not user-facing do not need to be translated or have support for translation.
The pot files at the root of the locale directories are translation templates to give to translators. The locale/$lang/LC_MESSAGES/$textdomain.po file should contain the translation mapping. The .mo files are the compiled version used by the software and can be generated by running make locales
in the root directory.
Note that the format of the locale directories must be: locale/$lang/LC_MESSAGES/$textdomain.mo. We do not have any control over that. (Other then the name of the first "locale" directory, but that seems pretty standard.)
The server must have the locale installed for gettext to support the translation, not just LORIS.
Javascript Info:
JSON files are generated from the same .po files used by the PHP side of file, which are then imported into the i18next resources. They are generated at compile time with the i18next-conv package. Modules (in this case candidate_list) must call the addResourceBundle method of i18next to add the strings which are specific to their module.
The withTranslation
HOC can be used (as in the example from #9797), but functional components can also use the useTranslation
hook instead.
Additional context
View meeting notes here in the "Multilingual Design meeting agenda", as well a summary of the overall task in the "Multilingual LORIS Task Summary" tab.