Localization
See also: Locale, Value from localization, Company specific localization
The Localization menu node combines menu items that relate to the management of localizations for the Lobster Data Platform:
The Localization entries item appears under the Localization menu node if the Role of session has the 'Administration/Configuration/Localization/Display' permission.
The Company specific localization item appears under the Localization menu node if the Role of session has the 'Administration/Configuration/Company specific localization/Display' permission.
►NOTE◄ The Localization menu node appears in the Main menu in the 'Administration' menu node if at least one child menu item is to be displayed for the Role of session.
For many texts (labels, messages, menu entries, etc.) within the Lobster Data Platform (especially for Lobster Data Platform / Orchestration functions), it is possible to assign a so-called localization instead of the default text specified in the source code, which can be used to define a specific text for different output languages.
In all relevant cases, the relevant 'text resource' is identified by a unique combination of two text values (Resource bundle, Resource name), which serves as a composite key for the assignment of localizations.
Text resources are often combined into a bundle for a specific object class. The fully qualified class name for the relevant class is then used as the text key for the Resource bundle, while the Resource name uniquely names the resource in the bundle. The name of the data field is used as the Resource name for the properties of an object. By convention, the Resource name $name identifies the resource that defines the localization for the class name.
Examples of use
Customize localizations specified by the system
CAUTION
Customizations for Localization entries have a system-wide effect and can therefore theoretically affect all users of the Lobster Data Platform. Global interventions in the system defaults for Localization always have a certain risk potential. At best, they only cause confusion. However, they can also result in difficult-to-recognize misconfigurations due to confusion and misunderstanding. Even functional consequences cannot be ruled out if the configurations deliberately or unintentionally refer to localizations, e.g. for Enumerations values.
In view of the risks mentioned, the following example should primarily be understood as a demonstration of what can be achieved.
|
The screenshot on the right shows the default localizations for the 'Date range' (DateRange) data type, which defines a straightforward data structure with three fields (start, end, timeZone). The first line (selected in the screenshot) defines the localizations for the name of the class via the Resource name $name. The text 'Date range' can be found in the 'German' and ‘Current’ column because the screenshot comes from a session for which the Locale 'German' (de) was selected as the Current locale. |
|
|
The screenshot on the right shows a section of the graphical editor for Event handling and how in this example context the system uses the localizations for the Localization entries from the DateRange bundle:
|
|
|
The screenshot on the right again shows the list of all Localization entries for the Resource bundle DateRange, but after adjustments for the Locale German (de) have been made and saved for the first three entries:
►NOTE◄ The State column now shows the value 'Database' for all adapted localizations. Only for the unchanged timeZone field is the State still 'System' (see Localization entries for details). |
|
|
The screenshot on the right shows the effect of the customizations on the image section shown above from the graphical editor for Event handling:
►NOTE◄ To reset Localization entries provided by the system for which changes have been made to the 'delivery state', it is sufficient to select the relevant entries in the overview and click on the 'Remove' ribbon button. This temporarily removes the entries from the list. After clicking 'Save' to apply the changes, the 'removed' entries reappear with the localization texts specified by the system. ►IMPORTANT◄ This procedure is only recommended if predefined entries are selected by the system. Custom entries are deleted. |
|
Custom content localization
Custom configurations or extensions to predefined structures (e.g. Enumerations) can imply additional 'localizable' content in the system.
The system often provides text fields in the relevant Input forms in which localizations for supported languages can be specified directly:
|
The screenshot on the right shows a typical layout of text fields in which localizations for supported languages (by default: English, German, French) can be entered, using the input form for Roles as an example. |
|
|
The screenshot on the right shows the localization entry that is automatically generated when the role shown above is saved in order to persist the specified localization texts in the database. ►NOTE◄ Localizations are explicitly not part of the data structure for the role, but are assigned from the Localization (Resource bundle rolename) via the 'Role name' (roleName) as a Resource name. Localization entries for such localizations (here: for Roles as 'target object') can also always be created, edited or deleted directly. ►IMPORTANT◄ An empty localization entry (see screenshot below) for a newly created 'target object' without localizations only appears in the Localization if client-side access to the target object has already been carried out in the context of the same session. |
|
|
The screenshot on the right shows an empty localization entry for a newly added role DUMMY_ROLE, for which no localizations were defined when it was created. The overview for Localization entries shows the empty entry shown directly after the role has been created, although there are no localizations and the database does not contain an entry for the Resource name DUMMY_ROLE in the Resource bundle rolename. If this session is closed without creating any localizations for the localization entry, the overview for lLocalization entries in a new session will only display the empty entry for the DUMMY_ROLE role if it has been accessed by a client at least once, e.g. because the overview for Roles has been opened and the DUMMY_ROLE role has been displayed in the list area (including paging). |
|
Special case: Define language-specific settings as a 'text module'
The 'localizations' defined by Localization or as Company specific localization do not necessarily have to be 'languages' in the sense of label texts. The functional principle can also be used to assign specific text values for the Current locale to technical parameters.
|
On the system side, this approach is used, for example, to define language-specific defaults for the formatting of certain content within the user interface (ui= user interface) via the Resource bundle lobsterui. The screenshot on the right shows the patterns predefined by the system for formatting the date (Resource name dateFormat) and time (Resource name timeFormat) for various supported languages. ►NOTE◄ Customizations for such localizations affect the formatting of corresponding data in user interfaces where no explicit formatting is applied. |
|
The Resource bundle lobsterui contains numerous other functionally effective 'localizations' that enable language-specific fine-tuning of the appearance of the user interface globally (→Localization) or depending on the Company of session (→Company specific localization).
►NOTE◄ Of course, customized 'text modules' with language-specific characteristics can also be added. Ideally, such extensions should be created with reference to an independent Resource bundle name (e.g. customParams) and not by adding fictitious Resource names to a predefined Resource bundle.