Game UI String Translation and Length Limits

Quick answer — Game UI strings are constrained by art that does not reflow, so length limits have to travel with every string. German and Russian run longer than English, and a menu built to fit English breaks in both.

Vitra.ai Universe keeps character voice and terminology intact across every language.

The panel does not stretch

Application UI reflows. Game UI is usually art — a carved menu plate, a HUD element, a button baked into a texture — with a text field of fixed size sitting on it.

So a translation that runs long has three outcomes, and all of them are bad: truncation, a font scaled down until it is unreadable, or text spilling past the frame.

Send the limit with the string

A limit is a design constraint, so the translator writes to it rather than translating to it. A shorter word that fits beats an accurate one that truncates, and only the translator can make that trade if they know the budget.

Design for the longest language

The usual guidance is to leave thirty percent headroom for German, which is roughly right and not sufficient on its own — Russian runs long too, and compound-heavy languages produce single words that cannot be broken.

Better where the art allows: text fields that can grow downward, two-line tolerance on buttons, and no critical label baked into a texture.

Anything with words inside the artwork needs image translation rather than a string pass, and it is the most commonly missed part of a localized build.

Reused strings are a false economy

One Confirm shared across twelve screens looks efficient and guarantees at least one context where it is grammatically wrong. Separate keys per context cost nothing at build time and remove a whole class of LQA finding. The saving from reuse is a handful of translated words; the cost is a tester filing a bug, a translator explaining that the word is correct in eleven of twelve places, and somebody deciding which context loses. That trade is never worth taking.

Check it on screen

String length problems are invisible in a spreadsheet and obvious in the build.

Run pseudo-localization before translation — every string padded and accented — and the fixed-width fields surface while the fix is still a UI change rather than a re-translation. Then quality control on the extracted text, and a human on the running game.

FAQ

Why is game UI harder than application UI? Because it usually does not reflow. Menus, HUD elements and buttons are art with fixed text fields, so a long translation truncates, shrinks below legibility, or spills past the frame.

What should be sent with each UI string? The character or pixel limit, a screenshot or screen name, whether the string is reused, its source, and what any variables hold. A limit lets the translator write to it rather than overflow.

How much headroom should game UI leave? Around thirty percent for German is the usual starting point, but it is not enough alone. Russian also runs long and compound languages produce unbreakable single words.

Should the same UI string be reused across screens? No. One shared label across many contexts guarantees at least one is grammatically wrong, and separate keys per context cost nothing while removing a common class of LQA finding.