Design an internationalization system

Requirements: what an i18n platform really has to do

Internationalization, shortened to i18n (18 letters between the i and the n), is the engineering work that makes a product able to run in any language and region. Localization (l10n) is the per-language work done on top of it: translating the strings, picking the right date format, adapting images. A locale is a language plus optional region and script, written as a tag like en-GB, pt-BR or zh-Hant-TW. This question asks for the i18n system: the platform that makes localization cheap, fast and safe for every team.

The naive version is a JSON file per language and a t('key') function. It works for two languages and one team.

At 32 languages and 14 teams it falls apart in predictable ways: English strings ship in German for weeks because nobody exported them, translators guess what "Book" means (a noun or a verb?), a Polish plural reads like broken grammar, the Arabic page lays out left to right, the bundle carries all 32 languages, and one translator's typo in a placeholder crashes checkout. A strong answer is mostly about those failures and the system that prevents them.

The published lessons teach the building blocks: translation-architecture covers catalogs and ICU syntax, locale-formatting covers the Intl APIs, rtl-layouts covers logical CSS properties, and i18n-performance-seo covers hreflang and catalog loading. This guide designs the whole system around them and weighs the trade-offs between its parts.

Questions to ask

Each answer below changes a real part of the design. The middle column is what this guide assumes.

Functional requirements

• Developers write UI text once, in English, with a message id and a description for translators. No hand-edited translation files.
• Messages support variables, plurals, select by gender or type, and rich text such as a link inside a sentence.
• New and changed strings reach the TMS automatically on merge; finished translations come back automatically as a pull request or a published bundle.
• The app renders in the locale from the URL, remembers the user's choice, and can switch language without a full page reload.
• Dates, numbers, prices, relative times and lists are formatted for the locale, and times are shown in the user's time zone.
• Arabic and Hebrew render right to left, including layout, icons and mixed-direction text.
• Missing translations fall back through a chain such as pt-PT then pt then en, and get reported.

Non-functional requirements

• Bundle size: the user downloads only their locale and only the strings of the screens they open. Budget: under 15 KB compressed on the first page for translation data plus any message parser.
• Switch speed: changing language takes under 300 ms on a fast connection, with no flash of the wrong language and no layout jump.
• Freshness: a translation fix can reach production in under an hour, without waiting for an app deploy.
• Safety: a bad translation can't break the page, drop a variable, or inject HTML.
• Developer experience: adding a string is one line of code; the build fails on obvious mistakes like a hard-coded English sentence.
• Scale: 6,000 strings today, 20,000 later, times 32 locales, without slowing the build or the TMS sync.

Out of scope

We leave out translating marketing pages and CMS content (the admin-cms guide covers content localization), localizing emails and push notifications on the server (same pipeline, different renderer), and currency conversion (a pricing problem, not a display one). We do cover how user-generated content is labelled and optionally machine translated, because it shares the page with UI strings and gets confused with them.

What makes this hard

Rendering a string from a dictionary is easy. Four properties of real languages, real teams and real releases make the system hard, and every later chapter answers one of them.

• Grammar is not English grammar. English has two plural forms for whole numbers (1 item, 2 items). Japanese has one. Russian and Polish have four categories. Arabic has six: zero, one, two, few, many and other. Many languages change words by gender, and word order differs. Any design that glues sentence pieces together in code breaks the moment a translator needs a different order.
• Two clocks run at different speeds. Code changes ship in minutes. Translations arrive in days. The system must ship code with missing translations and fill them in later, so every string is in one of several states at any time: new, in translation, in review, done, or stale because the English changed.
• Text is the biggest repeated payload. 6,000 strings at about 60 bytes each is roughly 360 KB per locale before compression, and 32 locales is over 11 MB. Users need one locale and only the screens they visit. Loading has to be split by locale and by route, and cached well.
• The text is written by people who never see the code. Translators work in a TMS, often without seeing the screen. They need context (what is this, where does it appear, how long can it be), and their output must be checked by machines before it reaches users, because one dropped {count} or a stray tag can break a page.

There are also layout effects. Translated text is usually longer than English: IBM's guidelines, quoted by the W3C, expect long passages to grow by about 30 percent in European languages and strings of up to 10 characters to double or triple. German and Finnish add long compound words that don't wrap.

Right-to-left scripts flip the whole page. Chinese and Japanese put no spaces between words, and CJK characters (Chinese, Japanese, Korean) are wider than Latin letters, so line breaking and truncation behave differently. Buttons, tabs and table headers built for English widths overflow or wrap.

Keep the four properties in mind as the axes of the design: a message format that encodes grammar, a pipeline that tolerates two clocks, a loader that ships the minimum text, and checks that guard the translator-to-user path. The rest of the guide takes them one at a time.

Messages: choosing a format that encodes grammar

Start with the inbox badge on the trips page. The naive code builds the sentence from parts: 'You have ' + n + ' new ' + (n === 1 ? 'message' : 'messages'). It reads fine in English. Now send it to a translator: they get You have, new, message and messages as four separate strings, with no idea they form one sentence.

Russian needs three noun forms (1 сообщение, 2 сообщения, 5 сообщений, and 21 goes back to сообщение). Japanese needs none but puts the number in a different place. Arabic has six plural categories, and German moves the verb. The code's n === 1 check is English grammar baked into JavaScript, and no translator can fix it.

The rule that follows: a message is a whole sentence, with named placeholders and all its grammatical variants inside it, and the translator owns the whole thing. Code passes values in; the message decides the words and the order. That needs a message format with plural and select built in. There are four serious choices in 2026.

ICU messages in practice

Here is one real message from the booking summary, with a gender select around a plural, plus rich text. Notice that each branch is a complete sentence. Splitting {host} has from # guests would bring back the concatenation problem inside the message itself.

defineMessages({
  hostSummary: {
    id: 'booking.summary.host',
    description: 'Under the booking total. host = host first name, hostGender from profile, guests = guest count.',
    defaultMessage: `{hostGender, select,
      female {{guests, plural,
        one {{host} is expecting # guest. <link>Message her</link>}
        other {{host} is expecting # guests. <link>Message her</link>}}}
      male {{guests, plural,
        one {{host} is expecting # guest. <link>Message him</link>}
        other {{host} is expecting # guests. <link>Message him</link>}}}
      other {{guests, plural,
        one {{host} is expecting # guest. <link>Message them</link>}
        other {{host} is expecting # guests. <link>Message them</link>}}}
    }`,
  },
});

• other is required in every plural and select. It's the safety branch when a value doesn't match, and some languages use only other.
• Exact matches like =0 {No guests yet} override categories. Use them for the zero case in English instead of an if in code; a translator can still choose to use them or not.
• selectordinal handles 1st, 2nd, 3rd ("your 2nd stay"), which has its own rules per language.
• Don't use plural for anything but numbers. A select on {status} is the right tool for enums like confirmed, pending and cancelled.
• Numbers and dates go through the formatter, not into the string pre-formatted: {total, number, ::currency/EUR} or {checkIn, date, medium}. That keeps digits, separators and month names in the user's locale.

Try it below. The lab renders one plural message for English, Arabic, Russian and Japanese and shows which CLDR category each count lands in. Edit the translations and break them: drop the {hotel} placeholder, remove the other branch, delete Russian's few branch, or add a few branch to Japanese, which has only other. The validator reports what a CI check would.

Ids: stable keys or the English text?

Every message needs an id: the name that links the English in code to its 31 translations. It sounds like a naming detail. It decides what happens every time someone edits English, which on a 14-team codebase is dozens of times a week.

The naive setup is a hand-edited en.json with keys like payButton, and code calling t('payButton'). Within a year it has 900 keys nobody dares delete, three keys with the same English, and keys whose names no longer describe the text. Developers must open a second file to know what a key says, and translators see payButton with no description.

When the English changes

The extractor stores a fingerprint, a hash of defaultMessage, next to each id. On the next sync it compares fingerprints with the TMS: same id with a new fingerprint means the English changed. The TMS keeps the old translations but marks them as needing review, and the runtime keeps serving them meanwhile. A slightly outdated German sentence is better than an English one.

If the meaning changed, the old German is now wrong, not just old: Free cancellation became Free cancellation until 48 hours before check-in. That's a new message, so the developer gives it a new id, and German falls back to English until translated. A lint rule asks the question in review: if defaultMessage changed by more than a few characters and the id didn't, the pull request gets a warning.

• Naming convention: area.screen.element[.variant], for example checkout.summary.payButton. The first segment maps to a namespace file and to an owning team.
• Duplicates: the same id with two different defaultMessage values fails the build. Two ids with the same English are allowed: they may need different translations.
• Dead ids: ids in the TMS but not in the latest extraction are marked obsolete and deleted after 30 days, so older deployed versions still find their strings during a rollback.
• Descriptions are mandatory: a lint rule rejects a message without one. It's the cheapest context a translator gets.

The string lifecycle: from code to translators and back

A string's life starts in a pull request and ends, days later, as 31 translations in users' browsers. The naive pipeline is manual: once per sprint someone exports en.json, uploads it to the vendor, waits, downloads 31 files and commits them. Each round takes a week, the export misses strings merged after it, two teams' commits conflict on the same JSON files, and features launch half-English because their strings missed the cutoff. With many deploys a day, any manual step becomes the bottleneck.

Continuous localization fixes this: every merge sends new strings to the TMS automatically, translators work all the time, and finished translations flow back automatically. The design question is where translations live and how they get to users.

Giving translators context

Most bad translations are good translations of the wrong meaning. Book becomes the noun, Free becomes "without cost" when it meant "available", and a 9-character button gets a 26-character label. The pipeline attaches context to every string it uploads:

• Description from the code, required by lint: "Button on the payment step. Charges the card."
• Placeholder notes: what {host} and {guests} are, with example values.
• Max length for tight spots like tabs and buttons, which the TMS enforces as a warning.
• Screenshots: our end-to-end tests run once in a special pseudo-locale that wraps each string with its id; a script finds those markers on screen and uploads cropped screenshots to the TMS, tagged with the ids they contain.
• Glossary and do-not-translate terms: the brand name, "Superhost", product tiers. The TMS warns when a translation breaks them.
• Translation memory: the TMS suggests earlier translations of the same or similar text, which keeps wording consistent and cuts cost.

Each string then moves through states. Vendors translate, in-country reviewers approve for the top 8 markets, and the publish job only ships approved text. Edits to English send a string back to review, and machine translation can fill gaps for low-traffic locales, clearly marked, until a human gets to them.

Fallback chains for missing strings

At any moment some strings are untranslated, so every lookup needs a chain. For pt-PT the chain is pt-PT, then pt, then en. For en-GB it's en-GB then en: a British user should see "colour" where we have it and plain American English elsewhere, not a raw id.

Chains aren't always the obvious prefix. zh-Hant-HK must fall back to zh-Hant (Traditional characters), never to zh that defaults to Simplified, and es-AR goes through es-419 (Latin American Spanish). CLDR publishes these parent locales, and we generate chains from it rather than chopping strings at the hyphen.

Where do we walk the chain? At runtime, the client would load up to three files per namespace and check each lookup three times. Instead the publish job merges the chain into one file per locale per namespace, and adds a list of the ids that came from a fallback. The client loads one file and does one lookup, and the list feeds the missing-translation dashboard.

Bundling and loading: ship one locale, one screen at a time

Do the arithmetic first. 6,000 strings at about 60 bytes is roughly 360 KB of JSON per locale, which compresses to somewhere near 80 to 100 KB with Brotli. Times 32 locales, that's 3 MB compressed.

The search page uses about 250 of those 6,000 strings. So almost everything a naive setup downloads is waste: other languages, and screens the user never opens.

The naive setup imports every locale file into the JavaScript bundle so t() is synchronous. It's simple and fast to switch, and it puts megabytes on the critical path of every first visit. The opposite naive setup fetches one file for the active locale on startup, then renders. That's better, but still about 90 KB for a page that needs under 10 KB, and it adds a request before any text can show.

Caching with content hashes

Each published file's name includes a hash of its content: /i18n/de/checkout.9c1e2a.json. A file with a given name never changes, so the CDN and the browser can keep it for a year with Cache-Control: public, max-age=31536000, immutable. What changes is a small manifest that maps each locale and namespace to its current file.

The server reads the manifest (cached in memory for 60 seconds) and writes the right URLs into the HTML it renders, so the browser never fetches the manifest on the first page. The cdn-caching lesson covers the general pattern; here it means a German fix costs a returning German user one small download of one namespace.

type CatalogManifest = {
  version: string; // publish id, for rollback and logs
  files: Record<string, Record<string, string>>; // locale -> namespace -> URL
};

const routeNamespaces: Record<string, string[]> = {
  '/search': ['common', 'search'],
  '/hotel/[id]': ['common', 'hotel', 'reviews'],
  '/checkout': ['common', 'checkout', 'payments'],
};

async function loadMessages(locale: string, route: string, m: CatalogManifest) {
  const urls = routeNamespaces[route].map((ns) => m.files[locale][ns]);
  const parts = await Promise.all(urls.map((u) => fetch(u).then((r) => r.json())));
  return Object.assign({}, ...parts); // id -> precompiled AST
}

On the first page, server rendering embeds the messages the page used into the HTML payload, so hydration needs no extra request. On client navigation, the router prefetches the next route's namespaces together with its code chunk when the link becomes visible or is hovered (the code-splitting lesson explains route prefetching). Formatting itself costs almost nothing in bytes: we use the browser's built-in Intl objects for plurals, numbers and dates instead of shipping locale data in a date library.

Runtime: picking the locale and switching it live

Two moments decide which language a user sees. The first request, when the server must choose a locale before it renders a single byte. And the switch, when a user picks another language from the menu. Getting either wrong produces the classic bugs: a French user bounced to English by a redirect, a page that flashes English before German arrives, or a switch that changes the text but leaves dates in the old format and the layout facing the wrong way.

Choosing the locale on the server

The server checks sources in a fixed order, and the first one that names a supported locale wins:

1. The URL: /de/hotel/123. It's explicit, shareable, and what search engines crawl. If the URL has a locale, nothing else is consulted.
2. The saved choice: a locale cookie set when the user picked a language, or the profile setting for a signed-in user.
3. The browser's preference: the Accept-Language header, such as de-CH,de;q=0.9,en;q=0.8, matched against our 32 supported locales.
4. The default: en.

Steps 2 to 4 only run on URLs without a locale, like the bare home page, and they end in a redirect to the localized URL. A localized URL never redirects based on headers. That rule protects search: crawlers usually don't send Accept-Language, so a header-based redirect on /fr/hotel/123 could send the crawler to English and the French page would never be indexed. The bare-root redirect response must not be cached publicly, or it must vary by cookie and header, or the CDN will send everyone to whichever language came first.

Matching isn't string equality. de-CH should land on de when we have no Swiss German. zh-TW should land on zh-Hant, which new Intl.Locale('zh-TW').maximize() reveals by adding the likely script: zh-Hant-TW. A small matcher walks the user's list in order of q weight and returns the first locale whose fallback chain hits a supported one.

Switching without a reload

The order of operations matters. Load first, then commit: fetch every namespace the current route needs, and only when all of them arrive, update the provider. Mark the update as a React transition so the old screen stays interactive. In the same commit set document.documentElement.lang and dir, replace the URL so it reads /fr/... (no new history entry), and update the document title.

Then persist: set the cookie for a year and, for a signed-in user, save the choice to the profile so other devices follow. Data that came from the server in the old language, such as a localized hotel description, refetches under its new cache key, because the locale is part of every localized query key.

Routing, search and right-to-left

Two parts of the system act on the whole page rather than on single strings: where the locale lives in the URL, and which direction the page flows. Both must be decided once, at the platform level, because retrofitting either across 14 teams is a quarter of work.

Right-to-left as a platform feature

For Arabic and Hebrew the server renders html lang="ar" dir="rtl", so the first paint is already mirrored. The browser then flips text flow, flex and grid order, and table columns by itself. What it can't flip are left and right written into CSS and icons. The rtl-layouts lesson covers the CSS; here's what the platform enforces:

• Logical CSS only. A stylelint rule rejects margin-left, padding-right, left: and text-align: left in favor of margin-inline-start, padding-inline-end, inset-inline-start and text-align: start. The design system's components do this once; product teams inherit it.
• Mirror icons that mean direction, not all icons. Back and forward arrows, a progress chevron and a "reply" arrow flip. A checkmark, a clock, a play button and brand logos don't. The icon set marks each icon as directional, and the Icon component flips those under :dir(rtl).
• Isolate mixed-direction values. A hotel name in Latin letters inside an Arabic sentence can scramble nearby punctuation. Wrap user-supplied values in bdi elements, or give inputs dir="auto", so each value keeps its own direction.
• Motion and gestures follow direction. A drawer opens from the inline-start side, a carousel's next is on the left in Arabic, and a swipe to go back goes the other way.

Switching direction at runtime is the same commit as switching language: set dir on the html element and every logical property recomputes. That works only because nothing hard-coded left or right. Components that measure positions in JavaScript, like a tooltip or a virtualized carousel, must read the direction from the provider instead of assuming left.

Formatting: dates, numbers and time zones

Translated strings are half of what users read. The other half is values: prices, dates, counts, durations, lists of amenities. The browser's Intl APIs format all of them for any locale with no data to download, and the locale-formatting lesson covers each API. The system design questions are different: which locale and time zone get passed in, where formatters are created, and how server and client agree.

The naive code calls price.toLocaleString() and date.toLocaleDateString() with no arguments. On the client that uses the browser's language, not the app's, so a German page shows US dates for a user whose browser is set to English. On the server it uses the server's settings, usually en-US and UTC. The two disagree, and React reports a hydration mismatch on every date.

The rule: every format call gets the app's locale and an explicit time zone, and both come from the same provider on server and client.

Create formatters once

Creating an Intl formatter means resolving locale data and options, which is far slower than calling format() on an existing one. A search page with 50 hotel cards, each with a price, a rating and a date range, would create hundreds of formatters per render. The platform exposes formatting through hooks backed by a cache keyed by locale and options, so each combination is built once per session. FormatJS already memoizes its formatters this way; our own helpers for non-React code, such as chart labels, use the same cache.

const cache = new Map<string, Intl.NumberFormat>();

export function numberFormat(locale: string, options: Intl.NumberFormatOptions = {}) {
  const key = locale + JSON.stringify(options);
  let f = cache.get(key);
  if (!f) {
    f = new Intl.NumberFormat(locale, options);
    cache.set(key, f);
  }
  return f;
}

// numberFormat('de-DE', { style: 'currency', currency: 'EUR' }).format(1234.5)
// -> '1.234,50 €'

Whose time zone?

Time zone is a separate setting from language, and our product has three kinds of time. Store every instant in UTC, then pick the zone by meaning:

• Place times use the place's zone. "Check-in from 15:00" is 15:00 at the hotel in Lisbon, whatever zone the user is in. The hotel record carries timeZone: 'Europe/Lisbon'.
• Personal times use the user's zone: "Booked on 3 March at 21:40" in their profile zone, or the browser's Intl.DateTimeFormat().resolvedOptions().timeZone for guests.
• Relative times like "2 hours ago" don't need a zone, but they change as time passes, so the server renders an absolute date and the client upgrades it after hydration.

Region preferences go beyond time zones: the first day of the week (Monday in Germany, Sunday in the US, Saturday in some Middle Eastern countries) matters for the calendar, which the date-picker guide handles. And currency follows the market setting, never the language: de with CHF is a valid pair.

Architecture, data model and the developer API

With the decisions made, the system has three halves that meet at the catalog files. Build time turns code into source strings, and the localization pipeline turns source strings into validated, compiled catalogs on the CDN. Runtime picks a locale and renders with those catalogs. Each half can fail or change without breaking the others, which is why the boundaries sit where they do.

Why these cuts? The extractor and the publish job are separate so developers never wait for translators, and translators never wait for a deploy. The CDN sits between the publish job and the app so a TMS outage can't take the site down: the last published catalogs keep serving. And everything locale-dependent in the app reads from one provider value, which is what makes a live switch a single re-render instead of a hunt for stale strings.

Data model

type MessageSource = {
  id: string;              // 'checkout.summary.payButton'
  defaultMessage: string;  // ICU, English
  description: string;     // for translators
  fingerprint: string;     // hash of defaultMessage
  maxLength?: number;
  placeholders: string[];  // ['host', 'guests'], from the parsed message
};

type TranslationState = 'new' | 'translating' | 'review' | 'approved' | 'stale' | 'obsolete';

type PublishedNamespace = {
  locale: string;          // 'pt-PT'
  namespace: string;       // 'checkout'
  messages: Record<string, unknown>; // id -> precompiled AST
  fallbackIds: string[];   // served from 'pt' or 'en'
};

type LocaleContext = {
  locale: string; dir: 'ltr' | 'rtl'; timeZone: string;
  market: { country: string; currency: string };
};

What app developers write

The platform's success is measured by how little developers think about it. They get two hooks and one component, and never touch a locale file:

const m = defineMessages({
  cancelNote: {
    id: 'checkout.summary.cancelNote',
    description: 'Below the price. date = last free cancellation day.',
    defaultMessage: 'Free cancellation until {date}. <terms>Read the policy</terms>',
  },
});

function CancelNote({ until }: { until: Date }) {
  const t = useT();
  const { formatDate } = useFormat(); // locale and time zone from the provider
  return (
    <p>
      {t(m.cancelNote, {
        date: formatDate(until, { dateStyle: 'long' }),
        terms: (chunks) => <Link href="/policy">{chunks}</Link>,
      })}
    </p>
  );
}

The language picker is a platform component too, so every team gets the same behavior. It lists each language in its own name and script (Deutsch, العربية, 日本語), because a user who can't read the current language must still find theirs. It separates language from region formats and time zone, and shows a live preview of a date and a price before the user commits.

Quality and safety: catching problems before users do

With 6,000 strings, 32 locales and many deploys a day, mistakes are a certainty: a hard-coded English label, a button that truncates in German, a translation that drops {count}, a link tag typed as raw HTML. The platform's job is to catch each kind as early and as cheaply as possible: in the editor, in CI, at publish time, and finally in production monitoring.

Pseudo-localization: test every language before it exists

A pseudo-locale is a fake language generated by a script from English, built to expose bugs. Android ships two that make good models: an accented one (en-XA) and a right-to-left one (ar-XB). Ours are generated by the publish job for every build:

• Accented and expanded: Pay now becomes [Ƥåý ñöŵ one two]. Accents prove the text went through the catalog; any plain English on screen is a hard-coded string. Padding of about 40 percent shows where longer languages will overflow. Brackets show truncation: a missing ] means the end was cut off, and brackets in the middle of a sentence reveal concatenation.
• Bidi: English words reversed inside right-to-left marks, with dir="rtl". Engineers who can't read Arabic can still see a broken mirror: a left-pointing back arrow or a margin on the wrong side.
• Ids: each string wrapped with its id, used by the screenshot job for translator context.

Pseudo-locales run in CI visual tests on the 30 most important screens and are selectable on staging. Combined with an ESLint rule that flags literal text in JSX (such as formatjs/no-literal-string-in-jsx or i18next/no-literal-string), they catch nearly every hard-coded string before a translator ever sees the feature.

Validating translations at publish time

The publish job parses every translation and compares it with its source. It rejects a string, keeps the last good version live, and reports the error back to the TMS when:

• A placeholder is missing or renamed: the source has {count} and the translation has {cnt} or none. The UI would show a wrong or empty value.
• A plural or select has no other branch, or the message doesn't parse.
• Tags don't match: the source has terms and the translation has term, a missing closing tag, or a tag the source doesn't have.
• Raw HTML appears, such as an a or script tag. Translations never carry markup.

It warns, without rejecting, on plural categories the language doesn't use (a few branch in German is dead text), on length above maxLength, and on glossary violations. Most TMS tools run similar checks in the translator's editor; we repeat them because the publish job is the last gate we control.

Watching production

Some problems only show up live. The provider's error handler reports two event types to our logging endpoint, batched and deduplicated per session: i18n.missing (an id with no entry, which should only happen when code and catalog are out of step) and i18n.format_error (a message that threw while formatting, for example a select value nobody planned for). Each event carries the id, locale, route and catalog version.

A dashboard ranks ids by affected users, and the fallback lists from the publish job give a second view: what share of each locale's strings is still English, per namespace. A release that pushes de checkout below 98 percent translated gets flagged before launch.

User-generated content is not UI

Reviews and host messages are written by users in their own language, and they share the page with our translated UI. They never go through the TMS. Instead, the server detects each review's language when it's submitted and stores it, the page renders each review inside an element with that lang (so screen readers pronounce it correctly and the browser picks the right fonts and hyphenation), and inputs use dir="auto" so an Arabic review typed on an English page flows correctly.

A "Show translation" button calls our backend, which machine-translates on demand and caches the result per review and target language. The translated text is labelled as machine translated, carries the target lang, and offers the original one click away.

Running it in the interview

This question is wide, and the trap is spending 30 minutes on ICU syntax. Interviewers want to see the system: how strings move, how the runtime stays small and correct, and how mistakes get caught. Here's a plan for 45 minutes.

1. Minutes 0 to 5, scope. Ask about languages (any RTL?), who translates, whether releases can wait, rendering model, and SEO. Write the numbers on the board: 32 locales, 6,000 strings, deploys many times a day.
2. Minutes 5 to 8, what's hard. Name the four properties: grammar, two clocks, payload, untrusted translators. Say which chapter of your answer handles each.
3. Minutes 8 to 15, messages and ids. Show the concatenation bug, pick ICU, write one plural message. Pick semantic ids colocated with English and explain what happens when English changes.
4. Minutes 15 to 25, the pipeline. Draw extractor, TMS, publish job, CDN, manifest. Explain context for translators, review states, fallback chains merged at publish time.
5. Minutes 25 to 35, runtime. Locale negotiation order, the no-redirect rule, per-namespace precompiled loading with content hashes, live switching with load-then-commit.
6. Minutes 35 to 45, depth. RTL, formatting with time zones, pseudo-locales, publish-time validation, rich text tags, and user content. Let the interviewer steer which one.

Draw the architecture diagram first, as three columns: build, pipeline, runtime, meeting at the CDN. Every later point attaches to a box on it. Say trade-offs out loud as numbers: "one catalog is 90 KB, per-namespace is 8 KB for the search page" lands better than "it's more efficient".