36 lines
5.5 KiB
Markdown
36 lines
5.5 KiB
Markdown
# 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
|
||
1. 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.
|
||
2. 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.
|
||
3. 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.
|
||
4. 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.
|
||
5. 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.
|
||
6. 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.
|
||
7. 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.
|
||
8. 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.
|