Globalization and localization, explained

The three terms

Globalization, internationalization and localization describe related work, but they don't all mean the same thing. The distinction to keep in mind is how much each term covers.

Globalization is the broad work of preparing and launching products and activities internationally. Internationalization is designing and developing a product so you can adapt it for different audiences. Localization is making that adaptation for a particular market.

You'll see them shortened to g11n, i18n and l10n. The shorthand looks more technical than the idea behind it. It's just a way to write long words.

Where the numbers come from

Each number counts the letters between the word's first and last letters:

• Globalization becomes g11n: g, then 11 letters, then n.
• Internationalization becomes i18n, with 18 letters between i and n.
• Localization becomes l10n, with 10 letters between l and n.

That's the whole trick.

You might also see G11n with a capital G. It still stands for globalization, not a separate process or a different kind of work.

Globalization

GALA (the Globalization and Localization Association) defines globalization broadly: it covers the processes needed to prepare and launch products and activities internationally, including multilingual communication and making products and services ready for global use.

Under that definition, you're talking about more than adapting the product itself. You're also talking about the wider work around offering it internationally. Internationalization and localization sit within that broader effort.

But terminology isn't perfectly consistent. W3C notes that some people use "globalization" to mean the same thing as "internationalization." When you see g11n in a project description, check what the writer means: the broad international effort, or the product design and development work?

Internationalization

W3C defines internationalization as designing and developing a product so it can be localized easily for audiences that differ in culture, region or language.

This is the preparation work. You're making room for those differences in the product rather than adapting it to a particular locale yet.

W3C's examples include enabling Unicode and keeping user interface strings out of code. It also includes supporting local formats for dates, numbers and names, and separating localizable content so translations can be loaded for each user.

That last part connects the design work to what someone sees: the product needs a way to load the translations for that user, while the localizable content stays separate from the code.

So when you're discussing i18n, the question is: can this product be localized easily? You're looking at how it's built, not just whether translated text is available.

Localization

Localization is the adaptation itself. W3C defines it as adapting a product to the language, cultural and other requirements of a target market, also called a locale.

Translation belongs here, but the work isn't limited to words. W3C includes number formats, date and time formats, and currency. Keyboard usage and sorting are part of it too.

Then there are symbols, icons and colors, along with legal requirements. Those all fall within localization's scope; a discussion of l10n can cover more than the text you send for translation.

Think of the distinction this way: with internationalization, you support local formats in the product. With localization, you adapt those formats for the target locale. Related work, different focus.

How they fit together in a real project

If you're preparing a product for international use, GALA's broad definition puts that effort under globalization. Within it, you can separate the work of making the product localizable from the work of adapting it for a target market.

On the development side, that means looking at Unicode, keeping interface strings outside the code, supporting local formats. On the localization side, you're working on translated content and the target locale's other requirements. The boundary isn't about which abbreviation sounds more technical. It's about what you're working on.

For locale files, Translinga is a translation API made by Bitgate for Shopify stores, WordPress sites and apps. Its CLI and GitHub Action sync locale files on every push and translate only new and changed strings:

npx translinga sync --to nl,de,fr

It reads i18next, next-intl, vue-i18n and any JSON. You can add a $context note to a JSON file to describe what the strings are for (key names count as context too).

That handles translation work on the locale files. Your localization work still includes the target market's other requirements.