Localization Overview

Globalization is the first step in the process of creating a world-ready application. In this step, the application's executable code is written. A truly global application should be culture-neutral and language-neutral. Therefore, you should focus attention on creating an application that will be able to support localized user interfaces and regional data for all users. Note that although a globalized application has this flexibility, the globalization process itself does not involve translating the user interface. Instead, you should strive to create an application with functionality that works equally well for users from all cultures and regions your application supports.

For each localized version of your application, add a new satellite assembly that contains the localized user interface block translated into the appropriate language for the target culture. The code block for all cultures should remain the same. The combination of a localized version of the user interface block with the code block produces a localized version of your application.

Kinds of Resources in the Hierarchy

• At the top of the hierarchy sit the fallback resources for your default culture, for example English ("en"). These are the only resources that do not have their own file; they are stored in the main assembly.
• Below the fallback resources are the resources for any neutral cultures. A neutral culture is associated with a language but not a region. For example, French ("fr") is a neutral culture. (Note that the fallback resources are also for a neutral culture, but a special one.)
• Below those are the resources for any specific cultures. A specific culture is associated with a language and a region. For example, French Canadian ("fr-CA") is a specific culture.

Localization Best Practices

• Move all localizable resources to separate resource-only DLLs. Localizable resources include user interface elements, such as strings, error messages, dialog boxes, menus, and embedded object resources.
• Do not hardcode strings or user interface resources.
• Do not put nonlocalizable resources into the resource-only DLLs. This causes confusion for translators.
• Do not use composite strings that are built at run time from concatenated phrases. Composite strings are difficult to localize because they often assume an English grammatical order that does not apply to all languages.
• Avoid ambiguous constructs such as "Empty Folder" where the strings can be translated differently depending on the grammatical roles of the string components. For example, "empty" can be either a verb or an adjective, which can lead to different translations in languages such as Italian or French.
• Avoid using images and icons that contain text in your application. They are expensive to localize.
• Allow plenty of room for the length of strings to expand in the user interface. In some languages, phrases can require 50-75 percent more space than they need in other languages.
• Use the System.Resources..::.ResourceManager class to retrieve resources based on culture.
• Use Visual Studio 2008 to create Windows Forms dialog boxes, so that they can be localized using the Windows Forms Resource Editor (Winres.exe). Do not code Windows Forms dialog boxes by hand.
• Arrange for professional localization (translation).