There is a lot more to offering your Web site, mobile app, or other digital product in other markets than automatically translating or hiring a service to translate your content into another language. In Part 1 of this two-part series, I provided an overview of how to regionalize your products—approaching regionalization from a procedural and technical point of view—and detailed the approach you should take, as follows:
Do more than just translate. Rewrite the content in the target language, considering the context of use. Avoid slang, jargon, colloquialisms, metaphors, and jokes.
Use people, not just tools or services. Hire a content manager or content designer to create content-management documents. Work with your translation service, and engage locals who are sufficiently familiar with your product to at least review it.
Don’t fear using other languages. While the same words in different languages do vary in length, their lengths are generally within 10% of one another. So don’t avoid regionalization just because it could break your user interface.
Leverage style guides and branding. Create a glossary of terms and guidelines for both your organization’s writing style and your digital products, so your terminology is consistent and translation services can better understand your approach and meanings.
Offer a complete experience. Translate everything, including metadata, alt text, title text, app-store descriptions, text in images and screenshots, Help documents and user guides, customer-service content, social-media posts, and legal documents.
Employ default and fallback languages. Use default languages that are common regionally to reduce user effort and increase user appeal, but don’t assume your native language is what everyone in a region speaks. Just provide it as the first option or use it if there’s no other good match.
Select the language automatically. Use technical methods to select the language automatically based on the user’s device and browser preferences, with location or IP location as a fallback.
Let users change their localization settings. Never make users select a language on entry. But do let them change language, units, or other regionalized settings easily, in case they share their device or move, or you got the settings wrong by default.
Communicate localization settings in the user’s native language. Never use national flags to represent language or otherwise conflate language and region. When displaying status or allowing the user to select a language, display all languages in their native language. Never translate them.
Now, in Part 2, I’ll get into more details about how to design for different regions, as well as describe how to format specific attributes such as date, time, currency, names, and units of measurement.
Planning Your Design for Global Use
In addition to the functionality differences I mentioned earlier, there are many things in your designs that simply converting text to other languages can impact. If you fail to consider these, you’ll end up with a product that’s difficult to use for many users—or that could make it impossible to enter some markets.
One important thing to consider is the twelve languages that are written right to left, including Arabic, Azeri, Persian, and Hebrew. About 2 billion people speak such languages, so this is an important consideration. However, many teams build user interfaces that assume left-to-right text. For example, I generally build lists with left-aligned labels, more information to the right, and optional functionality such as a menu in the rightmost column. The user first finds the information’s label, then scans across the additional information and the options to the right. Keeping the same design grid, but flipping the direction of the language would make this design hard to use at best. Does your platform support flipping an entire user interface depending on language selection?
Likewise, many teams agree that forward is rightward, so when building forms, they place submission buttons on the right and Cancel buttons on the left. Plus, selection lists that load new pages place a right-pointing arrow at the right of each line to go forward; a left-pointing arrow at the left of each line to go back. Consider how these assumptions about left and right that are based on users’ behaviors would work if you flipped the rest of the UI conventions for right-to-left languages.
Even just the order of written items can cause problems with your designs. For example, if you like to design very conversational products, as I do, you might have a user-interface element that comprises the phrase “Send confirmation message to,” with a drop-down list of users following it. This sounds very reasonable, and you could even easily reorder the elements for right-to-left languages, but you could not translate this user interface to the many languages in which the object of the sentence—the person to whom the user is sending a message—should appear first rather than last. Should you place the list of users first? Is it possible that your platform could support that sort of UI change in concert with a language change, or would you need your designs to avoid this sort of conflict?
Right from the start, you should consider the worldwide reach of your product and what other languages or language conventions could mean for your assumptions about how people use your user interface.
What to Translate and What Not to Translate
Our product-design processes use lots of jargon, brand names, and abbreviations. All too often, we use such terms without much thought in our final product designs. We can’t always avoid their use entirely, but we can use them intelligently to ensure that all users can understand such terms better, and they work when the user selects a different language.
No matter how much your product owner insists that all users are trained experts or are familiar with your system, they might not be familiar with it. Despite your best efforts, people might forget or misunderstand your user interface. Don’t assume that all of your users are familiar with specific terms. Avoid introducing abbreviations or jargon in titles or subheadings. Instead, spell out words and explain abbreviations or acronyms when you first introduce them in the text.
Avoid using nonstandard abbreviations that are internal or unique to your organization, project, or product. Never use text within icons because it cannot be translated and won’t always make sense. Even some international standards make this mistake—for example, the international standard for a generator icon is denoted as a circle with a big G in the middle—so it could take some effort to get around this problem.
Unless there is a common translation for an organization’s name such as Doctors Without Borders / Médecins Sans Frontières, use its official native spelling instead of translating it to a local language. Watch out for similar words that have different spellings in dialects such as British English versus US English—for example, Programme / Program or Centre / Center.
Formatting Data Display
Many digital products display data of some sort. They rely on users’ easily and accurately reading the information they present. Therefore, we must display the values, the units, and the labels themselves in ways that match the users’ expectations and workflows. Display the data and units in common formats with which users are familiar and at a scale that works for the task at hand.
Numerical formats are not as consistent as you might think. Render numbers using the region-specific preferences that users have set on their device. Commas and decimals have different, inverted meanings in some regions. All of the following examples are the same number:
Only about 60% of countries use a comma as a scale delimiter and a decimal point to indicate a break between whole numbers.
In some regions and in official scientific works, spaces replace commas or decimals as the scale delimiter. Officially, these spaces should be the Unicode character U+202F, which is a nonbreaking space. But if that doesn’t work on your platform, using U+2009, or a normal space, should work, as long as you have otherwise provided enough room for the value to fit on one line.
If you provide product pricing in multiple currencies for local markets, you must indicate them accurately. This involves a lot more than just changing the symbols. The position of the symbol can also vary, with some symbols appearing before and some after the numerical value. Many locales also add a space between the value and the currency symbol. Treat this as a unit indicator, so use a nonbreaking space between them, ensuring that users always read them as a single phrase.
Many countries use the same currency symbol—for example, the dollar sign, $. If it is not clear whether your product is from one region or another or there’s any chance that users might become confused about what currency they’re using, substitute the international code for the currency for the symbol or add the currency code. You can show Canadian dollars in either of these ways, but the second approach is often necessary to avoid confusion with US dollars—especially because of the physical proximity of these countries and their shared language. For example:
When using the letter code, be sure to use special formatting such as a slightly different font size, weight, or color to make the value easier to read.
Once everyone is on board with using these codes when displaying currencies, you can even use them to improve the display of currency within a single market. In the US—as well as in many other countries—cents have their own symbol, which appears after the amount. Displaying a price as 99¢ is much better than $0.99, so if you sell many items that cost under one dollar, displaying costs in cents would be worth the effort.
Never store dates or times as strings. Instead, use temporal data in UTC (Coordinated Universal Time). Apps can parse such values to display date and time information appropriately, using the user’s regional display preferences and usually their current time zone.
Always display the time zone to reassure users that the system has rendered the time properly. Even users who do not travel might want reassurance. For example, they might be aware that a far-flung server farm is feeding them data, or they might be on a corporate network or using a mobile provider that could indicate their location incorrectly. Sometimes it is necessary to display data for other time zones—or for more than a single time zone at once—for example, when the user is making travel plans.
There is no useful standard for human-readable names of time zones. This tends to worry engineers, who want all attributes to be globally unique. Ideally, we would use a long name such as Central Time, US, but that would usually take up too much space. Plus, such long labels might obscure the actual data—the time value itself. In practice, using the conventional local abbreviations works well enough. Very rarely is a time zone so wrong that users would get data for an entirely different country and become confused.
To be extra careful—or for audiences for which time is more critical or who have a more technical mindset—include the UTC offset. Even people who don’t know their UTC offset would eventually learn it by seeing it in your product and would notice if the time zone had changed. Here’s an example:
12:42 pm CT (-6)
Be careful not to confuse people with labels for time zones. Always ensure that they get translated. Ideally, similar to what I suggested for pricing, find a way to use typography design to either emphasize the time value or deemphasize the time zone so it won’t be distracting.
In many parts of the world, 24-hour time is simply called 24-hour time, not military time. It may even be the standard time format. So when users can select 12-hour or 24-hourtime, label the values as such.
If you’re using a 12-hour clock, the official way of displaying the period of the day—either am or pm—is in small caps. However, digital user interfaces support this poorly, so use lowercase instead, with a space after the time and no periods. Use a nonbreaking space character or another method of ensuring that the time period never wraps onto another line.
While the official convention for the separator between hours and minutes varies, the colon is in wide enough use—and the context is usually clear enough—that there is no compelling need to regionalize times by removing this character in different contexts. While this is not strictly proper, it’s simple, so is what I often end up doing. However, if the proper regionalization is easy to achieve with a plugin or operating-system support, by all means use it.
In dates, the month, day, and year appear in different orders in various regions—and sometimes even depending on certain types of job roles. In the US, we generally use a MM/DD/YYYY format for numerical dates—for month, day, and year. But much of the world uses DD/MM/YYYY. The following two values represent the same date in two different regions:
But numerical dates are always ambiguous. When you’re displaying dates in only one format, how can the user know at a glance whether they’re properly regionalized? Does the date in the previous example mean October 1st or January 10th? Regardless of the need to properly regionalize the order of dates, you should make all dates unambiguous. Therefore, you should display the month in text whenever there is sufficient space—whether spelling it out in full or abbreviating it, with no period following the abbreviation—as follows:
Oct 10, 2017
10 oct 2017
October 10, 2017
10 octobre 2017
In some languages such as French, the convention is not to capitalize the names of months, as in the previous example. Follow regionalization rules carefully and precisely.
Formatting Names and Addresses
Many countries invert the display of given and family names, prefer to use all caps for family names, or have other display conventions with which you may be unfamiliar.
Addresses are even worse. Many countries have street addresses that do not follow the standard format we use in the US: number plus street name. Or they use address formats that require the use of many more lines to accurately indicate the address.
The easiest way to resolve this issue is to avoid imposing your own country’s formatting on data from another country. The conventions we’ve adopted that parse data into separate fields is partly a result of our detail-oriented engineering cultures, but it’s mostly because of standard banking and credit-reporting practices that require matching information. However, in most other cases, you probably don’t need to parse out names or addresses. Instead of using labels such as First name and Last name, simply provide a Name text box—or an Address text area. Then people can fill in their information as they see fit, and you can store it in whatever format they use. Doing this provides valid data for almost all real-world use cases. Services such as Google Maps can handle addresses in any format, so you won’t be limiting your functionality, either.
Using Units of Measurement
If no explicit preferences exist for the display of units of measurement in a given context, either display them using the user’s device preferences or follow the specifications for particular regions or languages.
Store dates and times as readable data, not text strings. However, you must store almost all other data as translatable units. Many technical systems retrieve or store all data in SI, or the International System of Units, which are not units most people use—even engineers. But systems can easily convert them to any measurement scheme.
It is important to let users set their own preferences for units of measurement. They may be accustomed to using units that differ from those that are prevalent in their mobile device’s current location; their preferences for units might change from task to task, as they change devices or clients; they may be consulting on a project in another region; or they might be working in an industry with different conventions from those of their current region.
Unit sets such as Metric or English are probably not what you’re used to. Never, ever refer to your regional default as Default, Normal, or Standard. Instead, use the proper labels for the two most common unit sets, as follows:
These are not likely to be the only unit sets you’ll need. There is also an Imperial unit set, which is not the same as U.S. Customary. In Latin America, they use Metric, but with a few U.S. Customary units thrown in. For certain industries or regions, you might need to add one or both of these other unit sets as well.
Using these labels for unit sets goes only so far in describing units of measurement, especially if users are completely unfamiliar with them, don’t have a clear understanding of what they mean in comparison to one another, or don’t have an accurate label in mind. Therefore, when you’re allowing users to change their units of measurement, be sure to provide a brief list of the units they would be using in proximity to each label for a unit set, as follows:
Metric—km, kg, l, kPA, °C
U.S. Customary—mi, lb, gal, psi, °F
Imperial—mi, lb, imp gal, psi, °C
Latin America—km, kg, l, psi, °C
This is just one example. If you’re building a fitness app, you probably won’t need liquid volumes or pressures, so just display the most important units for your users and their contexts.
When you’re displaying units of measurement, ensure that there is always one space after the value, separating it from the unit label that follows—with the exception of the degree symbol. Always use a nonbreaking space ( or U+00A0) for that space. Value/unit pairs must always appear together or they would make little sense. In tables, you can sometimes get away with having a column header indicate units to avoid repetition, increase readability, and save space.
Whatever level of precision you use in your original design should carry through to converted units of measurement. For example, if you have rounded decimal places to no more than two places, rather than precisely converting a unit of measurement, round it off to approximately the same degree. Also, use the proper units that follow local conventions, and make sure that they are readable and understandable.
Wrong units, too long—0.907185 kg
Excessive precision or providing the incorrect unit options can reduce the readability or value of the information.
Not all measurements should be translated. Specifications or marketing values should usually remain in their native units—for example:
Metric thread sizes would become nonsense if you translated them to another unit of measurement.
The name of a product that includes a horsepower rating would be inconsistent and confusing if it were translated to display in kw.
Be sure that you understand what information you’re displaying and how the user would use it before allowing it be translated or converted.
Formatting Positional Data
Most of the time, we simply display locations on a map or as an address. However, if you must display a location as coordinates, this can sometimes cause confusion when you’re regionalizing a user interface. Coordinates are not quite the same as other display units.
You could display the horizontal position—the coordinates—in any of a large variety of systems, but it would not correlate to any of the units of measurement I’ve described. Do not confuse and accidentally translate degrees of latitude and longitude with degrees of arc or temperatures. In most cases, you should be able to display the positional data directly in the format you receive, but special user types might require specific formats. For example, governments use USNG and militaries use the related MGRS. These are very, very different systems, so translating from degrees to grids is not a simple formula.
When necessary, display horizontal position accurately, as a simple measurement, usually in meters. Unlike coordinates, you should convert this value into the user’s preferred display unit.
When you’re displaying the vertical position, or altitude, it is also a conventional length, so subject to conversion based on the user’s or regional preferences.
Designing for Context and People
Yes, this is yet another article that basically says everything is more complex than you might have expected. The best way to address a new need is to have thought of it early on. This is true of almost any aspect of design, and there are no cheats.
The success of any new mobile app does not depend on its feature count or technical completeness, but on your designing and building it for real people and the way they actually work. I hope this overview has given you a few more insights into how people’s needs vary across regions, so you can plan and research the right approaches to take for your next UX design project.
The earlier you understand all the complexities of regionalization, the more quickly you can make decisions about how to solve your short-term problems—with the least wasted effort or technical debt—and the better position you’ll be in for either your next major release of an existing product or an entirely new product.
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