There are two kinds of mobile apps:
If you've ever tried to retrofit localization into an English-only app, you know the drill: text overflows, broken layouts, plural rules that make no sense, and UI constraints that collapse under pressure.
The solution is straightforward: design for localization from the start. This guide covers the core practices that make multi-language support manageable in 2026.
If a human can read it, it should live in a strings file — not embedded in your code.
strings.xml.strings / .stringsdictExternalized text keeps your app's language layer organized, translatable, and maintainable. It also makes it possible to validate translations systematically rather than hunting through code for hardcoded strings.
English tends to be compact. Most other languages are more verbose.
Plan for roughly 35% text growth in typical UI labels. German compound nouns and Arabic script can push this even higher.
Your layouts should handle:
* Longer words that don't break naturally
* Text wrapping across multiple lines
* Dynamic constraints that adjust to content
* Fallback spacing when things get cramped
One effective approach is testing with artificially expanded text during development. Tools that inflate your strings reveal layout stress points before real translations arrive.
Concatenation creates translation nightmares:
"Hello " + name + ", your order is " + status
Different languages reorder sentence components, change grammatical cases, and move placeholders around. Use complete sentences with placeholders instead.
For complex formatting needs, consider established solutions like ICU MessageFormat rather than building custom concatenation logic.
Placeholder validation becomes critical as your app scales across languages.
Plural rules vary dramatically across languages. English has essentially two forms (singular/plural), but other languages have complex rules based on quantity, gender, and context.
Use the right structures:
* iOS → .stringsdict files
* Android → <plurals> resources
* Cross-platform → ICU MessageFormat
Don't assume you can extrapolate from English plural patterns. Each language needs proper plural handling from day one.
Translators need context clues. The word "Apply" could be:
* A button action
* A verb in instructions
* A filter operation
* Part of an application process
Include developer comments, usage notes, and UI context in your string files. The more context you provide upfront, the fewer translation revisions you'll need later.
Text embedded in images seems harmless until localization day, when you discover you need separate image assets for every language.
Make text dynamic whenever possible. Use overlays, separate text layers, or vector graphics with replaceable text elements.
When you must use text in images, plan for the asset management overhead across all target languages.
Pseudo-localization reveals:
* Missing externalized strings
* Invalid placeholder handling
* Character encoding issues
* Basic structural problems
But pseudo-loc doesn't always catch length-related layout issues. That's where synthetic long-text testing helps — tools that deliberately stress your layouts with expanded content can reveal cramped designs before real translations expose them.
Right-to-left languages affect more than just text direction:
* UI element alignment
* Navigation flow
* Icon orientation
* Animation directions
* Gesture patterns
Building RTL support early is significantly easier than retrofitting it later. Most modern UI frameworks provide RTL layout support — enable it during initial development rather than treating it as a later enhancement.
Well-prepared projects typically have:
☐ All user-facing strings externalized
☐ No string concatenation in UI code
☐ Proper plural rule implementation
☐ Flexible, content-aware layouts
☐ Pseudo-localization testing integrated
☐ Long-text stress testing completed
☐ RTL layout validation
☐ No text embedded in images
☐ Comprehensive translator context
☐ Clean, organized resource file structure
☐ Validation workflows in place
Hitting most of these items puts you in strong position for smooth localization workflows.
Building localization support from the beginning requires some upfront planning, but it prevents the much larger effort of retrofitting international support into an English-centric codebase. The practices outlined here have proven effective across teams scaling from single-language prototypes to globally distributed applications.