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
Why building internationalization into your app from the start saves time, money, and prevents embarrassing translation fails
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
Click below to load the embedded presentation.
| 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 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.
| 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](https://en.wikipedia.org/wiki/ISO_8601), [NumberFormatter](https://developer.apple.com/documentation/foundation/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 |
NumberFormatter.localizedUppercase/localizedLowercase.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.