What Is Internationalization?

Internationalization — commonly referred to by its shorthand notation i18n (an acronym based on the fact that there are 18 letters between the i and the n in the word itself) — actually consists of two key ideas: localization and globalization:

• Localization is the act of customizing, translating, and/or encoding language- and culture-specific content in order for it to be delivered by the application based on user preferences.

• Globalization is the process of enabling your application to understand, react to, and deliver such localized content based on a given user's global preferences.

The distinction between the two is admittedly fuzzy and often gets confused in books, articles, and conversations. This chapter will help to tease the two apart in your mind.

Once you've decided to internationalize your application and have introduced support for a small set of cultures, adding support for new ones is a simpler task. Doing so is typically just a matter of performing the localization tasks necessary for that given culture (e.g., translation), capturing those in resource bundles, and delivering the software to your new target audience. Rarely does it require application changes. With that said, the translation of the content is honestly one of the (if not the) most costly and erroneous tasks in the entire internationalization process.

Platform Support

The .NET Framework provides a number of key tools and techniques that aid the development of global applications. Things begin with the fact that the CLR treats strings as Unicode-encoded data, regardless of whether this is a program literal or some assembly metadata. Unicode is a character encoding that uses 2 bytes (16 bits) to represent each character, expanding the number of characters in the character set exponentially when compared to the traditional 8-bit ASCII character set. (In some circumstances, the CLR and .NET Framework utilize UTF-8 for efficiency purposes; this enables some of the more common characters, for example the lower-range English characters, to use up only 1 bit. We discuss encodings in more depth later in this chapter.)

Cultures are the hub of the internationalization system in the .NET Framework. Many of the APIs in the Framework accept culture specifications, represented as CultureInfo instances, in order to change logic appropriate to a user's cultural preference. As noted above, in the absence of an override many APIs will actually automatically detect and customize behavior of formatting based on the current user's culture. A firm understanding on the cultural subsystem and the various encodings, such as UTF-8 and Unicode, will prove indispensable.

Resources are the .NET Framework's way to encapsulate, distribute, and retrieve data based on a user's cultural preferences. Such data can include textual information, like error messages or user interface strings; media; serialized objects; or, quite frankly, just about any other data that could be specific to a culture. Resources are sets of culture-specific bundles that enable you to store and organize multiple cultural packages together within a single application. The specific resource package to use is decided at runtime based on the user's environment (e.g., explicit preferences, machine settings).

Cultures

As already noted, the backbone of globalization in the Framework is something called a culture. A culture is a combination of language and optionally country, region, or geopolitical region. Windows users select a culture in their Control Panel, and various types in the runtime recognize and change behavior based on this setting — from the content of the text presented, to the formatting of currency, numbers, and dates, to specialized logic that is only appropriate for specific cultures. Your types can do the same.

Figure 8-1 shows a few select cultures. Cultures relate to each other in a tree-like fashion, where the invariant culture is at the root, followed by neutral cultures, with the specific cultures as the leaves. The invariant culture is the root of all cultures and indicates a lack of any culture preference and neutral cultures are those that have only language (and no country) specified. We will discuss these three discrete types of cultures more in depth later on in the chapter.

Figure 8-1: Tree of sample invariant, neutral, and specific cultures.

If a user were to select one culture over the other from the list, it would create differences in the way that ordinary information is presented. For example, many of the native data types will be made to look different automatically when you invoke ToString on them. This table illustrates some key differences among a few select cultures from above:

Open table as spreadsheet

	en-US	en-GB	es-MX	de-DE
Name (English)	English (United States)	English (United Kingdom)	Spanish (Mexico)	German (Germany)
Name (Native)	English (United States)	English (United Kingdom)	Espaol (Mxico)	Deutsch (Deutschland)
LCID	1033	2057	2058	1031
Calendars	Gregorian	Gregorian	Gregorian	Gregorian
Days	Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday	Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday	domingo, lunes, martes, mircoles, jueves, viernes, sbado	Sonntag, Montag, Dienstag, Mittwoch, Donnerstag, Freitag, Samstag
Months	January, February, March, April, May, June, July, August, September, October, November, December	January, February, March, April, May, June, July, August, September, October, November, December	enero, febrero, marzo, abril, mayo, junio, julio, agosto, septiembre, octubre, noviembre, diciembre	Januar, Februar, Mrz, April, Mai, Juni, Juli, August, September, Oktober, November, Dezember
Short Date Example	9/12/1980	12/09/1980	12/09/1980	12.09.1980
Long Date Example	Friday, September 12, 1980	12 September 1980	viernes, 12 de septiembre de 1980	Freitag, 12. September 1980
Currency	$100,299.55	100,299.55	$100,299.55	100.299,55 €
Number (Negative)	-100,299.55	-100,299.55	-100,299.55	-100.299,55

The Process

As with any investment, you should first understand the expected return on it. As hinted at in the opening paragraphs, if you are an Independent Software Vendor (ISV) the single most compelling reason to make your software world-ready is to open up new markets that would have otherwise been excluded by a single-culture version of your software. A close second to that might be reacting to a competitor that has already released an internationalized version of their software. In both cases, the name of the game is expanding global reach, which in turn normally helps to benefit your company's bottom line, either directly, through increased sales, or indirectly, through presenting a more globally friendly image.

If you're writing software for an intracompany audience, as in a large enterprise that might have a presence in multiple countries, in many cases there isn't a choice. Developing a U.S.-centric sales force automation application when a significant portion of your sales department is operating in Europe and Asia might not be conducive to a successful application launch, for example. Not creating an international version might have the consequence that employees will subvert it and indeed prefer spreadsheets and manual processes to dealing with a culturally insensitive application. (I speak from experience.)

Some cultures accept certain languages although they might have a different native preference. For example, in the medical and technology communities, English is often the global language of choice. Thus, the extent to which you must localize content should be driven by your users' requirements. Usually, all of this is part of the thought process of sales and marketing teams when identifying the target audience for your software. Seldom should the decision to internationalize be made by the geeks.

Stages and Costs

Internationalizing an application is a staged process, with increasing risks and costs at each stage. Some teams might choose to implement all stages at once, while others might do it as an incremental process in order to evaluate progress as it is made. In any case, if you're new to the process, you should likely start out with a single-language prototype in order to gauge how successful you will be when you take on a higher quantity later on.

Roughly, the four stages of internationalization are as follows:

• Translate documentation, marketing material, web site help, and generally any or most content that is not part of the applications execution itself. This has no direct cost to the application, although it can impact the packaging in some cases. No additional test costs are incurred. The most costly part of this phase is getting content translated.

• Enable your application — that is, globalize it — so that cultures and languages can be supported later on. There is a certain level of actual development at this stage but overall is not overly risky or costly. Some additional test is needed to ensure that regional settings on the client's machine don't affect the overall execution of your program.

• Translate application content for each language you wish to support and package it with the application to create localized versions. This is the step where costs increase dramatically. First, creating the localized content is very costly and can be a lengthy process. Second, you will now need to test each local version of your application thoroughly to ensure that there aren't feature bugs or content problems on a culture-specific version. Depending on whether this is a class of culture you haven't previously supported (e.g., a right-to-left language, vastly different character set such as Japanese), the cost increase can vary dramatically.

• Create locale-specific features, for example in situations where special logic should be executed depending on which culture a user has selected. This is the most costly of the four stages, although it is not required and is somewhat rare in practice.

Obviously, this process isn't necessarily sequential. But the above should be viewed as the natural way to progress through the internationalization process. Something not explicitly called out, but that becomes necessary once you start packaging and supporting localized content for client applications, is that international setup interfaces will be necessary. And you can't forget support. Presumably if your target audience interacts with your application in a different language, they're going to want to speak it too when they run into problems.