Going Global: Key Considerations for Developing Multilingual Mobile Applications

Medialocate USA, Inc.

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

Currently there are over 815 million Chinese mobile phones in use, that's nearly triple the number of mobile phones in the US. 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 % (multiple cell phones per subscriber). 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 still quite "English-centric" and the development of a multilingual application is often more of an "afterthought", rather than consisting of built-in process steps. It is far more cost-effective for both marketing and development strategies to "think global" early on in the game.

For developers, here are some key considerations:

• 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.

• 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?

• Text "Externalization"

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

• 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.

• Cultural Assumptions in the UI

  In addition to such things as different cultural representations of dates, times, numbers, names, addresses, 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" (the structure and flow of English is quite different from many other languages).

• Accessibility

  Can your application accommodate the sight-impaired? The hearing-impaired? The US 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.

• Icons/Images

  Are there any culturally inappropriate icons/images? 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 deemed "innocent" in one culture could be obscene in another. Do all your icons have "tooltips"?

• 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.

• Keypad layout and Key Functions

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

• Documentation vs. Actual UI

  There is noting more frustrating than inconsistency between the UI and the documentation. If this is a problem in the English, it will get carried over into the other languages.

• Multilingual Support

  Will your website, FAQs, email support, and telephone support have multilingual capability, concurrent with your software release? Being a member of FastTrack provides a window into the myriad issues of mobile computing. Medialocate is a FastTrack 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 internationalization/localization services, or for a free "25-Point Website Globalization Readiness" checklist, please contact Medialocate at info@medialocate.com or call 1-800-776-0857.