A product manager decides to "add French." A fortnight later the engineers come back with a list: the prices are hardcoded with a dollar sign, dates assume month-then-day, half the buttons break when the labels get longer, and there's no way to store a translated string anywhere. The translation was the easy part. The product was never built to hold it.

The quick version

  • Internationalisation (i18n) is engineering a product so it can be adapted to other languages and regions. Localisation (l10n) is doing the adapting for one specific market. You build the first; you repeat the second.
  • Localisation is far more than translation: numbers, dates, currency, sorting order, address formats, icons, colours and legal requirements all change by locale.
  • Retro-fitting i18n into a live product is slow and expensive. The cheapest moment to design for the world is before you've shipped to one country.
  • You don't have to localise everywhere. Pick the few markets where the return justifies the ongoing cost, every locale you add is a permanent maintenance bill, not a one-off.

The idea in depth

The single most useful distinction in this whole topic is the one most teams skip. The World Wide Web Consortium (W3C) draws it cleanly. Internationalisation is "the design and development of a product, application or document content that enables easy localization." Localisation is "the adaptation of a product... to meet the language, cultural and other requirements of a specific target market (a locale)." Read those two verbs again, enables versus adaptation, because the whole discipline hangs off them. Internationalisation is the plumbing that makes adaptation possible; localisation is what flows through it. The shorthand you'll see everywhere, i18n and l10n, is just the first and last letters with the count of letters between them.

Why does the order matter so much? Because the most essential property of a localisable product, as Microsoft's globalisation guidance puts it, is that the executable code is cleanly separated from the localisable resources, the strings, formats and assets that change per market. If a price, a date or a sentence is baked into the code, every new market means hunting through the codebase again. The discipline, then, is to internationalise once, properly: pull every user-facing string into resource files, never concatenate sentences from fragments, and route every number, date, currency and sort through a locale-aware library rather than hand-rolled formatting. Do that, and adding a market becomes a content job. Skip it, and adding a market becomes an engineering project, every single time.

Internationalise once. Localise many times. Get those in the wrong order and you pay the i18n bill again with every new flag you add.

It also helps to see how much localisation covers, because "we'll translate it" undersells the job. The W3C lists the things that vary by locale: numeric, date and time formats; currency; keyboard layouts; collation and sorting (alphabetical order isn't universal); symbols, icons and colours; culturally sensitive text and graphics; and region-specific legal requirements. A green tick, a list "sorted A–Z," a thumbs-up emoji, each can read differently, or wrongly, somewhere else. Treat translation as one stream of localisation work, then, not the whole of it, and give formatting, sorting and imagery their own line on the plan.

flowchart LR
  CODE(["One product, internationalised"]) --> RES(["Locale-aware resources
strings · formats · assets"])
  RES --> L1(["en-US: $, MM/DD, A–Z sort"])
  RES --> L2(["de-DE: €, DD.MM, ß in sort"])
  RES --> L3(["ja-JP: ¥, era dates, kana sort"])
  RES --> L4(["ar-EG: ٠١٢, RTL layout"])
Internationalisation builds the trunk once; each localised market is a branch of resources, not a fork of the code. Leaders Loop

Test the plumbing before you spend on translation

Here's the trap. You can internationalise diligently, ship to one English market, and have no idea whether the plumbing actually holds, because English text never stretched it. Then the first real translation arrives, German doubles the length of your labels, and the UI shatters in production. The fix for this is older and cheaper than most teams realise: pseudo-localisation.

Pseudo-localisation, described in Microsoft's globalisation methodology, is an automated transformation that fakes translation without a translator. It swaps letters for accented look-alikes (so account might render as àccõûñt), pads each string out, and wraps it in markers like ^...^. Because it stays just readable, the product is still usable, but every internationalisation defect lights up. Strings still in English haven't been externalised. A missing end-marker means a string was truncated or two were glued together. Layout that breaks reveals where text expansion will hurt. Microsoft's own heuristic: when the source is English, lengthen text by about 40% to simulate translation, and in extreme cases a short string can grow 200% or even 400% longer. The crucial detail is timing, pseudo-localisation "can be applied in the earliest phases of development before translation begins" and is sustained throughout. Wire a pseudo-locale into your build, then, and turn it on long before you commission a single word of real translation. You find the expensive structural bugs while they're cheap, with no translator on the clock.

flowchart TD
  I18N(["Internationalised build"]) --> PL{"Run pseudo-locale
(accents + 40% padding + ^markers^)"}
  PL -->|"English left in UI"| B1(["String not externalised, fix"])
  PL -->|"Missing ^ marker"| B2(["Truncation or concatenation, fix"])
  PL -->|"Layout breaks"| B3(["Won't survive text expansion, fix"])
  PL -->|"All clean"| OK(["Now commission real translation"])
Pseudo-localisation surfaces structural i18n defects before any real translation is paid for. Leaders Loop

Localise where it pays, not everywhere

The business case for localising at all rests on a genuinely strong, often-cited piece of research. In its 2020 "Can't Read, Won't Buy" survey, the market-research firm CSA Research polled 8,709 consumers across 29 countries (with survey partner Kantar filtering a much larger pool for honesty) and found that 76% prefer to buy products with information in their own language, and 40% said they would never buy from a website in another language. That's the upside of localising, and the size of the market you forfeit by not.

But the same number is a warning against doing it everywhere. Every locale you support is a standing cost: translations to keep current as the product changes, formats and edge cases to test, support to staff, legal terms to maintain. Better to treat localisation like any portfolio decision, rank candidate markets by the revenue or strategic value at stake against the full lifetime cost to serve them, and start with the two or three that clear the bar. A pragmatic sequencing many teams use: internationalise comprehensively (cheap insurance, do it once), then localise selectively and deepen only where the numbers earn it. This is opinion drawn from practice, not a law, but "localise the whole world on day one" is how good products spread themselves into mediocrity in twenty markets instead of winning three.

An honest limitation. Most of the practical canon here, Microsoft's and the W3C's guidance, the localisation-industry playbooks, is engineering and practitioner wisdom rather than controlled academic study, so treat the tactics as well-tested craft, not proven theorems. The consumer-preference figures are real and methodologically transparent, but they're stated-preference survey data from one (reputable) firm with a commercial interest in the answer; read 76% and 40% as a strong directional signal, not gospel for your exact market. And localisation has a deeper failure mode the frameworks underplay: translating words while ignoring context. A perfectly translated screen can still feel foreign if the imagery, examples and assumptions weren't localised too. The plumbing is necessary; it is not sufficient.

A worked example

Picture a UK SaaS company, a small-business invoicing tool, that wants to expand into Germany and Japan. (Illustrative scenario and figures throughout; this is a teaching example, not a real product.) The instinct is to send the interface to a translation agency and wait. The disciplined version runs in a different order.

First, internationalisation. The team audits the product and finds the usual debt: the "£" is hardcoded in front of every total, dates render as DD/MM/YYYY in raw code, and a dozen sentences are stitched together from fragments like "You have " + count + " unpaid invoices", a construction that's impossible to translate cleanly because word order changes between languages. They externalise every string, route money and dates through a locale-aware formatter, and rebuild the fragmented sentences as whole, parameterised strings.

Then, before paying for a word of German or Japanese, they switch on a pseudo-locale. The home screen lights up the problems: three labels still show plain English (strings the audit missed), the invoice table truncates once text is padded by 40%, and a "Send" button overflows its box. None of that needed a translator to find. The team fixes the structure while it's cheap.

flowchart TD
  S(["UK invoicing tool → DE + JP"]) --> A(["1. Internationalise
externalise strings, locale-format money/dates"])
  A --> B(["2. Pseudo-localise
catch truncation + missed strings early"])
  B --> C{"3. Which markets clear the bar?"}
  C -->|"Strong demand, manageable cost"| DE(["Germany: localise now"])
  C -->|"High value, higher effort (RTL? no, JP script + formats)"| JP(["Japan: localise next, staged"])
  DE --> D(["4. Localise: translation + formats + currency + support"])
  JP --> D
  D --> E(["5. Maintain each locale as the product changes"])
Order of operations: build once, test cheaply, choose markets deliberately, then localise and keep maintaining. Leaders Loop

Only now does localisation proper begin, and only for the markets that earn it. Germany clears the bar first: large market, close formats, manageable effort, euros, DD.MM.YYYY dates, the comma-as-decimal convention, and German invoicing-law fields handled. Japan is high value but heavier, different script, era-based dates, distinct number and address formats, local support to staff, so it's staged as a deliberate second step, not a same-sprint afterthought. The payoff isn't just two new languages; it's that the next market after these is mostly a content exercise, because the plumbing was built right the first time.

Frequently asked questions

What's the difference between internationalisation and localisation?

Internationalisation (i18n) is engineering the product so it can adapt to any locale, externalised strings, locale-aware formatting, room for text to grow. Localisation (l10n) is the actual adaptation for one specific market: translating, switching currency and date formats, adjusting imagery and meeting local legal requirements. The W3C frames it as i18n enables l10n. You internationalise once and localise many times.

Isn't localisation just translation?

Translation is one part of it. Localisation also covers number, date, time and currency formats, sorting and collation order, address and phone formats, icons, colours, culturally appropriate imagery and examples, and region-specific legal text. A screen can be flawlessly translated and still feel foreign, or break, if those weren't handled.

What is pseudo-localisation, and why bother?

It's a fake "translation", accented characters, padded length, wrapping markers, generated automatically so you can test that your product is localisable without paying a translator. It surfaces the expensive structural bugs early: strings left hardcoded, layouts that break when text expands by ~40%, and sentences truncated or concatenated. Turn it on before you commission real translation.

Should we localise into as many languages as possible?

Usually no. Each locale is a permanent maintenance cost, not a one-off. Internationalise broadly because it's cheap insurance, but localise selectively, rank markets by the value at stake against the full cost to serve them, and start with the few that clearly pay. Depth in three markets beats thin coverage of twenty.

When in the project should we think about this?

At the start. Retro-fitting internationalisation into a live codebase means re-touching nearly every screen, whereas designing for it up front costs little. You don't have to translate anything early, but you should externalise strings and use locale-aware formatting from the beginning, so going global later is a decision, not a rebuild.

Related in the Toolkit

Deciding which markets to localise for is a product-strategy call, and a new locale is a bet you'd be wise to de-risk before committing a translation budget to it.

Where to go next