The other day Jeff Wilcox had a great post on Metro design guidance for Windows Phone developers. While it covered a lot of ground is an outstanding resource, there was a couple of topics that weren’t touched upon, globalization and localization. Given the exponential growth we’ve seen in the mobile marketplace, you’ll need to understand these are concepts if you want to create a great user experience for as many users as possible around the world. You’ll also want to think about them while you’re designing your application, NOT RIGHT BEFORE YOU SHIP IT. I’ve seen numerous applications on a variety of platforms (Windows, web, and mobile) try to throw globalization and localization in at the 11th hour only to realize that UI’s need to be refactored to account for right-to-left languages, or languages with extremely long words. The goal of this post to help you understand how to implement globalization and localization in your Windows Phone applications so you can get your next great app on as many devices as possible!
In case you have never had to deal with globalization or localization in the past, let’s start with some definitions. First globalization:
A globalized application targets multiple languages or cultures. A globalized application can display content such as date, time, currency, numbers, calendars and sort order in different formats for specific regions or cultures. For example, in the U.S. the date is displayed as month/day/year, but the date is displayed differently in other countries or regions. A globalized application also supports different input methods provided by the operating system.
Localization describes the process of adapting an application for a specific local market. This includes translating the user interface, resizing dialog boxes, customizing features, and testing results to ensure that the application works for the target market.
Now that we have a general idea of what globalization and localization refer, let’s tackle making a Windows Phone application globalized. There are four specific things you need focus on to ensure your application is globalized:
Dates. Different countries and regions display dates differently. For example, in the United States dates are typically displayed as month/day/year. However, in many other countries dates are displayed as day/month/year. It’s important that you take these differences into account as a date like 12/11/2011 can have two different meanings (December 11th, 2011 in the US and November 12, 2011 elsewhere).
Time. Different countries and cultures display time differently as well. In the US, it’s common to display time using a 12 hour clock (i.e. 10:04 PM). However, many countries use a 24 hour clock (i.e. 10:04 PM = 19:02).
Currency. Many countries have their own currencies (i.e. US Dollar, Japanese Yen, etc.) When displaying currencies you’ll want to make sure to display the appropriate currency symbol. You’ll also want to make sure that the numeric value is formatted appropriately as well since some countries use commas and decimal points differently (some countries use 1,000.00 while other use 1.000,00 to represent the number 1000).
Sorting. NEVER, EVER implement your own sorting algorithm in a globalized application. The CompareInfo property of the CultureInfo class defines how sort strings for each culture. By simply using the Sort method of something like the Array class, you will get the benefits of this property doing the culture sensitive sorting for you.
Below is a picture of how a globalized application should look when running under different cultures:
Did you know that you can change the language the emulator runs in? Simply go to the Settings application, select region & language, choose your display language of choice (current options are German, English (UK), English (US), Spanish, French and Italian). To apply the changes you’ll then have to click a link at the top of the main page in the Settings application that will “reboot” the emulator into your desired language. Pretty handy for testing your application’s globalization/localization.
So far so good, our app is globalized. However, we have some issues in terms of localization:
As you can see in the picture above our application isn’t localized for Spanish as the various labels as well as the text associated with ApplicationBar is not translated appropriately. Taken care of this is pretty straightforward:
- Add resource (.resx) files to your project to store various translated strings and/or images.
- Perform the translations (for strings I like to use Bing Translator).
- Set the neutral language for the application via the Assembly Information that can be accessed in the Application tab of the project’s properties page.
- This next one is an bit tricky. You need to close (or unload) the project in Visual Studio and manual modify the xml that is part of the .csproj file. Specifically you’ll need to update the SupportedCultures element to include the cultures you plan on supporting. In the case of my sample app, it would look something like <SupportedCultures>es-ES</SupportedCultures>.
- You’ll then need to bind your UI elements to the translations. You can do this in a number of ways. Since I use MVVM for my Windows Phone development, I typically expose the resources as a property on the ViewModel being used by the page. However, there is one caveat here. If your application uses the ApplicationBar (as my sample app does) you can’t bind the text associated with its buttons and menu items in xaml. This is due to the fact that the ApplicationBar is not actually a Silverlight control. As a result, you’ll need to construct your ApplicationBar in code to localize it properly.
Once you do this, you should get an application that looks something like this:
As you can see it’s pretty easy to globalize and localize your Windows Phone applications, so there’s no reason why you shouldn’t being doing it RIGHT NOW!
If you want the source code for this demo app to see how all the pieces work, you can get it here.