Building Microsoft ASP.NET Applications for Mobile Devices, Second Edition [Electronic resources] نسخه متنی

Defining Culture for Formatting Strings, Dates, and Times

By defining a culture, you influence the formatting style of methods that your application uses to output information, such as strings, dates, and number formats. If you don't specify any culture settings, the application uses the local settings of the Web server. However, it's good practice to specify culture settings explicitly.

You can define the culture settings for an application in three ways: in the Web.config application configuration file, in the @ Page directive, and in the code. The first two methods are appropriate for establishing an application's default settings. Defining Culture or UICulture in the @ Page directive overrides any settings in Web.config, as the following code demonstrates. Here's some code defining Culture and UICulture in Web.config:

<configuration>
<system.web>
<globalization
culture="de-DE"
uiCulture="de"
/>
</system.web>
</configuration>

And here's the code defining culture settings in the @

Page directive:

<%@ Page UICulture="en" Culture="en-US"…%>

These two culture settings determine the formatting the runtime applies to dates, times and currencies, and where the application should look for localized strings:

Culture attributeThis setting ensures that the runtime formats information according to the appropriate conventions for the specified culture. You must set the specific culture identifier, such as en-US (English-United States) or fr-CA (French-Canada). You can't specify a neutral culture identifier such as en or de because these don't distinguish among different cultures, such as U.S. English (en-US) and U.K. English (en-GB). Search the Microsoft .NET Framework documentation for the CultureInfo class for a complete list of supported culture identifiers. In code, you shouldn't set the corresponding MobilePage.Culture property. Instead, set the CurrentCulture property of the System.Threading.Thread class, as shown in the next example.

UICulture attributeAs with the Culture attribute, this must be one of the culture identifiers supported by the CultureInfo class. Unlike Culture, however, with UICulture you're allowed to use neutral culture identifiers such as de or fr as well as specific culture identifiers. The Resource Manager uses the identifier at run time to select a resource file for accessing localized string values. For example, if you set UICulture to en, the Resource Manager accesses the Resourcesfile.en.resx resource file. If you set UICulture to "", the empty quotation marks indicate the neutral culture, and the Resource Manager accesses the resources from Resourcesfile.resx. We'll describe the use of resource files and the ResourceManager class later in this section. In code, you set this feature by setting the CurrentUICulture property of the thread, as shown in the example below.

One approach to building multicultural applications is to develop a set of mobile Web Forms pages, each of which implements the user interface of your application—one for each supported locale. In this case, you define the Culture settings in the @ Page directive of each page.

However, you can also have a single mobile Web Forms page that sets the Culture in code at run time, depending on the user preferences defined in the client device's browser. Many handheld devices allow the user to specify the preferred language for content. Sophisticated browsers such as the desktop Internet Explorer allow the user to specify more than one preferred language, in order of preference. The devices then pass these preferences to the server in the HTTP headers of every request. For example, in Internet Explorer, click Tools and then Internet Options. Then click the Languages button to select your language preferences. Mobile phones usually allow the user to specify the preferred language in the Settings menu.

Internet Explorer is a useful tool for testing applications that respond to the language preference that the user sets in the client browser, and which is passed to the server in the HTTP headers, as we've described in this section.

If you want to test a multilingual application with a mobile phone emulator, you can use a real device or you can download one of the developer's toolkits available from a major mobile phone browser manufacturer. Emulators from Nokia, Openwave, Ericsson, and other manufacturers offer the capability to specify language preferences. For example, in the Openwave UP.Browser 4.1.1 emulator, click on the Settings menu, option Device settings; the dialog that displays allows you to define the Language and Charset to use. See Chapter 16 for more details on downloading and using emulators.

Within code, the client's preferred languages are available in the UserLanguages property of the Request object, which returns a string array of a user's specified preferences, normally in the order of preference. Be aware that the strings sent from the client browser can also include additional data such as a weighting factor (for example, en-us;0.3), which some applications can use to determine the relative preference weighting of each language in the list. Therefore, you need to process the array passed in the headers to extract the locale code for the user's preferred language. But be warned: browsers often allow you to specify language preferences by using neutral culture identifiers (such as en or fr), and you can't use these neutral identifiers to set the CurrentCulture property of System.Threading.Thread directly. Instead, use the System.Globalization.CultureInfo.CreateSpecificCulture method, which will accept as a parameter a neutral culture identifier and return the default CultureInfo object for the specified culture.

In your applications, you can choose how far you wish to fine-tune your support for different cultures. For example, perhaps you want to observe the cultural differences between French-Canadian, French-Algerian, and French-French, so you create string resource files for each of these cultures. Alternatively, you might wish to provide a single French language string resource to be used with any of these French-speaking cultures (and any others in the world), avoiding the effort of writing separate string resource files for each.

The example shown in Listing 14-2. You'll learn how to create and use string resource files in the next section, "Creating and Using Resource Files."

Listing 14-1: Setting Culture and UICulture by examining the preferences sent from the client browser. This method is part of Default.aspx.cs of the LocalizingExample project.

private void setCulture()
{
// Extract first element of languages array  
String lang = Request.UserLanguages[0])
// Strip off any weighting appended to the string.
String langOnly = lang.Split(new Char[] {';'})[0];
// Set Culture – sets date-time, currency formats etc
System.Globalization.CultureInfo ci = 
System.Globalization.CultureInfo.CreateSpecificCulture(langOnly);
System.Threading.Thread.CurrentThread.CurrentCulture = ci;
// Set the UICulture – defines string resource file
// We support string resources for 'main' language only
// such as en, fr or de
ci = CultureInfo.CreateSpecificCulture(langOnly.Substring(0,2));
System.Threading.Thread.CurrentThread.CurrentUICulture = ci;
}