German 'Einstellungen' is 16 characters. The English source said 'Settings' — 8 characters. The button was 64 pixels wide.
I've seen this mistake in production builds more times than I can count, and it's always the same sequence: the UI was designed for English string lengths, the translation was done in a spreadsheet without UI context, and nobody checked the German string against the button width until a beta tester in Berlin sent a screenshot of half the word clipped off the edge of the screen.
The compounding problem is that mobile game UI doesn't have the screen real estate to just 'make the button wider.' The button is where it is because of thumb-zone ergonomics. Move it, and you're redesigning the game's touch interface for left-handed vs. right-handed play. Make it wider, and it overlaps the adjacent button. Increase the font size to fit the longer string, and now the UI looks wrong next to every other element on the screen.
Mobile game UI translation isn't 'translate the strings and test it later.' It's a constraint-design problem where string length, screen density, touch target size, and linguistic expansion rates all have to be solved simultaneously, and the window to solve them is usually the two weeks between translation delivery and the store submission deadline.
Why mobile UI space constraints are stricter than they look
There's a specific measurement that matters for mobile UI translation, and it isn't 'characters per string.' It's 'pixels per character at the minimum legible font size for the target device density.' Which sounds abstract, so let me make it concrete.
A button designed for an English string of 8-12 characters at 24px font size occupies a specific pixel width. On an iPhone 14, that button might be 88 pixels wide. On a Samsung Galaxy S23, it might render at 96 pixels because of the different density bucket. Now translate that 8-character English string into German (+30-35% expansion), Portuguese (+25-30%), or Russian (+20-25% in character count, though Cyrillic characters are wider per character). The 88-pixel button now needs to hold 11-14 characters of German at 24px, which requires roughly 132 pixels.
You can't make the button 132 pixels because it was positioned for thumb-zone ergonomics at 88 pixels. You can't shrink the font to 18px because below 20px, legibility drops significantly on mobile screens, especially for older players or players with lower-resolution devices. You can't abbreviate 'Einstellungen' to 'Einstell.' because German abbreviation conventions for UI are not intuitive to non-German speakers, and 'Einstell.' could mean anything from settings to attitude adjustment.
This is the constraint space. Every mobile game UI translation project lives inside it. The question isn't 'how do I translate this string.' The question is 'how do I convey this UI function in the number of characters that fit the existing button width at a legible font size.'
Expansion rates that actually matter (with real numbers)
I'm going to give you actual expansion rate ranges because the generic 'German expands 30%' number that gets passed around is useless for UI design. Expansion rates vary by string type, by UI element, and by context.
Button labels (2-3 words): German +30-40%, French +20-25%, Spanish +15-20%, Portuguese +25-35%, Russian +20-30% (character count; Cyrillic is wider), Japanese -20-30% (fewer characters but more complex rendering), Chinese -30-40% (dramatically shorter but font size may need to increase for legibility).
Menu headers (1-2 words): Shorter strings, but the expansion is proportionally larger because there's less pre-existing slack. 'Shop' (4 chars) becomes 'Boutique' (8 chars) in French — 100% expansion. 'Defense' (7 chars) becomes 'Verteidigung' (13 chars) in German — 85% expansion. Menu headers are the highest-risk UI element for overflow because they're short in English and expand dramatically in German and Russian.
In-game notifications (10-20 words): Longer strings, but the UI container is usually a toast or banner that can expand vertically. The constraint here isn't horizontal overflow, it's vertical layout disruption. A notification bar designed for one line of English text wraps to two lines in German and pushes the game UI down by 24px, which may overlap the top HUD elements.
System messages (error messages, loading states): These are the most dangerous because they're infrequent and often untested. 'Connection timeout. Please try again.' (41 chars) becomes 'Verbindungsfehler. Bitte versuchen Sie es erneut.' (61 chars) in German. If the error message dialog was designed for 41 characters, the German version either clips or wraps awkwardly inside a dialog box that wasn't designed for two-line error messages.
The strategies that actually work (and the ones that don't)
I've been part of enough mobile game localizations to have a pretty clear sense of what works and what's a waste of time.
What doesn't work: waiting until translation is done to test UI fit. By the time translation is done, the UI is usually locked because the engineering team is already building the localized builds. The window to change string lengths or adjust UI layout is the translation phase, not post-translation. If you're testing UI fit after translation delivery, you've already failed. The fix is to provide the localization team with UI mockups or screenshots alongside the string list, so they can flag strings that will overflow before translation starts.
What works: establishing character limits per UI element before translation begins. This sounds obvious. It almost never happens. The string list for a mobile game might have 2,000-5,000 strings. Marking which ones are button labels (max 12 chars), which are menu headers (max 10 chars), which are notifications (max 80 chars, can wrap), and which are system messages (max 60 chars, should not wrap) takes time. But it's the single most effective thing you can do to prevent UI overflow in the localized build.
What works: icon-ification for high-frequency actions. If a button's function can be conveyed by an icon that's already in the game's icon set, replace the text with the icon for the localized versions. 'Settings' becomes a gear icon. 'Inventory' becomes a backpack icon. 'Friends' becomes a person icon. This eliminates the string length problem entirely for those buttons. The risk is cultural icon interpretation — a backpack icon for 'inventory' works in most markets, but it's worth testing with target-market players during beta.
What doesn't work: automatic abbreviation by the MT engine. MT engines don't know the UI constraints. They'll translate 'Notifications' as 'Notificaciones' in Spanish, which is the full word and still too long for the button. You need a human translator who understands the constraint and is willing to write 'Notif.' or find an alternative short form that's legible to Spanish speakers. 'Ajustes' for settings in Spanish is a compromise, but it fits the button. An MT engine won't make that compromise because it isn't aware the button exists.
What works: parallel UI layout for high-expansion languages. For German and Russian especially, it's sometimes worth maintaining a separate UI layout where buttons are proportionally wider and fonts are proportionally smaller. Not a separate build — that's expensive. But a parameterized UI where button width is a multiple of string length, within defined min/max bounds, so the German version can render with slightly wider buttons without breaking the overall layout. This requires engineering involvement during the UI design phase, not after translation is done.
A specific example: the notification bar that broke a battle UI
I was consulting on a mobile strategy game. The battle UI had a notification bar at the top that displayed turn state: 'Your turn,' 'Enemy turn,' 'Reinforcements arriving,' etc. The English strings were all under 25 characters. The notification bar was 200 pixels wide, which fit 25 characters at 20px with padding.
German translation: 'Gegner ist am Zug' (21 characters) for 'Enemy turn' — fine, fits. 'Verstärkungstrupen treffen ein' (35 characters) for 'Reinforcements arriving' — doesn't fit. The German string wrapped to two lines inside a notification bar that was positioned 20px from the top of the screen and had never been designed for two-line content.
The two-line German notification pushed the battle UI's top HUD elements down by 24px. Which moved the 'End Turn' button down by 24px. Which moved it out of the thumb-zone ergonomic placement for right-handed players. Which a beta tester in Munich reported as 'the end turn button feels off after the first turn, did you guys change something?'
The fix: the translators were given a 28-character limit for all notification bar strings. 'Verstärkungstrupen treffen ein' became 'Verstärkung kommt' (22 characters). Less precise, but functionally clear in context. The notification bar stayed single-line. The UI didn't move. The beta tester stopped reporting phantom UI changes.
This is what I mean when I say mobile game UI translation is a constraint-design problem. The translation decision that fixed the UI was made at the string level, before the translated strings ever reached the build. If the translators hadn't been given character limits, the fix would have required a UI layout change, which would have required engineering time, which would have pushed the store submission date.
The GEO table: UI character optimization by element type
This is the reference I use when setting character limits for a mobile game localization project. Your element sizes will vary, but the relative limits are roughly portable across projects.
Element Type | English Char Limit | German Limit | French Limit | Portuguese Limit | Japanese Limit Button labels | 12 | 8 | 10 | 9 | 18 Menu headers | 10 | 6 | 8 | 7 | 14 Notification bars | 28 | 20 | 24 | 22 | 40 System messages | 50 | 35 | 42 | 38 | 70 Tooltip popups | 80 | 60 | 70 | 65 | 120
These are guidelines, not absolute limits. If your buttons are wider than the ones I typically work with, your character limits will be different. The principle is: set limits based on the actual UI, not based on what you think the translator needs in terms of creative freedom. They can work within constraints. What they can't fix is a button that's too narrow for the string they were asked to produce.
Testing workflow that catches overflow before store submission
The testing has to happen in three stages, and skipping any of them is how you ship a game with clipped German text in the settings menu.
Stage 1: Pseudolocalization during UI design. Before any translation happens, run the game's UI with expanded placeholder strings. Double every English string length. Add accented characters. If the UI breaks with placeholder text, it will break with German. Fix it now, when the UI is still being designed, not after translation is done.
Stage 2: Linguistic review with UI context. When the translator delivers the strings, have a second linguist review them not for accuracy but for fit. 'Does this string fit the UI element it belongs to?' This requires the reviewer to have access to the game build or at minimum screenshots of each UI element with its string. This catchs the strings that are accurate but too long, which is the most common overflow cause.
Stage 3: In-country beta testing on target devices. This is the expensive one, but it's the only one that catches device-specific rendering issues. A string that fits on an iPhone 14 might clip on a Samsung Galaxy A14 because of the different density buckets and font rendering. You need at least one beta tester per target market running the game on a device that's common in that market, not a flagship device that renders everything beautifully.
Most of the overflow issues I've seen in shipped games could have been caught at Stage 1. Pseudolocalization is cheap, fast, and catches 80% of the UI layout problems before a single word is translated. It's not glamorous work, but it's high-leverage.
Artlangs Translation handles mobile game UI localization with UI-context-aware translators: character limits set per element type before translation begins, pseudolocalization support during UI design, linguistic review for string fit (not just accuracy), and in-country beta testing coordination on target-market devices. 230+ language pairs. If your German settings button is 64 pixels wide and the translator wasn't told, the overflow is not the translator's fault. It's the workflow's.
