a visual guide to localization

Localized products function better for everyone.

about

There's a lot of good information online about localization, but sometimes it's missing a visual explanation. Ironically, the audience for this content is often designers. So there's an opportunity to explain the significance of localization in a way that's easier to understand for visually-oriented people.

Here, I've documented just a handful of the many learnings my team and I experienced over several years, working across over 20 countries and languages at Wikimedia.

I've broken this into three sections: design, copywriting, and payments with some tips throughout.

1
design

Most languages are "longer" than English, and character length differs by language. Anything that's non-English often requires more space for characters and / or words.

Here's what it looks like when people say English is "shorter" than most languages:

It can be difficult to avoid this layout challenge if the product's origin language is English. So allowing for a flexible interface is key: Ideally there are containers that can expand, and button language should be simple: universal commands, no sentences. Stacking can also be helpful, but only in certain circumstances, which I'll explore, below.

Allowing for a flexible interface is key.

Also, many languages have different grammatical requirements or sentence structure. Here's an example of what that could look like:

Our team once wrote some simple code that would display the correct day of the week to appear in a banner; it was browser-based functionality. (The following was not the actual copy written.) It works great in English, and looks good in Italian, right?

24 hours later ...

Grammarical error! After 24 hours the days updated in the phrase and, in the Italian example, "questo" should have been "questa".

Why? Some languages have a fixed-gendered noun, so unless you want to write extra code (and add a string of gendered adjectives affiliated with nouns), it's easier to avoid this complexity altogether by simply not having code in the middle of the sentence.

Another reason to avoid putting code in the middle of a sentence: It's really hard to QA, thus there's a higher chance of error.

Avoid inserting code (or functionality) into the middle of a sentence.

Here's a way to visualize the challenges of breaking up sentences that have different sentence structure; let's take a look at these forms:

"I'm looking for shirts that are yellow" can be translated into Russian, but not with the same sentence structure as English. In fact nothing about the above sentence structure reads naturally to a native Russian speaker. It might sound more like: "I'm looking for shirts who are yellow."

The design above forces a sentence structure upon all languages, not allowing us to change the order of the words in the sentence. But if we follow the simple rule of not breaking up sentences, problem solved:

Stacking is a good way to be proactive about longer text.

Here's an example of some text without stacking (and no surprise that Japanese is longer than English).

Here's the same text in a stacked format. As long as the information hierarchy is in tact, stacking is a good way to keep text tidy and clear.

What about localized design differences that differ from the original? For example, our team wondered whether it was true that orange resonates better with Dutch readers. We tested this in on some banners for Wikipedia and the orange did, in fact perform better. (We retested the same orange against other colors, and in a dozen other countries, and did not see the same results.)

But keeping these customizations should be kept to a minimum, as the more complicated code gets on the back-end, the harder to QA, and the higher the chance something breaks in the long run.

Some design customization can resonate well.

2
copywriting

Localization is not the same as translation. Here is an example to demonstrate why:

The word coffee, in Italian, translates literally. Culturally, it has a very different meaning. There was a big fuss when Starbucks opened in Rome, given that Italians, "take their coffee culture very seriously."

Below is a simple mood board to visualize this cultural phenomenon. It's paired with a phrase we once used at Wikimedia to ask readers to donate: "The price of your coffee today is all we ask." When translated literally, this phrase was received differently from people of different cultures.

Just because something translates literally does not mean it translates culturally.

The price of your coffee today is all we ask.

Il prezzo del tuo caffè oggi è tutto ciò che chiediamo.

Multiple, independent Italian localization specialists and linguists recommended that we use either a "cappuccino" or "colazione", to create the same effect intended by the original copy.

So what happened when we A/B tested "cappuccino"? We were surprised to get neutral results, across multiple tests, given the strong opinion from the localization team ("coffee in Italy is like ... religion!"). But we decided to adopt cappuccino for the cultural reasons they described.

After all, we didn't want the copy to feel unnatural, or worse, that we didn't care to understand Italian culture and people.

Control

Test results: Wash

p-value: .2

range: -4.7% – 0.98%

improvement: -2%

We applied a similar approach in Japan, where we scrapped using "coffee" altogether per the advice of our localization team, and tried a multivariate test by using a "metro ticket" as a more familiar, daily item. We also had to adjust the ask amount strings to match the slightly different cost, but the total amount raised was competitive to the control.

"... a donation of about 300 yen, the cost of a cup of coffee, will help Wikipedia grow.

"... a donation of about 150 yen, the cost of a single metro ride, will help Wikipedia grow."

Control ("coffee")

"Metro ticket" Test results: Win

p-value: .0001

range: 4.1% – 25%

improvement: 18%

The result was a quantitative win (contributions per impression), neutral-performing revenue, and also a win for the users in Japan, for whom a more culturally relatable item was used.

3
payments

The wild world of currency formatting includes decimals, commas, colons, symbols, and ISO country codes. Luckily there is an existing repository that organizes this sort of information called Unicode CLDR (we relied on this at Wikimedia).

If you're operating internationally, it's considered best practice to include not only the currency symbol but the country's ISO code if there is the slightest chance a user would be confused.

In its most basic form, let's say you have an American product and are advertising or selling in Mexico, Canada, or Australia. All of those countries use a dollar currency symbol, but the currency is not the same and does not have the same value:

Simple enough. But it gets more complicated in other currencies and countries such as the Swedish krona, Danish and Norwegian krone; all different currencies but can easily be confused when using the currency abbreviation of "kr":

While the correct "kr" currency symbol is used in the example at left, it isn't sufficient enough information to differentiate between Swedish, Danish or Norwegian crowns (all "kr"). Given the close proximity of those countries, it's safer and more clear to indicate the currency using the ISO code.

If operating internationally, use both currency symbols
and ISO codes for extra clarity.

summary

Let's put it all together:

If product origin language is English, remember it's a "shorter" language, so design with a flexible interface in mind.
Avoid inserting code into the middle of a sentence and don't break up sentences in the design.
Stacking is generally safe, just make sure the information hierarchy stays in tact.
Some simple, cultural design customization can work well.
Translation isn't the same as localization; keep in mind that meanings may differ.
Best practice for currency formatting is to include the symbol and ISO code, and to ensure decimals and commas are used properly.

Doing localization work for the first time, I gained an understanding of what it means that so much of the online world has historically been built by native English speakers, many of them American or European.

But times are changing fast, and for the better.

People will resonate with your products if they experience it in ways that feel comfortable to them. Plus, if localization guidelines are in place from the design's inception, the process tends to go faster, thus increasing efficiency.

People will resonate with your products only if they
experience it in ways that feel comfortable to them.

Thank you for reading!