Localization Engineering

i18n (internationalisation): designing software to support multiple languages and locales — externalising strings, supporting Unicode, RTL layouts, date/number/currency formatting. L10n (localisation): adapting for a specific locale (translating strings, adjusting cultural formats).

"i18n is the engineering work: replacing hardcoded English strings with translation keys, using ICU format for plurals, using Intl APIs for date formatting. L10n is the content work: translating the extracted strings for each target language, adapting tone and idioms for the culture. Engineers do i18n; translators do L10n; the TMS connects them."

A message syntax standard for expressing plurals, selections, and placeholders in translatable strings. Handles grammatically complex cases that differ by language — such as plural rules that require different forms for 0, 1, 2, 3-10, and 11+ items in some languages.

"English plurals are simple: 'You have {count, plural, one {1 item} other {# items}}.' Arabic has 6 plural forms. ICU MessageFormat handles both with the same syntax — the translator provides the correct form for each plural category in their language. Without ICU, engineers hardcode English-specific plural logic that fails for Arabic, Russian, and Polish."

An industry-standard XML format for exchanging localisation content between tools. Contains source strings paired with target translations, along with metadata (state, note, id). Supported by all major CAT tools and TMS platforms.

"Our localisation pipeline: i18next extracts strings to JSON, a script converts JSON to XLIFF 2.0, XLIFF files are uploaded to Crowdin. Translators work in Crowdin's editor; exported XLIFF is converted back to JSON and committed to the repo. XLIFF is the format that enables any TMS tool to ingest our content without custom integration."

A database of previously translated segments: source text paired with target translation. When new content arrives, TM matches are found — 100% match (identical), fuzzy match (similar), and no match (new translation needed). Reduces translation cost and ensures consistency.

"When we rebranded 'workspace' to 'environment,' the TM showed 847 matches across all language files. Translator only needed to update the translations once; TM propagated the change to all 847 uses. Fuzzy matches (85-99% similar) are presented to translators with the old translation as a starting point — saving time while ensuring human review."

Replacing source strings with pseudo-translated versions — typically by expanding the string length and replacing characters with accented equivalents — to test layout and i18n issues before actual translations exist. Finds truncation, hardcoded string, and missing placeholder bugs early.

"Our pseudo-locale (en-XA) replaces 'Submit' with '[Ŝúbmïţ šóméẃhéré lóñgér]' — 30% longer than English, all accented characters, wrapped in brackets to spot untranslated strings. Running the app in en-XA revealed: three buttons truncated, one modal overflowed, two hardcoded English strings not extracted. Found and fixed before real translations were delivered."

An approach where localisation is integrated into the development workflow: strings are extracted automatically on commit, sent to the TMS, and translated continuously rather than in batches before a release. Eliminates the pre-release localisation crunch.

"Our CI pipeline on every main branch commit: extract new/changed strings → upload to Phrase Strings → translators receive tasks immediately. Translated strings are synced back to the repo via a bot PR every 4 hours. When we ship a feature, translations are already in the repo for all 12 languages. No localisation sprint, no release delay."

A review process to evaluate the quality of translated content — checking for accuracy, fluency, terminology consistency, and contextual appropriateness. May use a scoring framework (MQM, BLEU for MT) and is performed by native speakers, not the original translator.

"For our market launch in Japan, we ran a formal LQA on all UI strings. A native Japanese reviewer used the MQM framework, scoring each segment for accuracy (source meaning preserved), fluency (natural Japanese), and terminology (consistent with our Japanese glossary). 3.2% of segments required revision, mostly for formal/informal register consistency."