Retrieving the Right Locale

Since all APIs and functions that allow locale-specific formatting take as an argument the locale ID or the culture name for which this formatting should be performed, the first step in writing locale-aware software is to retrieve the proper locale. How you retrieve this locale will depend on whether you're dealing with Win32 applications, Web pages, or the .NET Framework.

Retrieving the User Locale in Win32

The user locale defines a user's preferences for formatting locale-sensitive data (such as date, time, and currency). Your application should use the appropriate user locale to display formatted data.

Use the GetUserDefaultLCID API to retrieve the user locale value shown as follows:

 LCID uiVal; uiVal = GetUserDefaultLCID(); 

Since this is a user-specific setting, there is no API made public to alter its value. The user must manually change the value. Besides retrieving the currently selected user locale, you might also want to enumerate and find out about all installed or supported locales in the system. An installed locale is a locale for which the appropriate code page and language support have been installed on the system; a supported locale is the locale for which the system provides appropriate NLS information with appropriate script support installed. The code sample that follows enumerates all installed locales in the system and finds the appropriate language name associated with each LCID.

 EnumSystemLocales(EnumLocalesProc, LCID_INSTALLED); // the enumeration callback function BOOL CALLBACK EnumLocalesProc(LPTSTR lpLocaleString) { LCID uiCurLocale; TCHAR szCurNam[STR_LEN];   if (!lpLocaleString)       return FALSE; // This enumeration returns the LCID as a character string while //    we will be using numbers in other NLS calls.    uiCurLocale = uiConvertStrToInt(lpLocaleString); // Get the language name associated with this locale ID.    GetLocaleInfo(uiCurLocale, LOCALE_SLANGUAGE, szCurName, STR_LEN);    return TRUE; } 

The big limitation of this enumeration is the fact that LCIDs are returned as character strings, and yet in other NLS APIs, a numeric value is expected. To address this, you can write your own string-to-integer transformation function. (Keep in mind that the character string is the actual hexadecimal representation of the LCID.) In the code sample you've just seen, the call to uiConvertStrToInt is an internal call to this transformation function.

Another thing that's noteworthy about this code sample is the call to a commonly used API called GetLocaleInfo. GetLocaleInfo can retrieve a variety of locale-specific information, from localized names for days of the week to the default paper size used for each locale. You can either specify the LCID of the locale for which the information is being retrieved, or use the predefined flag LOCALE_USER_DEFAULT. The latter defaults to the currently selected user locale and saves you from having to call GetUserDefaultLCID.

The user locale represents the user's preference for formatting locale- sensitive data for Win32 applications. In Web content, you will need to retrieve the browser language setting to represent content that corresponds to the language and locale of the user.

Retrieving the Browser Language Setting

By default, the global locale of your Web content will always match the following:

  • The user locale of the hosting server for HTML or Dynamic HTML (DHTML) pages
  • The system locale of the hosting server for Active Server Pages (ASP)

When it comes to locale-aware and culture-aware Web design, it's important to represent the data in the client-side format rather than defaulting to the server-side setting. Suppose your server is hosted on an English machine with an English (United States) user locale, but its content is viewed by an English (United Kingdom) user, where the date formatting goes from the English (United States) format of mm/dd/yy to the English (United Kingdom) format of dd/mm/yy.

The browser language setting is commonly used by multilingual Web sites to define the default language in which their content should be represented to the user, as well as the locale in which the data formatting should follow its standards. The technique of trying to get the browser-setting information from the client side is usually referred to as "browser sniffing." The user can set the language in the browser. For example, in Internet Explorer choose Internet Optionsfrom the Tools menu, and then click the Languages button of the General tab to choose one or more preferred languages. Other browsers support the same functionality; Netscape 4.x and 6.x allow the user to set this information by clicking Preferences in the Edit menu. If using Internet Explorer, the user can also change regional settings and have the browser automatically pick up the new language choice. This information is sent to the server in the form of a server variable known as "HTTP_ACCEPT_LANGUAGE." You can retrieve it in ASP with VBScript code such as the following:

 Dim stLang stLang = Request.ServerVariables("HTTP_ACCEPT_LANGUAGE") 

This string, now sitting in the stLang variable, can be used in many different ways to control the content of your site. For example, you can:

  • Use the Microsoft Internet Information Services (IIS) 5 Server.Transfer or Server.Execute methods to move to a localized page.
  • Use the VBScript 5 SetLocale function to change the locale of the page, which will affect the display of the date, time, number, percent, and currency formats.
  • Query a database for content (assuming some or all of your site is database-driven).
  • Provide localized content through components.
  • Provide localized content directly in your ASP code.

(For more information on the possibilities just listed, see Chapter 6.)

The only difficulty in retrieving the browser language is that if you select multiple languages, your HTTP_ACCEPT_LANGUAGE string will look something like the following:

 et,en-us;q=0.8,fa;q=0.6,it;q=0.4,fr;q=0.2 

In this string, locales are separated by a comma-in this case, Estonian, English (United States), Farsi, Italian (Italy), and French (France). The "q=" represents the priority of each language to help create a fallback mechanism. Suppose the preferred language is Estonian (q=1 by default). However, if you are not offering any support for this language, you can parse the HTTP_ACCEPT_ LANGUAGE string for the next preferred language (q=0.8 for English).

You can then use the SetLocale function to set the global locale of your Web content. (This setting will only be applicable to your session and context.) The following example explicitly sets this locale to Estonian, and the original variable keeps the previous or original locale:

 Dim original     original = SetLocale("et-EE")) 

The navigator object navigator.userLanguage can also be used to retrieve the browser locale. (For an ASP sample application that handles browser sniffing and that represents formatted data in browser-locale standards, see the Samples subdirectory on the companion CD.)

While the browser language setting is important within Web content, in the .NET Framework the CultureInfo class is what you'll need to retrieve. In this environment, the particular culture that is associated with both a language and a region is used to determine the appropriate formatting conventions.

Retrieving the Current Cultureinfo

As mentioned previously, the CultureInfo class holds culture-specific information, such as the associated language, country or region, calendar, and cultural conventions. The CurrentCulture property gets the CultureInfo instance that represents the culture used by the current thread and returns the value of Thread.CurrentCulture. By default, the CurrentCulture property is set to the currently selected user locale of the system, as set by the user in the Regional And Language Options property sheet. Properties and standards of this default culture should be used to represent formatted data to the user. You can also explicitly set the value of CurrentCulture to a given culture name in your code (for the purpose and usage of your application only and not through the system). The following example sets the CurrentCulture to Finnish (Finland) in C#:

 Thread.CurrentThread.CurrentCulture = new CultureInfo("fi-FI"); 

The CurrentCulture property expects a culture that is associated with both a language and a region, such as ("es-ES") for Spanish in Spain. Because a language is often spoken in more than one country or region, the regional information is necessary to determine the appropriate formatting conventions to use. A neutral culture cannot be used for the creation of the CurrentCulture property. If you only have access to a neutral culture, you can create a CultureInfo object in the format that the CurrentCulture property expects. This is done by using the CultureInfo.CreateSpecificCulture method. This method maps a neutral culture to the default specific culture it is associated with, and then creates a CultureInfo object that represents that specific culture. The following code example uses the CultureInfo.CreateSpecificCulture method to map the neutral culture "it" for Italian to the specific culture "it-IT." It then creates a CultureInfo object for "it-IT" and uses it to initialize the value of the CurrentCulture property.

 Thread.CurrentThread.CurrentCulture =    CultureInfo.CreateSpecificCulture("it"); 

Similar to the Win32 NLS paradigm, the CultureInfo class allows you to enumerate all installed or supported cultures. The CultureInfo.GetCultures method can be used for that purpose, as shown in the following example where all supported locales are enumerated:

 using System; using System.Globalization; public class printClass {public static void Main()    {       foreach (CultureInfo ci in       CultureInfo.GetCultures(CultureTypes.AllCultures))       {          Console.WriteLine(ci);       }    } } 

The .NET Framework allows you to get an LCID from a Culture object by using the LCID property of CultureInfo.

In addition to retrieving the culture, another task involved in creating an application that's locale-aware is to properly format dates and calendars in accordance with the locale. You'll need to account for the many differences that exist among various countries and regions.



Microsoft Corporation - Developing International Software
Developing International Software
ISBN: 0735615837
EAN: 2147483647
Year: 2003
Pages: 198

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net