Regionalizing Your Mobile Designs, Part 2

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.

Formatting Numbers

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:

1,205.43

1.205,34

1 205.34

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.

Formatting Currency

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:

$1,205.43

CAD 1,205.43

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.

Formatting Time

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-hour time, 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.

Formatting Dates

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:

10/1/2020

1/10/2020

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:

Metric

U.S. Customary

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.

• Original—2.0 lbs.
• Wrong units, too long—0.907185 kg
• Better—.91 kg
• Best—907 g

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.