Get in touch

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.

Mobile localization — five layersStrings · layout · formatting · assets · content. String translation is the easy 20%. — /localization layers 1 · StringsTMS · translation memory · build artifact 2 · Layout / RTLlogical properties · direction-aware icons · real-device test 3 · FormattingIntl.DateTimeFormat · number sep · currency · ICU plurals 4 · Assetsper-locale images · icons · cultural symbols 5 · Contentonboarding · help · legal · privacy per region
Strings · layout · formatting · assets · content. String translation is the easy 20%.

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 (marginStart vs marginLeft)
  • 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

  1. Source strings live in code with unique keys
  2. A build step extracts strings to TMS-friendly format
  3. TMS holds translations, translation memory, glossary
  4. Build pulls translations, validates coverage, fails on missing translations
  5. 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.