Localization
This article describes the technical localization options of the Mobile App. Localization includes the language of the UI texts and master data, but also the formats of values such as date values. This article requires version 2.5.1 of the Mobile App and version 2.5.3 of the App Server. The current version 2.2 is required to maintain the translations via the FSM translation editor . In previous versions, the available languages, translations and formats are fixed. With the versions listed, you can add further languages or deactivate existing languages, adapt existing translations and configure the formats for the individual languages.
Configuration of the available languages and the corresponding formats
The admin configures the available languages in the Control Center on the "Synchronization / Localization" page in the "Languages" tab. The admin can release different languages for each main group. These languages are available to the technician as languages in the Mobile App (see next section Selection/definition of the app language). Define formats per language in the "Language setting" tab. The time formats (and therefore also the date + time format) each consist of a 12-hour and 24-hour format. The choice between 12 or 24-hour format is up to the technician. You only define the order of the date components (e.g. month-day-year) and separators. In the "Languages" tab, you can define the standard hour format for each language, which is used for the language if the technician has not defined an hour format himself.
Since version 2.5.1, the admin can no longer assign the app language per user in the profile settings, as the administrative effort is too high. Instead, the admin releases the selectable languages (optionally per main group).
Selection/definition of the app language
The technician selects the app language on the app settings page. The configuration of the available languages is described in the previous section. The language selected by the technician is saved in the synchronization profile so that the selection is retained after a recoupling. If the selected app language is no longer enabled, the app server automatically determines the “best possible” app language. The same also applies to the first pairing, where the technician has not previously selected an app language. The app language is determined according to the following steps, depending on the released languages:
If an app language is saved in the profile settings (usually the case after the initial setup)
Use the saved app language if enabled
Otherwise try: Use a shared language that is "related" to the saved app language. E.g. if the saved app language is "de-at" and "de" is enabled (but not de-at), "de" will be used (and vice versa).
Try an approved language that matches or is "related" to the first device language. The device language refers to the set main language of the end device, e.g. cell phone.
Otherwise, use the shared language that the admin has configured as the default language in the Control Center (on the "Synchronization / Localization" page in the "Languages" tab, depending on the main group if applicable).
In addition to the language, the user also selects the hour format. The 24-hour format and the 12-hour format (am/pm) are available for selection. In principle, the admin configures the formats depending on the language; we leave the freedom to choose between 24-hour and 12-hour format to the user, as there are no clear allocations between cultures and hour format (and may be based on user preference in English-speaking countries). The admin defines a standard default for the hour format for each released language. This default applies as long as the user does not adjust the hour format himself and thus saves the hour format in the profile settings.
Examples: If the approved app language German "de" is determined during the initial setup based on the device language, the hour format that the admin has defined for the language "de" is used. If the technician manually changes the language to "en", the hours format specified by the admin for the language "en" is used. If the technician manually changes the hour format to 12 hours and then switches back to the "de" language, the 12-hour format is retained.
Determination of translations
The app supports multi-part language codes, i.e. you can define a culture-neutral English with the language code "en", but also culture-specific subtypes such as "en-us" for American English.
Depending on the source, different spellings are used for multi-part language codes. The Mobile App supports the "-" character as a divider (not "_"). Only use lower case letters to avoid casing problems: i.e. "en-us" instead of "en-US". The Control Center interface enforces these specifications when adding additional languages.
For most use cases, the culture-neutral languages such as "en" or "de" should be sufficient. Additional culture-specific languages may be useful for the following reasons:
You want to define different formatting rules: e.g. month/day/year for American English (en-us) and day/month/year for British English (en-gb).
You want to translate (individual) translation texts differently depending on the culture, e.g. color vs. color.
If you add culture-specific languages, you do not necessarily have to duplicate the translations for all subcultures. Take advantage of the app's resolution behavior and maintain the majority of the translations in the language-neutral "en" and only deviating terms under "en-gb" and "en-us", for example. The app selects the translation according to the following steps (this applies equally to translations of master data and UI labels/texts):
Use the translation for the set app language, if available.
Use the translation for the culture-neutral language of the set app language, if available (i.e. "en" if "en-us" is set).
Use the culture-neutral English translation "en", if available.
Use the lexicographically smallest language code (for technical completeness reasons).
If you use culture-dependent languages, you do not need to release the corresponding culture-neutral language. The culture-neutral translations for the culture-dependent languages are transferred automatically. This means that if you release "en-us", translations for "en" are also transferred implicitly so that the fallback mechanism works. In this case, the culture-neutral language cannot be selected as an app language unless it is enabled, only the enabled culture-dependent languages such as "en-us".
Customizing the UI translations
It may be necessary to adapt the app's UI translation texts for various reasons. This can be the addition of a new language or just the selective adaptation of individual terms. In addition, the app already contains translations of all UI labels/texts for the following languages: German (de), English (en), Spanish (es), Dutch (nl), Portuguese (pt), French (fr), Italian (it), Chinese (zh), Bulgarian (bg). The app uses the translation texts from these supplied languages unless you overwrite the translation keys in the head office. This means that if you enable the language "en-us" and do not add any translation keys in the head office, the app uses the supplied translation texts for "en" according to the procedure described above. You can maintain the translation keys using the translation editor in FSM. The FSM saves the adapted translations in the central database and the app server transfers the adapted translations (if the language is approved) to the mobile devices via the synchronization mechanism. Your self-defined translation keys are given preference over the supplied translations. This works at translation key level, so you only need to adapt the keys that are necessary.
Assuming the app looks up the key "GLOBAL_SPARE_PARTS" and contains the translation "Material" for the supplied language "en", the following translation texts result depending on the keys maintained:
|
Maintained values at the head office |
Displayed text for en-us |
Displayed text for en-gb |
|
- |
Material (en translation supplied) |
Material (en translation supplied) |
|
en: Spare part |
Spare part |
Spare part |
|
en-us: Spare part |
Spare part |
Material (en translation supplied) |
|
en: Spare part en-us: Replacement part |
Replacement part |
Spare part (Fallback to en, as key for en-gb not available) |
Determination of master data translations
The translations of master data, such as identifiers and article descriptions, are generally determined by the app using the same fallback procedure as for UI translations. The translations come entirely from the central database and are logically not supplied, e.g. for article descriptions from the "MATARTLANG" table. Historically, master data in Innosoft is assigned to a language/culture via an integer ID - the Innosoft Language Id - or directly via the language code (in newer tables such as the report value tables). Translations of master data with language codes can be transferred 1 to 1 to the app. There are two special features to note for older master data tables with Innosoft Language Id:
The Innosoft Language Id must be transferred to a language code.
Transfer of translations without a defined language. For example, the article tables contain translation texts in the main table "MATART" with an unknown language and optionally further language-specific translations in a secondary table “MATARTLANG”, which are assigned to a language via the Innosoft Language Id.
The App Server transfers the Innosoft Language Id to a language code under which the translation is transferred to the app. This requires a bidirectional mapping between the Innosoft Language Id and the language code. The App Server loads this mapping from the "IS_LANGUAGE" table (CODE ↔ ID).
Avoid remapping language codes to other language IDs by manually adapting the table. In particular, language allocations with single-digit language IDs, such as de ↔ 0 and en ↔ 1, are often stored statically in the program code (not only in the Mobile App but also across applications), so that adapting such languages can lead to inconsistencies. The table should mainly be filled via the db migration from FSM or Classic.
It is not necessary for each released language to be assigned to a Language Id. For example, you can release the language "en-us" without "en-us" being present in IS_LANGUAGE and therefore not having an Innosoft Language Id. The culture-neutral language "en" is assigned to a Language Id (should be Language Id = 1), so that translations are pulled for "en-us" via the culture-neutral language "en" (Language Id = 1). This is usually sufficient. Texts without a defined language (e.g. MATART.DESCRIPTION) are transferred as "en" translations, as "en" can be used for any language according to the fallback rules. This is only possible if the secondary table (MATARTLANG.BEZEICHNUNG) does not already define a translation for "en".
|
Maintained values using Matart/Matartlang |
Translations on the App |
|||||||||||||||||||||||
|
As "en" is the global fallback, the app displays "screw" for each app language. |
|||||||||||||||||||||||
|
|
|||||||||||||||||||||||
|
The unknown language from MATART cannot be transferred as "en" is already assigned by MATARTLANG. |