Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Localization

Pattern

A reusable solution you can apply to your work.

Also known as: l10n

Understand This First

Context

This is a tactical pattern that builds directly on Internationalization. Where internationalization prepares the architecture, localization does the actual work of adapting software for a specific language, region, or culture. This includes translating text, formatting dates and numbers according to local conventions, adjusting layouts for right-to-left scripts, and sometimes changing images, colors, or even features to suit cultural expectations.

The abbreviation “l10n” follows the same convention as “i18n”: the 10 letters between “l” and “n” in “localization.”

In agentic workflows, localization is an area where AI agents can help considerably: generating initial translations, identifying missing strings, and validating formatting. But human review remains essential for quality.

Problem

Your software is internationalized: strings are externalized, formats are configurable, and layouts are flexible. But the French version still doesn’t exist. Someone has to produce accurate, natural-sounding translations. Someone has to verify that dates, currencies, and numbers display correctly for each locale. Someone has to check that the interface still works when German words are 40% longer than their English equivalents. How do you actually deliver a localized experience that feels native to users in each target locale?

Forces

  • Machine translation is fast and cheap but produces awkward or incorrect results, especially for UI text that must be concise and unambiguous.
  • Professional translation is accurate but expensive and slow, creating a bottleneck for releases.
  • Each locale introduces a combinatorial expansion of testing: every screen, every message, every edge case, multiplied by every supported language.
  • Cultural adaptation goes beyond language. Colors, icons, humor, and formality levels vary across cultures.

Solution

Treat localization as a workflow, not a one-time task. Establish a process for extracting new strings, sending them for translation, reviewing the results, and integrating them back into the build. Automate what you can (string extraction, format validation, screenshot generation for translator context) and invest human attention where it matters most: translation quality and cultural fit.

Use professional translators for production content, especially for UI text where space is tight and meaning must be precise. Machine translation (including AI-generated translation) works well for internal tools, first drafts, and identifying gaps, but should be reviewed by native speakers before shipping to users.

Test each locale beyond just string translation. Check that layouts handle longer text gracefully (German, Finnish). Verify right-to-left rendering (Arabic, Hebrew). Confirm that date pickers, number inputs, and currency fields work with local formats. Watch for concatenated strings that break in languages with different word order.

When working with an AI agent, you can ask it to generate locale files, identify untranslated strings, or flag text that is too long for its UI context. But always have a native speaker review the output before release.

How It Plays Out

A startup expands to Japan. They run their English strings through a translation API and ship the result. Japanese users report that the translations are grammatically correct but socially awkward: the formality level is wrong for a consumer app, and some phrases are unnatural. The team hires a Japanese copywriter to revise the translations, producing text that feels native rather than translated.

A developer asks an agent to add Spanish support to an app. The agent generates a Spanish locale file by translating the English message file. Most translations are good, but the agent used informal “tu” forms throughout, while the app’s audience expects formal “usted” forms. A quick review and revision fixes the tone before launch.

Note

Localization is not just about language. A weather app might show temperatures in Celsius for European locales and Fahrenheit for the US. A calendar might start the week on Monday in Germany and Sunday in the US. A shopping app might need different payment methods for different countries. These are all localization decisions.

Example Prompt

“Generate a Spanish locale file by translating our English message file. Use formal usted forms throughout — our audience expects formal address. Flag any strings that need cultural adaptation beyond translation.”

Consequences

Well-localized software feels native to users in each market, which builds trust and adoption. It opens revenue opportunities in new regions and demonstrates respect for the user’s language and culture.

The ongoing cost is significant. Every new feature requires translation. Every release requires localization testing. Translation quality must be maintained over time. And the more locales you support, the more complex your build, test, and release processes become. Some teams address this by supporting a small number of locales well rather than many locales poorly.

  • Depends on: Internationalization — localization is only possible if the system is internationalized first.
  • Refines: UX — localization is about delivering a good user experience in every locale.
  • Uses: Configuration — locale selection is a configuration choice.
  • Uses: Deployment — localized content often needs to be deployed alongside or independently of code changes.