Using multilingual definitions in multilingual environments

Date: Archived
Product/Release: LANSA for the AS/400
Abstract: Multilingual definitions for a particular language should be typed in using a display device and keyboard descriptions set for that language
Submitted By: LANSA Technical Support

When compiling functions for multilingual applications, a separate program is created with the "local" multilingual definitions. This means that the generated multilingual program has embedded (ie. hard coded) the multilingual values for all the available languages, according to the LANSA for the AS/400 system where the function was compiled.

This approach has been taken to improve the performance of multilingual applications.

Multilingual definitions are stored in files [email protected] to [email protected] and they are retrieved "only" during compilation, not during execution. This happens regardless of the use of the *MLOPTIMISE option on the FUNCTION command. However, the *MLOPTIMISE option is still valid since it determines the way the values are stored internally in the generated RPG program (ie. initialised data structures instead of compile time arrays).

On the other hand, LANSA messages, stored in message files (eg [email protected] or [email protected]), are dynamically retrieved. This means that the LANSA messages are displayed depending on the message file available at execution time (ie. on the Run time system).

Here is a sample scenario to illustrate this issue:

An American company, with a subsidary in Japan, developed a LANSA for the AS/400 multilingual application using the American Code Page (ie 37). They wanted to run the same application at the Japanese company which had a LANSA for the AS/400 "run time only" system with no RPG compiler on it.

When entering the multilingual definitions, they used an American keyboard and display device description. They created a multilingual variable *MTXTAMOUNT with the label "AMOUNT IN $" (amount in dollars). The functions were compiled and exported.

When the application was imported and run on the Japanese machine, with Code Page 290, the multilingual variable label was displayed as "AMOUNT IN ¥" (amount in yens) instead of $, as they wanted.

Why did this happen?

Because the $ sign is actually stored as the hexadecimal value 5B which, under Code Page 290, is displayed as a yen sign.

Why is the multilingual variable label not displayed as per the LANSA for the AS/400 multilingual definitions on the Japanese machine?

Because the multilingual definitions are retrieved only when the function is compiled (ie with the American definitions).

Why did the automatic Character Code Set ID (CCSID) conversion not convert the data on the LANSA for the AS/400 files?

Because the LANSA for the AS/400 files did not pass through any automatic CCSID conversion. Any conversion of this type must be avoided using the CCSID 65535 (special non-convertible value).

How can we avoid this problem?

There are two ways to deal with this problem on the American machine:

  • If using an American keyboard and display device descriptions:

    Enter the multilingual values according to the hexadecimal value of the specific language Code Page. In this case, when entering the label of the multilingual variable for the Japanese language, type "\" (back slash) instead of "$" (because the hex value of "\" under the American Code Page is E0, and E0 is the hex value of $ under the Japanese Code Page).
  • If using a Japanese keyboard and display device descriptions:

    Enter the multilingual values directly as per the Japanese Code Page (ie 290). In this way you type $ (dollar) and it will be stored with the hexa value of E0. This is the recommended method.

What can be done if all the multilingual definitions were already typed in on the American machine?

There are two options:

  • Go back to the American machine and manually change the definitions as per 4.1 or 4.2. Then recompile all the functions and do the export/import again.
  • On the American machine, write a special conversion program (eg in RPG) to automate the hexadecimal conversions. After running this program, it will be necessary to recompile all the functions and do the export/import again. Please contact LANSA Technical Support for more information on this option.