Translation vs localization

The short answer

Translation changes the language of your words. Localization adapts your product or content for a particular market, including the language.

W3C defines localization as adapting a product, application or document's content to meet the language, cultural and other requirements of a specific target market, called a locale.

Translation is part of that. It isn't the whole job.

If you're planning a launch, "translate the text" and "localize the product" are different requests. The latter also asks you to look at things like currency, date formats, keyboard usage and legal requirements, not just what the words say.

What localization adds

W3C lists numeric, date and time formats among the things localization can change. Currency is on that list too. These are separate things to check alongside your translated text.

Then there's keyboard usage, plus collation and sorting: how items are ordered. Symbols, icons and colors also fall within localization, as do text and graphics that could be misread or seen as insensitive.

Legal requirements count too.

You don't have to treat that list as an instruction to change everything. Use it to decide what needs attention for your target locale, rather than assuming that replacing the words finishes the job.

You might also see localization written as l10n. That's shorthand for the 10 letters between the l and the n (not a different service).

Real examples

Translinga tested the DeepL API from English to Dutch on October 27, 2026. The results show a few different ways a translation can miss what a product needs.

In a Shopify string, DeepL changed the filter in {{ remaining_amount | money }} to | geld. Geld is Dutch for money, but Shopify doesn't know that filter. It skips filters it doesn't recognize and prints the raw amount in cents.

The filter wasn't text for the customer. It needed to stay unchanged.

In a combat menu, "Save" came back as "Opslaan," meaning saving a file, rather than a saving throw. That happened even with context.

On a billing page, "Charge" became "Opladen," the word for charging a battery.

These aren't all the same problem. The Shopify example calls for protecting code inside the string. The combat and billing examples call for choosing the meaning that belongs in that screen. Before you approve a translation, ask: does this mean the right thing here?

Where internationalization fits

Internationalization, or i18n, is designing a product so it can be localized easily. Using Unicode and keeping translatable text outside your code are examples.

It's preparation, not translation.

Plural handling belongs in that preparation too. Unicode CLDR uses six plural categories: zero, one, two, few, many, other. Apple's Xcode documentation shows English needing one and other, while Russian needs one, few, many and other.

So don't design your strings around the assumption that every language will use the English plural setup, then leave the translator to work around it.

Who does what

If you're assigning the work, give translation the job of expressing the intended meaning in another language. Include the screen or use behind the text, not just a file full of isolated words.

Give localization the wider check against the target locale: formats, currency, symbols and the other requirements above.

For developers, the internationalization work includes keeping text separate from code and supporting the plural rules your product needs. For marketers and founders, the useful question is what you're asking someone to deliver. A translated file? A product checked for a specific locale? Say which.

Doing both without breaking your code

Keep Liquid tags, HTML and placeholders out of the text being translated, and check that they're still intact when the translation comes back.

Translinga, a translation API made by Bitgate for Shopify stores, WordPress sites and apps, takes those elements out before translation, checks every reply tag by tag, and retries any string returned with a missing tag.

You can add a $context note to a JSON file to explain what the strings are for, and key names count as context too. Its glossary can specify that "cart" always becomes "winkelmandje" in Dutch; it also has a do-not-translate list.

But context isn't a guarantee, as the combat-menu result shows. Review the meaning in the screen where the text will appear, alongside the checks that protect your code.