i18n vs l10n: What's the Difference?

Just like In-N-Out Burger’s famous *secret* menu, every industry niche has a secret language that, once you master it, you now feel like you’re part of a special in-group. The translation and localization industry is no different. Always feeling a little bit of an inferiority complex compared to our math friends, our industry has decided to stuff numbers in the middle of our key words: i18n and l10n.

Sounds technical and intimidating, right?

Turns out it’s just shorthand for internationalization and localization.

Internationalization, or i18n (pronounced “eye-eighteen-en”) refers to the engineering work that gets software ready to run in any language. It does this by pulling text strings out of the code, handling character encoding, and building flexible formatting for dates, currency, and units. i18n is the technical, behind the scenes work that is done in preparation for localization (l10n), which is what is done per locale, per market.

Most of the explainer pages I see get a little muddy because they treat i18n and l10n as two flavors of the same task, then spend the rest of the article talking about code libraries. They’re not the same task. Internationalization is the thing your engineering team does, hopefully only once! Localization, on the other hand, is what happens to your website every time you add a market, and it’s the part that determines whether a multilingual visitor feels welcome when they visit or whether they feel like they’ve entered the uncanny valley, i.e. something’s off but they just can’t put their finger on it.

This distinction is more than just me being pedantic (it’s that for sure, but in this case it matters for teams that do localization!) A site can be perfectly internationalized and still read as “off” in the target language. Your team was careful to design buttons that expand to accommodate German text expansion, price tags with the right currency symbol, and dates stamped in a format familiar to the reader. That’s i18n! But what about the sentence next to the button? Does it sound like it was written by someone who understands the market or like it got run through a translation app and pushed straight to the page? That’s the job of localization and it’s the deciding factor in whether that visitor clicks through or decides to click away.

What i18n actually stands for

I’ve said it before, but worth spelling it out (pun intended): internationalization is a numeronym. Take the first letter (i), the last letter (n), count the 18 letters between them, and voilà, you get i18n. It’s shorthand that stuck because developers wanted a way to type the word without spelling it out fifty times in a code review. Hence, l10n for localization and a11y for accessibility, etc.

But the abbreviation is the boring part. What matters is what i18n actually does.

It’s the process of structuring a codebase so it can support any language or locale without a rewrite:

• Text strings pulled out of the code into external files, instead of hardcoded
• UTF-8 encoding, so accented characters and non-Latin scripts render correctly
• Layout that doesn’t assume text always reads left to right
• Date, number, and currency formats treated as variables, not fixed assumptions

Done well, i18n is like water to a goldfish, invisible and unnoticed (in the best way possible.)

l10n: the part that never finishes

If i18n is the car, then l10n is the fuel. When you decide to add French, you localize. When you add Japanese, you localize again. It’s not a phase you complete, but a repeating process, which is why localization needs its own workflow, owner, and toolset, kept separate from engineering.

A team can ship a genuinely internationalized product and still fall short on the localization front, because localization isn’t just swapping words. It can also include idiom and formality, as well as image swaps and even subtle color shifts, too!

Where the difference shows up on a live page

The format problems are the easiest way to see i18n and l10n operating separately.

Take numbers, for example. The US writes one thousand dollars and fifty cents as 1,000.50. Much of Europe writes the same value as 1.000,50, comma and period swapped. A currency field shows $99.00 in the US and 99,00 € in Germany, symbols on opposite sides. Dates split further still. 03/04/2026 means March 4th in the US and April 3rd almost everywhere else, which is the reason why ISO 8601 (YYYY-MM-DD) exists, to sidestep the ambiguity rather than argue about it country by country. Language codes follow a standard too: ISO 639-1 assigns two-letter codes like de, ja, and pt, so a locale system has a stable identifier to work from, instead of guessing from a country name.

Text expansion is the one engineering teams underestimate most. Phrase’s own i18n documentation uses a shoe size as a clean illustration: a UK size 10 is a European size 38, and a US size 38 is a completely different EU 6. Now, translate a UI label the same way and you get the same kind of word-length mismatch. German and Finnish routinely run 20 to 35 percent longer than the English source text, which is why a button labeled “Submit” fits fine and “Zur Kasse gehen” doesn’t, unless the layout was built with flexible containers. Arabic and Hebrew, as RTL (right-to-left) languages, add a different problem entirely: the whole layout mirrors, and not just the text direction.

None of this is adequately solved at translation time. It should be solved in the code, hence my push for doing i18n properly before l10n starts.

The workflow: build your house on a strong foundation

In a healthy setup, internationalization happens once and localization repeats indefinitely on top of it. You extract your strings, set your encoding, and build flexible layouts a single time. Then you localize into French. Later, you localize into Japanese. Later still, Arabic, without touching the underlying architecture again, because the architecture was built to handle any locale from the start.

What trips teams up is skipping the first step and trying to patch it in during the second. That’s when you get hardcoded strings buried three components deep and date pickers that only understand MM/DD/YYYY. Eventually the translation project turns into a refactor that nobody planned for.

Do we have to rebuild our stack?

I’ve sat in on enough sales calls to know what most teams are anxious about: “do we have to rebuild our stack in order to do this right?” The assumption here being that if their site wasn’t internationalized from the beginning, then localizing right means a complete teardown and overhaul.Most of the time, the answer is NO.

If the localization layer runs on top of the existing site instead of inside its codebase, then no rebuild is necessary. I’m tipping my hand a bit here, but this is precisely how Bablic works. Most of the time, a lightweight JavaScript snippet runs in the visitor’s browser and swaps the translated text in for the right locale at request time, without crawling or rebuilding the origin site (the original server where the page actually lives).

The performance worry that usually follows is that a browser-side approach means loading an entire translation corpus on every page view. If that’s a genuine concern for you, then choose a tool that offers pretranslation caching, which stores previously translated text so the browser isn’t hitting a translation API fresh on every request.

By now you’re saying, “but my product is a native app with deeply nested conditional logic and no separation between strings and code”...yadda yadda yadda. Well, now that’s an engineering problem that a browser-side layer won’t fix! In this case, look for a solution with an SDK. But for marketing sites and ecommerce storefronts, the pages built once in one language and now needing to serve five markets, the re-architecture assumption is generally wrong.

Don’t Translate Without Context

A page can pass every i18n check (the currency’s right, the date format is right) and still read as obviously foreign to the person it’s supposed to be speaking to. Customers can tell when a message misses the mark or just slightly wrong, and people who notice that don’t convert. That’s the uncanny valley I mentioned earlier, and that’s a true conversion killer.

Understanding and enforcing context helps solve this problem. First, with control over specific terms, like your brand name and your product’s proper nouns, you ensure critical phrases come out the same way every time, regardless of what a machine translation engine defaults to. A glossary that lets you lock those decisions in is what keeps a translated page sounding like your brand, instead of a generic version addressed to nobody in particular.

The second is the ability to actually look at the translated page and fix what’s wrong, in place, without needing to be fluent in the target language to spot an awkward phrase. An in-context editor shows you the live translated page and lets you edit directly, which means a Spanish-speaking colleague can spot-check the output in a few minutes instead of a translator redoing the whole thing from a spreadsheet.

For most pages, machine translation (MT) is a reasonable starting point. Bablic’s default engines are Google Translate and DeepL, which handle the first draft at a speed no human team can touch. For most businesses we talk to, these engines, combined with a glossary and spot check with an in-context editor is enough to feel like your site is truly localized.

FAQ

Why is internationalization called i18n? It’s a numeronym: the first letter (i), the last letter (n), and the 18 letters in between the two, counted and used as shorthand instead of spelling out the full 20-character word.

What does l10n stand for and how is it different from i18n? l10n stands for localization, an l, 10 letters, then n. Where i18n is the one-time engineering work that makes a product capable of running in any language, l10n is the repeated, market-specific act of actually adapting it, formatting, wording, and layout, for one locale at a time.

Should small teams use machine translation or hire human translators? Bablic’s default MT engines are Google Translate and DeepL, and provide a strong starting point for most site content because of speed and cost. The gap it doesn’t close on its own is brand context and tone, which is why a glossary and human review layer on top of MT output tends to outperform either machine-only or fully manual translation for teams that don’t have a dedicated localization staff. Translation cost per word varies enough by language and volume that it’s worth budgeting before committing to an all-human approach.