When developing or executing a multilingual application in LANSA you are required to have a Client PC with an Operating System running under the language you wish to develop or execute your application.
The reason for this is that you need a keyboard that can produce all the characters for the language and you need the Windows System Codepage to match the language you are entering.
The Visual LANSA Editor allows all languages to be entered on a machine of any language, provided operating system support for that language has been installed.
When executing an application, note that only data that matches the Windows System Codepage can be displayed correctly, unless NCharNChar and NVarChar fields are being used. If a database contains Chinese and English data in one NChar column of different rows, both languages will display correctly on a form. However, Multilingual Variables will only display correctly if the LANG= parameter is appropriate for the language the PC is using.
For data stored in Alpha, String or Char fields, some languages CAN co-exist. These are languages that share the same codepage. For example, English and French both use codepage 1252. Thus French and English data in one String column of different rows will BOTH be able to be displayed on BOTH French and English PCs.
But in general, data needs to either all be in the same language, it needs to be keyed by language, or it needs to be stored in an NChar or NVarChar.
Also note that there are a set of characters that are invariant on all Windows codepages. These WILL display correctly in all languages. The code range is 0x20 to 0x7F. This contains principally the English alphabet, numbers and punctuation. It may suit the design of an application to limit data entry to these characters, and just have the Field Descriptions, Multilingual text variables, etc displayed in a language to match the operating system. Limiting the data entry could be enforced using LANSA Repository rules.
