Translating your application's interface or its documentation into other languages may be the most important task you'll face when you target your application for a global audience, but it's not the only one. Cultures differ in the ways they display dates, numbers, currencies, and even text. For instance, in the United States, the month is always the first part of the numeric representation of a date. In England, on the other hand, the month comes after the day. This could potentially create confusion—imagine payment due dates being missed because the date was not formatted according to a culture's standards. One way to avoid misinterpretation of numeric dates is to adopt an international standard, such as ISO 8601, that specifies that all dates are to be represented from the most significant to the least significant element: year, month, day, hour, and so on.

Similarly, disagreements over cultural representations of decimal separators have the power to almost stall the development of the programming language (http://en.wikipedia.org/wiki/Decimal_separator). To illustrate how such heated debates can originate, consider the following example: the number "one thousand one and one tenth" would be written in the United States as "1,001.1", with the comma symbol used as the separator for the thousands and the period symbol used for separating the decimals. The same number would be written in Europe as "1.001,1", with the dot used for separating thousands and the comma used to separate the decimals. The Windows Phone 7 operating system, fortunately, automatically makes these locale-aware changes for you. As a developer, however, you must help the framework out a little and ensure that you use appropriate data types and appropriate formatting options for the operations you perform in your applications. For example, you should never represent dates or numbers as strings and hardcode the formatting of those strings in your application if an application is intended for more than one national market.

In addition to these variations in the way different cultures handle numbers and dates, languages also differ in the number of words they require to express an idea, with some more verbose than others. For instance, it is estimated that an average sentence in the German language is 44 percent longer than the same sentence in English. That means that a Windows Phone 7 user interface written in English—its labels, textblocks, text boxes, and so on—may need to reserve additional available white space when designed in the English language and later translated (dynamically, as you'll see shortly) into German or other languages.

Also, if you are targeting international markets, the design of an application should be flexible enough to allow it to "speak" different languages without your having to make extensive changes to the source code. That means that all strings, images, and audio and video content must be placed in separate resource-only files—one for each target culture and language to make it easy to package the application for a new locale. By sticking with Unicode characters (with over 95,000 characters) to encode your strings content, you'll be able to display virtually any language in the world.

Another important consideration in deciding how to prepare to support your application in multiple languages is the amount of material that will need to be translated. Later in this chapter, we recommend you use resource-only files inside Visual Studio. This technique is perfectly acceptable for smaller applications, when there are only a handful of items to translate. However, if the translation requires the use of third-party translation services, you will be better served by looking at more specialized localization tools, such as Alchemy Catalyst, Globalizer.Net, Lingobit Localizer, or Radialix. While the use of such tools is beyond the scope of this chapter, if you ever find that editing resource files in Visual Studio becomes hard to manage, you can refer to the foregoing list to determine whether any of these products makes the task easier.

In MSDN documentation, there are usually two separate sections on internationalizing applications—globalization and localization. Roughly, globalization refers to ensuring that all commonly used application concepts, such as dates and currency, are properly represented and used in the system regardless of the locale of the user. Localization, on the other hand, refers to translating application resources, such as text of the user interface, into local representation. To muddy these concepts a little more, in the non-Microsoft world, the term internationalization is used to represent what Microsoft refers to as globalization. Since this is already confusing, for the purposes of this chapter, we won't make such a distinction; when we talk about "internationalizing" an application, we refer to ensuring that the application will work without problems in all countries and regions it was intended to work in—i.e., the Microsoft concepts of globalization and localization are blurred.

.NET and the Windows Phone 7 SDK include a number of tools to help you ready an app for international distribution. These tools include the CultureInfo class to properly determine the culture that an application is running in, as well as easy management of resource files that were custom developed for each culture. You will explore these tools next.

To see how you can go about preparing an application for the world, you'll build a simple application that announces a new product, in this case a Windows Phone. But first, you will learn how to use the CultureInfo class to ensure dates, numbers, and text appear in the right form regardless of the culture in which the announcement is made. Then you'll see how, by using resource (.resx) files, you can easily add translated content to your app to reach new markets. Figure 12-8 shows how the finished application will look.

Let's jump into code that will set the stage for the discussion of internationalization of Windows Phone 7 applications.

Figure 12.2. Running the internationalization demo

Notice how the caption in Figure 12-2 reads "en-US." This caption represents two parts of the current Culture setting on Windows Phone 7. The first part—"en"—states that the English language is the current language on this Windows Phone 7 device (or device emulator in your case) and it is a part of an ISO standard to represent culture code associated with the language. The second part—"US"—states that the current locale is the United States, and indicates that dates, currency, and other region-specific items should be shown in the format that is native to people in the United States. That part is an ISO standard as well, to represent a subculture code associated with a country or region.

A concept of culture in .NET Framework refers to a set of user preferences specific to the user, such as dates, currency, and calendar format. Besides CurrentCulture, the CultureInfo class contains many properties that may be of interest to you as you internationalize your applications; you can find the full list at http://msdn.microsoft.com/en-us/library/system.globalization.cultureinfo_properties.aspx. For instance, you could have used the DisplayName property to show a friendlier description of the current culture (in your case, you would get "English (United States)." As mentioned, there is a lot of material to cover when it comes to internationalization—a good place to refer to for more information is the MSDN documentation of the System.Global namespace, located at http://msdn.microsoft.com/en-us/library/abeh092z.aspx.

You might think that the locale setting is of minor importance, yet it is extremely important to properly localize your application: in England, for instance, people speak English (certainly!), but, as mentioned, the numeric date format is "dd/mm/yyyy," where the "dd" is the numeric representation of the day, "mm" is the numeric representation of the month, and "yyyy" is the numeric representation of the year. Compare this to the United States, where people speak English as well, but for numerical date representations, the month comes first. In other words, it would be very time-consuming to keep track of all possible localization issues. In the end, you would very likely make mistakes. It's much easier to stand on the shoulders of giants who have thought through many internationalization issues and have made standard libraries and functions available for your use. Your main task is to make sure to use those libraries.

Suppose that you have built international support for only a portion of an application. What would happen when a user from a different country accesses features of an application that have not been internationalized? Will the application stop working, display a blank screen, etc.? The answer to this question lies in the concept of the .NET framework called culture hierarchy.

There are three types of cultures that you as a developer must be aware of: invariant, neutral, and specific. These cultures are arranged in a hierarchical manner, with invariant culture being at the top of the hierarchy, neutral in the middle, and specific culture at the bottom, as illustrated in Figure 12-3. When international users access Windows Phone 7 applications, the operating system starts at the bottom of this hierarchy and checks whether an application implements the specific culture of a given user. This check includes whether an application has the resources, such as text for menus and labels, which have been localized for the user's location. If such localized resources are not available, the system then moves up the culture hierarchy and checks whether there are provisions in the application for neutral cultures. Finally, if that check fails, the application defaults to the invariant culture, which is the same as English (US) culture.

For example, if a French-speaking user from Canada accesses Windows Phone 7 applications, the first thing the system checks is whether there are application resources implementing specific "fr-CA" culture. If that specific culture is not supported by an application, the system then performs a check of whether the neutral "fr" culture is supported. If the neutral culture is not supported, then the system defaults to the invariant culture, where none of the resources are localized. In this chapter, you will learn how to create resources for specific cultures, and let the .NET Framework do the heavy lifting of defaulting to neutral or invariant cultures when resources specific to users' culture are not available.

Figure 12.3. Culture hierarchy in Windows Phone 7

On Windows Phone 7, the System.Globalization.CultureInfo class contains all of the necessary information about the phone's current culture settings. In this section, you will write code to retrieve basic properties of the CultureInfo class, as well as code to change the current culture of the phone and to react to those changes. In real-world applications, you are not likely to adjust the current culture in code, since the culture setting should be fully controlled by the user.

In the following example, you will create a simple announcement of an upcoming event, and then, with a click of a button, adjust culture settings to properly display the date, time, and the cost of the event in a different region of the world—Spain. To accomplish that, you will instantiate a new CultureInfo class and set the current thread's CurrentCulture property to this new class. Later in this chapter, you will expand upon this example and make your event advertisement speak different languages without having to change the source code.

Note

You are probably wondering where and how the user would set Windows Phone 7 culture. On both the phone and the emulator, the culture is adjusted in Settings

Figure 12.4. Changing the phone's regional settings

In the preceding example, there are a couple of interesting points worth discussing in more detail. The first one is how you switched from one culture to another in code. To accomplish that, you instantiated a new CultureInfo class and set the current thread's CurrentCulture property to this new class. During the instantiation of the CultureInfo class, you passed a string to its constructor representing a specific culture ("es-ES" for Spanish and "en-US" for American English). The second important point is the illustration of the use of standard formatting constructs in your code to make internationalizing your application easier. For example, let's put the following line of code at the end of the ShowEventDetails() function:

txtEventDate.Text = dtLaunchDate.ToString("MM/dd/yyyy");

Now when you run the application, notice how the date will be displayed as "11/10/2011" for both Spanish and English versions of your event. This certainly is confusing for residents of Spain, who would think that the Windows Phone 7 anniversary date is actually on November 10, 2011. Remember to use standard formatting options for all UI elements—in the case of the date, the standard formatting you have used with the following line of code to show the "long date representation" is certainly more appropriate:

txtEventDate.Text = dtLaunchDate.ToString("D");

The third and final important point in the previous example is the ease of switching specific cultures on Windows Phone 7. If you pass "es-MX" instead of "es-ES" into the CultureInfo() constructor in the ToggleEventLocale() function, you can still see the date translated into the Spanish language, but the currency and time are formatted according to the Mexican standard and not the standard of Spain.

Assume now that you have been diligently designing your application for international markets: you have allowed enough space on the user interface for more verbose languages, and you have used only standard formatting options for date, time, and currency values. You still have to perform translation of the application interface and resources to other languages. This could be, certainly, the most labor-intensive part of internationalizing your application.

As mentioned, the application should be flexible enough to function in different locales without the need for code change and recompilation. That means that all resources required for proper functioning of the application need to be located outside the source code of an application and loaded on demand in response to request for culture-specific elements. The location of those resources are the resource-only files, or *.resx files. In this section's example, you will enhance your WP7 Anniversary Party announcement application with the use of .resx files.

One benefit of using .resx files is that Windows Phone 7 will automatically find and use the resource file appropriate for the user's locale based on the current user's culture settings. Another benefit of resource files comes from the concept of culture hierarchy mentioned previously—.NET Framework provides a default fallback mechanism (i.e., going one level up in the culture hierarchy) for those resources that have not been localized. Also, .resx files are easily parseable by external tools, since they are simply XML files. This allows easy editing of those files by third-parties (such as translation services).

Since you have provided a non-locale specific (invariant) file, AppResources.resx, with English (US) captions for the invitation text in it, you see a US English interface upon launching the application. Once you click the button to toggle the application into Spanish, you should see the event title and captions translated into the Spanish language, as shown in Figure 12-8. The cool part about this translation is that it's completely dynamic—the string values are loaded from the resource file instead of being hardcoded!

Figure 12.8. Spanish application interface

If you examine Figure 12-8 carefully, you will notice a couple of things. First, the date of the event almost ran off the screen in Spanish—a clear mistake on your part for not allowing an extra 40 percent of space (by perhaps allowing text wrapping) inside that date value for languages that are more verbose than English. Second, the caption for Cost did not translate into Spanish—it should be Costo in Spanish, not Cost. What's going on here?

The reason for this is that in AppResources.es-ES.resx, there is no entry named EventCost. There is an entry with the name Cost, but that is not the name you are referring to from code. This mistake is a good demonstration of the application's cultural fallback: there was no entry in the Spanish version for EventCost, so the application "fell back" to the default language (English-US) to represent a given caption—the raison d'être of the resource files!

Correct this typo by double-clicking the AppResources.es-ES.resx file and changing the name of the Cost entry to EventCost. Now re-run the application. You should see the proper caption, Costo, for the Spanish version of your announcement.

The main reason our example differs from the approach advocated by the MSDN documentation is that we are dynamically (i.e., in code) changing the culture of an application. We needed to do this for demonstration purposes, since changing local culture is a bit cumbersome if done in the emulator. Dynamic rebinding of elements (to toggle captions between English and Spanish) would be a bit more involved. The addition of a separate class and references to that class, as illustrated in the MSDN documentation, could have also taken away from the main points illustrated during the example. But we could certainly have used an approach other than using the ResourceManager class to accomplish the localization of the application.

In this chapter, you learned how to prepared an application to work in parts of the world other than the United States by using stored culture information and the ToString function to determine how to display data; ISO culture codes to reset an app's CulturalInfo object to the user's preferred language and country environment; and resource files to provide translated versions of field names, documentation, and even media. You learned what specific issues to consider when developing applications for international markets, such as dates, numbers, and currency translations between locales; you also learned how to translate application resources via Visual Studio resource files.

In the next chapter, you will take a look at how to persist files and settings on Windows Phone 7 via the use of local storage. You will save images and application settings and then load them on demand from a local store on Windows Phone 7.