Writing Multi-Lingual Dexterity Code
From the Translating Dexterity Applications Series.
With large international companies using Microsoft Dynamics GP in multiple countries, we are seeing the need to be able to run more than one language of the application on the same system.
Even if an application can be easily translated, you may still encounter problems when you run the application in multiple languages on the same system. This type of environment is called a multi-lingual system and it required another set of "Best Practice" rules.
To write Dexterity code that can be run in multiple languages, use the following guidelines:
- Do not use messages to store data or to retrieve data. Use constants to store data or to retrieve data.
If systems running in different languages used different values to access the same data, you would only be able to see the data entered in the same language as what you are currently using. The data needs to be language independent and so should not have translated key values.
- Do not use sorted lists unless it is absolutely necessary. However, you can use sorted lists if the user types the items in the list.
If a list is sorted, the order of the items will change depending on the language it is being displayed in. If the data is coming from a table and is always in the same language, it could be sorted if desired.
- Do not store a string in a table unless the user types the string or unless the string has a Language ID in the key. However, you can store a string in a table if the string is a constant value that the user cannot see. Or, you can store a string in a table if the table is a true temporary table.
There are times when we do want translated data stored in the tables, if this is a temporary table specific to a user and company or a true temporary table (with a filename of TEMP) there is no issue. If this is a permanent table then it should have the 'Language ID' field in the key, so a set of data for each language can be stored. When reading or writing the data the 'Language ID' field in the table should be set to the 'Language ID' of globals system variable.
- Trigger the syLanguage procedure to add third-party resources that need translation.
If you have data which needs to be added to a table when a new Language ID is being used, triggering on the syLanguage procedure will allow the developer to add those values when a new language is first used.
- Include the Language ID when you design new tables.
If you are creating a new table which needs to store translatable data, make sure the 'Language ID' field is added to the table and is part of the primary key.
- Do not use messages where constants are more appropriate.
This has been said a few times already, but if something should not be translated.... use a constant.
These guidelines are covered in the following Knowledge Base (KB) article:
The following KB article explains the Language ID variable in more detail:
Description of the Language ID global system variable in Microsoft Dynamics GP (KB 942751) 
Please let me know if you have had to work in a multi-lingual environment and if you had any issues.
David