After a model is loaded in AB Suite, each language defined in the multi-language list should be manually changed to the correct language code. This is required because the importer is unable to guess the exact code page required.
You should complete the following steps before specifying specific translations for the model and individual reports. The translations property of the deployment folder should be reset to the correct language after replacing the translations.
For each Segment in the Model:
Double-click the Segment in Class View. This displays the Members tab for the segment.
Select the Translations tab at the bottom of the object browser.
In the lower half of the Translations view, expand the list of translations by clicking the + (the plus sign) next to the Primary translation.
For each Non-English (United States) Translation:
Right-click the translation and select Delete.
Right-click in the lower half of the Translations view and select Add Language....
In the Add Language dialog, select the desired language and locale from the lists. Ensure that the languages with more than one entry explicitly state the locale.
For example, for a French translation, select "French (France)" for the language and "1036 - French (France)" for the locale, and not just French for the language and "12 - French" for the locale.
Right-click each language in the list and rename it so that it is identical to the original translation name, including the case. This is because the language translation might have been used in some logic of the system.
Migration and Deployment Guidelines for Locales other Than English
The successful migration and deployment of non-English based applications in AB Suite depends upon the correct locale settings used throughout the process. Following are the locale guidelines for migrating the EAE .mdl file.
There are two key steps in the migration where characters are translated to and from Unicode.
– Import
– Generate/Build
In EAE, all strings, such as logic are stored as ASCII characters. If the character set is non-English, such as Vietnamese or Polish, the characters might be stored as multibyte characters, also referencing a (Windows) code page to determine the actual symbol that is displayed.
During import, the characters are converted to Unicode. The translation code needs to ascertain the character set to be used. It uses the locale of the machine where the import is taking place. If an EAE .mdl file containing Polish encoded ASCII is imported on an environment where the locale is English (not Polish), the translation of certain Polish characters appears incorrect. For example, labels in the Painter might not contain the characters originally displayed in EAE. Similarly, in the Logic Editor, constants in the code might show incorrect representations of the characters.
Any subsequent modifications to the system, such as logic or documentation update, use the locale of the environment to determine the available characters. On an English locale, it is not possible to input Polish characters. Changing the locale to Polish does not change data that is already imported. Once imported using the wrong locale, the underlying data is converted incorrectly and cannot be safely recovered. The only safe option to ensure that the data in the repository is correct is to re-import the model with a locale that matches the EAE character set.
When the system is generated to MCP, characters are translated from Unicode to ASCII and then to EBCDIC. The locale of the generating machine determines how that translation is achieved. If you use a different locale on the generating machine to the language of MCP, it results in an unpredictable behavior. The locale of the generating machine must match the system language on the MCP host.
The locales of the machines that you use throughout migration and generation are very important. It is recommended that all environments use the same locale settings, as appropriate for the language of the application.