When we decided to launch France and Germany, I thought I knew what internationalization meant.
Translate the UI.
Ship new locale files.
Call it a day.
I was wrong.
Translation turned out to be the easiest part of the entire project.
Internationalization isn't about language.
It's about removing every assumption your product accidentally made about the country it was built in.
The first assumption: text has a predictable length
English is unusually compact.
German isn't.
Buttons that comfortably fit 'Continue' suddenly had to fit 'Weiter zur Zahlungsmethode'. Navigation items wrapped onto two lines. Cards that looked perfectly balanced became uneven.
Nothing was technically broken.
Everything looked slightly off.
That's often worse.
The fix wasn't shortening translations.
It was designing components that never depended on English being short in the first place.
Dates and numbers aren't universal
Users don't consciously notice date formatting.
They immediately notice when it's wrong.
07/04/2026 means one thing in the US and something completely different in Europe.
The same goes for decimal separators, thousand separators, currencies, percentages, phone numbers, and measurements.
Formatting isn't presentation.
It's meaning.
Search speaks a different language too
Our search wasn't just searching translated products.
It had to understand how people in different countries actually searched.
Pluralization.
Accents.
Localized category names.
Synonyms.
A search engine that's perfect in English can feel surprisingly unintelligent in another language if you simply translate the content and hope for the best.
SEO becomes a product feature
Launching a new language isn't just creating another route.
It's teaching search engines that each version exists for a different audience.
Localized metadata.
Canonical URLs.
hreflang.
Translated slugs.
Sitemaps.
Miss any one of them and you've technically launched a country that Google barely understands.
Analytics suddenly gets complicated
Questions that used to have obvious answers become surprisingly ambiguous.
Which country generated this conversion?
Which language was the user browsing in?
Did they switch locales halfway through checkout?
Did the translated version actually improve conversion, or did traffic quality change?
Internationalization isn't just a frontend concern.
It's an analytics problem too.
Product assumptions are everywhere
This was probably the biggest surprise.
Every product contains invisible assumptions about the people using it.
Addresses.
Phone numbers.
Taxes.
Payment methods.
Shipping expectations.
Legal requirements.
Holiday calendars.
None of these live inside your translation files.
But every one of them shapes the user experience.
The checklist I wish we'd started with
- Translation
- Text expansion
- Number and currency formatting
- Dates and time zones
- Locale-aware sorting
- Search behavior
- SEO (
hreflang, metadata, canonical URLs) - Analytics segmentation
- Addresses and validation
- Payment methods
- Emails and notifications
- Legal pages
- Accessibility
- Testing every locale on mobile
If I were starting another international expansion tomorrow, translation wouldn't even be the first item I'd worry about.
I'd start by asking a different question:
'What assumptions did we accidentally make because we built this product for one country first?'
Every one of those assumptions eventually becomes a bug.
Internationalization isn't translating your app.
It's systematically removing those assumptions until your product feels like it was built locally in every market you serve.