MOTODEV // FROM THE FAST TRACK
Welcome to MOTODEV // Please log in.

Going Global: Key Considerations for Developing Multilingual Mobile Applications

Going GlobalIt's a fact, #1: The United States is not the leader in the use of mobile technology services.

Currently there are over 520 million Chinese mobile phone users. That's more than double the number of users in the U.S., and China is projected to reach 600 million users in 2010. Penetration rates for the U.S. cell phone market are around 75%, but in Western Europe, Japan and Hong Kong penetration has already exceeded 100 %, with multiple cell phones per subscriber being commonplace. In Europe today, over 20% of all mobile phone subscribers have two phones – out of preference. One is a work phone; the other is a private phone. Or one is for calling, the other for texting; one for daytime, the other for evening, etc. Meanwhile developing countries/regions such as Brazil, India, Africa and Latin America have demonstrated blistering cell phone growth in recent years.

Translation: Your profits may be hindered by your application's lack of "localizability" to Asian, European, African, Middle-Eastern and Latin American languages. International mobile phone adoption is a source of tremendous growth in the wireless industry.

It's a fact, #2: If your application is English-only, there may be serious hurdles to expanding it to other languages quickly and effectively.

Translation: An application designed around English, without multilingual considerations, will seriously impede global time-to-market in other cultures, and may allow multilingual-savvy competitors to beat you to other lucrative markets.

The Bottom Line: "Multilingual" development is not only acceptance-smart, it's profit-smart. Unfortunately, many developers are quite "English-centric," leaving the development of a multilingual application as an afterthought, rather than part of their built-in process. It is far more cost-effective for both marketing and development strategies to "think global" early on in the game.

12 KEY CONSIDERATIONS FOR DEVELOPERS

1. Multilingual Design

The application must be designed with multilingual capabilities in mind. This means that an underlying structure, supporting multiple languages, must be implemented. The good news: Once the structure is in place, adding languages is relatively easy.

There are two methods frequently used to implement a multilingual structure:

  1. Language subdirectories: In the simplest form, this means having two-character language names as subdirectories within which the filenames for images, html pages, etc. are identical for each language.
  2. Adding a language-code as part of each filename: For example, a "Submit" button-image might be EN_BTN_SUBMIT.gif for English, FR_BTN_SUBMIT.gif for French, IT_BTN_SUBMIT.gif for Italian, and so on.

Sometimes a combination of both methods is appropriate; the decision should be made via consultation with an experienced globalization vendor, because the application's development platform is often an important consideration.

2. Language Recognition/Choice

How will the application determine the language? Will the user be able to choose or switch? Or will the language choice somehow be automatic?

Often, an application is "installed" in the user's language of choice; but you may wish to use the OS language-setting for an automatic determination of language. For sales demonstrations, and for multi-user interactions, you may want to consider other language-setting methods.

3. Text "Externalization"

ALL translatable text MUST be externalized (that is, not hard-coded into the application.) The application then "pulls" the translations from what is typically called the language-resource-file.

This is probably the single biggest problem that programmers unwittingly cause, probably because there is little or no emphasis on training in our universities in regard to programming for international usage.

4. Text Display

Can Asian characters be displayed properly? What fonts should be used? What font sizes? Some font sizes should specifically be avoided due to pixel-dropping in Asian languages; for example, 9-pt and 11-pt are generally fine for Asian fonts, but 10-pt is not.

5. Cultural Assumptions in the UI

In addition to such considerations as different cultural representations of dates, times, numbers, names, address, and calendars, it is important that the UI (User Interface) be culturally appropriate. This means attention to colors, look and feel, and avoidance of "sentence-building" because the structure and flow of English is quite different from many other languages. As an example, displaying the sentence "Please place my order for [10] [boxes] of [paper].", where "10" and "boxes" and "paper" are drop-down lists for the user to select from, is linguistically the wrong flow of words for many languages and presents gender issues as well.

6. Accessibility

Can your application accommodate the sight-impaired? The hearing-impaired? The U.S. government has accessibility requirements for government use, referred to as "Section 508" (see http://www.section508.gov/index.cfm?FuseAction=Content&ID=3). For an overview of the accessibility requirements of other countries, see http://developer.gnome.org/projects/gap/laws.html.

7. Icons & Images

Are there any culturally inappropriate icons or images in your application? Are you using the globally accepted icons for functions (for example, an envelope for "mail")? Are you using any "hand" symbols? Almost every hand or arm symbol that is considered innocent in one culture could be obscene in another.

8. Tooltips

Do all your icons and links have "tooltips"? Those are the helpful text-boxes that pop up on your website, your installers, or other PC supporting materials when the mouse hovers over them. If not, your application may be deemed "user-unfriendly" in some cultures.

9. Pseudo-Localization

When English is translated, the translated words are often significantly longer. For example, "Cancel" in English could become "Abbrechen" in German, or "Call Settings" might turn into "Programación de Llamada" in Spanish. Pseudo-localization is the term for determining if there are text-expansion issues with other languages, and this will also uncover text-display (font) issues. Particularly with the small footprint of mobile computing, pseudo-localization will uncover space and text display issues in the UI.

10. Keypad Layout and Key Functions

Characters common in American English such as the question mark, exclamation point, double quote, period, ampersand, and dollar sign are not universally used. Spanish will, additionally, require "¿" and "¡" symbols. German and French have upper/lower double quotes or chevrons.

11. Documentation vs. Actual UI

There is nothing more frustrating than inconsistency between the UI and the documentation. If this is a problem in the English version, it will get carried over into the other languages, and perhaps even be amplified. Even a small inconsistency that is easily "brushed over" or ignored in English might lead to an ambiguous or confusing statement in another language.

12. Multilingual Support

Will your website, FAQs, email support, and telephone support have multilingual capability, concurrent with your software release? "User Experience" is not just a marketing catch phrase; it is the single most important factor for the success and longevity of any product.

Being a member of MOTODEV's Fast Track program provides a window into the myriad issues of mobile computing. Medialocate is a Fast Track multilingual partner, and specializes in the educational and technical aspects of getting your application multilingual-ready, and then translating it (localizing is the industry term) into as many as 150 different target languages.

For further information on Medialocate's "Global Interactive Solution for Mobile, Desktop, and Wireless," or for a free "25-Point Website Globalization Readiness" checklist, please contact Medialocate atinfo@medialocate.com or call 1-800-776-0857.