Global Developer Blog
The term Locale is often misunderstood by developers creating international software for the Windows platform. Some of the confusion arises from the fact that there are several different locales to choose from. This blog post defines Locale and explains the different locales available in Windows. The concept of a .NET Culture is also defined here, although extensive exploration of cultures is left for future blog posts.
In general terms, Locale refers to a place or location. This concept is useful when developing international applications because the behavior of the program may need to change depending on the user’s geographical location. Possible changes include the language displayed to the user, formatting of data, units of measure, choice of calendars, and even time and date formats. There are four different Locales defined by Windows. Each is explained below.
The System Locale has existed in Windows for a long time. It is primarily used for legacy applications that do not have Unicode support. These applications depend on Windows code pages to display the proper fonts and characters to international users. We typically do not need to be too concerned about the System Locale for most modern applications since most new applications support Unicode. If you are running legacy applications, you will need to be sure that your System Locale is set properly for your location. When you change the System Locale, you will need to reboot Windows in order for the change to take effect. The System Locale is set by a system administrator via the Control Panel from the Region and Language dialog. Go to the Administrative tab and click the Change system locale… button to make the change.
The User Locale is probably the most interesting Locale in this discussion. This user-specific Locale determines the default settings a user wants for formatting dates, times, currency, large numbers, etc. For example the currency symbol for a Spanish user would be the Euro symbol and the default date format would be dd/MM/yyyy. Even the calendar type and sorting information is controlled by the User Locale settings. Although the various Locales are listed according to the language name, this is not really a language setting. It simply means that the user wants to use the formatting standards associated with the specified language when displaying data. This locale is also set using the Region and Language dialog. In Windows 7, use the Formats tab. (In previous versions of Windows this tab is called Regional Options.) When the user makes a change to this Locale, locale-aware programs should detect a change (via the WM_SETTINGCHANGE message) and update their output formatting as appropriate.
The Input Locale is also sometimes known as the Input Language. This is a variable describing the language a user will be inputting into running applications. The Input Language also maps to the keyboard layout or input method editor (IME) selected by the user. The Input Locale is set using the Keyboard and Languages tab in the Region and Language dialog. Users may define multiple Input Locales and switch between them.
The Thread Locale is used to retrieve the User Locale of the current application thread. This Locale typically defaults to the current User Locale and usually does not need to be overridden. Use the SetThreadLocale API if you need to programmatically change the Thread Locale.
Introducing .NET Cultures
.NET introduced the concept of the Culture to managed code programming for Windows. A Culture is slightly different from a Locale because it contains information for both for the language and the region of a user. For example the culture code fr-CA indicates that the language is French and the region is Canada. The last two characters are called a subculture code and may represent a country, region or writing system. The CultureInfo Class is used to store this language and region-specific information. There is even an LCID property on the CultureInfo object that returns the associated Locale ID for the object instance. For more information, please refer to the .NET documentation for the CultureInfo Class.
.NET provides a new, thread-specific CultureInfo property called CurrentCulture. This object encapsulates the User Locale for the thread and contains culture-specific settings such as time and date formats, sort order info, etc. You can get and set the Thread.CurrentThread.CurrentCulture value programmatically in your applications as needed.
The CurrentUICulture is another thread-specific CultureInfo property that defines the Culture used by the ResourceManager when loading resources for a running program. This object is initialized automatically with the value returned by the GetUserDefaultUILanguage API.
Watch Out for Culture Confusion!
.NET developers sometimes confuse CurrentCulture and CurrentUICulture and use them incorrectly. Remember that CurrentCulture is used to format and process data based on user preferences and CurrentUICulture is used for loading the correct localized resources.
Example: A Japanese user in Tokyo uses Japanese Windows 7 and has changed his Format setting in the Region and Language dialog of the Control Panel to English (United States) so that his time, date, numeric, and other format settings are consistent with his colleagues based in New York. When this user installs a new application, the UI resources loaded for that application should be displayed in Japanese rather than English since the user’s Windows UI is displayed in Japanese. (Of course the application can provide an option to override this behavior in order to load resources in another localized language.) If the application uses the CurrentCulture rather than using the CurrentUICulture value to load the resources, English UI will be displayed. In a similar fashion you may get unexpected formatting results if you use CurrentUICulture for formatting output instead of CurrentCulture.
So be sure you use the correct Culture value when you develop international applications. CurrentCulture and CurrentUICulture each have a specific purpose and they are not interchangeable.
Locales and Cultures are fundamental concepts for Windows developers in today’s global software industry. This blog post provides only a brief introduction to these useful programming constructs. To learn more on these important topics, please refer to the documentation and other resources provided on MSDN. I hope you’ve found this post useful to you. Thanks for taking the time to read this and other posts on the Global Developer Blog!
I found your blog above and wanted to see if you might be interested in writing about a Certificate program at the University of Washington on the topic of Localization. It's a program which is available both in the classroom and online and we're trying to get the word out among key bloggers within this community.
Would you be interested in participating in a conference call with other bloggers to learn more about the program? As program director I would participate as well as some faculty members from the program so you could learn more about this certificate during the call. We can also provide you with some useful content that you might fine helpful in writing a piece about the program. Lastly, if you have colleagues or fellow bloggers that you know about who you recommend we should include, please feel free to let us know.
Thanks very much for considering this request.
Erik Bansleben, Ph.D.
Program Development Director, Academic Programs
UW Professional & Continuing Education