UX Localization: Why Translation Alone Isn’t Enough

Your product is going global. You’ve handed the copy to a translator, the strings come back in twelve languages, and it ships. Job done. right?

Not even close. The words changed. The experience didn’t. Great localization isn’t a translation task. It’s a design problem. And most teams are solving the wrong one.

In 2009, HSBC spent $10 million rebranding globally. Not because of a failed campaign. Not because of a bad product. Because their tagline “Assume Nothing” had been translated in several countries as “Do Nothing.” Thirty words. One translator. Ten million dollars.

That is localization failure at its most expensive. But it happens every day at a smaller, quieter scale in digital products that technically work in twelve languages and genuinely feel right in none of them.

Here is the honest truth that most product teams avoid: translation is the easy part. Handing strings to a translator and shipping a multilingual build is table stakes. The real work, the work that determines whether a product feels native or foreign, lives in the design decisions that most teams never revisit for international markets.

This article is about those decisions.

Translation Is a Subset. Localization Is the Whole Thing.

When KFC launched in China in the 1980s, “Finger Lickin’ Good” became “Eat Your Fingers Off” in Mandarin. Pepsi once told Taiwanese consumers that Pepsi “brings your ancestors back from the dead.” These are translation errors, yes. But they point to something bigger: words carry context, and context is cultural.

Translation changes words from one language to another. Localization adapts the whole experience, including the typography, the layout, the imagery, the navigation, and the cultural assumptions baked into every interaction, so that someone in Tokyo, Riyadh, or Helsinki encounters something that feels built for them, not built elsewhere and shipped to them.

Translation vs. Localization

A good way to test whether your team thinks about localization or just translation: ask how your design handles a 60% longer string. If the answer is “it wraps,” you’re translating. If the answer starts with “we designed containers to flex at…” you’re localizing.

Your Font is misleading to 4 Billion People

There are over 7,000 languages spoken on Earth. Fewer than 526 have a meaningful presence on the internet. And of the web’s most visited languages, a large proportion use scripts that the average “premium” Latin typeface handles with somewhere between indifference and hostility.

Japanese Kanji have far greater visual density than Latin characters. A 16px body font in English reads fine. At 16px in Japanese, users are squinting. Arabic uses contextual letterforms where the same character changes shape depending on what surrounds it. Push a static Latin font through that and you get glyphs that don’t connect the way they should. It looks wrong in a way that is immediately obvious to every native reader and completely invisible to everyone else on the team.

Then there is the expansion problem. Translated strings are rarely the same length as the English source. German expands aggressively. Finnish is almost comedically long. Interfaces designed for English strings break quietly in both markets.

Japanese compresses by 20 to 30 percent, which sounds like a relief until you realize it needs a larger point size to carry the same visual weight. Arabic compresses too but introduces a right-to-left reading direction that the rest of your layout was never designed for.

A useful mental model: a font is a rendering engine for a specific writing system. When you choose a single global typeface, you are choosing a rendering engine that was optimized for one writing system and is now expected to handle several others. The results are exactly as rough as you’d expect.

If you have ever wondered why typography decisions carry so much weight in UX, the color and type psychology research I wrote about in 10 Subtle Ways Colour Psychology Shapes User Behaviour shows how deeply these perception signals land before a user has read a single word. Script-inappropriate fonts trigger the same response: wrong before the content has a chance.

The Whole Interface Is Pointing the Wrong Way

Here is something to genuinely sit with: approximately 420 million people read right to left. That is more than the entire population of the United States, almost twice the population of Brazil. And the overwhelming majority of digital products treat their reading direction as an afterthought, a single dir="rtl" attribute dropped into the HTML and shipped.

That attribute does almost nothing on its own.

RTL is not a stylesheet patch. It is an architectural question. Every directional affordance in your interface carries an assumption about reading direction: the breadcrumb flows left to right, the progress bar fills from left, the back chevron points left, the slide-in menu enters from the right. In an RTL context, most of those are wrong. Not visually wrong in a way that is hard to describe. Wrong in a way that any Arabic or Hebrew speaker identifies in under two seconds.

The Same Word. Very Different Rendering Needs.

The fix is not just mirroring. It is designing with logical CSS properties from the beginning so that direction is a parameter, not a hardcoded value. margin-inline-start instead of margin-left. padding-inline-end instead of padding-right. Small habit changes that make RTL localization a setting switch rather than a component-by-component audit months into production.

LTR vs. RTL: What Actually Needs to Flip

Elements that require RTL mirroring

• Navigation & menus – hamburger, logo placement, nav item order
• Breadcrumbs & pagination – step order, arrow directions
• Form fields & inputs – label alignment, placeholder text direction
• Directional icons – chevrons, arrows, back/forward controls
• Progress bars & sliders – fill direction, thumb starting position
• Animations – entrance transitions that imply directionality

These are the elements that need an explicit RTL review on every component:

This connects directly to accessibility work as well. The same logical CSS properties that support RTL layouts are the properties that respond correctly to user-defined reading modes and browser overrides. If you have not already read through the Web Accessibility Compliance Checklist, the overlap between a11y and localization is larger than most teams realize, and fixing one often fixes the other.

That Stock Photo Is Alienating Half Your Market

Consider what Amazon did when they entered Japan. It was not just the language that changed. The entire product page layout changed. Japanese e-commerce users expect far more information density than Western audiences, more product images, more specs, more social proof, more text, all visible without scrolling. Amazon’s famously minimal Western product pages felt, to Japanese shoppers, like something was being hidden from them. Trust requires density in that market. Minimalism reads as suspicion.

Imagery carries the same cultural weight. A hero image of a family that looks, dresses, and decorates their home in ways specific to one culture sends a quiet but clear message to everyone outside that culture: this was not made for you. Users do not consciously process this. They just feel less comfortable, less seen, and slightly less likely to buy.

There is also the color dimension. White is the color of mourning in several East Asian cultures. In Western markets, white reads as clean and trustworthy. Red signals danger in Western contexts and good fortune in Chinese ones. These are not decorative concerns. They sit directly underneath conversion rates. I covered the mechanisms behind this in the colour psychology piece, but in a localization context, the cultural layer compounds everything. The palette that your colour research validated for one market may be actively working against you in another.

Airbnb figured this out the right way. Rather than use generic accommodation stock photography globally, they invested in market-specific photography that reflected local aesthetic sensibilities. Japanese listing pages were shot to reflect Japanese interior design norms. The performance difference per market was significant. The investment was not in translation. It was in recognition.

None of this requires a per-market photoshoot budget. It requires a content model that treats locale-specific imagery as a first-class variable rather than a late substitution, a review step that includes a local perspective, and an honest look at whether your current hero imagery could have been shot anywhere in the world and probably was.

Key Insights

There is a version of localization that says: we have translated this product for you. And there is a version that says: we designed this for you. Users feel the difference within the first thirty seconds. Their time on site, their trust, and their willingness to come back all follow from which version they encounter.

The teams that get this right do not treat localization as a post-launch task. They build for it from the start, in the design tokens, in the component architecture, in how they model content. They design for the hardest locale first: if a layout handles Arabic RTL, Japanese Kanji density, and German text expansion without breaking, every other market slots in with much less effort.

HSBC lost $10 million because two words were wrong. Most localization failures are quieter. A Japanese user who silently closes a tab. An Arabic speaker who never finishes checkout. A German reader who gives up when a button label wraps badly and obscures the CTA. These losses do not show up as a single invoice. They show up as a mystery in your regional conversion data.

TL;DR

• Translation is not localization. It covers words. Localization covers typography, layout, imagery, navigation, and cultural framing. Translation is one input, not the output.
  
• Text expansion will break your layout. German and Finnish strings can run 35 to 55 percent longer than English. Design flexible containers by default, not as a fix.
  
• RTL is an architecture decision, not a stylesheet patch. Use logical CSS properties throughout the system. Audit every directional affordance before shipping to Arabic or Hebrew markets.
  
• No single font renders well across all scripts. Type tokens need to be scoped per locale group. Japanese needs larger sizes. Arabic needs cursive-aware fonts. Latin-only stacks fail silently.
  
• Color and imagery carry cultural meaning. White means mourning in several Asian markets. Red means fortune in China and danger in the West. Generic stock photography tells users you did not think about them.
  
• Designing for the hardest locale first is cheaper than retrofitting. The cost of building flexibility in at the start is a fraction of auditing and rebuilding a full system per new market.

Localization done well is invisible. Users in every market simply feel at home. That invisibility is the goal. And the gap between translation and localization is exactly the distance between a product that is technically available in a language and one that actually belongs there.

If this got you thinking about how your design decisions affect users before they even read a word, the article on Shaping the Future of Digital Experiences picks up a few of these threads from a broader systems perspective.

References and Further Reading

• CSA Research. Can’t Read, Won’t Buy: B2C. 2020. The source behind the stat that 75% of consumers prefer to buy in their native language, and that 56% rate language access above price. csa-research.com
• W3C Internationalization Working Group. Internationalization Best Practices for Spec Developers. The foundational reference for bidirectionality, script rendering, and cultural metaphors as architectural decisions. w3.org/TR/international-specs
• Nielsen Norman Group. Internationalization: Designing for a Global Audience. Research report covering layout, language, and cultural adaptation in enterprise product design. nngroup.com/reports/internationalization
• Google Fonts Knowledge. Choosing typefaces for multilingual websites. Practical guidance on font selection across Latin, Arabic, CJK, and Devanagari scripts. fonts.google.com/knowledge
• Mozilla Developer Network. CSS Logical Properties and Values. The reference for replacing directional CSS with locale-aware logical equivalents. developer.mozilla.org