Internationalization vs localization (i18n vs l10n)

Internationalization, written i18n, is engineering work: building software or a website so it can be adapted to other languages and regions without changing its code. Localization, written l10n, is the adapting itself: translating the text and adjusting formats, content and conventions for one market. The W3C puts it in one line: "Designers and developers internationalize products, so that they can be easily localized by translators and localizers." Internationalization happens once, in the code. Localization happens again for every locale you add, and it goes faster and breaks less when the internationalization was done well.

Where the names i18n and l10n come from#

They are numeronyms. W3C explains that internationalization "is often written in English as i18n, where 18 is the number of letters between i and n", and localization as l10n for the same reason. The GNU gettext manual gives the history: people "tired of writing these long words over and over again" kept the first and last letters and replaced the run in between with a count. You will also see g11n for globalization, which W3C notes some people use for the same idea as internationalization.

What internationalization means in practice#

The gettext manual's definition is the clearest for developers: internationalization is the work by which a program "is made aware of and able to support multiple languages", and "the operation by which further localizations are made possible". W3C lists what that typically involves. In a web project it comes down to a short list.

Use Unicode everywhere#

W3C's advice is to "choose UTF-8 for all content". A database, a template or an API that assumes one legacy encoding will corrupt the first Polish, Turkish or Greek string that passes through it.

Keep text out of code#

Every string a person reads belongs in a resource that a translator can reach: a message catalogue, a translation file, the CMS. W3C calls this "separating localizable elements from source code or content". In WordPress, the plugin handbook's version is to wrap strings in functions such as __(), with a text domain that "must match the slug of the plugin":

// Returns the translated string for the current locale.
__( 'Blog Options', 'my-plugin' );

Never build sentences from pieces#

W3C names "taking care over the concatenation of strings" as part of the job. Word order changes between languages, so a sentence glued together in code cannot be translated correctly, however good the translator.

Let the locale format numbers, dates and plurals#

Formats are data, and the data already exists. The ECMAScript Internationalization API, which MDN describes as providing "language sensitive string comparison, number formatting, date and time formatting, and more", reads it from the locale. The Unicode CLDR project supplies this kind of data to "all modern operating systems and browsers", in its own description.

Leave room for direction and length#

Text in another language can be longer, and in some scripts it runs right to left. MDN recommends setting dir on the root element explicitly, "especially important for RTL scripts", and CSS logical properties let layout follow the writing direction, so "content translated into languages with different writing modes will be rendered as intended".

What localization means in practice#

Localization starts once those foundations exist. The W3C list of what it can involve runs well past translation: numeric, date and time formats, currency, keyboard layout, sorting, symbols, icons and colours, references that could be misread in a culture, legal requirements, address and phone formats, and more. On a website that becomes translated pages, local prices and payment methods, adapted images and examples, and terms that meet local law.

The gettext manual divides the labour simply: internationalization "is usually taken care of by programmers, and localization is usually taken care of by translators". On a modern website team, localization also involves marketers, who decide what a page should say in a market, and reviewers, who check it. Our guide to website localization walks through that process, and localization vs translation shows where translation ends and the rest begins.

A worked example: one cart message, internationalized, then localized#

Take a hypothetical shop that shows how many items are in the cart. The first version is written for English only:

const message = "You have " + count + " items in your cart";

It already fails in English for one item ("1 items"), and it cannot be translated well, because a translator only ever sees three fragments.

Internationalizing it means two changes: the whole sentence becomes one message a translator can see, and the plural form is chosen by the locale's rules instead of by an if written for English. CLDR's plural rules show why the second change matters. English has two cardinal categories, one and other. Polish has four: one, few, many and other, as in CLDR's examples "1 miesiąc", "2 miesiące", "5 miesięcy". Arabic has six. MDN's page on Intl.PluralRules lists the full set of tags as zero, one, two, few, many and other.

const rules = new Intl.PluralRules(locale);
const messages = {
  en: { one: "You have {n} item in your cart", other: "You have {n} items in your cart" },
  // A translator adds pl: { one, few, many, other }; the code stays as it is.
};
const text = messages[locale][rules.select(count)].replace("{n}", count);

Localizing it for Polish is now a translator's job with no code change: they supply four forms of the sentence for the four categories, and the code picks the right one. Adding Arabic later means six more strings and, again, no code change. That is localization without re-engineering, and it is why the W3C says internationalization should be "a fundamental step in the design and development process, rather than as an afterthought".

Internationalization vs localization at a glance#

Where a website translation tool fits#

For a website, the line between the two moves slightly. A content site's text lives mostly in posts and pages, not in code, so most of it is reachable for translation without any i18n work. The theme, the plugins and the page builder are where i18n gaps hide: a hard-coded "Read more", a date formatted in PHP, a sentence glued together in a template.

LangRelay translates the page your WordPress site renders, after the theme and plugins have produced their HTML. Text in templates, menus and page-builder widgets is translated with the post content, even when the theme author never wrapped it in __(), and each language is served under its own path such as /fr/ with the html lang attribute set from the language's tag. What a rendered-page translator cannot do is repair internationalization in your code: it translates the text the page shows, so a sentence your theme assembles from fragments, or a plural your code picks with an English-only rule, is still worth fixing at the source. Our QA checklist for website translation lists the source checks to run before translating.

If you would like to see what LangRelay picks up from your own theme, book a demo.

Questions people ask about i18n and l10n#

What is i18n in programming?#

It is internationalization: making code able to handle any language and region, through Unicode, strings kept out of the code, locale-aware formatting and plural rules, so that adding a language needs translations and no code change.

Is localization the same as translation?#

No. Translation is the language part of localization. Localization also adapts formats, currency, images, examples and legal text to the market.

What is the difference between i18n, l10n and g11n?#

i18n prepares the product, l10n adapts it per locale, and g11n, globalization, is a word some teams use for the overall effort or, as W3C notes, for the same concept as internationalization.