Localization

Concept

Adapting the wording and formats inside a product so that users in one language and market read it as something made for them.

Why it exists

For a long time, shipping a product to another country was treated as one round of translation. Pull the sentences off the screens, hand them to a translator, put the results back. Products released that way kept running into the same set of problems.

Buttons broke. German text in a slot sized for "Save" ran close to twice as long, so the label clipped or wrapped onto a second line. Dates disagreed: an American user reads 03/04/2026 as March 4 and a European user reads it as April 3, which pushed bookings a month off. And a translator handed the single word "Order" with nothing around it has no way to know whether it means a purchase or a sort sequence, so it came back as the wrong one.

The problems lived outside the act of translating sentences. If the text is hard-coded, or the button has a fixed width, the screen breaks no matter how accurate the translation is. So the work got split in two: building a structure that can hold several languages, and filling that structure in for a particular language and market. The second half is localization. The abbreviation l10n comes from counting the ten letters between the first and last character of the word.

How it works

It starts with text managed as a list that lives outside the screens. The code holds a name like button.save instead of the sentence, and a file per language holds the sentence that name maps to, so adding a language becomes adding a file. Putting that structure in place is internationalization; localization takes the resulting list and fills it in per market.

What gets filled in is more than sentences.

  1. Formats. Dates, times, digit separators, currency, and the order of address fields all vary. Korean addresses run from the largest unit down and American ones from the smallest up, so the field order itself has to change to read naturally.
  2. Example content. Names of people and companies in help articles, phone number formats, and the text inside screenshots all become local.
  3. Register. Korean and Japanese force a choice about how formal to be, a choice English doesn't offer. Reinterpreting the attitude set in voice and tone for each language belongs here.
  4. Rules tied to sentence structure. Counting works differently across languages, so splitting "1 document" and "3 documents" into just singular and plural the way English does breaks elsewhere. Assembling a sentence from concatenated fragments breaks too, once word order changes.
  5. Screen direction. Arabic and Hebrew read right to left, so the whole layout mirrors, not only the text.

Giving translators context is what separates good output from bad. A bare list of strings leaves "Order" ambiguous, and leaves it unclear whether the string is a button label or a heading. So each string carries a note and a screenshot of where it sits, and a terminology consistency list is kept per language. Decide once what a workspace is called in Japanese and that word is the only one used from then on.

Where it shows up

The term comes up once a market has been chosen and the team is deciding how far to go. Product screens, help documentation, marketing pages, emails and notifications, and legal terms are all candidates with different costs and payoffs. Product screens go first because the product is unusable without them, help documentation slips because of its volume, and legal terms move separately since they need review by a lawyer.

Splitting the work into quality tiers is common. Screens where an error costs money, like signup and checkout, get a human translator plus a check by a local user, while deep settings screens get machine translation with a light review. Doing everything by hand multiplies the cost by the number of languages.

Maintenance is the real load. It isn't a one-time project; it follows every change to the product. Fix one string and six languages are attached to it, and shipping before the translations arrive leaves that one screen in English. So the release process is wired to open translation requests automatically.

Web pages pick up one more piece of work on the search side. A Korean page and a Japanese page with the same content can look like duplicates to a search engine, so the hreflang attribute tells it they are language variants of one page.

How it sounds at work

"Translation is done but localization isn't. The date formats and the screenshots are still ours."

A status report saying the sentences moved and the formats and images didn't.

"Lock the copy for this sprint by Friday — it has to go out for translation."

A request pointing out that late copy pushes the release back by the same amount.

"Let's use a human translator for Japanese and machine translation with review for the other three."

A proposal to set the quality tier by the size of each market.

Pagedeck shipped Japanese first. Theo spent three weeks pulling strings out of the code and into language files, and Noa built the list of notes explaining where each string appears. In an earlier draft translation produced without that list, the word for sharing showed up as two different Japanese terms — one on copying a link and another on granting access.

What came back most often in the first review round wasn't wording but length. Japanese ran short and caused no trouble, while German, prepared alongside it from the same files, pushed a settings tab label onto a second line. Noa made the tabs grow with their text, which turned the issue into a design one. Mia added a step after that: new mockups get checked with the longest language's copy dropped in.

What people get wrong

The most common mistake is treating localization as another word for translation. The visible output is changed sentences, so the reading is easy to arrive at. Plenty remains after the translation is finished, though. Currency symbols, address field order, example names, screenshots, and payment methods all have to match the market. Translate and stop, and you get screens that read fluently but still feel like a foreign product, and users withdraw trust over exactly that friction.

Assuming more supported languages is always better is the other one. A long list looks like a big product. In practice each added language attaches a translation and a review to every change you make, and a language nobody maintains sits there with half its screens in English. A half-localized screen leaves a worse impression than an English-only one. So the decision to add a language comes after confirming that the market actually produces revenue.

Easily confused with

TermWhat it doesHow it differs
InternationalizationBuilds a structure that can hold multiple languagesPreparation independent of any language, done once. Localization repeats per language and can't start until internationalization exists

Where to go next

  • UX writing

    see how the copy being localized gets written in the first place

  • Internationalization

    the step before this one, expensive to do in the wrong order

  • hreflang

    the search-side work attached to publishing pages in several languages

Last updated 2026-09-16