Learn the difference between Internationalization (i18n) and Localization (l10n), how they work together, and why implementing both early saves time as your application grows.
Think about some of the apps you use every day. Netflix, Spotify, GitHub, Amazon, Discord. They don't just translate text. They show dates differently, display currencies correctly, sort names differently, and even change layouts for languages that read from right to left.
Users don't notice these things when they're done correctly. But they immediately notice when they're wrong. Poor localization makes software feel foreign. Good localization makes software feel native.
It matters commercially too: many people prefer to buy in their native language, and some will not buy from a site they cannot read comfortably. If you are new to the topic, our beginner's guide to localization covers the business side in more depth.
i18n meaning: Internationalization is the process of designing your application so it can support multiple languages and regions without changing its source code later. It is not translating text. It is preparing your application for translation.
The word "Internationalization" has 20 letters. So developers shortened it: i + 18 letters + n = i18n. The same applies to Localization: l + 10 letters + n = l10n.
Text Externalization: Instead of hardcoding text, you use translation keys that point into per-language JSON translation files:
// Instead of:
<h1>Welcome</h1>
// Do this:
<h1>{t("welcome")}</h1>Dates: Use locale-aware formatting instead of hardcoded formats:
new Intl.DateTimeFormat("fr-FR").format(new Date())Currency: Format values according to locale:
new Intl.NumberFormat("de-DE", {
style: "currency",
currency: "EUR"
}).format(100);Plural Rules: Different languages have different plural forms. English has 2 (singular/plural), Russian has 4, Arabic has 6. Message syntaxes like ICU MessageFormat let each language define its own plural forms without code changes.
Text Direction: English reads left-to-right. Arabic reads right-to-left. Your layout must handle both, which is easiest with CSS logical properties.
Locale Identification: The app needs a consistent way to name languages and regions, such as en-US, fr-CA, or zh-Hans. These are BCP 47 locale codes, and getting them right early avoids subtle bugs later.
Localization happens after internationalization. It means adapting your already-prepared application for a specific language, region, or culture. Think of it as decorating the house after building it.
Localization includes:
The quickest way to see the difference between i18n and l10n is to compare them on the same dimensions:
| Aspect | Internationalization (i18n) | Localization (l10n) |
|---|---|---|
| Definition | Designing software so it can support any language or region | Adapting software for a specific language or region |
| Abbreviation | i18n (i + 18 letters + n) | l10n (l + 10 letters + n) |
| When it happens | During development, ideally from day one | After i18n, whenever you enter a new market |
| Goal | Remove language and region assumptions from the code | Make the product feel native to one audience |
| Who does it | Developers | Translators, reviewers, and developers |
| How often | Once per codebase, then maintained | Repeatedly, once per locale and per release |
| Typical work | Extracting strings, locale-aware formatting, plural support, RTL-ready layouts | Translating strings, adapting images, currencies, units, legal text |
| Output | Translation keys, locale files, Intl-based formatting |
Translated locale files such as fr.json and ja.json |
| Example | Replacing "Welcome" with t("welcome") |
Writing "welcome": "Bienvenue" in fr.json |
| If you skip it | Every new language requires code changes | Users see untranslated or awkward copy |
A simple way to remember it: i18n is engineering work you do once, l10n is content work you do for every market. Translation is only one part of localization, and localization is only possible once internationalization is in place. Because that content work repeats every release, most teams keep a translation memory so approved translations are reused instead of redone.
The most expensive mistake? Skipping internationalization entirely and treating it as something to "add later." Retrofitting i18n means touching every component that renders text, every date and price, and every layout that assumes left-to-right reading, which is why it costs far more than building it in from the start. Common pitfalls include (see more in common localization mistakes developers make):
dashboard.title instead of text1Once your application has been internationalized, managing translations across dozens of languages can quickly become a project of its own. If you are on Next.js, our step-by-step next-intl guide covers the i18n half. Tools like Babelize help automate translation workflows, organize language files, keep translations synchronized with your codebase, and reduce the repetitive work involved in maintaining multilingual applications. The Babelize CLI handles the l10n half by generating and syncing locale files from your repository.
Internationalization (i18n) is the process of designing and building an application so it can support multiple languages, regions, and cultural conventions without requiring code changes. It is the architectural foundation that makes localization possible.
i18n is a numeronym where 'i' is the first letter, 'n' is the last letter, and 18 represents the 18 letters between them. The same pattern gives l10n for localization, g11n for globalization, and a11y for accessibility.
Localization (l10n) is the process of adapting an internationalized application for a specific region or language by translating text, formatting dates and currencies, and adjusting cultural elements so it feels native to that audience.
Internationalization prepares your codebase for multiple languages (architecture and tooling). Localization adapts the content for a specific market (translations and formatting). i18n is done once by developers; l10n happens repeatedly for each target market.
Always start with internationalization. It is much more expensive to retrofit an existing app for i18n than to design it with i18n from the start. Localization can follow once the architecture is ready.
Internationalization is a design decision. Localization is a content decision. Build your application with flexibility from the beginning, and supporting new languages becomes an exciting product milestone instead of a months-long refactoring nightmare.
--- - [All articles](https://www.babelize.co/blogs)