I18N-08 — Europe-Wide QA, Human Linguistic Acceptance and Release Handoff

Objective

Conduct rigorous end-to-end localisation qualification across supported European markets. Assess foundational platform readiness separately from each locale's actual release readiness.

Tasks

Build a coverage matrix crossing language × application surface × country × profession × device. Representative synthetic occupations include teacher, cook, nurse, construction worker, electrician, driver, cleaner, retail employee, office administrator and software developer.
Execute automated test suites with exact process exit codes and commit-bound reports: backend, frontend, real MariaDB, Python, browser, existing RD21 revisions, CV import, CV templates/PDF fidelity, queued jobs and email, Global Jobs search, admin diagnostics, public routes, accessibility, SEO and security. Preserve existing passing baselines.
Exercise realistic user journeys in selected accepted locales: new user onboarding (country and language), account recovery email, saved searches, job discovery, application save, import multilingual CV, edit, per-document output language, generated letter, export PDF, reminder notification, language switch, re-login, profile deletion/export if supported.
Test linguistic edge cases: Polish and Slavic plural forms, Irish/Welsh patterns, Finnish inflection, German expansion, French/Spanish gender, Turkish casefolding, Greek accents, Nordic diacritics, Serbian Latin/Cyrillic, Ukrainian Cyrillic; validate supported locale rendering with real native review where possible. Avoid claiming language correctness based only on software tests.
Verify dates, salary currency display (without FX conversion), time zones, DST transitions, numeral formatting, field validation, address formats and partial date precision. Check screen-reader locale, focus, long-label responsive layout, PDF glyph embedding/selection and email deliverability in isolated test systems.
Verify all unshipped languages are honestly marked and excluded from public selectors and hreflang/sitemaps. Allow English fallback for unsupported markets. Independent owner/native reviewer approvals must be externally authenticated and not creatable by Codex.
Perform threat and privacy review of translated HTML, malicious placeholders, unsafe markdown, locale parameter injection, job ad translated content, PII sent to translators, SSRF/external content and cross-tenant locale preferences. Do not mark unresolved serious vulnerabilities accepted.
Create the final per-market launch matrix, with separate GO/CONDITIONAL/NO-GO for architecture, app, backend, CV, source/job data, communications, marketing and each locale. Estimate missing reviewer and translation work honestly. Distinguish development completion from deployment readiness.

Checkpoints

I18N-08A coverage and test corpus; 08B automated regression; 08C visual/PDF/email and accessibility; 08D linguistic/native review coordination; 08E security/release gates; 08F final acceptance and roadmap handoff.

Deliverables

docs/i18n/08/ACCEPTANCE.md, LOCALE_RELEASE_MATRIX.md, HUMAN_TEST_PACKAGE.md, REGRESSION_RESULTS.md, SECURITY_AND_PRIVACY.md, PRODUCTION_HANDOFF.md, validated updated LOCALE_CATALOG.json and LOCALE_SCHEMA.json.

Acceptance

Overall architecture may be GO while some/most European locales remain DRAFT or BLOCKED. No unqualified claims of "all Europe is live." Publish only locales with owner-approved, native-reviewed, critical-flow-complete status. No main merge/deployment; handoff to Security Audit and Release Readiness with exact outstanding tasks.

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.

5.5 KiB Raw Blame History Unescape Escape