When you are coding your application, several coding practices can make the internationalization process easier. A few of these practices are the following:
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.
Buffers that are declared to be 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.
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 works in an international market is to substitute your language strings with a pseudolanguage, and then test your code. Any potential problems should surface immediately.