Windows Phone: Globalizing And Localizing Apps
On the heels of Google’s announcement of Google Translate helping with the localization of Android apps, Microsoft is now talking up how Windows Phone developers can globalize and localize their apps. There is a difference between the two, I can assure you.
Kim Cameron of the Windows Phone team briefly goes over what it means for an app to be globalized as there’s not much to it. Globalization just means that your app will display the native currency and time format for the country in which your app is sold.
Cameron clarifies that you can choose not to localize an app and still sell it on the global marketplace. As long as you globalize the app, it will be available to all. The problem, of course, comes with the people of various countries that don’t speak English. Even if the currency and time format is native, the language won’t be.
Cameron does offer two reasons why you might not want to localize. Those reasons being your app title and language-specific apps. They’re both simple enough with the first meaning the title of your app should reflect what it is. If your app is named after a common item, you should translate it into a person’s native tongue. If your app is named after your company, don’t translate it as they will search for your company’s name in your native language. Language-specific apps are obvious for those apps that only want to target a specific audience.
When it comes to the actual localization process, you’ll want to localize four things – app title, app description, application bar and app text. That’s easy enough to remember and the process of doing it is just as easy as long as you know the language.
The app description is a bit more involved. When you submit your app to App Hub, it detects if your title has been localized into any other languages. From here, it will prompt you to enter in a description for each language that your app is in.
Localizing text is by far the most involved process when it comes to the localization process. First you’ll want to select your neutral language, or default language. By default, your neutral language will be set to the language in which you installed the Windows Phone SDK in.
From here, you have to create a resource file for each language. Then with a bit of coding magic, you can have the resource file replace the default language in your app through data binding. It makes it so that developers don’t have to hardcode each version of their app separately.
You can also do this for specific regions that speak the same language. With this tool, developers can create an app in Spanish, but specify that there is a resource file for Mexican Spanish. Normally Windows Phone would just select Spain Spanish regardless, but you can make the app target the specific region file through some code magic.
If your app uses an application bar, be sure to localize your text before you localize the application bar. You needn’t worry about this if you don’t use one in your app.
For all the examples and specific code, check out the Windows Phone blog post. There’s plenty of examples and code for you to go through. It’s a bit more complicated than Google’s localization process, but it seems to get the same stellar results.