What localisation is

About half of the websites on the internet are written in English. Only about a quarter of the people using the internet speak it.

The two sources measure different things, so treat the comparison as rough, but the gap is hard to miss. Chinese speakers make up about a fifth of internet users and write about 1% of websites.

That gap is what this book is about. If your software only speaks English, most of the people who could use it are either reading it in their second language or not reading it at all.

Localisation is more than translation

Ask a developer what localising an app involves and most will say "translating it". Translation is a big part of the job, but it's the part everyone sees coming. Most of the work is in places you wouldn't think to look.

Localising a product means adapting it to the language, culture and market of the people using it. That includes:

• Translating text, which brings its own problems, like languages that read right to left, words twice as long as the English ones, and plural rules English doesn't have
• Formatting dates, times, numbers and currencies the way people expect to read them
• Supporting other scripts, and fonts that can display them
• Sorting lists in the order people expect
• Accepting names, addresses and phone numbers that don't fit the same formats you're used to
• Swapping imagery, content and even products to suit a culture or market

Plenty of that list has nothing to do with language. Take an English app built for a UK audience. It's written in British English and shows prices in pounds. To localise it for the US, you'd switch the spellings to American English, show prices in dollars, deal with state-by-state expectation of sales tax, format dates differently and a dozen other things.

It starts off sounding like an afternoon's work, but it rarely is, and grows to be so much more. Same language, different locale.

Responsive design, but for content

When responsive web design took off, designers and developers had to change how they thought. A page no longer had one fixed size. The same content had to fit a phone, a tablet and a widescreen monitor.

Localisation asks for the same shift. Instead of the layout changing with the screen size, any of the content can change with the user's locale. A button label that fits on one line in English might need two in German. The date 06/07/2026 is in June for an American and in July for everyone in the UK.

Once you've made that shift, you stop asking "what does this say?" and start asking "what should this say?"

l10n, i18n and g11n

You'll see "l10n" and "i18n" all over the place. They're numeronyms, where the number counts the letters between the first and last letter of the word. You've probably met "a11y" for accessibility, or "k8s" for Kubernetes.

Three of them matter here.

i18n, internationalisation. The engineering work that lets software adapt to any language or region without rewriting it each time. The W3C puts it this way: "If you internationalise, you design or develop your content, application, specification, and so on, in a way that ensures it will work well for, or can be easily adapted for, users from any culture, region or language."

l10n, localisation. Adapting that software for one particular language, culture and market. Translating the text is part of it, but so is formatting dates, numbers and prices the way people there expect, offering the payment methods they use, and swapping images and examples for ones that make sense to them. Every locale you add is another round of this work.

g11n, globalisation. Both of the above, plus the business side of taking a product into new markets. That means choosing which markets to go after, setting prices for them, dealing with local laws and taxes, and supporting customers in their own language. It's the widest of the three terms, and the one developers hear least, but it decides which locales the engineering work is for.

Roughly, you internationalise once and localise many times. Pulling every string out of your templates is internationalisation. Getting those strings translated into Polish is localisation.

Why bother

Most people would rather use a product in their own language. About 1.5 billion people speak English, counting everyone who speaks it as a second language, according to Ethnologue's 2025 figures. That's under a fifth of the world. An English-only product starts off ignoring most of its potential market.

That gap is growing, too. The ITU estimates that 2.2 billion people were still offline in 2025, about a quarter of the world, and 96% of them live in low and middle-income countries. The next billion people to come online mostly won't be in the US, the UK or Australia.

Reach isn't the only reason. A localised product is nicer to use, and people notice when something was built with them in mind. They notice even more when it wasn't.

Even as a Brit using American software, I run into a handful of these. Phone number fields formatted the American way. Address forms asking for a ZIP code that don't always accept my postcode. The biggest one is prices. In the UK, we expect the listed price to include tax. In most of the US, tax gets added at the end of checkout. So American prices look cheaper than they are, right up until the last step.

Usually none of it stops me using the software, but each one is a small reminder that it wasn't built with me in mind. But every now and then, I do run into something egregious that does stop me using the software in unexpected ways.

Localisation is also an accessibility concern. Plenty of people use English software in their second or third language, and clear, plain wording helps them even before you've translated anything.

For businesses, the results are easy to measure. You can see how much traffic each locale gets and how many sales come in through each currency, so you know quickly whether a new market is worth it.

It's never finished

Localisation isn't a project you complete. Every new feature brings new text to translate and new cultural details to get right. Every language you add is a language your support team now has to answer in.

That's why it pays to build it in early. Overhauling a large existing app to handle localisation is a lot of work. Setting it up in a fresh app and keeping it up as you build features is easy. I'd put a localisation system in place at the start of any new product, even if the only thing it handles at first is en-GB vs en-US.

What's in this book

The rest of the book is split into seven parts, and each one digs into a group of those places you wouldn't think to look.

It starts with the foundations: what a locale is, how to work out which one applies best to a user, and why text, and even the keyboard it's typed on, is harder than it looks. Then come the words, from how languages differ and getting text out of your code, to working with translators and why Americans read British spellings as typos.

After that, the book covers everything an app shows that isn't a sentence, like numbers, units, money, calendars, dates, addresses, people's names and everything else forms ask for. Then it moves on to design, like text that changes length, video captions and right-to-left layouts. After that come the places your product lives outside the web page, like emails, PDFs, native apps and AI features that have to answer in the right language. The last part is about shipping. It covers URLs and SEO, the phones, networks and services people actually have, testing, keeping it working, and the business side, including laws about language. Adjoined to the book are helpful resources you can refer to, like checklists you can use for your own products, and a step-by-step playbook in case you're not sure where to start.

Who this book is for

You're a developer of some kind. Maybe your company has decided to localise its product and you're the one doing it. Maybe you work for yourself and want to know what it takes to make an app work around the world. Either way, you've built software before and know your way around it.

You don't need to know anything about localisation already, and you don't need to use any particular language or framework. The book teaches the concepts and the standards underneath them, so the ideas carry over to whatever stack you use. The code examples are there to show the idea, not to sell you a library.

If you're not a developer, look for the "For the business" boxes. They cover the costs, decisions and legal side of each topic without the code.

How to read this book

You don't have to read it front to back, though it's written so you can. If you're building something new, reading it in order. If someone has just told you "we're launching in Germany next quarter", skip ahead to the playbook, which turns the whole book into a step-by-step plan for an existing app, and points you to the right place for each step. If you're deciding whether localisation is worth it for your business at all, start with running localisation as a business.

Otherwise, jump to whichever topic you're dealing with right now, and keep the field guide and glossary at the back to hand.

Each chapter follows the same pattern:

• The problem. A real bug, screenshot or story.
• How it works. The concepts and standards behind the topic.
• Doing it in code. Language-agnostic examples.
• Designing for it. What changes in the interface.
• Around the world. Sidebars on how particular countries do things differently, plus case studies and gotchas worth watching out for.
• For the business. The non-code side.
• Checklist. What to check before you ship.

Localisation changes fast, so this book does too. It's a reference that keeps being updated as standards, tools and my own experience move on.

Translation is where localisation starts. The rest of this book is everything that comes after it.