Localization best practices for Windows Phone 8

Article
05/20/2016

[ This article is for Windows Phone 8 developers. If you’re developing for Windows 10, see the latest documentation. ]

To build an app that can be easily localized, consider the following best practices. For more info about general globalization and localization concepts, see Globalization and localization for Windows Phone 8.

This topic contains the following sections.

Separate resources from code

Separate resources, such as strings, images, and videos, from your code; move them into separate, resource-only files. This ensures that your code is language-independent and that it can support different language encodings. Unicode is the preferred solution. For an example of how to create separate resource files, see How to build a localized app for Windows Phone 8.

Tip

The Multilingual App Toolkit, which integrates with Visual Studio Professional 2012 and Visual Studio Express 2012 for Windows Phone, provides translation support, translation file management, and localization tools to create Windows Phone apps and Windows Store apps. Use this toolkit to connect with the Microsoft Translator for quick translation suggestions. For more information, see How to use the Multilingual App Toolkit.

Don’t over-localize

Include only the precise string that needs to be localized. For example, don’t include tags in the localizable string. Consider the following examples.

Over-localized string	Correctly localized string
<link>terms of use</link>	terms of use
<link>privacy policy</link>	privacy policy

In the preceding examples, including the <link> tag in the resources means that it too will be localized, which renders the tag invalid. Localize only the strings themselves.

Increase string length

A mobile device has limited space for a UI. To accommodate localized languages on Windows Phones, use a string length that is approximately 40 percent longer than what you would need to display the string in the English language. In addition, enabling multiline support and text wrap in a control gives you more space for displaying each string.

Localize sentences rather than words

Consider the following string: "The {0} could not be synchronized". A variety of words could replace {0}, such as “appointment,” “task,” or “document.” Although this example would appear to work for the English language, it doesn’t work for the corresponding sentence in a different language, such as German.

English (United States)	German (Germany)
The appointment could not be synchronized.	Der Termin konnte nicht synchronisiert werden.
The task could not be synchronized.	Der Aufgabe konnte nicht synchronisiert werden.
The document could not be synchronized.	Der Document konnte nicht synchronisiert werden.

As another example, consider the sentence "Remind me in {0} minute(s)". Although using "minute(s)" works for the English language, a different language may use a different term. For example, in Polish it could be "minuta," "minuty," or "minut," depending on the context.

To solve this problem, localize the entire sentence, rather than a single word. Although this may seem like extra work and might be an inelegant solution, it’s the best solution because:

A clear error message is displayed for all languages.
Your localizer won’t be uncertain about what the strings will be replaced with.
You won’t need to implement a costly code fix if this kind of problem appears after your app is completed.

Ensure correct parameter order

Don’t assume that all languages use parameters in the same order.

For example, consider the string "Every %s%s", in which the first %s is replaced by the name of a month, and the second %s is replaced by a day of the month. This example works for the English language, but not for the German language, in which the date and month are displayed in reverse order. To solve this problem, change the string to "Every %1%2", so that the order is interchangeable depending on the language.

Don’t reuse strings

Although reusing a string may seem like the best solution, it can cause localization problems if the context of the string changes.

For example, consider the strings "on" and "off". Although in the English language using these strings works in the context of Flight Mode, Bluetooth, and the device toggle switch, in Italian, the translation of “on” and ”off” depends on the context of what is being turned on and off. In this example, you would need to create a pair of strings for each context.

Additionally, a string like "text" or "fax" could be used as both a verb and a noun in the English language, which can confuse the translation process. Instead, create a separate string for both the verb and the noun format.

Use unique attributes to identify resources

When you design your resources, identify each resource by using a unique value, such as an ID, or by name. Then, when you access the resource, you can access it only by using the unique value, which doesn’t change, rather than by using the actual value of the resource, which can change depending on the language.

Choose an appropriate translation approach

After strings are separated into resource files, they can be translated. The ideal time to translate strings is after the strings in your project are finalized, which usually happens at the end of the development process.

You have several options in the way that you approach the translation process, depending on the volume of strings to be translated, the number of languages that need to be translated, and how the translation will be done, for example, in-house versus using an external vendor. Consider the following options:

The resource files can be translated by opening them directly in the Visual Studio project. This approach works well for a project that has a lower volume of strings, and which needs to be translated into two or three languages. This approach could be suitable for a scenario in which a developer speaks more than one language and is willing to undertake the translation process. Although this approach has the benefits of being quick, it requires no tools, and it minimizes the risk of mistranslations, it’s not scalable.
Resource files are in XML format, so they can be handed off for a translation process that uses any text editor. The translated files would then be copied back into the project. This approach carries a risk of translators accidentally editing the XML tags, but it allows translation work to take place outside of the Visual Studio project. This approach also could work well for projects that need to be translated into a small number of languages.

Additionally, consider implementing some or all of the following suggestions:

Use a localization tool. There are a number of localization tools that can parse resource files and which allow only the translatable strings to be edited by translators. This approach reduces the risk of a translator accidentally editing the XML tags, but has a drawback of introducing a new tool and process to the localization process. Using a localization tool is useful for projects that have a large volume of strings, but which are localized into a small number of languages.
Use a localization vendor. If your project contains a large volume of strings, and translation is required for many languages, consider using a localization vendor. A localization vendor can give you advice about tools and processes, in addition to translating your resource files. Although this is an ideal solution, it’s also the most costly option, and the turnaround time to receive your translated content may increase.
Keep your localizers informed. Inform localizers of strings that can be used as either a noun or a verb. Explain uncommon jargon and technical terms to your localizers by using terminology tools. To avoid confusion, keep strings grammatically correct, unambiguous, and as nontechnical as possible.

Share via