Internationalize From Day One: Treat English Like Any Other Locale
Why building internationalization into your app from the start saves time, money, and prevents embarrassing translation fails
Internationalize From Day One: Treat English Like Any Other Locale
Modern apps travel further than their creators ever will. Yet many still break the moment they cross a linguistic border—sometimes hilariously so. If you've ever seen "This is what it feels like to read text translated into your language when you don't internationalize properly," you know the pain.
Watch the talk: Internationalization For English on Vimeo
Why Bother? Three Fast Facts
- Users pay for polish. A premium subscription should feel native, no matter the language.
- The world isn't anglophone. 72% of iPhone owners prefer a language other than English; China alone drives a huge percentage of global mobile-game revenue.
- Tech debt is real. Like documentation, i18n costs time now or much more later.
i18n vs. L10n (and Why Both Matter)
| Term | What it means |
|---|---|
| Internationalization (i18n) | Designing software so it can adapt to any locale. |
| Localization (L10n) | Supplying the locale-specific pieces—copy, images, colors, culture. |
Think of i18n as building a house with modular walls; L10n is painting those walls the color each guest prefers.
The Case for Treating English as a "Foreign" Language
- Encapsulates all text early, so swapping strings later is trivial.
- Keeps copy edits out of your view controllers.
- Produces translator-ready files by default.
The traditional flow—"ship English first, retrofit later"—guarantees angry designers, duplicated code, and creeping bugs. Flip it: internationalize first, localize English, then add more locales when you're ready.
Five Engineering Practices to Adopt Today
| Practice | Why it helps |
|---|---|
| Ban raw strings. Use resource files or constants exclusively. | Prevents hardcoded text that's impossible to translate later |
Lean on system libraries (ICU, ISO8601DateFormatter, NumberFormatter). | Leverages battle-tested localization logic |
| Assume text can shrink or grow. Never hard-code widths. | Accommodates languages with different text lengths |
| Document every string—explain context for translators. | Provides crucial context for accurate translations |
| Write code samples, not comments, to show engineers exactly how to fetch localized copy. | Makes implementation clear and consistent |
Ten Common Gotchas (and How to Dodge Them)
- Calendars – Gregorian isn't universal; iOS users can pick Japanese or Buddhist calendars.
- ISO 8601 – Always use the standard when exchanging dates; never roll your own.
- Truncation – Word-break rules differ; don't guess where you can split.
- Current vs. fixed locale – Show data in the user's locale; send data in a known one.
- Number formatting – Periods vs. commas, lakhs vs. millions—delegate to
NumberFormatter. - Capitalization – Some languages lack case; use
localizedUppercase/localizedLowercase. - Plurals – English has two forms; Slovenian has four, Celtic six. Use ICU plural rules.
- Gendered nouns & pronouns – Store grammatical gender when it changes wording.
- String length limits – Hard caps break Japanese and emoji; design flexible UI.
- Left vs. right – Use "leading"/"trailing" to support RTL scripts.
Conclusion
Language is hard; fixing it later is harder. Bake i18n into your project from sprint one, and English becomes just another locale—no more, no less. The payoff? A codebase that scales worldwide and users who feel at home the moment they open your app.
Comments (0)
Sign in to join the discussion