15 Interface Layout Problems to Check Before Localising a Digital Product
Fifteen layout problems that break interfaces in other languages, from text expansion and truncation to right-to-left mirroring, fonts, plurals and formats.
Which layout problems should you check before localising?
Check for text that grows and gets cut off, fixed-width buttons and labels, text inside images, strings built by joining fragments, right-to-left mirroring, fonts and line heights for other scripts, date, number, currency, name and address formats, plurals, sorting, icons that imply direction, and hard-coded text. Test early with pseudo-localisation and at least one long language and one right-to-left language, before paying for full translations.
This list is for product designers and front-end developers preparing a website, app or SaaS product for new languages. It focuses on interface layout; for wider market adaptation, see localisation vs translation. Expansion figures come from the W3C Internationalization Activity's guidance on text size in translation.
Text length
1. Text expansion. Translated text is usually longer than English, and short strings grow most. The W3C cites IBM averages of 200–300% expansion for English strings up to 10 characters and about 130% for strings over 70 characters. Buttons, tabs and table headers are the usual casualties.
2. Truncation that hides meaning. Ellipses that cut "Delete account" to "Delete acc..." in another language create confusion or risk. Allow wrapping where possible, and show full text in a tooltip only as a last resort.
3. Fixed widths and heights. Fixed-size buttons, cards and navigation items break with longer text. Use flexible layouts that grow and wrap, and test the navigation at its longest translation.
4. Text in images. Text baked into images cannot be translated without new artwork and is invisible to screen readers. Keep text as live text over images.
Strings and grammar
5. Concatenated strings. Building sentences from fragments ("You have " + count + " new messages") fails in languages with different word order or grammar. Use full sentences with placeholders, so translators can reorder them.
6. Plurals. Many languages have more than two plural forms, and some change by number in complex ways. Use an internationalisation library that supports plural rules (based on the Unicode CLDR data) instead of "if count is 1".
7. Hard-coded text. Labels, error messages, emails and alt text left in code will appear in English in every language. Search the codebase and templates for literal strings before translation starts.
Direction and scripts
8. Right-to-left mirroring. Arabic, Hebrew, Persian and Urdu read right to left, so the layout mirrors: navigation, progress steps and back arrows flip. Use CSS logical properties (start and end rather than left and right) and the dir attribute so mirroring happens automatically. See multilingual and RTL website development.
9. Icons that imply direction. Back, forward, reply and progress icons usually mirror in RTL; icons such as a clock, a play button or brand logos usually do not. Decide per icon.
10. Fonts and line height. Your brand font may not include Arabic, Devanagari, Thai or Chinese characters, and fallbacks can look out of place or be taller. Choose fonts per script and allow extra line height for scripts with tall marks.
11. Mixed-direction text. Product codes, email addresses, numbers and English brand names inside RTL text can display in a confusing order. Isolate them correctly in markup and test real examples.
Formats and data
12. Dates, times and numbers. Day and month order, 12- or 24-hour time, decimal separators and digit grouping (including India's lakh and crore grouping) differ. Format with locale-aware functions rather than fixed patterns.
13. Currency. Symbol position, spacing and decimals vary by locale and currency. Use locale-aware currency formatting and allow longer price strings in product cards.
14. Names, addresses and phone numbers. Forms with fixed first and last name fields, a required state field or a five-digit postcode exclude many countries. Adapt fields per market.
15. Sorting and search. Alphabetical order differs between languages, and search must handle accents and other scripts. Use locale-aware sorting and test search with real non-English queries.
Preparing a product for new languages?
ZSpace Labs designs and builds multilingual websites, apps and SaaS interfaces, including right-to-left layouts. See our UI/UX design service.
Pre-localisation checklist
| Problem | How to catch it | Fix |
|---|---|---|
| 1. Text expansion | Pseudo-localisation; German or Finnish test | Flexible layouts |
| 2. Truncation | Review longest strings per screen | Wrap; rewrite; tooltips as last resort |
| 3. Fixed sizes | Resize text to 200% in tests | Flexible components |
| 4. Text in images | Image audit | Live text over images |
| 5. Concatenated strings | Code review of string building | Full sentences with placeholders |
| 6. Plurals | Test counts 0, 1, 2, 5, 11, 21 | CLDR-based plural rules |
| 7. Hard-coded text | Pseudo-localisation shows untranslated text | Move strings to resource files |
| 8. RTL mirroring | Arabic test build | Logical properties; dir attribute |
| 9. Directional icons | Icon inventory | Mirror only where meaning is directional |
| 10. Fonts and line height | Render each script | Per-script fonts; extra line height |
| 11. Mixed direction | Real RTL content with codes and numbers | Isolate embedded text |
| 12. Dates and numbers | Locale switch tests | Locale-aware formatting |
| 13. Currency | Price display per market | Locale-aware currency formatting |
| 14. Names and addresses | Form review per market | Market-specific fields |
| 15. Sorting and search | Search tests with real queries | Locale-aware collation and search |
Making it easier next time
- Run pseudo-localisation in development builds so problems appear before translation.
- Use design tokens and components that allow text to grow; see design token categories.
- Give translators context: screenshots, maximum lengths where they are real, and notes on placeholders.
- Write source text in plain, short sentences; it translates more reliably. See UX writing.
- Budget design review time for each new language, especially the first right-to-left one.
Conclusion
Most localisation bugs are layout and string-handling problems that exist before a single word is translated. Test with pseudo-localisation, a long language and a right-to-left language early, fix fixed widths, concatenated strings and hard-coded text, and use locale-aware formatting. For a market-specific example, see Saudi website localisation.
Sources
W3C Internationalization Activity, text size in translation. Unicode CLDR, language plural rules. Accessed 28 October 2026.
Common questions.
More for short strings than long ones. The W3C cites IBM figures showing that English strings of up to 10 characters can grow by 200–300% in European languages, while strings over 70 characters grow by about 130%. Design flexible layouts rather than fixed widths.