The most visible difference between different language versions of the same application may be in the translation of the interface text.
The following design tips can help to minimize potential translation errors:
Such messages are more likely to be translated incorrectly. It’s best to use short, unambiguous sentences that are written without technical jargon. Be sure that messages describe what’s happening from the user’s point of view – not the computer’s.
The individual messages will be translated separately, without regard to all the situations in which they will appear. If the sentence structure of the target language is different from that of the language in which you’re creating your application, the final appearance of a concatenated message will most likely be incorrect.
If a language uses two separate words for those two concepts, it would be impossible to translate the message correctly for all situations. For example, the word Period refers both to an amount of time for which accounting data is tracked and to a type of currency separator.
A well-designed application should minimize the potential problems associated with translating the interface text.
English text commonly expands by about thirty to fifty percent when translated into other languages. For example, if the English version of an application requires a string that’s 22 characters long, you may wish to define it as a 30-character string instead.
Typically, this means making the area for the prompt thirty to fifty percent wider than required for an English prompt.
Depending upon the language you’re translating to and from, you may need to provide alternate sorting methods. For example, you’ll probably use ASCII values when sorting the English alphabet. However, languages that use accented characters that appear in the extended character set – such as å or ç – typically aren’t sorted correctly when using the ASCII sequence.
One way to addresses this problem is by adding the International=TRUE setting to the defaults file and adding an alternate collating sequence text file, DEX.ACS, to the same directory where the RUNTIME.EXE file is located. The .ACS file provides a list of how the characters ought to be sorted. As long as the .ACS file is in the correct location and International is set to TRUE, any new tables that are created will use the alternate collating sequence. Existing tables must be shrunk to enable the alternate collating sequence.
In some cases, local business practices may also require changes in the application’s functionality. You may wish to do market research in your target locales to determine which parts of your application may need to change and try to anticipate those needs as you complete your initial design.