Design a Runtime Localization System

Quick Overview

Design a runtime localization system for dozens of countries with locale and regional resolution, variables, plural rules, safe fallback, and offline-capable bundles. Address live copy updates, approvals, rollbacks, formatting, missing translations, cache behavior, and longer-text layout failures.

Design a Runtime Localization System

Company: Adobe

Role: Software Engineer

Category: System Design

Difficulty: medium

Interview Round: Onsite

## Question Design a localization system for a product released in dozens of countries. Every user-facing string should resolve by locale, support variables and language-specific plural rules, fall back safely when a translation is absent, and allow copy updates without requiring an application release. The design must also detect missing translations and layout problems caused by longer text. ### Constraints & Assumptions - Locale may include language and region, such as `zh-TW` or `en-GB`. - Human-authored translations are primary; a default-language bundle ships with the application. - Clients cache downloaded resource bundles and may start offline. - Runtime locale switching should not require a process restart. - Dates, numbers, currencies, and plurals use locale-aware formatting rules. ### Clarifying Questions to Ask - Which clients and release versions must consume the same translation catalog? - How quickly must an edited string become visible? - Is fallback allowed for every string, or must legally sensitive text block release when missing? - Who approves translations and rollbacks? - Are experiments allowed to vary copy within one locale? ```hint Use semantic keys Map stable identifiers such as `checkout.button.confirm` to localized message templates; using English prose as the key couples copy edits to every translation. ``` ```hint Treat messages as structured templates Use a locale-aware message format for variables, selection, and plural categories instead of concatenating fragments. ``` ### What a Strong Answer Covers - Catalog schema, semantic keys, locale fallback chains, and packaged defaults. - Versioned bundle publication, client caching, integrity checks, and rollback. - Placeholder validation, plural and formatting support, and protection against unsafe interpolation. - Build-time completeness checks, runtime missing-key telemetry, and ownership workflow. - Pseudolocalization, bidirectional text, text expansion, accessibility, and visual regression testing. - Gradual rollout and behavior when remote bundle delivery fails. ### Follow-up Questions 1. How would you prevent a translator from removing a required placeholder? 2. How should a client choose among `zh-TW`, `zh`, and the default locale? 3. How would you support copy experiments without fragmenting the catalog? 4. What would you test before adding a right-to-left language?

Quick Answer: Design a runtime localization system for dozens of countries with locale and regional resolution, variables, plural rules, safe fallback, and offline-capable bundles. Address live copy updates, approvals, rollbacks, formatting, missing translations, cache behavior, and longer-text layout failures.

|Home/System Design/Adobe
Adobe logo
Adobe
Apr 19, 2026, 12:00 AM
mediumSoftware EngineerOnsiteSystem Design
0
0

Question

Design a localization system for a product released in dozens of countries. Every user-facing string should resolve by locale, support variables and language-specific plural rules, fall back safely when a translation is absent, and allow copy updates without requiring an application release. The design must also detect missing translations and layout problems caused by longer text.

Constraints & Assumptions

  • Locale may include language and region, such as zh-TW or en-GB .
  • Human-authored translations are primary; a default-language bundle ships with the application.
  • Clients cache downloaded resource bundles and may start offline.
  • Runtime locale switching should not require a process restart.
  • Dates, numbers, currencies, and plurals use locale-aware formatting rules.

Clarifying Questions to Ask Guidance

  • Which clients and release versions must consume the same translation catalog?
  • How quickly must an edited string become visible?
  • Is fallback allowed for every string, or must legally sensitive text block release when missing?
  • Who approves translations and rollbacks?
  • Are experiments allowed to vary copy within one locale?

What a Strong Answer Covers Guidance

  • Catalog schema, semantic keys, locale fallback chains, and packaged defaults.
  • Versioned bundle publication, client caching, integrity checks, and rollback.
  • Placeholder validation, plural and formatting support, and protection against unsafe interpolation.
  • Build-time completeness checks, runtime missing-key telemetry, and ownership workflow.
  • Pseudolocalization, bidirectional text, text expansion, accessibility, and visual regression testing.
  • Gradual rollout and behavior when remote bundle delivery fails.

Follow-up Questions Guidance

  1. How would you prevent a translator from removing a required placeholder?
  2. How should a client choose among zh-TW , zh , and the default locale?
  3. How would you support copy experiments without fragmenting the catalog?
  4. What would you test before adding a right-to-left language?

Submit Your Answer to Earn 20XP

Sign in to leave a comment

Loading comments...