Multilingual Translation

1. Introduction to Multilingualism

Typically, a multilingual system includes user interface multilingualism and backend message multilingualism. In enterprise-level business systems, to facilitate multinational companies and multilingual users accessing the same data, data multilingualism support is also needed for things like country names, activity names, units of measurement names, and so on.

In OpenMeta, standard interface elements and message templates use unified translations. Interface elements such as buttons for add, edit, delete, import, export, and message templates are implemented by front-end and back-end multilingualism, respectively. Metadata stored in the database, like menu names, model and field names, are supported at the data multilingualism level.

Therefore, when adding support for a new language, it is necessary to translate both front-end and back-end languages, and also convenient data multilingual translation tools are needed.

Moreover, the symbols for multilingualism should be region-independent, for example, they should not be simplified to country names, nor is it appropriate to use national flags to represent language options.

2. Backend Message Multilingualism

Backend message multilingualism is mainly used for server-side data validation, exception prompts, and other message contents. The content and parameters of these messages are determined by the code, so these messages use standardized translations, with translation files stored in the backend multilingual resource files. New language support can be added by extending the language files.

To unify the mechanism of using backend message multilingualism and separate the development process from the translation process, OpenMeta still retains the original text in exception messages, while in the translation files, the original text directly corresponds to the translation.

2.1 Multilingual Translation

Use JSON files in the <module>.<language>.json format to define the translated text in the code. In the JSON file, original represents the original text, and translation corresponds to the translated text.

2.2 Custom Messages

When throwing exceptions or prompt messages, directly use the original text definition.

throw new BusinessException("The operator {0} does not exist", name);

Here, the exception messages support placeholder parameters, identified by numeric order, to accommodate the syntactic order of translations in different language environments.

2.3 Manually Retrieving Translations

In scenarios such as message rendering, manual text concatenation, email rendering, etc., the current or specified language’s translation can be obtained by calling static methods from the I18n.java utility class.

I18n.get("Hello world!");
I18n.get("Hello world!", Locale.SIMPLIFIED_CHINESE);
I18n.get("Hello {0} {1}", firstName, lastName)

2.4 Language Priority

1. Priority is given to the user Profile language settings as the language for the current request.

2. If the user’s language is not configured, or in the case of anonymous user access, the client language is used as the current language. Firstly, the Accept-Language header parameter is obtained. If this header parameter is absent, such as in some API call scenarios, the language parameter can be passed via a URL parameter, such as language=zh_CN.

3. When the language parameter is not recognized, the global default is to use the English language, en_US.

2.5 Translation Priority

1. Priority is given to the translation of the current language.
2. If there is no corresponding translation in the current language, the original text is returned. According to the global default language setting, the original text is generally in English.

2.6 Precautions

Exception messages thrown by dependent components may still be in the original text. Such exception messages, in most cases, are only used for troubleshooting and do not need to be thrown to the client/user. Generally, messages that need to be returned to the user should undergo multilingual translation.