Languages

The languages that your application supports dictate many of the considerations that arise when internationalizing your application. Latin languages, such as French, German, and Spanish, make the fewest demands on your application and require a relatively low level of technology to support. The further you go from Latin languages, the greater awareness you need of issues that Latin languages do not require.

Right-to-left languages (such as Arabic, Hebrew, and Persian [Farsi]) require support for reading text right to left (instead of left to right) and mirroring. In a mirrored form or Web page, controls are repositioned from one side of a form to the other. In addition, controls are rendered right to left (e.g., scrollbars are on the left of a control, and menus start from the right and expand to the left).

Your choice of operating system affects the level of font technology available to support your languages. Chinese, Japanese, and Korean (often abbreviated to CJK) languages use glyphs that are not present in most fonts. Windows 2000 and above support font linking. This allows a font, such as MS Mincho, to be linked to another, such as Microsoft Sans Serif, so that when a glyph is required that is not found in the base font, the other linked fonts are searched for the required glyph. This technology takes away much of the burden of choosing a suitable font because you can stay with a single font, such as Microsoft Sans Serif, and rely on font linking to find the missing glyphs. Similarly, other languages (e.g., Devanagari) use scripts that require complex rendering, which is not found in Latin scripts. This complex rendering is achieved automatically if your operating system supports font fallback (which Windows 2000 and above do) and this support is installed.

East Asian languages (Chinese, Japanese, and Korean) make further demands on the application. These languages have considerably more characters than are available on a QWERTY keyboard (there are 5,000-odd Japanese Kanji characters), so a software component called an Input Method Editor (IME) is used to enter characters. Typically, this issue is more relevant to Windows Forms applications than ASP.NET applications: IMEs are used with both Windows Forms applications and ASP.NET applications, but Windows Forms applications can optionally offer help in controlling the IME. The question in terms of development is, do you offer help in controlling the IME, and, if so, how much help do you offer?

The languages that you need to support also dictate whether you need to use custom cultures. A custom culture is a language or a language and region (or a replacement of an existing language or language and region) that is not already known to the .NET Framework. For example, if you wanted to support Bengali in Bangladesh, you would have to create a custom culture. Similarly, if you wanted to support a known language outside of its "known" region (e.g., Spanish in the United States), then you would have to create a custom culture. Although custom cultures can be created in the .NET Framework 1.1, support for this is very low and you are strongly advised to use the .NET Framework 2.0.

The languages that you need to support also affect your testing process. For accurate testing, you must test your application on the version of the operating system that your users will be running. The "version" means not only the release (Windows 2000, XP, 2003, and so on), but also the language. If your users will be running German Windows XP Professional, then your testing is not complete if you test it in English Windows XP Professional. You should consider two testing scenarios: Windows Multiple User Interface and Virtual PC. Both are covered in Chapter 2, "Unicode, Windows, and the .NET Framework."