Guidelines and checklist for globalizing your app (Windows Store apps using C#/VB/C++ and XAML)

Use the correct formats for numbers, dates, times, addresses, and phone numbers.

The formatting used for numbers, dates, times, and other forms of data varies between cultures, regions, languages, and markets. If you're displaying numbers, dates, times, or other data, use globalization APIs to get the format that the user prefers.

For more info, see Quickstart: Using global-ready formats.

Support international units of measurement and currencies.

Different units and scales are used in different countries, although the most popular are the metric system and the imperial system. If you deal with measurements, like length, temperature, or area, get the correct system measurement by using the Globalization namespace. If your app supports displaying currencies, make sure you use the correct formatting. You can also get the currency for the user’s geographic region by using the CurrenciesInUse property.

Use Unicode for character encoding.

By default, recent versions of Microsoft Visual Studio use Unicode character encoding for all documents. If you're using a different editor, be sure to save source files in the appropriate Unicode character encodings. All Windows Runtime APIs return UTF-16 encoded strings.

Don't use language to assume a user's location, and don't use location to assume a user's language.

In Windows, the user's language and location are separate concepts. A user can speak a particular regional variant of a language, like en-gb for English as spoken in Great Britain, but the user can be located in an entirely different country or region. Consider whether your apps require knowledge about the user's language, like for UI text, or location, like for licensing issues.

For more info, see How to manage language and region.

Don't use technical jargon, abbreviations, or acronyms.

Technical language is less likely to be understood by non-technical audiences or people from other cultures or regions, and it's difficult to translate. People don't use these kinds of words in everyday conversations. Technical language often appears in error messages to identify hardware and software issues. At times, this might be be necessary, but you should rewrite strings to be non-technical.

Avoid political offense in maps or when referring to regions.

Maps may include controversial regional or national boundaries, and they're a frequent source of political offense. Be careful that any UI used for selecting a nation refers to it as a "country/region". Putting a disputed territory in a list labeled "Countries", like in an address form, could get you in trouble.

Don't assume that sorting is always alphabetic.

For languages that don't use Latin script, sorting is based on things like pronunciation, number of pen strokes, and other factors. Even languages that use Latin script don't always use alphabetic sorting. For example, in some cultures, a phone book might not be sorted alphabetically. The system can handle sorting for you, but if you create your own sorting algorithm, be sure to take into account the sorting methods used in your target markets.

Separate resources such as UI strings and images from code.

Design your apps so that resources, like strings and images, are separated from your code. This enables them to be independently maintained, localized, and customized for different scaling factors, accessibility options, and a number of other user and machine contexts.

Separate string resources from your app's code to create a single language-independent codebase. Always separate strings from app code and markup. and place them into a resource file, like a ResW or ResJSON file.

Use the resource infrastructure in Windows to handle the selection of the most appropriate resources to match the user's runtime environment. For more info, see Guidelines for app resources.

Set your default language, and mark all of your resources, even the ones in your default language.

Always set the default language for your apps appropriately. The default language determines the language that's used when the user doesn't speak any of the supported languages of the app. Mark default language resources, for example en-us/Logo.png, with their language, so the system can tell which language the resource is in and how it's used in particular situations.

Use resource identifiers in the code and markup to refer to resources.

Instead of having string literals or specific file names for images in your markup, use references to the resources. For XAML, see [link], for HTML see link. Be sure to use unique identifiers for each resource.

Support mirroring.

Text alignment and reading order can be left-to-right, as in English, or right-to-left (RTL), as in Arabic or Hebrew. If you are localizing your product into languages that use a different reading order than your own, be sure that the layout of your UI elements supports mirroring. Even items such as back buttons, UI transition effects, and images may need to be mirrored.

For more info, see How to adjust layout for RTL languages and localize fonts.

Use short strings.

Shorter strings are easier to translate and enable translation recycling. Translation recycling saves money because the same string isn't sent to the localizer twice.

Strings longer than 8192 characters may not be supported by some localization tools, so keep string length to 4000 or less.

Comment strings.

Ensure that strings are properly commented, and only the strings that need to be translated are provided to localizers. Over-localization is a common source of problems.