Skip to content

[candidate_parameters] Multilingual Support #9815

@CamilleBeau

Description

@CamilleBeau

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

  1. The infrastructure changes & php examples made in [i18n] Add support for 日本語 #9747
  2. The Javascript code example in [candidate_list] Translate candidate_list module #9797
  3. 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.

Metadata

Metadata

Assignees

Labels

Category: FeaturePR or issue that aims to introduce a new featureEvent: GSOCPR or issue accepted for Google Summer of CodeLanguage: JavascriptPR or issue that update Javascript codeLanguage: PHPPR or issue that update PHP codeModule: candidate_parametersPR or issue related to candidate_parameters moduleMultilingualAny tasks related to making LORIS multilingualProposalPR or issue suggesting an improvement that can be accepted, rejected or altered

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions