Some important design considerations apply to developing truly multilingual applications. Consider the following simple sequence of screen panels representing a product inquiry:
|
|
Initially the RDML program could be coded like this:
GROUP_BY NAME(#PANEL001) FIELDS(#PRODNO #PRODES #PROSDES #PRICE #STOCK)
BEGIN_LOOP
REQUEST FIELD((#PBINST01 *OUTPUT *NOID) #PRODNO)
FETCH FIELDS(#PANEL001) FROM_FILE(PRODMST) WITH_KEY(#PRODNO)
IF_STATUS IS_NOT(*OK)
MESSAGE MSGTXT(*MTXT12347)
ELSE
DISPLAY FIELDS(#PANEL001)
ENDIF
END_LOOP
By setting up the correct multilingual attributes for this program you can instantly achieve the following variations in this program. Refer to Specifying a Field's Multilingual Attributes for details.
Execute the application in French
|
|
Execute the application in German
|
|
Notice what's wrong?
The product description and short description shown are still in English.
This simple example illustrates a very important point.
LANSA can get all the details it knows about out on the screen in the correct language, but because this is intended to be a completely multilingual program, it should have stored the product details in two separate files:
If the program was coded like this (making use of the system variable *LANGUAGE to determine the language):
GROUP_BY NAME(#PANEL001) FIELDS(#PRODNO #PRODES #PROSDES #PRICE #STOCK)
BEGIN_LOOP
REQUEST FIELD((#PBINST01 *OUTPUT *NOID) #PRODNO)
FETCH FIELDS(#PANEL001) FROM_FILE(PRODMST) WITH_KEY(#PRODNO)
FETCH FIELDS(#PANEL001) FROM_FILE(PRODLNG) WITH_KEY(*LANGUAGE #PRODNO)
IF_STATUS IS_NOT(*OK)
MESSAGE MSGTXT(*MTXT12347)
ELSE
DISPLAY FIELDS(#PANEL001)
ENDIF
END_LOOP
The result would be a true multilingual system where side by side users could be running the same program in completely different languages.
Execute the application in French
|
|
Execute the application in German
|
|
