Internationalisation & accessibility

Five locales are wired: en-GB, en-WA, pt-BR, es-LatAm, it-IT. The strings dictionary at apps/sporthead-id/lib/strings.ts holds ~110 string keys and every key has an entry for every locale. No silent en-GB-only fallback. Resolver chains exact locale → en-GB → key, with {placeholder} interpolation. Solid v0 plumbing.

Handle vocabulary is the weaker half. sporthead_prefixes and sporthead_suffixes carry a locale column; the RPC routes against it. The migration header is honest: "a working starter set ... enough vocab for the RPC to function without collisions in early founders cohort". The £5–12K-per-locale linguist budget has not been spent; only en-GB has had a curation pass.

The budget is genuinely tight. Professional adult-content + brand screening for handle vocabulary alone typically costs £4–8K per language before UI copy. The Phase 1 plan reads more like "ship at en-GB quality plus best-effort" than "five locales at parity" — defensible, but should be named internally so we don't claim parity at the December event.

The current strings.ts approach is "en-GB sprinkled with Pidgin verbs where it improves the read" ("where you dey?", "we go set ...", "you fit change am"). This is best-effort and shows respect, but has three failure modes:

• Inconsistent register. step.country.title is Pidgin ("where you dey?") while step.country.fallbackLabel reverts to plain English ("your country"). A Sierra Leonean reader experiences whiplash; a Liberian reader notices the Nigerian-Pidgin tilt and clocks it as foreign.
• Handle vocabulary is empty. Vocabulary tables have no en-WA-native prefix/suffix corpus seeded. The RPC will either fall through to en-GB or generate nonsense. A West African Sport Head's first sight of their identity will be an en-GB phrase with the en-WA flag next to it.
• Geo copy mixes registers inside a single sentence. step.geo.subtitle.sl_district reads "we go connect you to sport people for your area" (Krio); step.country.somewhereElse stays as plain en-GB "somewhere else?". The user flips registers every paragraph.

Honest call is one of: (a) treat en-WA as Krio specifically, hire a Krio linguist in Freetown, accept that Nigeria/Ghana/Liberia get a slightly foreign-feeling but coherent register; (b) split into en-WA-SL, en-NG, en-GH, en-LR — expensive but matches reality; (c) keep en-WA as standard West African English (no Pidgin), match BBC Pidgin's editorial line for headlines/CTAs only, use plain English elsewhere. The current path is none of those — it is improvised. That improvisation will be visible to the cohort.

The dual-handle migration alone is several weeks of schema and RPC work that needs to land before any CJK or Arabic translator starts — otherwise the linguist produces strings the database refuses to store. Sequence matters.

The football case is the canary. Sport/Football in en-GB = association football. In en-WA, same. In pt-BR the sport is futebol and the cultural weight is enormous — picking Sport/Football from an English-labelled picker is the smallest moment the brand can afford to get wrong. In US English (routed to en-GB) football means gridiron and the picker shows a soccer ball. That's a bug.

• Display names need a translation pass. Fastest path: add a trait_display_names table keyed by (category, filename, locale) with fallback to filename. ADR-0004 already flags trait-registry migration as a hard prerequisite; i18n display-name layer is the same migration's natural sibling.
• Culturally-specific drops vs rarity-weight. Decision 5 in strategy doc 01 commits to locale-specific drops (a Sierra Leone fight-night helmet, a São Paulo carnival mask). The helmet_rarity migration treats rarity as a global column. If the SL helmet is rare for everyone, it loses meaning at home; if common only for en-WA users, schema needs (filename, locale) → rarity_weight not (filename) → rarity_weight. Current column is single-axis.

One-trait-registry-many-locales is the right answer. Locale-shadow registries (separate catalogs per market) would fragment supply and break founder credentials. But the rarity column needs a locale axis before any culturally-specific drop ships.

What it gets right: inputMode="numeric" + pattern="[0-9]*" for the mobile numeric keypad; autoComplete="one-time-code" so iOS will offer SMS-OTP autofill (slight category mismatch — not actually an OTP — but the closest semantic and works); paste handler that splits a 6-digit clipboard into six cells; two-phase entry with mismatch detection.

What it gets wrong or skips:

• Auto-advance and screen readers. Auto-advancing focus between six separate input elements is a documented VoiceOver/TalkBack hazard. User types a digit, focus jumps, screen reader announces a new field, user types again, focus jumps again. Some users will hear nothing of their progress. Fix: single input with letter-spacing styling (GitHub, Stripe, Apple all moved to this) or explicit aria-live on each cell change.
• No visible-PIN toggle. Cognitive/motor-disabled users need to see typed PIN to confirm. No eye-toggle. Values stored as type="text" (not password) which leaks them visually anyway — toggle half-implemented by accident.
• The aria-label is unlocalised. aria-label={`PIN digit ${idx + 1}`} is hardcoded English at line 304. Italian, Portuguese, Spanish users get English screen-reader announcement during their most sensitive step.
• Phase-1 confirm has no button. Auto-advance to phase 2 fires 250ms after the 6th digit. Keyboard-only or screen-reader users have no opportunity to review before commit. Add an explicit "continue" button as alternative path.
• No PIN strength check. 111111, 123456, 000000, birth-year sequences not blocked. Six-digit PIN with no strength gate ~1M possible values — bruteforce-feasible if rate-limiting fails.

User gets an override — step 1 has an explicit "somewhere else?" path surfacing 24 fallback countries. Good. Once picked, locale is written to localStorage and that becomes the journey source of truth.

The harder question is post-lock. The profiles.locale column is one of the fields the enforce_identity_lock trigger does not currently lock. If locale is mutable, a user can move from Sierra Leone to Italy and switch their display register — desirable. If locked, migrants are stuck. Needs a deliberate decision in an ADR: locale follows the person, not the identity. The handle's locale-derived vocabulary stays fixed regardless (you don't lose @phantom-dodger because you moved to Milan), but UI strings should follow you.

To get from "starter strings + en-GB-only vocab" to "launch-quality across five locales" you need, in order:

• Translation memory tool. Crowdin, Lokalise, or Phrase. £50–250/month. Without this, every string change becomes a four-way email thread.
• Linguist procurement. Four locales × £5–12K = £20–48K. Krio linguist (Freetown), pt-BR sport-culture writer (São Paulo/Rio), es-LatAm — note: in practice we need either a neutral MX-Spanish writer or two writers (MX, AR/CL) and merge — Italian sport-writer. None on contract yet.
• Sign-off process. Who decides "this Krio is right"? Not the founders. Need a named cultural reviewer per locale with veto on launch copy.
• Locale freeze date. Six weeks before the December event. After freeze, only hotfix-grade string changes.
• pt-BR vs pt-PT. detectLaunchRegion() routes all pt-* browsers to pt-BR. Comment in lib/locale.ts:185 acknowledges this. Currently no pt-PT brief. Portuguese Sport Heads get Brazilian copy. Acceptable for v0; needs a deliberate decision before Portugal market is prioritised.