Technical Issues
Developers can reduce their development time on almost any international application by considering the following issues prior to the start of the development cycle:
- Use Unicode as your character encoding to represent text. If you cannot use Unicode, you will need to implement DBCS enabling, bi-directional (BiDi) enabling, code page switching, text tagging, and so on.
- Consider implementing a multilingual user interface. If you design the user interface to open in the default UI language and offer the option to change to other languages, users of the same machine who speak different languages reduce down time related to software configuration. This may be a particularly useful strategy in regions such as Belgium with more than one culture/locale and official language.
- Watch for Windows messages that indicate changes in the input language, and use that information for spell checking, font selection, and so on.
- If you are developing for Windows 2000, test your application on all language variants of Windows 2000, using all possible cultures/locales. Windows 2000 supports the languages used in more than 120 cultures/locales.
Cultural and Political Issues
Sensitivity towards cultural and political issues is an especially important topic when developing world-ready applications. In general, these items would not prevent your application from running; instead, they are items that may create such negative feelings about the application that customers may seek alternatives from other companies. Political issues, such as disputes related to maps, can induce governments to prevent distribution in entire regions. The following are areas in which problems commonly occur:
- Avoid slang expressions, colloquialisms, and obscure phrasing in all text. At best, they are difficult to translate; at worst, they are offensive.
- Avoid images in bitmaps and icons that are ethnocentric or offensive in other cultures/locales.
- Avoid maps that include controversial regional or national boundaries. They are a notorious source of political offense.
Additional User Interface Issues
You can localize well-designed software to any of the languages supported by Windows 2000 without changes to the source code. In addition to the guidelines mentioned above, you should also consider the following:
- Isolate all user interface elements from the program source code. Put them in resource files, message files, or a private database.
- Use the same resource identifiers throughout the life of the project. Changing identifiers makes it difficult to update localized resources from one build to another.
- If used in multiple contexts, make multiple copies of the same string. The same string may have different translations in different contexts.
- Only place strings requiring localization in resources. Leave non-localized strings as string constants in the source code.
- Allocate text buffers dynamically since text size may expand when translated. If you must use static buffers, make them extra large (perhaps doubling the length of the English string) to accommodate localized strings.
- Keep in mind that dialog boxes may expand due to localization. For example, a large dialog box that occupies the entire screen in low-resolution mode may require resizing to an unusable size when localized.
- Avoid text in bitmaps and icons, as these are difficult to localize.
- Do not create a text message dynamically at run time, either by concatenating multiple strings or by removing characters from static text. Word order varies by language, so dynamic composition of text in this manner requires code changes to localize to some languages.
- Similarly, avoid composing text using multiple insertion parameters in a format string because the insertion order of the arguments changes when translated to some languages.
- If localizing to a Middle Eastern language, such as Arabic or Hebrew, use the right-to-left layout APIs to lay out your application right-to-left.
- Test localized applications on all language variants of Windows 2000. If your application uses Unicode, as recommended, it should run fine with no modifications. If it uses a Windows code page, you will need to set the culture/locale to the appropriate value for your localized application and reboot before testing.
Globalization Best Practices
- Make your application Unicode internally.
- Use the culture-aware classes provided by the System.Globalization namespace to manipulate and format data.
- Use the culture property settings provided by the System.Globalization.CultureInfo class in the appropriate situations. Use the CultureInfo.CurrentCulture property for formatting tasks, such as date and time or numeric formatting. Use the CultureInfo.CurrentUICulture property to retrieve resources. Note that the CurrentCulture and CurrentUICulture properties can be set per thread.
- Enable your application to read and write data to and from a variety of encodings by using the encoding classes in the System.Text namespace. Do not assume ASCII data. Assume that international characters will be supplied anywhere a user can enter text. For example, the application should accept international characters in server names, directories, file names, user names, and URLs.
- When using the UTF8Encoding class, for security reasons, use the error detection feature offered by this class. To turn on the error detection feature, the application creates an instance of the class using the constructor that takes a throwOnInvalidBytes parameter and sets the value of this parameter to true.
- Whenever possible, handle strings as entire strings instead of as a series of individual characters. This is especially important when sorting or searching for substrings. This will prevent problems associated with parsing combined characters.
- Display text using the classes provided by the System.Drawing namespace.
- For consistency across operating systems, do not allow user settings to override CultureInfo. Use the CultureInfo constructor that accepts a useUserOverride parameter and set it to false.
- Test your application functionality on international operating system versions, using international data.
- If a security decision is based on the result of a string comparison or case change operation, have the application perform a culture-insensitive operation. This practice ensures that the result is not affected by the value of CultureInfo.CurrentCulture. See the "String Comparisons that Use the Current Culture" section of Best Practices for Using Strings in the .NET Framework for an example that demonstrates how culture-sensitive string comparisons can produce inconsistent results.
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 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).
- For a complete description of creating and localizing resources, see Resources in Applications.
Globalization Best Practices for ASP.NET Applications
- Explicitly set the CurrentUICulture and CurrentCulture properties in your application. Do not rely on defaults.
- Note that ASP.NET applications are managed applications and therefore can use the same classes as other managed applications for retrieving, displaying, and manipulating information based on culture.
- Be aware that you can specify the following three types of encodings in ASP.NET:
- requestEncoding specifies the encoding received from the client's browser.
- responseEncoding specifies the encoding to send to the client browser. In most situations, this encoding should be the same as that specified for requestEncoding.
- fileEncoding specifies the default encoding for .aspx, .asmx, and .asax file parsing.
- Specify the values for the requestEncoding, responseEncoding, fileEncoding, culture, and uiCulture attributes in the following three places in an ASP.NET application:
- In the globalization section of a Web.config file. This file is external to the ASP.NET application. For more information, see <globalization> Element.
- In a page directive. Note that, when an application is in a page, the file has already been read. Therefore, it is too late to specify fileEncoding and requestEncoding. Only uiCulture, Culture, and responseEncoding can be specified in a page directive.
- Programmatically in application code. This setting can vary per request. As with a page directive, by the time the application's code is reached it is too late to specify fileEncoding and requestEncoding. Only uiCulture, Culture, and responseEncoding can be specified in application code.
- Note that the uiCulture value can be set to the browser accept language.
