Most apps weren’t designed to be localized. They grew that way.
Legacy mobile apps tend to accumulate assumptions: strings embedded directly in code, UI layouts tuned for English, copy mixed into logic, and no clear ownership of text. When the decision to add languages finally happens, teams often assume the only safe option is a the real cost of maintaining localization in-house or a long feature freeze.
It usually isn’t.
This guide walks through a practical, low-risk approach to localizing an existing iOS or Android app incrementally, without stopping development or refactoring the entire UI layer.
Most legacy apps share the same issues:
- Hardcoded strings
- Inconsistent capitalization and punctuation
- No pluralization strategy
- Layouts that barely fit English
- No validation around translated files
None of these are fatal on their own. Together, they make “just translate the app” unrealistic.
The most common mistake is trying to localize everything at once.
A safer approach:
1. Pick 5–10 high-traffic screens
2. Externalize only the strings on those screens
3. Leave the rest untouched
This limits blast radius and makes problems visible early.
Instead of a massive refactor:
- Move strings out screen by screen
- Keep keys stable once introduced
- Avoid renaming keys during translation
On Android, this usually means gradually migrating hardcoded text into string.xml. On iOS, it means introducing .strings (and later .stringsdict) files as needed.
Legacy layouts are often tuned tightly to English.
Once translations land, you’ll see clipped buttons, overlapping labels, and truncated titles. This isn’t a failure — it’s expected. The key is surfacing these issues early and repeatedly, not all at once right before release.
Teams often use pseudo-localization or synthetic long-text languages to force layouts to stretch before real translations arrive, making layout fixes predictable instead of reactive.
Pluralization and placeholders are where legacy apps break most often.
Incomplete plural definitions or mismatched placeholders can cause runtime errors or subtle grammatical bugs that only appear in certain languages. These issues are much harder to fix once multiple languages are live, which is why getting them right early matters.
One of the reasons legacy localization feels risky is that teams treat it as a one-time project.
Modern teams approach localization as a continuous process instead:
- Strings are synced automatically as code changes
- New or modified text is translated immediately
- Validation runs on every update, not just before release
This reduces fear. Localization becomes part of the normal development loop instead of a disruptive event.
Tools like GetTranslated.AI are designed around this model. Instead of batch translations and manual reviews, they provide continuous string syncing, automated validation for plurals and placeholders, and safe AI-powered translation that fits into CI. The result is that adding a language — or changing copy — stops feeling dangerous.
The most painful localization bugs appear after the second or third language is added.
Before expanding, validate structure, placeholders, and required plural categories automatically. Without automation, these checks become manual and unreliable — especially once AI translation or multiple contributors are involved.
Localizing a legacy app isn’t about perfection. It’s about control.
By scoping carefully, externalizing incrementally, and adopting continuous localization with validation built in, you can add languages safely without rewriting your app or freezing development.
