Regionalizing Your Mobile Designs, Part 1

Doing More Than Translation

Of course, you must provide the content in your digital product in other languages. But don’t create your entire design in your product team’s native language, then just translate the text to the other languages. Instead, render, or localize, the text into the language your intended local audiences would understand. Internally, it would be best to avoid the use of the word translate to ensure that no one thinks they can fake it and just use Google Translate.

Don’t just translate individual words or phrases. Instead, rewrite the text in the new language to ensure that it has the proper structure and uses other appropriate aspects of a specific language—such as gendered words and plurals.

The context of a phrase you’re converting is critical. For example, if a translation service saw the word close without the context of the corresponding user interface, they wouldn’t know whether it means near versus far, refers to a process function such as closing a ticket; or means to close a dialog box, window, or app. Any number of words might be appropriate for each of these meanings, but the wrong one could be confusing or even dangerous.

Too often, translators receive words or individual phrases in isolation, without any order or context. Instead, you should integrate translators with your team. This would ensure they understand the product and can see the entire user interface and its interactions, so they can understand what they’re labeling and know what user interface to associate with the text.

Because of the large number of users who might not know an app’s primary language or be native speakers or who do not speak a dialect that varies enough from a language they know to be confusing, you should avoid using slang, jargon, colloquialisms, or metaphors, even in your base UI language. Avoid jokes or anything else an international audience might not understand or that some users might find insulting.

If your company uses very casual marketing language or you’re dealing with large amounts of written content such as articles or reviews, handling this kind of text is very different from localizing UI language. You’ll need not just dedicated translators but probably localized marketing and editorial staff as well, to make sure the content keeps the proper tone and makes sense.

Using People, Not Just Tools or Services

In modern business, it seems that everything gets outsourced these days, including translation services. As with any vendor, you can’t just throw your content over the wall and expect good results. You need to manage the relationship with your translator, monitor their output, and make sure they do translations completely, competently, and consistently.

One approach to doing this is working with your content manager or content designer. (You should have one of these anyway.) Someone on your team should be a writer and focus only on that work. They shouldn’t just create text and labels but also manage the content by creating and maintaining documents in which all the text stored, as well as style guides that indicate how to write content and a glossary of terms.

You can see how this would help with localization. You wouldn’t need to have anyone go page by page. Instead, they could start by translating tricky technical or branded terms. By using this approach, you can make your text more consistent and better structured.

Plus, you should try to engage locals who are familiar with your product—at least to review the output of the translation service. They could even help write the text and would often be happy to do so. Many organizations already have offices around the world or partnerships with local distributors, sales, or repair or customer services. In my experience, they’re almost always thrilled to have someone from corporate headquarters ask for their help and are willing to put in the time, as long as you compensate them for the extra work.

Not Fearing Other Languages

Do not avoid implementing other languages such as German just because their words are generally longer, making it impossible to fit long words into limited spaces.

While the words of different languages do vary in length, they’re generally within 10% of each other’s length. Even text in written languages that employ ideograms or logograms, such as Chinese, does not end up being notably shorter than alphabetic languages such as English.

Misconceptions about the differences in word length across languages often result from bad translations, which typically end up being very literal, formal, and, therefore, long. If you instead render the content properly and consistently in each language, the text length should be similar.

Leveraging Style Guides and Branding

If you don’t already have a written style guide or glossary for your digital product, now is the time to create one. You probably have a fairly consistent set of words and phrases you use to refer to functions, features, products, company divisions, and so on. In addition to your having a writing style guide to help ensure the consistent use of text, the localization effort makes having a style guide for each language critical. Create equivalent words and phrases for each language’s style guide.

Teams often distribute localization efforts across several people, then do everything at once, instead of working on it bit by bit, with the whole product team overseeing the results, as you built the original product. Without having such style guides, inconsistencies and inaccuracies in your internal and technical terms inevitably creep in.

Branding—for product names, taglines, catchphrases, and individual product attributes— all too often does not get translated. This is a mistake. Confirm that the branding text is relevant, understandable, and not locally insulting. Localize as much branding text as you possibly can.

Offering a Complete Experience

In addition to displaying the text of your Web site or app in the localized language, you must also translate the text of all the PDF documents you let people download, email and SMS password resets, shipping notices, and absolutely everything that is part of the customer’s experience.

Interactions must also be consistent. Too often, organizations offer most or all of these ancillary digital features in other languages, but they do not inherit the settings from the app or Web site. For example, if you have a setting for language, there’s no need for a setting for email language. Once users set regionalization features, save their settings, and use them by default for downloaded documents, email messages, and everything else.

Also, don’t forget to translate the following:

• metadata for Web site crawlers—Doing so improves your search results.
• alt text, element names, and ARIA labels—This makes your content more accessible to all.
• app-store descriptions—Translate all content, including change logs.
• app-store images—Never use US-English screenshots for app stores outside the US.
• other marketing content—For demo videos, at least provide captioning options in multiple languages.
• Help documents and user guides—This should include all user assistance.
• customer service—Your company probably provides customer service both online and by phone.
• social media—Offer both localized versions and links to whatever social-media platforms are preferred or available in different regions.
• legal documents—These include privacy policies.

Employing Default and Fallback Languages

There are around 6,500 languages in the world. Despite English barely edging out Mandarin Chinese for reach, by no means does everyone speak English.

Don’t let bias creep in and assume that everyone speaks your language or that the most popular second languages locally or worldwide are what the people using your app or Web site can actually read and write. Obtain the actual data for the regions in which you’ll market your product or your audience who would use your product. Try to find out the specifics about your users. There is no average person, so your specific audience could have very different needs from the rest of their region.

Many things about language usage are more complex than you might think. For example, there’s really no Chinese language, but various dialects. Only about 70% of the Chinese population speaks Mandarin. Often, you can work around such language issues by using simplified or generalized language. Shared written languages are often easier to generalize than spoken languages. Therefore, you’re in a better position if you’re designing UI elements than if you were distributing written articles or producing TV shows.

A common generalized language for the Americas is Spanish. But the Spanish dialect that people speak in Europe, Castilian Spanish, is relatively uncommon there. Plus, among the more than 20 countries that officially speak Spanish, there are some ten officially recognized regional dialects. However, many of these countries share a Latin American Spanish, ISO es_419, for official documents, which people in most Central, South American, and Caribbean countries can use with adequate results. But if your audience is in Mexico or the US, they use a fairly different dialect, so it might not work for those users.

Don’t fall back to English or whatever your native language is. Instead, consider creating a table of the most likely fallback languages by region. In many of the largest countries in the world— for example, China, Russia, and Brazil—less than 10% of the population speaks English. Therefore, English is not a suitable, global fallback or default in much of the world. In general, don’t specify any one default language. Instead, use regional settings and your knowledge of your users and their regions to offer them the most suitable language.

Selecting a Language

We’ve all seen a Web site whose first page is a giant map of the world, with a list of countries and perhaps a subordinate list comprising the languages that are spoken in that region. This is a terrible, out-of-date design practice for many reasons. We can do better using simple Web technologies—and even better for mobile apps. Instead, use automatic methods of selecting the most likely language for the user, then let the user change it easily.

Automatic settings are easiest to implement in mobile apps: you can simply read the device language from the phone or the regional settings from the app store. Anyone who wants to use your app would certainly want it to be in the language they use on their phone or tablet. However, if you don’t offer their language, the fallback rules come into play.

Avoid using location services such as GPS (Global Positioning Systems) to determine language. It rarely matters where the user is right now, but instead, where the user lives or what language they know well.

On the Web, determining location has always been more difficult. However, recently, the Geolocation API (Application Programming Interface) has gained good browser support and provides accurate information. However, not all older browsers support it. Plus, the user has control and might block access to this information.

The fallback is IP (Internet Protocol) location, which is often troublesome. However, issues regarding the wrong location are generally unimportant for regionalization. Many browser sessions return IP addresses for a service provider’s home-office location instead of the user’s computer location, which could be a problem for weather reports. But at least it’s usually in the user’s home country, so it works well enough for our purposes.

Changing Localization

A key thing to remember is that people neither change much nor change quickly. Don’t switch localization settings such as language just because the user is traveling. Save the user’s settings and make them persistent for the user. But also allow the user to change these settings. There are plenty of use cases in which users might want to change their localization settings. For example, a fallback language might not be the best choice, so users may want to select another location or language. They might share a computer or be collaborating with others. They might have first visited your Web site outside their home region, making their first visit an anomaly. They might be using a VPN (Virtual Private Network) for privacy, which obscures their location. They might want to change only some settings such as units of measurement, but keep the UI language the same. Allow the user to make individual changes, without assuming they also want to make other changes.

Don’t require users to restart their session. In fact, you should even avoid their having to refresh a page, which wipes out whatever they’ve already selected and reduces the value your product to them.

Communicating Localization Settings

Be very careful with the use of icons for any localization settings. The most common icons depict national flags. This can sometimes be politically contentious even for regions, but is simply incorrect for language and other settings.

Whenever the user can select a language, be sure to use text labels to indicate the current language if at all possible. Never label a function that lets the user change the language using the language that is currently selected. The users who need to change the language might not be able to read a label in the current language.

The one thing that should never be translated: the labels in the language picker. Instead, always label languages in their actual language—for example, as follows:

English

Español Centroamericano

汉 语

Users who encounter a user interface in a foreign language quickly notice text in their own language. They might also recognize languages other than their own more readily in their own language than languages whose labels you’ve translated to the same language.

Next: Displaying Regionalized Content

So far, I’ve covered the concepts of regionalization and selecting the language for a region—both automatically and manually—and described some of the pitfalls you might encounter in selecting languages and creating processes to convert your app or Web UI language.

In Part 2, I’ll get into the details about how to design a user interface to support some of the more likely changes in the display of regionalized content—both broadly and in details such as decimals, currency, dates and times, and supporting input to accommodate the ways names and addresses vary worldwide.