# I18N-00 — Europe-Wide Audit, Coverage Matrix and Implementation Specification

## Objective
Perform independent full-stack inventory and produce a testable roadmap for full European localisation. This stage is **research and documentation only**, suitable to run while earlier development gates remain blocked. Read the master prompt first.

### Tasks
1. Trace existing `en`, `nb` and related language handling across React, .NET, Python sidecar, DB, auth, marketing, public/legal pages, emails, billing, job enrichment, background queues, AI, errors, CV import, CV editing, PDFs, server logs and admin monitoring. Identify hardcoded UI text, database values mistaken for translated display labels, and language assumptions.
2. Inventory every string with namespace, English source text, translation context, placeholders, sensitivity and owning component. Distinguish user content, source job ads and controlled UI strings. Include mobile, empty/loading/error states, ARIA, screen readers, toasts, generated filenames and export labels.
3. Create a country/territory-to-language matrix for all European countries/markets, including multi-official, minority/regional and script variants. Cross-check using authoritative CLDR/territory data and relevant official country records. Include EU 24 and non-EU countries; distinguish official vs regionally recognised vs candidate support. Do not imply EU-membership or political recognition from language tags.
4. Prioritise shipping waves by usage/verification feasibility, not by engineering bias. Include `en-GB`, `nb-NO`, `nn-NO`, `sv-SE`, `da-DK`, `fi-FI`, `is-IS` early candidates, then EU-24 and broader Europe. List all 24 EU official languages explicitly and map candidate locale codes; evaluate Serbia Latin/Cyrillic and Swiss variants. Do not commit to shipping a locale without translators/review capacity.
5. Inspect actual library versions and decide whether to extend current i18n solution or migrate. Compare use of i18next/Intl vs FormatJS/ICU where relevant; evaluate compatibility with .NET localisation and message tooling. Prefer minimal coherent shared catalogs over duplicate systems.
6. Model the boundaries between country of residence, search countries, location filters, UI locale, job ad language preferences, per-document output language and optionally preferred communication language.
7. Build a detailed risks register: dates, plurals, gender, word order, RTL future-proofing, extended Latin/Greek/Cyrillic glyph coverage, Turkish casing, Serbian scripts, name ordering, accessibility, legal copy, GDPR and subscription markets.
8. Define acceptance per locale *and per surface*, staged publication, fallback semantics and human/native review requirements.

### Deliverables
`docs/i18n/00/AUDIT.md`, `SURFACE_INVENTORY.md`, `EUROPE_COUNTRY_LANGUAGE_MATRIX.md`, `IMPLEMENTATION_PLAN.md`, `RISKS_AND_APPROVALS.md`, `BASELINE_TESTS.md`, draft `LOCALE_CATALOG.json` and validated schema. Include source URLs and verification dates for authoritative language lists. Give explicit integration contracts for Global Jobs and Launch Site.

### Acceptance
No missing critical surface in the inventory; country/language coverage is not limited to EU; each proposed locale has planned status and ownership; no promised completed translations; no feature code changes. Verdict: PLANNING READY/BLOCKED; I18N-01 entry decision with real predecessor checks.

---

### Execution and evidence rules (mandatory in every stage)
- Read the current repository, Phase 10/product-review/global-jobs/homepage acceptance and the preceding I18N stage handoff. Verify rather than assuming a historical milestone is complete.
- Use the latest **accepted development integration baseline** and a dedicated stage branch. Never assume `main` contains redesign work. Confirm ancestry, active worktrees and clean state; do not clobber concurrent Codex work.
- Inspect existing React/.NET/MariaDB and localisation patterns before introducing packages. Choose based on verified compatibility, not guessed APIs. Preserve old English/Norwegian data and behaviour.
- Work autonomously on approved, safely executable checkpoints. For each: implement, run targeted tests, write evidence, commit and push to the development branch, verify remote HEAD. If Gitea is unreachable, preserve the commit and report publication as BLOCKED. No force push.
- Never merge into `main`, trigger production deployment, touch live MariaDB/Docker/Ollama, expose production credentials, buy services, or self-approve a security/linguistic/legal exception. No production data in translation/test fixtures.
- Mark each capability IMPLEMENTED, AUTOMATED-TESTED, HUMAN-REVIEWED, ACCEPTED, RELEASED or BLOCKED independently. Preserve evidence of failures and incompleteness. Stage can conditionally complete when documented and authorised; *locale publication* requires its own gates.
- Never modify source career facts, user-created CV text, employer descriptions, qualification titles or legal content as a side-effect of switching UI language. Human-authored content is not interface chrome.
- On completion give: branch, commit hashes, remote publication state, implemented scope, actual test counts and commands, remaining risks/owner actions, next-stage eligibility and Production NO-GO unless explicitly authorised after all release gates.