A Japanese enterprise customer of ours cancelled a six-figure annual contract three months after rollout. The reason wasn't feature gaps, pricing disputes, or competitive switching. It was a settings screen where three localized strings had overflowed their container boundaries, the navigation breadcrumb trail was displaying in reverse order, and the date picker was using MM/DD/YYYY format instead of the Japanese standard 年月日.

The Japanese product manager who made the cancellation decision wrote in their exit feedback: "The product does not feel like it was made for us."

Three strings. One breadcrumb. One date format. Six figures gone.

I've been working in software localization for long enough to know that this story doesn't surprise anyone who's actually shipped localized software. What surprises me is how many companies still treat UI localization as a linguistic exercise — send the strings to translators, get them back, plug them in, ship it. That workflow works fine for documentation. For software interfaces, it's almost guaranteed to produce something that feels wrong, looks broken, or behaves unexpectedly.

Why UI localization is a design problem, not a translation problem

When you translate a user manual, the page layout adapts to the text. Content flows. Paragraphs grow or shrink. Nobody notices if a paragraph in German takes 30% more space than the English original because the page just gets longer.

Software interfaces don't work that way. A button has a fixed width. A sidebar has a fixed width. A modal dialog has a fixed width. The text inside those containers needs to fit, and when you translate English UI strings into other languages, the character length changes unpredictably.

A string like "Create New Project" fits comfortably in a 160-pixel-wide button in English. The German translation, "Neues Projekt erstellen," needs roughly 190 pixels. The French translation, "Créer un nouveau projet," needs about 210 pixels. If your button is locked at 160 pixels, three things can happen: the text gets truncated with an ellipsis, the text wraps to a second line, or the text overflows its container. None of these are acceptable, and none of them are the translator's fault.

The solution isn't to ask translators to write shorter text. The solution is to design interfaces that accommodate text expansion from the start. Flexible containers, responsive layouts, text that scales gracefully, buttons with generous padding. If you're building a SaaS product that will be localized into multiple languages, text expansion needs to be a first-class design requirement, not an afterthought discovered during localization.

The invisible problems that destroy trust

Some localization failures are obvious. Garbled characters — the classic "tofu" boxes or question marks that appear when the wrong character encoding is used — are impossible to miss. These are usually fixed quickly because they're visually jarring.

The more damaging localization problems are the subtle ones. The ones that don't look broken but feel wrong.

Navigation structure is one of the most common. English-language software typically uses a horizontal top navigation bar with a left-aligned logo and menu items reading left to right. In Arabic and Hebrew interfaces, the entire navigation paradigm needs to flip. Logo right-aligned, menu items reading right to left, breadcrumb trails reversed. Getting this right requires more than CSS direction properties — it requires a systematic review of every interactive element.

Date, time, and number formatting is another minefield. The US uses MM/DD/YYYY. Most of Europe uses DD/MM/YYYY. Japan uses 年月日. Time can be 12-hour or 24-hour. Numbers use different separators: 1,000.00 in the US, 1.000,00 in Germany, 1 000,00 in France. A financial SaaS application displaying currency values in the wrong format for a user's locale isn't just confusing — it's potentially misleading in ways that could affect business decisions.

Form field design interacts with localization in ways most teams don't anticipate. Name fields that assume a first-name/last-name structure break for Chinese, Korean, and many other naming conventions. Address forms designed around US/UK formats don't accommodate Japan, Germany, or Brazil. Phone number fields with fixed format validation won't work for international numbers. Postal code fields with length limits will reject valid codes from other countries.

These aren't edge cases for a product serving global markets. They're the default experience for a significant portion of your user base.

The UX localization process that actually works

Pseudolocalization first. Before any real translation happens, run your UI through a pseudolocalization pass. Replace all English strings with fake versions that simulate translated text characteristics — longer strings, accented characters, different character sets. This immediately reveals which UI elements will break. Every major design system recommends this step. Very few teams actually do it.

String context documentation. Every translatable string should be accompanied by context: where it appears, how much space is available, what it's next to, whether it's a button label or a heading or a tooltip. Translators working without context guess, and their guesses are sometimes wrong in ways that are embarrassing at best and confusing at worst.

Layout flexibility in the design system. Replace fixed-width text containers with flexible containers using max-width constraints. Test layouts at 130% of the original English text length — that covers most Germanic and Romance language expansions. If a layout breaks at 130%, redesign before localization starts.

In-context review after implementation. Don't review translated strings in a spreadsheet. Review them in the actual running application, on the actual screen sizes your users will use. This is where you catch text overlapping icons, buttons too small for touch targets, tooltips truncated, and dropdowns that don't display properly.

What user-centric design means in a localization context

"User-centric design" is a good principle, but in localization it needs to be made specific, because "the user" isn't a single persona — it's a collection of personas across different markets with different expectations, different mental models, and different assumptions about how software should behave.

A user-centric approach to software localization means designing your interface so that a user in Tokyo and a user in Berlin and a user in São Paulo all have the same quality of experience — not the same literal interface, but the same feeling that the product was designed with them in mind. Same ease of navigation. Same clarity of information. Same confidence that the text they're reading means what they think it means.

That's the standard. And it requires treating localization as a core product capability, not a bolt-on feature handled by a separate team after the "real" work is done.

At Artlangs Translation, software UI/UX localization is delivered by specialists who understand both language and interface design constraints, working with validated terminology and in-context review workflows across 230+ languages. Because a button that truncates its label is a bug, not a translation quality issue.