The Internet can make the world seem very small, but a lot of the digital products you’ll work on must eventually work well for the billions of people outside your home country.
“Easy!” some product manager might say, giving your team a story to add multiple-language support to your app or Web site, maybe add a few specific features to make it acceptable to your new audience or local governments, and upload it to the app store.
But there’s much more than autotranslating to a new language to prepare your product for another market. A lot of the problems you’ll encounter in new markets are likely to emerge from your translation being culturally insensitive or just your being unaware of how different things can be in other regions.
Instead of just translating a site or app, you should think about regionalization. Product teams too often misunderstand region to be the same as their sales regions, then conflate region with language and various settings. But we don’t mean that.
Regionalization means considering the entire context of people’s different needs in other parts of the world, not just hiring some service to change the display language. There’s a lot to it, so for starters, here’s a list of some things you should think about when planning to offer your Web site, app, or other digital product in additional regions or around the world:
All of your content should be in a CMS (Content-Management System) database, and absolutely no content should be hardcoded into the presentation layer.
This means absolutely all of your content—including images, audio recordings, alt text, email messages, PDF guides, video explainers, and knowledge-base articles for customer-care representatives. Everything!
Content should be in UTF-8, or Unicode, so whenever your product displays content, it can support any character, in any language. There should be no call for ASCII limits anywhere.
Make sure your input fields are not regionally specific. For example, your name and address fields probably make a lot of assumptions that aren’t true for other regions.
Automatically set region, language, currency, and other display values, either by using the user’s device preferences or by using location detection as a proxy and making best guesses.
Choose the set of languages you intend to support—based on your users’ actual locations and what they can understand, not on what you feel is right or on global averages.
Don’t make assumptions about a base language. Instead, check regional standards for dialects and variants.
Because there is no language that people universally understand, don’t set any language as the default. Instead, build a set of fallbacks for each region or a user-preferred language in cases where their top choice isn’t one you support.
Allow users to change any of these settings, in case you’ve guessed incorrectly or for collaboration or shared devices.
Keep track of your users. Remember, they don’t change just because they’ve traveled to another country. They still speak the same language and buy things in their home currency. Automatically set language once, then leave it alone.
Think about how changes to language might impact your user-interface (UI) design. For example, right-to-left languages should probably invert most of a user interface. Can you do that?
Understand regional laws and policies such as privacy restrictions. These often involve more than just UI changes and might require special handling of personal data or requests for clearing private data.
Don’t assume anything about your local audience is true everywhere. Even simple things such as mobile-network speed are not universal worldwide. How does this change the fundamental way your product should work?
Now, let’s dive into a few of these considerations in more detail, focusing just on things that relate to the user interface to keep the scope reasonable.
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.
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:
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.
For his entire 15-year design career, Steven has been documenting design process. He started designing for mobile full time in 2007 when he joined Little Springs Design. Steven’s publications include Designing by Drawing: A Practical Guide to Creating Usable Interactive Design, the O’Reilly book Designing Mobile Interfaces, and an extensive Web site providing mobile design resources to support his book. Steven has led projects on security, account management, content distribution, and communications services for numerous products, in domains ranging from construction supplies to hospital record-keeping. His mobile work has included the design of browsers, ereaders, search, Near Field Communication (NFC), mobile banking, data communications, location services, and operating system overlays. Steven spent eight years with the US mobile operator Sprint and has also worked with AT&T, Qualcomm, Samsung, Skyfire, Bitstream, VivoTech, The Weather Channel, Bank Midwest, IGLTA, Lowe’s, and Hallmark Cards. He runs his own interactive design studio at 4ourth Mobile. Read More