Summary

Web and mobile applications today should be designed and built from the ground up to support international markets, unless there is a strong business case to restrict them to a single market.

The availability of tools and frameworks to provide your application with international support (including multiple languages, currencies, locales, etc.) lowers the barrier for application development teams, but the technology build is only part of the challenge of supporting international markets.

You should also consider how to include local market experts in the decision-making process, and integrate local market requirements, including market-specific content and user experience (UX). You should also adapt your processes to enable translation and localisation to happen as early as possible in the product release cycle to achieve the best UX across all markets. Finally, make sure you understand the impact of mobile application proliferation and plan for more complex production infrastructure and operations processes.

Introduction

International software applications are those which present information in the user’s native language, currency and locale (display conventions). For example, someone in North America would expect “March 4^th 2011″ to be written “03/04/2011” but someone in the UK or Eire would expect the same date to be represented “04/03/2011”. Likewise, someone familiar with the Arabic, Hebrew or Urdu script would expect to begin reading and interacting with a web page or mobile app from the top-right of the screen, rather than the top-left, as those familiar with Latin, Greek and Cyrillic-based scripts would do. The use of written quotation marks also differ from place to place: German uses „.. “, French and Greek use «…», and English uses “…”. Each of these conventions is correct within its own language/locale context and incorrect without.

Modern software development frameworks and tools make the process of developing international support relatively straightforward, although international support does add an effort overhead of perhaps 20-40% on top of an application developed for a single market, depending on the complexity.

However, tempting as it might be to cut corners and release the first version of your web or mobile app without international support (to meet time or budget pressures), you should think carefully before leaving out international support; retro-fitting international support to a previously single-market application is painful, sometime expensive and completely avoidable process.

The Basics of International Applications

There are several basic features you should include in your international application. Most of these will be provided by your chosen development framework, but you may need to configure or enable some options:

• Unicode support – this is the single most important feature you can include. Unicode is the text format which supports almost all characters from almost all scripts in use in the world today. You should also understand text encoding, particularly UTF-8, the most widely-used Unicode encoding format, and how to parse text to and from this format.
• Unicode-friendly data structures – all modern databases and software languages support Unicode, but some require you to use specific data types or structures for Unicode. For example, when using Microsoft SQL Server, the nvarchar type should be used in place of the older varchar type in order to hold Unicode characters safely. Similarly, MySQL requires you to specify a UTF-8 character set when storing or requesting data in order to read Unicode data.
• UTC date calculations – all date/time calculations should be with reference to the international standard UTC time, which is independent of time zones and daylight saving offsets. Make sure your software framework supports time zone offset and daylight saving calculations, and keep your database in UTC.
• Decimal point – some countries use “.” and some use “,” for the decimal point. Your software framework should handle this for you if configured and used correctly.
• Set the Locale/Culture – setting the “locale” or “culture” in an application or processing thread typically allows the software framework to handle most international formatting rules, removing a major complication for developers. For instance, in C# use Thread.Culture, in Java use the Locale class, and in Ruby use the I18n module.
• Avoid text in graphics – try to avoid using text within images and static Flash files, as this creates a substantial overhead when additional support for other locales. Embedding fonts into Flash files which do not support Unicode characters is also problematic. Use browser-based CSS typefaces and XML include files to achieve the same effects as embedding text in graphics.

Following these basic technical design precepts will avoid many of the common problems associated with international software applications.

Localise Early

For many, the process of building an international application is to create the initial version in a source language (often the language of those developing the app, or else US English), and only then create “localised” versions of the app for other languages and markets. This process is usually called localisation and is usually associated with two other concepts:

• Localisation (L10n) – creation of locale-specific assets to adapt the application for a particular locale, country or region.
• Internationalisation (i18n) – preparing an application to support international use.
• Globalisation – the combination of i18n and L10n.

This step-by-step process can be visualised in the following figure:

However, there is a major flaw with this common approach of leaving localisation until the very end of the process: it fails to account for the changes and customisations usually needed for each locale or market, which generally leads to substandard or even misleading user experience (UX) for all users apart from those in the source language group.

The Effect of Grammar on Localisation

In many languages, the form of words changes depending on the grammatical context. In both German and Greek, the possessive form of a noun is spelled differently from the normal form. So whilst in English, the spelling of the noun “money” does not change in the possessive (“of the money”), in German, “das Geld” changes to “des Geldes“, whilst in Greek “τα χρήματα” (ta chrimata) changes to “των χρημάτων” (ton chrimaton). This means that the application may need to be re-worked to support languages other than English; any per-language reference data may need to be given additional forms (e.g. possessive), or else the application re-worked to remove the use of grammatical forms problematic in other languages.

These problems are not always easy to predict, so deciding not to change the application to accommodate these localisation changes risks leaving potentially the majority of your users with poor UX – why would you want to do that?

The solution is to localise early in the process of developing the application, so that any necessary changes to the application can be made before the technical and functional design is completed, allowing for a more natural UX across all locales. This process could be represented like this:

Figure 2

Following an initial i18n preparatory phase, the application is designed and built with several different locales/languages concurrently, leading to a final version which inherently supports all the needs of each local market.

By following a more holistic process where all locales contribute to the design and development process, the resulting application should provide a superior UX across all those locales, rather than merely the source locale.

In Part 2 of this  two part post, we’ll look at using local market knowledge to speed up localisation efforts, the pros and cons of a translation management system, and some way to avoid mobile app “sprawl”.