Localization Best Practices for Windows Phone

Separate resources, such as strings, images, and videos, from your code into separate resource-only files. Doing so ensures that your code is language independent and 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 Application for Windows Phone.

Localize specific strings, not tags. Consider the following examples:

Including the above <link> tag in the resources means that it too will be localized, rendering the tag invalid. Only the strings themselves should be localized.

There is limited space available for a user interface on a mobile device. To accommodate localized languages, ensure that your string length is approximately 40% longer than what you would need for the English language. In addition, enabling multiline support and text-wrapping in a control will leave more space to display each string.

Consider the following string: "The {0} could not be synchronized". A variety of words could replace {0}, such as appointment, task, or document. While this example would appear to work for the English language, it will not work for the corresponding sentence in another language.

As another example, consider the sentence "Remind me in {0} minute(s)". While using "minute(s)" works for the English language, other languages may use different terms. For example, the Polish language uses "minuta," "minuty," or "minut" depending on the context.

To solve this problem, localize the entire sentence, rather than a single word. While doing this may seem like extra work and is an inelegant solution, it is the best solution because:

• A clean error message will be displayed for all languages.

• Your localizer will not need to ask about what the strings will be replaced with.

• You will not need to implement a costly code fix when a problem like this surfaces after your application is completed.

Do not assume that all languages use parameters in the same order.

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

While re-using a string may seem like the best solution, doing so can cause localization problems if the context of the string changes.

For example, consider the strings 'on' and 'off'. While in the English language, using these strings will work in the context of Flight Mode, Bluetooth, and the device toggle switch, in Italian, the translation of 'on' and 'off' is dependent 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 noun format.

When designing your resources, ensure that each resource is identified with a unique value such as an ID or common name. Then, when accessing the resource access it by only using the unique value, which will not change, rather than the actual value of the resource, which will change depending on language.

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 a project.

There are a number of ways to approach the translation process, depending on the volume of strings to be translated, the number of languages to be translated, and how the translation will be done (such as in-house versus hiring an external vendor). Consider the following options:

• The resource files can be translated by opening them directly in the project. This approach works well for a project that has a small volume of strings and that needs to be translated into two or three languages. This approach could be suitable for a scenario where a developer speaks more than one language and is willing to handle the translation process. While this approach has the benefits of being quick, requires no tools, and minimizes the risk of mistranslations, this approach is also not scalable.

• Resource files are in the .xml format, thus they could alternately be handed off for translation using 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 could work well for projects that need to be translated into a small number of languages.

Additionally, consider the following suggestions:

• Use a localization tool. There are a number of localization tools available that can parse resource files and 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 with a large volume of strings, but 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 advice about tools and processes as well as translating your resource files. While this is an ideal solution, it is 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 considered a noun or a verb. Explain fabricated words to your localizers by using terminology tools. Keep strings grammatically correct, unambiguous and as non-technical as possible to avoid confusion.