Coding for Internationalization (Windows Embedded CE 6.0)
1/6/2010
When you are coding your application, several coding practices can make the internationalization process easier. A few of these practices are the following:
- Do not hard-code localizable elements.
Hard-coded strings, characters, constants, screen positions, file names, and file paths are difficult to track down and localize. Isolate all localizable items into resource files, and minimize compile dependencies. - Do not make buffers too small to handle localized text.
Buffers that are declared the exact size of a word or a sentence will probably overflow when text is translated. Consider the following example. Your application declares a 2-byte buffer size for the word "OK." In Spanish, however, when it refers to the text in an OK button, the same word is translated as "Aceptar," which would cause your application to overflow. - Do not perform string composition.
For example, translating "wrong file" and "wrong directory" to Italian results in "file errato" and "cartella erratta," respectively. If you try to perform string composition using the syntax "wrong%s", it does not work.
Another potential problem involves declaring a single string and displaying it in a number of different contexts: on a menu, in a dialog box, and perhaps in several messages. The problem with using all-purpose strings is that in European languages, adjectives and some nouns have from 4 to 14 different forms--such as masculine, feminine, and neuter singular, and masculine, feminine, and neuter plural-- that must match the nouns they modify. A single string displayed in different contexts is correct in gender and number in some cases but incorrect in others.
One way to ensure that your coding practices work in an international market is to substitute your language strings with a pseudo language, and then test your code. Any potential problems should surface immediately.