5 exercises — choose the best-structured answer. Focus on i18n vs l10n, ICU MessageFormat, pseudo-localisation, TMS selection, and continuous localisation pipelines.
Structure for localisation engineer interview answers
Tip 1: Distinguish i18n from l10n: internationalisation = making code adaptable; localisation = adapting content for a specific locale
Tip 2: Name the standard formats: ICU MessageFormat, XLIFF, BCP 47 — correct terminology signals depth
Tip 3: Show pipeline thinking: continuous localisation integrates with CI/CD; translation is not a one-time export
Tip 4: Mention QA techniques: pseudo-localisation catches layout bugs before real locales are available
0 / 5 completed
1 / 5
The interviewer asks: "What is the difference between internationalisation (i18n) and localisation (l10n)? Give a concrete example of each." Choose the most complete and accurate answer.
Option C is strongest: it defines both terms operationally (what changes in code for i18n; what work is done per locale for l10n), gives a concrete code example for i18n (hardcoded string → t() lookup), and enumerates the six dimensions of l10n beyond translation (date format, currency, number separator, plural forms, RTL, cultural imagery). The i18n/l10n separation is the architectural insight that matters in practice. i18n: externalise all locale-specific content from logic (strings, formats, images) so locale can change without code change. l10n: produce locale-specific content for translation + date/time/currency/number format + plural forms + RTL + cultural conventions.
2 / 5
The interviewer asks: "How would you design a continuous localisation pipeline integrated with your CI/CD process?" Which answer best demonstrates production-ready thinking?
Option D is strongest: it describes the six-phase pipeline (extraction → machine translation + review → pull-back → coverage check → pseudo-loc → screenshot testing), explains the automation at each phase, names concrete tools (Phrase/Crowdin/Lokalise, i18next-scanner, DeepL), and adds the professional insight that untranslated strings should fall back to source locale (key exposure in production is a bad user experience). Continuous localisation pipeline: automated string extraction on commit → TMS push → machine translation draft + human review → pull-back to repo → CI coverage threshold gate → pseudo-locale in CI → visual diff for layout issues.
3 / 5
The interviewer asks: "A language has 6 plural categories — how do you handle plural forms in your codebase?" Which answer demonstrates the deepest understanding?
Option B is strongest: it names ICU MessageFormat as the standard (not custom keys), explains the architecture (CLDR plural rules engine maps numeric value to category), names the specific data source (CLDR), gives the concrete ICU syntax, and critically explains WHY custom key approaches fail (the example of Russian "few" applying to 2–4 except 12–14 shows language-specific rules cannot be hardcoded). Option C is partially correct but vague about the mechanism. Option D is an anti-pattern that produces poor UX. Plural handling: ICU MessageFormat + CLDR plural rules engine. CLDR defines category rules per language. The message pattern has one entry per plural category; the ICU runtime selects the category based on the numeric value and the language's CLDR rule. Custom key-per-count = always fails edge cases.
4 / 5
The interviewer asks: "What is pseudo-localisation, and how does it help your QA process?" Choose the best answer.
Option A is strongest: it defines the four mechanisms of pseudo-localisation (character replacement, length inflation with specific percentages, bracket wrapping to catch concatenation bugs, RTL characters for bidi testing), names what bugs each mechanism catches, and explains the CI/CD value (runs immediately without waiting for translators). Options B–D are all common misconceptions. Pseudo-localisation: character replacement (catch non-i18n strings) + length inflation 30–50% (catch layout overflow) + bracket wrapping (catch unsafe string concatenation) + bidi characters (catch RTL bugs) — runs in CI before any real translations exist.
5 / 5
The interviewer asks: "Walk me through how you would evaluate and choose between three TMS tools: Phrase, Crowdin, and Lokalise." Which answer demonstrates a structured evaluation approach?
Option C is strongest: it structures the evaluation across seven dimensions (integration, TM quality, workflow, file formats, collaboration, API quality, pricing model), names specific integration capabilities per tool (Phrase GitHub Actions, Crowdin Git sync), identifies the XLIFF quality variation risk, explains the per-word vs. per-seat pricing model trade-off for continuous deployment, and names the in-context screenshot feature which is critical for translation quality. TMS evaluation: (1) Integration fit (GitHub Actions, CI/CD) → (2) Translation memory quality → (3) Workflow (MT + human review + glossary) → (4) File format support (XLIFF, JSON, Android/iOS) → (5) Translator collaboration UX → (6) API automation quality → (7) Pricing model fit for your deployment frequency.