TL;DR — String translation is the easy part of mobile localization. The hard parts are RTL layouts, plural forms, date / number / currency formats, region-specific assets, and the build pipeline that keeps it all in sync. Plan for them up front; retrofitting is brutal.
Localization presented as “we just translate the strings” is the project that ships at 70% quality. Real localization touches layout, formatting, assets and content — not just text.
The five layers
1. Strings
The obvious layer. Use a translation management system (Crowdin, Lokalise, Phrase). Treat translations as a build artifact, never hand-managed.
2. Layout (especially RTL)
- RTL flips horizontal direction — flex, padding, margins, icons
- Logical CSS properties (
marginStartvsmarginLeft) - Direction-aware icons (e.g., back arrow flips, brand logo does not)
- Test on a real device with RTL set, not just a CSS toggle
3. Formatting
- Dates — never concatenate parts; use Intl.DateTimeFormat
- Numbers — separators differ (“1.000,50” vs “1,000.50”)
- Currency — symbol placement, ISO codes, formatting
- Plurals — ICU MessageFormat, not
if (count === 1)
4. Region-specific assets
- Images with text — need per-locale versions or text overlay rendered at runtime
- Icons that imply cultural context (gestures, symbols)
- Voice / video content where applicable
5. Content
- Onboarding flows often need per-region pacing
- Help articles and support content per locale
- Legal / privacy content has regional requirements
The pipeline that works
- Source strings live in code with unique keys
- A build step extracts strings to TMS-friendly format
- TMS holds translations, translation memory, glossary
- Build pulls translations, validates coverage, fails on missing translations
- App ships with locale bundles separate from code
What we wish we had done sooner
- Design with RTL in mind, not retrofit
- Build the formatting helper layer in week 1, not after the first localization bug
- Test on real devices in target locales, not on CSS toggles
Frequently asked questions
Do I need RTL support if I do not target Arabic / Hebrew markets?
Depends. If your app will ever be sold to companies with employees in MENA, yes. RTL added later is brutal; RTL designed in costs little.
How do you handle string changes after translation?
Treat strings as a build artifact. Translation memory + a TMS + a pipeline. Stop emailing CSVs to translators.
Working on something similar?
T-Square architects, builds and operates production systems for learning, AI and custom software products. Talk to a senior engineer for a second opinion.