Multiple Language Support
The BPC supports the use of multiple languages. The language data is provided via separate language packages. The translation service can be embedded in customer-specific modules via corresponding APIs.
Selection of the active language
The current language in the client is defined at login. All currently available languages are offered in a selection dialog on the login screen. The default setting is controlled using the following criteria (descending by priority):
-
Configured language in BPC Core Services (still open)
-
Current browser language
-
German (if browser language cannot be met)
Interface description
In general, the translation of text is key-value based. This means that a translation can be offered for a "key" for each language.
Providing module-specific texts
Each frontend module can contain a JSON file for each language within its (war) package, which contains the translated text for each "key".
These files are stored in the resources/languages folder of the package.
The file name is made up of the language code according to ISO 639-1 and the extension ".json" (example de.json for German).
|
The language files can optionally be stored in both the backend and the frontend. It is advisable to place the text modules in the frontend or backend depending on their primary use. |
The keys must be unique across all modules to prevent overlaps with existing keys. It is recommended to use the ID of your own module as a prefix. Example: MODULID_MEIN_KEY.
{
"KEY1": "Text 1",
"KEY2": "Text 2",
"KEYn": "Text n"
}packages/local/demo/
├── resources/
│ ├── languages/
│ │ ├── de.json
│ │ └── en.json
└── src/
├── main.js
└── ...packages/local/MODULID/resources/languages/de.json{
"MODULID_GREETING": "Guten Tag",
"MODULID_FAREWELL": "Auf Wiedersehen",
"MODULID_THANKS": "Vielen Dank"
}packages/local/MODULID/resources/languages/en.json{
"MODULID_GREETING": "Hello",
"MODULID_FAREWELL": "Goodbye",
"MODULID_THANKS": "Thank you"
}Backend module
The language files for backend modules should be stored in the resources/languages folder within the backend package. The structure of the JSON files is identical to that of the frontend modules.
backend-module/src/main/
├── resources/
│ ├── languages/
│ │ ├── de.json
│ │ └── en.json
└── ...Consuming texts
Two options are offered for obtaining and using translated text in the GUI.
API function getTranslation
KEY → Value
The getTranslation function essentially has three different function modes. In the simplest case, a KEY is simply passed and the translation is returned. If no translation is found, the KEY is returned.
Example:
//current language is en
> BpcCommon.Api.getTranslation("CORE_ERROR")
"Fehler"
> BpcCommon.Api.getTranslation("NOT_EXISTING_KEY")
"NOT_EXISTING_KEY"
KEY → Value → Template
A template can also be specified as the translation text. This must comply with the Ext.XTemplate syntax. In this case, an object of the following type is passed to the function:
{
key: "LANGUAGE_KEY",
data: DATA_OBJECT
}
The translation text is resolved using the "key" argument and the result is transferred to an XTemplate. The template is then called with the data argument.
Example:
{
"GREETING": "Guten Tag Herr {lastName}. Darf ich {firstName} sagen?"
}
> BpcCommon.Api.getTranslation({
key:"GREETING",
data: {
firstName: "Hans",
lastName: "Mustermann"
}
);
"Guten Tag Herr Mustermann. Darf ich Hans sagen?"
TEMPLATE → KEYS
It is also possible to pass a template and several language keys. The keys are then resolved and can be used in the template. The Parameters object must look like this:
{
tpl: "XTEMPLATE_STRING",
keys: [LANGUAGE_KEY1,LANGUAGE_KEY2,LANGUAGE_KEYn]
}
Example
{
"GREEN": "grün",
"RED": "rot"
}
Object with content
AB V3.2.0
The API method can also accept an object with content for several languages and then returns the content matching the current language.
Example object:
{
"de": "grün",
"en": "green"
}
In this example, "green" (German), "green" (English) or undefined (other language) is returned depending on the language.
Singleton class
All existing translations of the current language are available via the singleton "BpcCommon.lang.Current". Where each "KEY" is available as an attribute on the singleton. In the event that no translation of the current language is available for a key, the value is equal to the key.
//current language is en BpcCommon.lang.Current.MONITOR_DELETE_FILTER_TOOLTIP
Implicit call via bind string
When "binding" within ExtJS, the "getTranslation" function can also be called implicitly. The "KEY" can be predefined or come from the result of a bound value.
(...)
viewModel: {
data: {
vmVariable: "LANGUAGE_KEY"
}
}
(...)
bind: "Statischer Text und eine Übersetzung {vmVariable:translate}",
(...)
(...)
bind: "Statischer Text und eine Übersetzung {translate:translate('LANGUAGE_KEY')",
(...)
Use of "localized" on ExtJS components
For ExtJS components, other attributes of the component (Ext.Component) can be translated via a special attribute. This is evaluated during instance creation, so that a declaration is possible before the BPC has loaded the language data. Since the function BpcCommon.Api.getTranslation is also used internally, all three function variants can also be used.
Example:
Ext.define('moduleid.Button', {
extend: 'Ext.button.Button',
localized: {
text: "BPC_ERROR",
tooltip: "BPC_BUTTON_TOOLTIP"
}
});
Ext.define('moduleid.Button', {
extend: 'Ext.button.Button',
localized: {
text: {
key: "BPC_LANGUAGE_KEY_WITH_TEMPLATE_STRING",
data: {
eins: 1,
zwei: 2
}
},
tooltip: "BPC_BUTTON_TOOLTIP"
}
});
Ext.define('moduleid.Button', {
extend: 'Ext.button.Button',
localized: {
text: "BPC_ERROR",
tooltip: {
tpl: "<h1>{BPC_ERROR}</h1>",
keys: ["BPC_ERROR"]
}
}
});
Formatting
The formatting of numbers and dates in standard ExtJS components is ensured by including the appropriate "ExtJS locale" via the BPC (see also Localization in Ext JS).
