Do you want to make your new app accessible for a worldwide market and potentially increase the number of customers for it? Windows 8 makes it easier than ever to write an app that can be tailored for different languages and cultures. Here, I’ll show you how to design a new world-ready app with little to no code modification.

Sara Thomas described the market opportunities available to you in her post about the Multilingual App Toolkit. I hope her mention of “a potential reach of over 4.5 billion people,” and the possibility to sell apps “in more than 200 markets” entices you to read on.

A scenario

Let’s say you’re designing a Windows Store app that runs on a tablet and is used at a car rental lot. The rental agent and the customer use the app to see a picture of a rental car, its description, and its location on the lot. They take the tablet with them as they enter or verify information about the car (such as current mileage) and note any existing damage. The customer signs her agreement to the contract on the tablet.

Car rental app with labels and controls in English

The same app is used when the car is returned. They enter the new mileage and note any additional damage to the car. This is a universal experience. People all over the world rent cars and follow a similar protocol. This app is a great candidate for a global market, opening up many opportunities for you to sell your app.

There are two closely-related processes you employ as you develop your app:

  • Globalization: The process of designing and developing an app to function in multiple geographic areas and languages.
  • Localization: The process of adapting your app (including text and non-text elements) to meet the language, cultural, and political expectations of a specific local market.

Globalization

A few things to think about when you globalize your app:

  • Design a flexible app layout.

Don’t design apps with static forms. Windows Store apps support layout features that enable your app to be flexible and to adjust to varying text sizes, layouts, and orientations. See Choosing a layout in the Dev Center for recommendations.

If for some reason you do need to use static forms, ensure that text fields and button captions are large enough to hold translations. English text strings can increase by 40% when translated. Additional vertical space is needed for languages with marked characters such as Å or Ņ, or which require larger minimum font sizes to remain legible.

  • Create text and images that are easy to translate.

You want your app to be easily translated to other languages and cultures, whether you do the translation yourself or have it done by a third party.

Things to think about:

    • Avoid colloquialisms or metaphors that are specific to a single language.
    • Avoid technical jargon, abbreviations, or acronyms that are difficult to translate.

If you do adopt an informal voice or tone in your app, or if it does employ jargon for a specific demographic, be sure to explain this for your translators.

    • Avoid text in images that needs to be translated.
    • Also avoid culture-specific images (such as mailboxes) that are not common around the world. If these cannot be avoided, provide localized images (I’ll touch on this later).
  • Be sensitive to cultural differences.

Images that might be appropriate in your own culture may be offensive or misinterpreted in other cultures.

Things to think about:

  • Avoid the use of religious symbols, animals, or color combinations associated with national flags or political movements
  • Avoid maps that include controversial regional or national boundaries. Refer to a nation as a "country/region". You don’t want to put a disputed territory in a list labeled "Countries."
  • Be mindful when using color to convey meaning. Colors can have unexpected connotations in some cultures. Try to convey information by additional means such as size, shape, or a label, for the benefit of colorblind readers.
  • Use globalization APIs to express dates, times, numbers, and currencies in appropriate formats.

  • Our car rental app displays the dates and times when the car is checked out and returned, and we want to display them in the appropriate language and format. Make sure the mileage is formatted with the proper digit grouping, and the currency of the rental price is displayed properly.

    Your Windows Store app can use globalization namespaces to create formatting objects. These objects supply strings formatted for the user’s preferred language. For example, to use JavaScript to display today’s date whatever the user’s language:

    JavaScript:

    var dtf = new Windows.Globalization.DateTimeFormatting.DateTimeFormatter
    ("dayofweek day month year");
    var now = new Date();
    var el = document.getElementById('todaysDate');
    el.TextContent = dtf.format(now);

    And in C#:

    var dtf = new Windows.Globalization.DateTimeFormatting.DateTimeFormatter
    ("dayofweek day month year");
    DateTime now = DateTime.Now;
    todaysDate.Text = dtf.Format(now); // todaysDate is a XAML TextBlock.

    For more info, see Quickstart: Using global-ready formats. And look at our formatting samples:

    Localization

    Now that you have all the info you need to design a globalized app, you'll want to start diving into the code. As you write your app make use of Windows 8 resource technology that help with localization.

    Don’t write your app with the idea that you’ll localize it for another language later when necessary. The best way to make your app localizable is to think of the first version as being localized for your initial language! To do that, follow these steps right from the start:

    Separate code from resources.

    As you write your code, don’t include any hard-coded strings, display elements, or controls. Not a single one—not a title, label, button caption, image caption, or paragraph! The complete separation of code and string resources gives two complementary benefits:

    • You can localize resources separately from the code. Translators don’t need to compile your code, so you don’t have to worry about bugs being introduced during localization.
    • You can maintain the code separately from the content of the resources. Code can be modified in a single code base, which reduces the risk of changing localized content.

    In your markup, refer to resources using resource identifiers (we’ll see how in the next section). The strings are retrieved from the appropriate resource and displayed when the page is processed.

    In your code, load strings using resource identifiers and the appropriate versions are retrieved.

    Write markup and code that use resources.

    HTML and JavaScript

    I’ll present a few highlights of a process that is covered more completely in Quickstart: Using string resources (Windows Store apps using JavaScript and HTML). Use the info in this quickstart when you are actually coding.

    In Visual Studio, create a folder to contain the resource files. Place the resource file for each language in a subfolder named for the BCP-47 language tag. The resource file itself is typically named resources.resjson.

    For example, for United States English, create the following resources.resjson file in a strings/en-US folder:

    {
    "greeting" : "Hello",
    "_greeting.comment" : "A welcome greeting.",

    "farewell" : "Goodbye",
    "_farewell.comment" : "A goodbye."
    }

    This is strict JavaScript Object Notation (JSON) syntax, where you must place a comma after each name/value pair, except the last one. In this example, "greeting" and "farewell" identify the text strings that are displayed. We also created "_greeting.comment" and "_farewell.comment" as comments describing the strings. The comments are the place you provide any special instructions to translators about voice, tone, or meaning.

    In your HTML, refer to the string resources using the resource identifiers:

    <h2><span data-win-res="{textContent: 'greeting'}"></span></h2>
    <h2><span data-win-res="{textContent: 'farewell'}"></span></h2>

    And in JavaScript, you can get strings and set them in your HTML like this:

    var el = document.getElementById('header');
    var res = WinJS.Resources.getString('greeting');
    el.textContent = res.value;
    el.setAttribute('lang', res.lang);

    XAML and C#/VB/C++

    Here are more highlights, this time from Quickstart: Using string resources (Windows Store apps using C#/VB/C++ and XAML).

    In Visual Studio, create a folder to contain the resource files. You place the resource file for each language in a subfolder named for the BCP-47 language tag. The resource file itself is typically named Resources.resw.

    For example, for United States English, create the following Resources.resw file in a Strings/en-US folder:

    Resource file showing name, value, and comment for text strings to be displayed

    In this example, "Greeting.Text" and "Farewell" identify the strings that are to be displayed. The identifier "Greeting.Text" includes the property of the XAML control that receives the string, and "Farewell" identifies a string to be loaded by code. The comments are the place you provide any special instructions to translators about voice, tone, or meaning.

    In your XAML, refer to the string resource using the resource identifier and the property:

    <TextBlock x:Uid="Greeting" Text="" />

    In C#, you can get strings like this:

    var loader = new Windows.ApplicationModel.Resources.ResourceLoader();
    var string = loader.GetString('Farewell');

    Provide Localized images.

    If you aren’t able to create images that don’t require translation, you can create localized versions, and the correct file can be automatically loaded by your app. In fact, apart from localization, you use the same resource technology to create multiple versions of your images for different scaling factors, contrast settings, and more.

    For example, you can create your logo file in combinations of different scale factors, contrast settings, and multiple languages. Give them qualified names such as

    • Images\en-Us\logo.scale-100.png
    • Images\en-Us\logo.scale-140.png
    • Images\fr-Fr\logo.scale-100.png
    • Images\fr-Fr\logo.scale-140.png

    Your app simply refers to Images/logo.png, and the appropriate image is loaded. See How to name resources using qualifiers.

    Windows Store requirements.

    I lured you in with a large number of markets for your app, so you’ll want to meet the Windows Store requirements to begin selling it. Read on for detailed info about app certification and choosing markets and languages.

      • Certification languages: The languages that we support when confirming that your app meets our certification requirements. Your app must support at least one of these languages.
      • Allowable languages: Languages that we support but do not use as part of the certification process. Your app can support as many of these languages as you like, as long as it supports at least one of the certification languages.

    Summary

    So how did our car rental app do? If we built it correctly, it contains all its text strings and images in resources. It displays dates, times, numbers, and currencies properly formatted for the user’s preferred language. And when we want to localize it for an additional market, we change no code—we add a new resource file (translated by ourselves or sent to a third-party translator), create new image files (if necessary), and rebuild the app.

    car rental french

    For more info about processes described here, see

    --Ray Shuman, Programming Writer, Windows Content Services

    Special thanks to Karl Bridge, Rylan Hawkins, Dave Shevitz, and Bob Watson for their help and contributions to this post.