Quiz - Internationalization
Forty buttons across your app read “Save” in English. A teammate proposes routing all of them through a single t('common.save') key to avoid duplication. What is the senior call?
Mint a separate key per surface. The settings page’s “Save” (save preferences) and the checkout’s “Save” (place the order) may need different words in German — a shared key takes that choice away from the translator.
Use the shared common.save key. The English text is identical, so deduplicating is good engineering and keeps the catalog small.
Use common.save but override it per page in component code with a conditional, so each surface can diverge when needed.
You are authoring the catalog string for “You have N unread messages.” Which branch table is correct across every language, not just English?
{count, plural, =0 {No unread messages} one {# unread message} other {# unread messages}}{count, plural, =0 {No unread messages} =1 {{count} unread message} other {{count} unread messages}}=1 matches only the literal number 1, so languages whose one category also covers 21, 31, … silently fall to other — use the CLDR keyword one, reserving exact matches for wording overrides like =0. And inside a branch the count is # (locale-formatted), not {count} (raw); {count} ships ungrouped numbers like 1234 instead of 1,234.A 1,000-row invoice table renders each amount with value.toLocaleString(locale, { style: 'currency', currency }). The output is correct for every user. What is the problem, and what fixes it?
It is a scale bug: toLocaleString builds a throwaway formatter on every call, loading a CLDR slice each time. Construct one Intl.NumberFormat (behind a module-scope cache) and reuse it across all rows.
It is silently wrong output: toLocaleString ignores the currency option, so reach for Intl.NumberFormat to get the symbol right.
Nothing is wrong — toLocaleString is the recommended shortcut and the runtime caches the formatter internally between calls.
toLocaleString produces correct output but constructs a fresh formatter on every invocation — fine once, a real CPU cost across a thousand rows. The defense is the family’s core rule: construct once, reuse, via a getNumberFormatter(locale, options) memo. This is “correct but wasteful,” distinct from the “silently wrong” no-argument trap (toLocaleString() with nothing passed).A signed-in user whose users.locale is 'fr-FR' opens a shared link to /de-DE/billing from a browser sending Accept-Language: en-US. Which locale renders?
de-DE — the URL prefix is the most explicit signal and sits at the top of the chain, above even a saved profile preference.
fr-FR — a signed-in user’s saved profile is the most deliberate, durable preference and should win over a URL someone else shared.
en-US — the browser’s Accept-Language reflects what this device is actually configured for right now.
Accept-Language best-match → default, first hit wins. A shared localized link is the most explicit request anyone can make, so it beats the profile — for the length of that link the user asked for something specific. The header is only rung 4, a hint, never the truth.Which statements about wiring next-intl into the Next.js 16 App Router are correct? Select all that apply.
Every page.tsx and layout.tsx under app/[locale]/ must start with setRequestLocale(locale); skip it in any one and that route silently converts to dynamic rendering with no error or warning.
In next-intl v4, mounting <NextIntlClientProvider> with no messages prop forwards the entire catalog into the client bundle — scope it to the smallest subtree and pick only the namespaces those client components use.
Server Components must use getTranslations because useTranslations is a hook that only runs in Client Components.
setRequestLocale is the most common production mistake — it writes the locale to a per-request store so downstream calls resolve without a dynamic header read, re-enabling static rendering; omitting it regresses perf invisibly. The v4 provider auto-inherits all messages when given no messages prop, so scope and pick. And useTranslations is synchronous but runs in both Server and Client Components; getTranslations is for code outside the render tree (generateMetadata, Server Actions, route handlers).You ship /billing (English, default) and /fr-FR/billing (French). On the French page, what should alternates.canonical point to?
/fr-FR/billing — each locale variant is its own canonical, so the French page claims itself as authoritative.
/billing — English is the source of truth and the translations are derivatives, so all variants should canonicalize to the original.
/billing tells Google “this French page is a duplicate of the English one — don’t index it,” and Google obliges, deleting your translation from French results. Each variant is its own canonical; hreflang (not the canonical) declares the relationship to the sibling languages. The generateAlternates(locale, href) helper sets this correctly by construction.Quiz complete
Score by topic