The groundwork nobody talks about: understanding internationalization

If you’ve ever poked around localization, you’ve seen the strange little word i18n and quietly wondered whether it was a typo, a robot, or a Star Wars droid.

It’s none of those. Internationalization is one of the most important (and most skipped) steps in bringing a product to the world. And getting it wrong is the reason so many “multilingual” products feel held together with tape.

Let’s clear it up.

First, the weird abbreviation

i18n = “i” + 18 letters + “n.” Internationalization is a genuinely exhausting word to type, so someone counted the letters between the first and last and called it a day. Localization gets the same treatment: l10n (“l” + 10 letters + “n”). Accessibility is a11y. The whole field runs on these little number-sandwiches, and now you’re in on the joke.

So what is it, actually?

Internationalization is designing and building your product so it can be adapted to different languages and regions, without re-engineering it every time.

That’s the whole idea: i18n is the groundwork. It doesn’t translate anything. It makes translation possible. Think of it as the plumbing you install before anyone moves in: invisible when done right, catastrophic when skipped.

The relationship, in plain terms:

Internationalization (i18n) — prepare the product so it can handle any language. (Engineers, mostly.)

Localization (l10n) — adapt it for one specific market: language, formats, culture. (Linguists and localizers.)

Translation — convert the actual words. (A part of localization, not the whole thing.)

Do the first badly, and the other two become impossible no matter how good your translators are.

The house analogy. Internationalization is wiring your house for any appliance in the world: the right sockets, the right voltage, the flexible layout. Localization is furnishing it for the specific family moving in. If you hard-wired everything for one exact fridge in one exact spot, good luck when the new tenants arrive from another country. That’s a non-internationalized product.

What internationalization actually involves

Here’s the part teams underestimate. i18n isn’t one task: it’s a checklist of assumptions your English-only codebase quietly made, each of which needs to be un-made.

Externalizing your strings. If your text lives hard-coded inside your components, it can’t be translated. Every user-facing string has to be pulled out into resource files, separate from the code. This is i18n step one, and everything else depends on it.
Unicode, everywhere. Your product has to store and display characters from any language. Accents, “ñ,” “ß,” Chinese characters, emoji, Arabic script. UTF-8 encoding handles this. Skip it, and you get the dreaded ”�” boxes where someone’s name should be. Nobody feels welcome when your app renders their name as gibberish.
Handling plurals and gender properly. English has two plural forms. French treats zero as singular. Polish has four plural categories; Arabic has six. Hard-coding “add an s” is wrong in most of the world. Internationalization means using something like ICU MessageFormat, which lets each language define its own rules instead of inheriting English’s.
Locale-aware formatting. Dates (03/04/2026 means two different days depending on where you are), numbers (1,000 vs 1 000 vs 1.000), currencies, times, time zones. A well-internationalized product never hard-codes these, it formats them by locale.
Designing for text expansion. Translations change length. German and Finnish expand enthusiastically; French runs 15–25% longer than English. If your layout was pixel-perfect for English, i18n means building flexible components that don’t shatter when the text grows.
Supporting right-to-left. Arabic and Hebrew read right to left and flip your entire interface. Making your layout RTL-aware is far cheaper as a design principle than as a panicked retrofit.
Sorting and collation. Alphabetical order isn’t universal. In Swedish, “å,” “ä,” and “ö” come after “z.” In traditional Spanish, “ñ” sits after “n.” Your “sort A–Z” button has to know that.
The tell of a non-internationalized product. Type a name with an accent and watch it break. Set your device to another language and watch half the app stay stubbornly English. Add an item and read “1 items.” None of these are translation bugs. They’re i18n bugs, baked in long before any translator showed up. Which is exactly why translators can’t fix them.

Why do it early?

Because internationalization is dramatically cheaper as a foundation than as a renovation.

Build it in from the start, and adding a new language is mostly a matter of supplying translations. Bolt it on afterward, hunting hard-coded strings through a mature codebase, retrofitting date logic, rebuilding layouts that assumed English, and you’ve signed up for one of the least glamorous, most expensive projects an engineering team can face. Ask anyone who’s done it. Then give them a moment.

You don’t have to translate into a single language on day one. But if global is even a maybe on your roadmap, internationalizing early is one of those quiet decisions that your future self will thank you for.

The short version

Internationalization is the engineering that makes your product ready for the world: strings pulled out of the code, Unicode throughout, plurals and formats handled by locale, layouts that flex, scripts that flow both directions.

It’s not translation. It’s not localization. It’s the foundation both of those stand on, and the reason a product can either welcome a user in their own language, or quietly show them they were an afterthought.

Get the foundation right, and everything built on top of it has a chance to feel native. Skip it, and no amount of good translation will save you.

I work as a French Language Lead, and part of that job is spotting the internationalization gaps before they turn into broken French: the hard-coded string, the English plural logic, the button with no room to breathe. If you’re preparing a product for the French market, let’s talk.