Localisation gets scoped as translation and turns out to be a layout, formatting and process problem. The strings are the cheapest part; what costs is everything that assumed English text lengths, Latin script and Western formatting conventions.
01Layout is the first thing to break
German and Finnish routinely run substantially longer than English for the same label. Interfaces designed against English text clip, truncate or overlap the moment they are translated, and the failure is per-screen.
Fixed-width buttons and single-line labels are the usual casualties. Designing for text that can grow - flexible containers, wrapping allowed, no fixed heights around text - is far cheaper than fixing it afterwards.
This compounds with dynamic type. A long translation at a large accessibility text size is the worst case, and it is the combination that produces the screenshots users post.
02What actually needs handling
Beyond strings, several categories need explicit work and are consistently missed.
- Plurals. Languages have different plural categories and a simple one-or-many branch is wrong in many of them. Use the platform plural mechanism rather than string concatenation.
- Dates, numbers and currency. Format with locale-aware APIs; hardcoded patterns produce dates that read as a different day entirely in some locales.
- Sorting and search. Alphabetical order is locale-dependent, and naive comparison mis-sorts accented characters.
- Right-to-left layout. This is a mirroring exercise across the whole interface, not a text direction switch, and it affects icons, navigation and gestures.
- Images containing text, which cannot be translated by your string pipeline and are easy to forget.
03The process problem
Translation is not a one-off. Every release adds strings, and without a pipeline the translated locales drift behind the default one - users see a mixture of languages, which reads as broken rather than incomplete.
Extract strings automatically, track which are untranslated, and decide the fallback behaviour deliberately. Falling back to English is usually right; falling back to a key name is a visible bug that reaches production regularly.
Give translators context. A string in isolation is ambiguous - the same English word is a noun and a verb, and a translator without a screenshot will guess wrong roughly as often as not.
04Do not forget the store
Store listings localise separately from the app, and an app translated into eight languages with an English-only listing loses most of the benefit for discovery and trust.
Screenshots need localising too. A listing showing an English interface to a user browsing in another language undermines the claim that the app supports it, and install conversion reflects that.
Topics
Lena Voss
Lead Architect · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.
Talk to an engineer