Jobjakt — I18N-01 MASTER ORCHESTRATOR

Full European Internationalisation, Localisation and Cross-Industry Language Support

Mission

Build Jobjakt into an international career-management application that can serve users throughout Europe in the appropriate local language(s) and English. This is an end-to-end platform localisation programme, not just translating React buttons. Include authenticated UI, onboarding, admin, accessible validation, backend errors, email/reminders, Career Profile/CV import/CV Builder/cover letters/PDFs, job discovery, occupation names, marketing interfaces and SEO contracts.

Europe-wide scope is broader than the EU's 24 official languages. Design locale registry, fonts, message engine, data contracts, testing and translation workflows for all European countries and major official/national/local languages, with a documented expandable path for regional/minority languages. Never claim every European language is already translated. A locale becomes public only after appropriate automated and human qualification.

Business and UX principles

All occupations, not developer-only: teachers, cooks, nurses, trades, retail, transport, public sector, graduates, etc.
Country does not equal language. Store residence country, job search countries, interface locale, job-ad language filters and per-CV/letter language independently; do not couple country switch to forced translation.
Suggest English and current-country local language(s) first, but allow any approved supported UI locale. Display native language name followed by English name, and preserve manual overrides across devices.
Store BCP 47 locale tags and stable ISO 3166 country IDs; verify territory-language relationships from current authoritative datasets. Locale/script/country variations require correct fallback.
Keep source job ads in their original language, alongside a labelled translation/summary only with rights and permission. Do not rewrite professional accreditation, employer statements or missing information.
Preserve existing users' documents, language preferences, drafts, frozen PDFs, billing entitlements and RD21 revision safety. Default/fallback for legacy settings must be deterministic and documented.
Provide explicit accessibility support, language direction and Unicode script coverage. Locale choice should never make a form unusable.
Avoid wide manual string concatenation: support context, plural/gender/select, variable interpolation, rich text, time zones, number/currency and date formatting.
Use machine translation/AI only as an explicitly labelled drafting aid, with terminology and human review. Never auto-send PII-containing CVs or private messages to external translators without separately approved consent, contracts and data controls.
Public marketing may say a locale is supported only after that locale's complete release gate passes; availability differs across products, providers, countries and languages.

Target coverage and sequencing

Phase 1 foundation: existing English/Bokmål production behaviour (en-GB or existing canonical English tag, nb-NO); add appropriate Nynorsk (nn-NO) and Scandinavian languages where translation and validation resources permit. Preserve backward compatibility.

Phase 2 broad EU coverage: all 24 EU official languages: Bulgarian, Croatian, Czech, Danish, Dutch, English, Estonian, Finnish, French, German, Greek, Hungarian, Irish, Italian, Latvian, Lithuanian, Maltese, Polish, Portuguese, Romanian, Slovak, Slovenian, Spanish and Swedish. The EU list is a coverage baseline, not the definition of Europe.

Phase 3 non-EU national/official languages and variants: Norwegian Bokmål/Nynorsk, Icelandic, Ukrainian, Albanian, Serbian Latin/Cyrillic, Bosnian, Montenegrin, Macedonian, Turkish, Luxembourgish, Welsh, Swiss Romansh, Faroese, Belarusian and other European-country languages as verified. Evaluate European/transcontinental contexts (e.g. Georgian, Armenian, Azerbaijani, Russian) explicitly in a defensible region/market matrix rather than inferring from geography. Consider national locale variants such as fr-CH, de-CH, it-CH, nl-BE, fr-BE, de-BE, en-IE, pt-PT, and regional/minority candidates Catalan, Basque, Galician and Scottish Gaelic. This is an illustrative research inventory, not a claim that any language pack is currently shipped.

Long-term: a catalogue covering all approved European markets, with verifiable locale status and easy addition of further regional/minority languages without architecture rewrites. Never prevent unsupported-language users from using the reliable English fallback.

The repository's actual existing locale identifiers take precedence when migration or interoperability requires preserving them. Distinguish language tags like el-GR (Greek language) from third-party country/organisation labels.

Workstream ordering

I18N-00 — Baseline, complete surface inventory, Europe country/locale scope and acceptance plan.
I18N-01 — Locale registry, user preferences, safe migration, fallback and formatting architecture.
I18N-02 — Full React/authenticated UI, forms, admin, accessibility and error states.
I18N-03 — .NET/Python/backend, queued jobs, emails, notifications, billing copy and diagnostics.
I18N-04 — Career Profile, CV import, CV editor, cover letters, typography, PDFs and source-language integrity.
I18N-05 — International job discovery: occupation taxonomy, suggestions, regional locations and source/ad language.
I18N-06 — European translation supply chain, catalogues, terminology, coverage and human review.
I18N-07 — Marketing/homepage locale contracts, country pages, SEO and content publishing gates.
I18N-08 — Pan-European end-to-end QA, native review, performance, accessibility, release gates and handoff.

Run each file in order; when independent work is possible, record dependencies and maintain sequential acceptance/integration. For cross-project dependencies, GJ owns job-source and search logic and LAUNCH-SITE owns homepage visual design; I18N owns localisation contracts and reviews. If a dependent component is not ready, complete the interface/fixtures without inventing released functionality.

Branch/integration contract

Prefer feature/i18n-00-audit through feature/i18n-08-acceptance (planning branches where appropriate). Use a shared, explicitly approved, non-production integration branch/worktree, not concurrent edits to one checked-out worktree. Integrate only accepted stage commits in dependency order and run regression after each integration. Never auto-merge to production main. All automated execution must obey owner-controlled approval files outside Codex-writable paths; self-generated JSON PASS must not override independent gates.

Standard per-locale release gate

For each UI locale/market/surface:

Locale registry and fallbacks valid; ownership and licence checked; every required message key complete and syntactically valid; placeholders/variables/plurals match source and render correctly.
Critical journeys reviewed: registration, login/recovery, onboarding, dashboard, jobs, Career Profile, CV import/edit/export, emails, notifications, privacy/security, payments/pricing where applicable, admin errors.
Native/proficient reviewer signs off user-facing language (especially legal, billing, security and CV wording) via externally controlled approval; proper product-specific glossary. AI drafts are not automatically approved.
Font/script coverage, accents/diacritics, long labels, plural cases, dates/currency, keyboard/screen-reader labels and PDF exports tested; automated snapshots and realistic E2E pass.
Website country/locale availability and provider/job-ad languages accurately represented. SEO alternates only for actually published translated pages.
Approved and deployed language explicitly distinguished from staged/dev language. Partial locales hidden from public language picker, while en fallback remains available.

Deliverables and location

Produce docs/i18n/ with audit, coverage matrix, terminology, locale registry, message inventory, translation process, screenshots, backend contracts, CV/PDF fidelity, job-discovery contract, marketing/SEO agreement, native sign-off, test results, blocker register, final acceptance. Produce machine-readable LOCALE_CATALOG.json and LOCALE_SCHEMA.json with statuses per surface, validated independently. Reuse existing authoritative documentation rather than creating incompatible duplicates.

Gating and autonomy

GJ-00 planning is reported complete locally at 0ec9f98, with Git publication previously blocked. Pre-Phase-10 acceptance reported 5032ccb; do not assume remote push or Phase 10 approval. I18N implementation is part of the post-Phase-10 and product-review roadmap; inspect and obey the current accepted gates. Current permission, if those stages are not approved: research/planning only. Do not run stages 01–08 without documented owner authorisation and their entry prerequisites.

For every stage follow its individual prompt and the common execution/evidence rules. Stop for missing material consent, commercial translation services, legal review, native approval or release/publication decisions. Work autonomously on other independent authorised safe tasks.

Final master instruction

Build and qualify European-wide localisation as a scalable capability. Follow files 01_I18N_00_* through 09_I18N_08_* in order, without skipping explicit gates. Do not promise full European language coverage merely because locale files exist. Commit/push validated non-production checkpoints, preserve evidence, request human review where required, and never merge to main or deploy automatically.

9.7 KiB Raw Blame History Unescape Escape