The biggest enemy of localization? UI that can’t handle another language

16 min

July 23, 2026

Author: Petr Poláček, Vojtěch Schubert

Overflowing texts, broken menus, text squeezed into buttons, and text baked directly into images. When localization goes wrong, the fault sometimes isn’t in the translation, but in a poorly prepared user interface.

The most visible localization problems often don’t arise during translation, but long before it begins. It happens the moment creators design an interface that, in reality, only accounts for English. In the original English version of the game, everything fits perfectly. The text inside the buttons is aligned both horizontally and vertically, the subtitles as well, and all possible settings look organized. But then come the other languages. German, French, Czech, Arabic, Japanese, and more. And it turns out that the interface wasn’t prepared for localization at all, but merely for swapping English words with other words of the exact same length. That, however, is not how localization works in relation to UI, and this is largely an internationalization issue.

And what’s internationalization? It’s the process of designing products, services, or software so that they can be easily adapted to various languages, regions, and cultural conventions without requiring engineering changes. It acts as the foundational framework for localization – the actual translation and adaptation for a specific local market.

English is having fun; the rest are crying in the corner

English is treacherously convenient for interface design. Many common gaming terms are short: Play, Save, Load, Quit, Map, Shop. When a menu is tailor-made strictly around these words, it results in something that looks neat only until it needs to be translated.

Take an example from the Flickr interface. The English word “views” becomes roughly 2.6 times longer in French and Portuguese, 2.8 times longer in German, and a full three times longer in Italian. It’s precisely these short labels that tend to be the most high-risk because creators often literally cram them into buttons, tabs, or narrow columns without leaving any buffer space.

The translation might be completely accurate, but it simply won’t fit anywhere. In practice, this type of situation is sometimes resolved through “creativity” in the translation. A sentence is shortened, a more precise term is replaced by a broader one, or part of the meaning is suppressed just to make the text fit inside a button or panel. On the surface, everything looks fine. Nothing overflows. But at that point, localization is no longer looking for the best possible solution, but rather the shortest acceptable one. This is a difference that a player might not consciously pinpoint, but they will certainly feel it in the overall clarity of the game.

A word broken in the middle

Some languages challenge the UI not just with longer sentences, but with long single-word units that break poorly within narrow spaces. A classic example is German. The English phrase “Input processing features” might turn into “Eingabeverarbeitungsfunktionen”. While the English phrase is split into several words, the German compound acts as one long, solid block that easily spills over a button, tab, or narrow information bar.

German isn’t alone in this. Finnish and Dutch are also frequently cited for generating long compound words. The Finnish “asiakaspalautejärjestelmä ”means “customer feedback system,” which is a concept English naturally breaks down into multiple words. For UI design, the core issue is that such a compound word might not elegantly break across lines exactly where the screen layout requires it to.

In games, this doesn’t just affect settings menus; it can just as easily break an ability name, an inventory category, a game-mode label, or text inside a confirmation prompt.

Flowery language doesn’t play nice with the UI

Sometimes, however, the UI doesn’t break visually, but rather because the language itself gets tangled up. This frequently occurs in segments where the game reuses a single short English term across many different situations, or pieces sentences together based on specific contextual meanings.

The English word “Enabled” works almost anywhere. In Czech, however, it changes completely depending on whether it refers to an “enabled" mode (povolený), an “enabled” feature or option (zapnutá), or an “enabled” setting (povolené). One universal translation is nowhere near enough, and it means devs have to create more than just one string that would fit all, namely to cover all grammar variants that simply do not exist in English.

Equally problematic is stringing sentences together from fragments like “Press {button} to” + “open.” English can tolerate this. But Czech, Polish, and other Slavic languages need to work with the entire sentence structure, word order, and grammatical cases.

The solution actually exists long before the text is sent off for translation. Either these diverse linguistic needs are factored in during the initial UI design phase, or the interface is tested early on using pseudolocalization. According to Unity’s documentation, pseudolocalization can reveal a lack of space, hardcoded strings, and text that’s concatenated in ways that will assemble poorly post-translation.

Beginning at the end

For example Arabic and Hebrew introduce not only the right-to-left (RTL) text, but bring two separate challenges. The first is bidirectional (bidi) text: right-to-left (RTL) text routinely mixes with numbers, Latin names, and technical strings that still read left-to-right, so correct bidi handling is non-negotiable wherever the text appears, regardless of layout.

The second is layout direction. For software and websites, platform guidelines from Microsoft, Apple, and Google call for mirroring the interface: menus, sliders, and navigation flip to match reading direction, while direction-neutral icons stay put. In games, practice varies, many titles keep the familiar layout and localize the text within it, and from the experience of our Arabic team, many bilingual RTL players prefer exactly that.

Either way, the direction of each element should be a deliberate design decision validated with native players or experts, not a mechanical flip.

Hey, symbol! Get to the end of the line!

Japanese and Chinese might seem less problematic at first glance because their translations often require fewer characters than English. But character count isn’t the same as proper line breaking. These languages don’t separate words with spaces the way European languages do, and they follow strict, inherent rules regarding which characters are allowed at the beginning or end of a line. In Japanese, these line-breaking rules are known as kinsoku shori.

The result can be deceptive. The text might not overflow anywhere, but to a native reader, the line breaks can look incredibly clumsy and the quality of localization (and player immersion) is immediately compromised. This is most glaringly obvious in narrow item descriptions, help text, or quest logs.

Afraid of heights? You should be...

Interfaces are often tested based on whether the text fits horizontally. However, certain languages require more vertical space, both upwards and downwards. A prime example is Vietnamese. It uses the Latin alphabet but features rich, frequently stacked diacritics. For some characters, multiple accent marks are layered on top of the base letter. According to Google Fonts guidelines, these specific combinations require meticulous handling of vertical spacing and diacritic design.

For the UI, this means one thing: it’s not enough to simply verify that the translation fits the width. If a button, label, or text line has an overly restricted height, the text can look squashed, bleed into the adjacent line, or have its upper portions clipped. A similar issue easily occurs when a chosen font technically supports a language on paper but hasn’t been properly optimized for it.

Tricky baked-in images

A completely separate challenge is text embedded in graphics, often referred to in the localization industry as text-in-art. This is text that isn’t a standard, localizable string, but is permanently burned into an image file. It could be a tutorial screen, a promotional banner for an in-game event, a poster in a 3D scene, a controller layout graphic, or a stylized menu logo.

This poses no issue in the English version, as the graphic was originally created in English. During localization, however, one single graphic suddenly spawns a massive set of language variants that must be generated, implemented, QA-checked, and later manually updated with every subsequent change. Microsoft explicitly reminds developers that localization isn’t just about text; it encompasses images and other visual assets as well.

This doesn’t mean text graphics have no place in gaming. However, if the player genuinely needs to read, comprehend, and act on that text, it’s usually much safer to render it as standard, localizable text rather than baking it directly into the graphical asset, even if it means extra work for the scripters and programmers.

Mistakes cost time and money

A poorly prepared UI doesn’t just ruin the player experience; it drives up costs. When developers realize just before launch that translations are overflowing or the interface is crumbling across several languages, simply tweaking the text is rarely enough. Fixing it requires the combined efforts of a translator, a localization tester, a UI designer, and the personnel responsible for implementation and compiling new builds.

Once again, this points back to pseudolocalization: catching these issues early logically saves both time and money. Adjustments to text limits and layout structures can be made before the content is even sent to translators.

Take a basic model scenario: ten screens require layout adjustments post-localization. Between design and implementation, that’s two hours of work per screen. That equals 20 hours. Factor in a second round of QA across four different languages, and suddenly “a few overflowing text boxes” balloons into 40 hours of extra work for multiple team members. While not a universal formula, it perfectly illustrates how quickly a minor UI design oversight morphs into a major production (and financial) bottleneck.

Consoles are in a league of their own

For console releases, this entire subject becomes even more sensitive. Public documentation from Xbox, Sony, and Nintendo reveals that localization covers not just in-game text, but also the title of the game, store descriptions, logos, splash screens, and other assets tied to the user’s system-language settings. If it’s discovered late in the process (typically during the first wave of platform-holder certification testing) that a localized variant doesn’t fit, it’s rarely a quick fix of a single sentence. It becomes a structural intervention into the game’s release candidate.

And that gets expensive. It can delay the launch date. Sometimes it demands a completely uncoordinated, emergency overhaul of individual UI screens.

A good UI, therefore, isn’t just one that works in English. It’s one that actively anticipates that another language will be longer, taller, will wrap differently, read in the opposite direction, or require entirely different sentence structures. When done right, localization teams working alongside QA and designers don’t have to scramble to salvage a design that ignores the existence of other languages. Instead, they can do exactly what they were meant to do: help the game feel perfectly natural in every supported language.

Need help?

Whether you are preparing to release your next game internationally or need guidance on best practices during the design phase, let us know. We would be glad to help!

Sources