Globalization

Globalization is the process of adapting an application so that it does not have cultural preconceptions. The most common example is the different date formats used throughout the world. An application that displays dates as "MM/dd/yy" assumes the U.S. date format. Globalization is not limited to dates, however, and covers many lesser-known subjects. How many of the following, for example, do you know?

Not all languages have a concept of upper case.

A conversion to upper case does not result in the same string in all cultures.

Not all regions use the Gregorian calendar.

Some regions use a 13-month calendar.

"AM" and "PM" suffixes are not "AM" and "PM" in all languages.

In some languages, month names take a different form when the month can be said to "own" a day.

Several regions have more than one way of sorting data.

Thai does not use spaces to separate words (words are not separated at all).

The Windows Program Files folder isn't always called "Program Files" on non-English versions of Windows.

The good news is that the .NET Framework understands all these issues (and many more), and the advice is quite clear: Always use the .NET Framework classes. This will solve a very large part of the globalization issues of your application. You need a very good reason to use your own classes instead of those provided by the .NET Framework. For more details, see Chapter 6, "Globalization."

One decision that you might need to make early in the development of your application is how to refer to cultures. A culture is a language or a language-and-region combination. If you need to store a culture or a list of cultures (for, say, a user's preferred settings), you must decide whether to store them as names or as numbers. If you are using the .NET Framework 2.0, the answer is simple: Always store culture identifiers as strings (because strings can identify all cultures, regardless of whether they are custom cultures, cultures for alternate sort orders, or any other culture). Unfortunately, if you are using the .NET Framework 1.1, there is no easy answer to this; your decision will depend upon the functionality your application requires. If you use alternate sort orders, you must store these cultures as numbers. If you don't use alternate sort orders, you should store cultures as strings. Of course, you could store alternate sort orders as numbers and all other cultures as strings; in that case, you would need to be able to read and write cultures as both names and numbers.