Page History
...
|
|---|
|
|
|---|
|
Initially the RDML program could be coded like this:
GROUP_
...
BY NAME(#PANEL001)
...
FIELDS(#PRODNO #PRODES #PROSDES #PRICE #STOCK)BEGIN_LOOPREQUEST 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) ENDIFEND_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_LOOPREQUEST 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) ENDIFEND_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
|
|---|
...
|
|---|
|
|---|
...
|
|---|