Designing for a Truly World Wide Web
5 ways localization affects UX
In the early days of the web, we didn’t pay much thought to the fact that our sites were being viewed by people around the globe, let alone consider translating them into another language. But as companies began to expand their presence on the web and take their products out of the box, web professionals were suddenly confronted with a whole new set of challenges caused specifically by the need to localize sites and applications.
At Salesforce, not only are we a global organization, our products are translated into multiple languages. We’ve seen first-hand, the ramifications of globalization in our design patterns. But before we get into the weeds, let’s start with a definition.
“Internationalization and Localization (sometimes shortened as i18n and l10n) are means of adapting computer software to different languages, regional differences and technical requirements of a target market. I18n is the process of designing a software application so that it can potentially be adapted to various languages and regions without engineering changes. L10n is the process of adapting internationalized software for a specific region or language by adding locale-specific components and translating text.” — Wikipedia
One of the biggest challenges to both internationalization and localization for designers is the need to understand just how different our audience can be from ourselves. Did you realize, for example, that in some parts of the world, thumbs-up doesn’t mean good? And just so we are clear, it’s not just web designers that have to deal with these differences — even Pixar had to change its recent movie “Inside Out” for an international audience.
Let’s look at five ways that internationalization and localization affect what we build.
1. Think globally
Culture has a big impact on people’s perceptions and behaviors. As web professionals, the design decisions we make are influenced by our own backgrounds and culture and can have unexpected results when viewed through the lens of a different culture.
For example, have you ever thought about the way that you read or scan a webpage? Everyone does that the same way, right? Well, actually… if you do an eye tracking test, you will find in the West, people tend to be more analytical: they read sequentially from left to right and from top to bottom following an “F” pattern. In Asia, however, they take a more holistic approach when reading which includes more skimming, scanning and jumping back and forth. This means that the placement of UI elements, such as calls to action, might be impacted simply by the way an audience reads.
The use of color is another classic example of where a simple design pattern can go horribly wrong. Think about the color red. What does it typically mean? What emotion is tied to it? In the US, red is a color that often indicates warning or danger, but in Asian countries, red is actually a positive color that indicates happiness and luck. In the Chinese stock market, for instance, red is used to indicate when a stock goes up, while green indicates when a stock goes down.
For small sites, you might not be thinking globally, but when you move into enterprise scale web sites and applications, like Salesforce, it is imperative that cultural differences be kept in mind. With each design decision, think about the diversity of users who will put their hands on your product.
Every person, no matter what country they live in or which language they speak, deserves a quality, and culturally appropriate experience.
2. Indicate languages in an appropriate way
You’re doing some web surfing and you land on a webpage in a different language. What do you do? I think most of us would say that we start looking for a way to change the language. A typical design pattern is to indicate the ability to switch languages by offering flag icons to indicate available languages. Sounds logical, but it’s a really bad design choice. Why? Think about the following scenario:
You’ve been tasked with designing a site that will also be translated into Spanish. You need to indicate to your Spanish-speaking audience that the site is also available in Spanish. To make the language selector more visual, you prefer flag icons to plain text.
The question becomes:
“Which country flag will you choose for Spanish?”
People often opt to use Spain’s flag since the Spanish language originated there. But from a user perspective, Mexico has a much larger Spanish-speaking population than Spain. And how about the other 19 Spanish-speaking countries out there in the world?
When thinking language and country, unfortunately, it’s not always a one-to-one pairing. A language may be spoken in many countries, or a country may have more than one official language. Think about Canada: which language do you think the maple flag will lead you to? English or French?
The blog, Flags Are Not Languages, states the difference between flags and languages very clearly: “flags are symbols that represent countries or nations” while “languages represent a shared method of communication between people.”
Of course, this doesn’t mean you should never use flag icons. But before you decide to use that pattern, ask yourself:
“What is this icon supposed to represent? How might a user interpret it?”
3. Account for text expansion
Do you remember the first time you saw a foreign language in writing? Did anything jump out at you? It probably had different letters, or maybe it didn’t even use the same alphabet as your native language. And, although it might not have jumped out at you, that language was probably longer or shorter than your own.
When a web site or application gets translated into another language, the text length is likely to change. English, for example, is a very compact language, leading to longer translated text in most languages. How is that going to impact your design? Can things like buttons or tabs accommodate more text? You’ll need to conscientiously build in a “buffer” in your designs to accommodate potential text expansion after translation.
The general rule for text expansion is, the shorter the English text, the longer the translated text is likely to be. The following is an average of text expansion rate listed in IBM’s Globalization Guidelines:
However, we can’t assume the same rule applies across the board to all languages. The target language also has an impact upon the amount of expansion which might be needed. For example, when “Share” is translated into German, the text length is almost doubled; however in Korean, the text is only 70% the length of English.
In general, Asian languages are less of a headache since they tend to be more compact than European languages, but there’s no “always”. Chinese, Japanese and Korean have much more complicated characters than those in the Latin alphabet. In addition, their characters tend to be more square, thus taking more horizontal space. Japanese is especially problematic due to its use of Katakana for transliteration of foreign words. As a result, the translated text can get as long as, or even longer than, the most verbose European languages. In the example below, both English and Japanese have 6 characters, but Japanese is much longer due to the wider characters.
Some good strategies to tackle text expansion include:
- Leave blank space around condensed UI components, such as buttons and tabs.
- Make your UI components expandable. Don’t assign a fixed width to your button or menu unless you have a good reason.
- For longer text, wrapping is a good solution. However, you will need to be aware of the potential layout change since translated text will take more vertical space.
- Truncation with hover text can be an alternative. But this brings the risk of making the UI less effective.
Below is an example from Salesforce where users can create a new record using a component. In Italian, the first two tabs don’t convey any message since all it shows is “New”. That means the user will have to hover over the tab to determine what they can do. This could easily be resolved by making the tab width expandable.
4. Avoid inline components
Another typical UI pattern that introduces a localization issue is the use of “inline” components such as input fields or dropdown lists. This problem is caused by the fact that most languages do not follow the same word order. Due to this fact, the UI components need to be repositioned to accommodate correct sentence structure in translated text.
Below is an example from Google Calendar:
When “After [input_box] occurrences” is translated into Simplified Chinese, it says “[input_box] 次后” ([input_box] occurrences after). The text input box needs to be moved to the beginning of the line:
Is there a solution to this issue? Sure — if you want to maintain language-specific CSS. If you support 2 languages, yes it’s doable. If you support 50 languages, good luck with that!
An alternative solution to this problem is rephrasing translated text to fit into this structure. In the previous example, instead of saying “[input_box] 次后” ([input_box] occurrences after), the translated text can be “重复 [input_box] 次后” (Repeating [input_box] occurrences after):
What an easy fix! Unfortunately that’s not how the current localization industry works. Instead of hiring in-house translators who can work with development teams directly, most companies outsource their translation work to LSPs (language service providers). The problem with this is that translators only see the text, they don’t see it in a UI. For example:
Since they are not seeing the words in context, a translator will most likely treat these words separately, possibly producing a mistranslation.
Below is one possible solution to this problem. A colon is a good way to connect labels with UI components. It may not be as “nice” as the inline design, but it removes the localization blocker.
5. Capitalization concerns
Capitalization can be very tricky, even in English. There are different rules for capitalization, on the title and header level, or at the sentence level. And these rules keep changing. In most English style guides, almost every word in a title or heading is capitalized except for articles and prepositions. Below is an example of Facebook’s post composer. Every word in the tab names is capitalized:
In Spanish, however, only the first word is capitalized. This applies to other continental European languages (French, Spanish, Italian) and Nordic languages (Danish, Finnish, Norwegian). In fact, in many languages, capitalization is used less than in English. For example, a language’s name, calendar months and organization names are capitalized in English, but none of these are capitalized in Spanish.
Due to these differences, it’s important that a developer avoids using CSS to handle capitalization. Leave capitalization up to the translators since they are the experts when it comes to styling rules in their own languages.
Never use capitalization as a styling differentiator, due to the fact that some languages don’t have capitalization in their writing system.
While I’ve attempted to highlight some of the more common issues and the solutions, these are by no means the only ones. Internationalization and localization are huge topics. I’d love to hear your thoughts and solutions that you’ve come up with!
Big thanks to Greg Rewis for all the great advice and edits to make this blog post shine.