Glossary / Localization
Localization
Localization (l10n) adapts an internationalized product for a specific language, region, and audience. It includes translated interface text, formatting, imagery, content, legal conventions, and sometimes product behavior. Localization is not merely replacing English strings: the interface must preserve meaning, fit translated text, support locale-specific input and output, and provide an appropriate user experience. The glossary filename includes -2 to avoid a collision with another topic’s filename.
What to know
- A locale can identify language and regional conventions (for example
fr-CA); language alone may not determine currency, date, or vocabulary. - Translate complete messages with context, not concatenated fragments. Use plural/select message patterns and translator notes for ambiguous labels.
- Distinguish translation from transcreation: some marketing content needs adaptation while preserving intent and brand, not literal wording.
- Localize formatting for dates, numbers, currency, units, addresses, names, phone numbers, calendars, and sorting. Use locale-aware APIs such as JavaScript
Intl. - Keep identifiers and canonical values stable; render localized strings at the presentation boundary. Do not parse a display string as a database value without locale-aware validation.
- Provide locale fallback rules and define what happens when a translation is missing. Do not silently mix languages in a way that changes meaning.
- Localization includes accessibility: language metadata, pronunciation, direction, captions, alt text, labels, and screen-reader messages must be localized too.
Workflow
Create extraction and review pipelines, version message catalogs, provide source context/screenshots, and allow translated strings to expand. Test locale switching, fallback, plural forms, long content, RTL, and mixed-language text. Treat user-generated content and names carefully; do not assume names can be split or transformed according to one culture. Separate legal or regional policy from purely linguistic choices.
Interview questions
- What must be localized beyond UI strings? Date/number/currency formats, input validation, accessibility strings, media alternatives, content, and sometimes imagery or workflows.
- How do you handle a missing translation? Apply an explicit fallback chain, monitor gaps, and ensure fallback language is correctly tagged.
- Why not store localized currency strings? They are presentation; store amount and currency code separately to preserve precision and support reformatting.
- How do you avoid layout breakage? Use flexible layouts, pseudo-localization, translation expansion tests, and RTL/script coverage.
- How do you choose locale? Use a predictable precedence—explicit user choice, account or device preference, then product default—and make it changeable.