I18N-06 — European Translation Catalogues, Quality Workflow and Locale Launch Gates

Objective

Build a sustainable translation operation capable of shipping Jobjakt to all intended European markets through phased, provably complete language packs. This must create substantive translation/catalogue tooling, not just English strings copied under new locale codes.

Tasks

Read I18N-00 coverage plan; build a versioned translation corpus with source language, namespace, translator notes, context screenshots, placeholders, plural/select variants, glossary references, review status and feature ownership. Export/import to standard formats (JSON/ICU/XLIFF/PO as compatible with chosen library); preserve keys and comments.
Seed actual translations for prioritised locales through permitted translation workflows. Default first wave may be English, Bokmål, Nynorsk, Swedish, Danish, Finnish and Icelandic, but check reviewer availability and owner priorities. Then cover EU 24 and non-EU country languages per the verified country matrix. Document each pack's true progress rather than making all 40+ languages appear complete.
Create approved terminology for Job Applications, Career Profile, CV, résumé, cover letter, interview, shift, apprenticeship, seasonal work, workplace, salary, qualifications, nursing/teaching licences and other all-industry job vocabulary. Avoid English source ambiguity and misleading literal translations.
Use machine translation/LLM only to draft public template/UI strings with appropriate licensed tooling; never transmit private CVs, user emails or tokens. Human proficient/native reviewers must approve critical copy; include a reviewer workflow and immutable approval evidence outside Codex control. Explicitly label unreviewed machine translations.
Implement automated gates: 100% required keys for eligible active locale; parse messages; compare placeholders/types; CLDR plurals/select; HTML escaping; dangerous/empty strings; duplicate keys; gender/case assumptions; hardcoded-string detection; screenshot/text-overflow checks; pseudolocalization; untranslated source-identical checks with exemptions for proper nouns.
Implement locale statuses planned, draft, machine_draft, review_required, reviewed, qa_passed, release_approved, released (or project-compatible equivalent) per namespace/surface. Prevent draft packs from appearing as supported public locales; allow safe English fallback during development.
Generate automated coverage dashboards with counts by key, namespace, blocker severity, reviewer and date, and source-text change invalidation. A change to critical source copy must reopen affected translations; no silent stale publishing.
Include legal/privacy/security/payment template sign-off by qualified reviewers; do not accept machine translations as legally adequate. Research whether regional minority languages need dedicated reviewers before committing to a public timeline.

Checkpoints

I18N-06A translation workflow/tooling; 06B terminology and foundational packs; 06C EU 24 staged corpus; 06D non-EU/variants corpus and review queue; 06E automated QA and per-locale release gates; 06F approvals and evidence handoff.

Deliverables

docs/i18n/06/TRANSLATION_PIPELINE.md, EUROPE_ROLLOUT_MATRIX.md, GLOSSARY.md, HUMAN_REVIEW_PLAN.md, CATALOG_COVERAGE.md, LOCALE_RELEASE_GATES.md, plus actual validated resource files and CI tooling. List every language's implemented/reviewed/released percentage by required namespaces; distinguish draft from accepted.

Acceptance

Can add any new approved European locale without code rewrite; no unreviewed language claimed supported; real locale packs and reproducible checks delivered; no fake 100%-complete counts, no self-generated native approvals.

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.6 KiB Raw Blame History