5.5 Multilingual Process or Function Design Considerations
The following basic guidelines apply to creating and maintaining multilingual applications:
Database Design Considerations
Understand the difference between an application system that is designed to run in different national languages and one that is designed to run in true multilingual mode.
For instance, a software company in France might develop a system that they can sell to Germans (to run in only German) and also to Italians (to run in only Italian). This is a system designed to run in different national languages.
However, a Swiss company may wish to design a system where the end user can, at execution time, elect to run the system in French, German or Italian. This is a true multilingual system.
You will need to use multilingual support in both of these situations, but the type of system you require will make a large difference to the database that you design to support it.
DBCS Considerations
It is almost impossible to use a DBCS language on a machine that does not have DBCS support installed.
The best approach is to implement the system in all other required languages and port it to a machine that does have DBCS support. Then add the DBCS language to the partition definition and enter all dictionary, multilingual variable, file, process, function and component definition DBCS information before recompiling the application.
Note that an application compiled when the current language is a DBCS language may only execute on a machine with DBCS support.
RDML and RDMLX Programming Considerations
The following considerations and guidelines apply to RDML and RDMLX development using multilingual attributes:
- Text should never be placed on screen panels. Use a field that has a multilingual variable as its default or current value.
For example:
"Key Customer Number and press Enter."
is a classical piece of text from a screen panel. In a multilingual application this text should be associated with a multilingual variables value:
DEFINE FIELD(#PANI782) TYPE(*CHAR) LENGTH(76)
OUTPUT_ATR(PBPI) DEFAULT(*MTXTPANI782)
DISPLAY FIELDS((#PANI782 *NOID *OUTPUT) etc, etc .... )
- Text should never be placed on reports. Use the same approach as recommended for screen panels.
- Never issue text messages. Use *MTXT variables or messages from user message files that are overridden by LANSA at execution time.
- Code description should be displayed using *MTXT (including field visualizations) or values retrieved from an language specific file.
- Code values are usually NOT required to be multilingual but their associated description usual is required to be multilingual. Consequently code value can be used in RDML or RDMLX code without consideration of language.
- Be as flexible as possible. For example, the following code allows YES or NO to be specified in any language. It is assumed that field #YESNO is defined in the data dictionary with multilingual labels, column headings and *MTXTYES as a default value.
REQUEST FIELD(#YESNO)
BEGINCHECK
VALUECHECK FIELD(#YESNO) WITH_LIST(*MTXTYES *MTXTNO)
MSGTXT(*MTXT12345)
ENDCHECK
IF (#YESNO = *MTXTYES)
SUBMIT ... whatever ...
ENDIF
- If you are writing applications using processes and function for languages which typically have longer phrasing, such as German and Dutch, consider using the description (*DESC) rather than labels (*LABEL) to identify information on screens or panels.