Internationalize From Day One: Treat English Like Any Other Locale

I gave this talk after one too many apps shipped with English hardcoded everywhere and "we'll localize later" on the roadmap forever. Later never comes cheap. If you've seen the meme about reading text translated into your language when a developer skipped i18n, you've felt why.

Watch the talk: Internationalization For English on Vimeo

Click below to load the embedded presentation.

Why bother on day one

Users pay for polish. A premium subscription should feel native in every language you ship.
Most iPhone owners aren't reading English. 72% prefer another language. China alone drives a huge chunk of global mobile-game revenue.
i18n is tech debt you choose. Like documentation, you pay now or pay a lot more when you're retrofitting under deadline.

i18n vs. L10n

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.

i18n is the structure. L10n is what you plug in for each locale.

Treat English like any other language

Pull all user-facing text into resources early so swapping strings later is trivial.
Keep copy edits out of your view controllers.
Export translator-ready files by default.

The usual flow, ship English first and retrofit later, buys you angry designers, duplicated code, and bugs that only show up in German. Flip it: internationalize first, localize English, add more locales when you're ready.

Five practices I still recommend

Practice	Why it helps
Ban raw strings. Use resource files or constants exclusively.	Hardcoded text doesn't translate
Use system libraries (ICU, `[ISO8601DateFormatter](https://en.wikipedia.org/wiki/ISO_8601)`, `[NumberFormatter](https://developer.apple.com/documentation/foundation/numberformatter)`).	Apple and ICU already solved most formatting edge cases
Assume text can shrink or grow. Never hard-code widths.	German labels are not English labels with more letters. Sometimes they're fewer. Often they're way more.
Document every string with context for translators.	"Book" as a verb and "Book" as a noun need different notes
Write code samples, not comments, for how to fetch localized copy.	Samples get copied. Comments get ignored.

Ten gotchas I've watched teams trip on

Calendars – Gregorian isn't universal. iOS users can pick Japanese or Buddhist calendars.
ISO 8601 – Use the standard when exchanging dates. Don't roll your own.
Truncation – Word-break rules differ by language. 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 don't have 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" so RTL scripts work.

Language is hard. Fixing it after you've shipped is harder. Bake i18n into sprint one and English is just another locale in your bundle, not a special case you'll regret.

Why bother on day one

Users pay for polish. A premium subscription should feel native in every language you ship.

Most iPhone owners aren't reading English. 72% prefer another language. China alone drives a huge chunk of global mobile-game revenue.

i18n is tech debt you choose. Like documentation, you pay now or pay a lot more when you're retrofitting under deadline.

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.

Treat English like any other language

Pull all user-facing text into resources early so swapping strings later is trivial.

Keep copy edits out of your view controllers.

Export translator-ready files by default.

Five practices I still recommend

Practice

Why it helps

Ban raw strings. Use resource files or constants exclusively.

Hardcoded text doesn't translate

Use system libraries (ICU, [ISO8601DateFormatter](https://en.wikipedia.org/wiki/ISO_8601), [NumberFormatter](https://developer.apple.com/documentation/foundation/numberformatter)).

Apple and ICU already solved most formatting edge cases

Assume text can shrink or grow. Never hard-code widths.

German labels are not English labels with more letters. Sometimes they're fewer. Often they're way more.

Document every string with context for translators.

"Book" as a verb and "Book" as a noun need different notes

Write code samples, not comments, for how to fetch localized copy.

Samples get copied. Comments get ignored.

Ten gotchas I've watched teams trip on

Calendars – Gregorian isn't universal. iOS users can pick Japanese or Buddhist calendars.

ISO 8601 – Use the standard when exchanging dates. Don't roll your own.

Truncation – Word-break rules differ by language. 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 don't have 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" so RTL scripts work.

Language is hard. Fixing it after you've shipped is harder. Bake i18n into sprint one and English is just another locale in your bundle, not a special case you'll regret.