18.3.3 Handling Foreign Languages

Never make assumptions about language usage when dealing with foreign languages. The ordering of words can be different, and the number of words required is often greater than in English.

Keep in mind the following grammatical points when preparing an application for localizing:

Avoid using the same word in more than one message. Some words, such as none, can have different translations (different gender and number) depending on the context.

Do not create plurals of words by adding s. Keep two strings, one for the singular and one for the plural.

Avoid using slang, abbreviations, or jargon, because they are difficult to translate.

Keep these syntactical considerations also in mind when localizing:

Avoid parsing text to obtain information. Parsing normally assumes specific syntax.

Do not create a long string from several short strings. The long string may not make sense in another language, because the order of parts of speech varies in different languages.

Incorporate graphic objects such as bitmaps, cursors, and icons with these considerations in mind:

Avoid the use of embedded text in graphics. Text is difficult to modify when in graphical form. If you cannot avoid this, leave enough space for translation and try to create tools to simplify the modification.

Look for graphic objects that represent international concepts, because graphic objects are also language dependent.

Keep in mind the following points when planning screen elements:

Do not hard-code the position or size of any element on the screen, because an item changes position and size as it gets translated. In cases where you need to define the size or position of certain object, place this definition in the resource-definition (.RC) file.

Use the CreateWindow function carefully. The lpClassName parameter should be constant and independent from localization, but the lpWindowName parameter, which is the string that appears in the title bar, should be localized. The string used for lpWindowName should be taken from the resources.

All messages should be self-contained, not dynamically assembled. In cases where messages have variables added to them at run time, do not make any assumptions about the position of the variable in the message. Handle variables in messages in the following manner:

1.Place the string containing the variable in the resource-definition (.RC) file:

CannotOpen,       "The application could not open the file %s"

2.Use the wsprintf function to incorporate the variable into the string:

LoadString(hInst, CannotOpen, lpFormat, MaxLen);
wsprintf(FinalString, lpFormat, FileName);