l10n (localization)
Adapting an already-prepped product for one specific place: its language, formats, currency, tone, and imagery. The work after i18n.
See it
What it is
l10n ('l', 10 letters, 'n') is what you do once i18n made it possible: adapt the product to one actual market. Translated copy is the visible part. The rest is date and number formats, currency and price display, sort order, address and name fields, legal text, support hours, and images that read differently outside your home country.
It runs as a pipeline, not a task. Source strings go to a TMS, translators work with context and a termbase, translations come back into the catalogs, then a localization QA pass checks the rendered UI. Marketing copy usually needs transcreation instead of translation: a literal German rendering of your clever headline is a dead headline.
Gotcha: localizing to 'Spanish' is not a thing. es-ES, es-MX, and es-AR differ in vocabulary, formality, and currency, and picking the wrong one reads as careless rather than neutral. Pick target locales deliberately, and budget for the fact that every product copy change afterwards costs N translations.
Ask AI for it
Localize this app for de-DE. Translate every string in the message catalog into German using the formal 'Sie' register, preserving only the termbase entries explicitly marked do-not-translate and translating the rest. Format dates and numbers with the active locale's Intl formatters, and format EUR amounts with Intl.NumberFormat('de-DE', { style: 'currency', currency: 'EUR' }). Do not hand-build separators or decide symbol placement yourself. Apply German plural rules via ICU MessageFormat. Flag every place where the translated text runs more than 30 percent longer than the English source and would overflow its container.