GJ-01 — Country Preferences, Multilingual UI and Search Defaults

Suggested branch: feature/gj01-country-language-preferences

Objective

Give every user an easy first-run and Settings experience that saves where they live, where they want to work, what roles they seek and in which languages. Automatically prefill job discovery from persisted preferences without locking the search page to a single country.

Implement

Audit auth/onboarding/Settings, localization and existing preference persistence. Add migration-safe per-user search preferences using established MariaDB and revision semantics; retain backwards compatibility.
Model country of residence separately from nationality/home country, desired work countries (0..N), preferred regions/places (0..N), advertised-job languages (0..N), interface locale (single), each CV/cover letter's language (document-specific), occupations/skills, work arrangements and saved profiles. Defaults should be understandable and editable; no forced demographic collection.
Provide country selector with ISO country identifiers, display names localized where supported, searchable options, multi-select for job-search countries, optional city/region suggestions and clear default/override semantics. A user can live in Norway and search Sweden + UK.
Language menu: show English and official/local language(s) relevant to residence/selected region at the top, rendered as native label + English label (e.g. Norsk bokmål — Norwegian Bokmål, Svenska — Swedish, Deutsch — German). Account for multilingual countries, region-specific Welsh in Wales, Bokmål vs Nynorsk in Norway, and user-chosen overrides. Do NOT equate ESCO translations with complete Jobjakt UI support. Unsupported UI locales may appear under Coming Later, not as functional toggles.
Use BCP 47 language tags and explicit fallback rules (e.g. en-GB, nb-NO, nn-NO, sv-SE; verify support). Keep UI locale independent of ad-language filtering and document language. Persist across sessions/devices; initial suggestion may use browser locale but never lock it.
Localise all new Settings, onboarding, search-preference controls, validation, empty/error/help text in the actually approved interface languages; avoid machine-translated legal/professional terminology without review. Provide translation completeness report and automated missing-key checks.
Search page loads saved defaults; user can override for one query, save overrides to a named search profile, or explicitly Update defaults. Never silently overwrite permanent settings from temporary filter changes.

Acceptance examples

Norwegian-resident user, English UI, Norwegian + English ad languages, searches both Norway and UK.
Swedish-resident user with Swedish UI and English ad results; switch UI English without changing query language.
Welsh user sees Welsh and English prominently if Welsh UI is supported; non-Wales UK user isn't forced into Welsh.
Reopen account on another device and recover default countries, occupations, languages and regions.
Empty preference fallback: usable search with explicit country-choice invitation rather than empty broken state.
Tenant isolation, concurrent editing, revision conflict, account deletion/data export, migration and reset.

Checkpoints

GJ01-A schema/compatibility, GJ01-B onboarding/Settings, GJ01-C selector/localisation, GJ01-D search defaults/overrides, GJ01-E full regression and handoff. Commit/push validated checkpoints.

Deliverables

docs/global-jobs/01/ for preference schema, screen states, local-language mapping, supported-vs-planned locales, localisation checks, permissions, regressions and acceptance. End with GO/CONDITIONAL GO/NO-GO and GJ-02 readiness; stop.

Shared rules for every INT-GLOBAL-JOBS-01 stage

Product: Jobjakt, a general-purpose, commercial job-search and career-management SaaS. It is not an IT-only product. Current architecture includes React/TypeScript, .NET backend, MariaDB, an AI sidecar, existing Career Profile/CV/document/application features, and an established EN/NO localisation approach. Verify actual repository reality before making assumptions.
Entry gates: Do not implement new global-job-discovery features until the authoritative Phase 10 and product-review/development-entry decisions permit this initiative. Planning-only reconnaissance may precede them. If an entry gate remains NO-GO, produce safe analysis and stop before code changes.
Baseline: Find the latest accepted, integration-complete development commit by reading Git history and the latest authoritative acceptance reports. Do not assume main is current. main deploys production: NEVER merge to main or trigger production. Never change live MariaDB, Docker, Ollama, storage, secrets or other production services.
Branches: Use the specified independent stage branch from the latest accepted development integration history including the preceding accepted stage. Verify ancestry, remote, clean tree and existing branch collisions. Use checkpoint commits; push each validated checkpoint; verify remote HEAD equals local HEAD. Do not force-push. Do not advance to another stage without its actual entry criteria.
Autonomy: Investigate, design, implement, add tests, document, commit and push safe work without pausing for routine decisions. Stop only for external API agreements, new paid resources, security-risk acceptance, destructive changes, privileged infrastructure actions and production operations. Continue independent work when one provider or model capability is blocked.
Sources: Integrate only documented, authorised sources. Verify current licensing, commercial eligibility, credentials, permitted display, storage, cache lifetime, update/delete/tombstone, attribution, user-click-through and rate-limit rules. No covert scraping, private APIs, stolen cookies, bypassing anti-bot controls or fetching protected listing content without authorisation. An external-link-only source is not a direct searchable provider.
Data trust: All provider data, job descriptions and user-provided URLs are untrusted. Guard SSRF, XSS/unsafe HTML, prompt injection, HTML injection, unsafe redirects, credential leakage, denial of service and cross-user/tenant access. Do not present missing facts, inferred salaries, regulated-profession eligibility, or AI-generated job details as verified employer facts.
Availability: Preserve offline/disabled provider states. Use realistic fixtures in automated tests; any live contract test needs authorised test credentials and bounded rates. Never claim unavailable external API functionality passed.
User-facing quality: Desktop/tablet/phone, keyboard and screen-reader access, light/dark, EN/Bokmål plus future qualified locales, loading/empty/error states, responsive design, sensible defaults, performance, source transparency, internationalisation and accessible non-drag alternatives.
Data integrity: Source advertisements and user-owned saved jobs/applications are separate records and lifecycles. Preserve existing Career Profile, historical CVs, cover letters, saved applications, revisions, RD21 protections and MariaDB compatibility. Follow source rules for removing or masking withdrawn advertisements, while handling user-owned records under a separately justified retention policy.
AI: Existing live-model inference and semantic quality must remain gated unless separately qualified. Rule-based/ESCO-backed title suggestions and auditable matching should function without a generative model. Do not invent user qualifications or automate application submissions.
Evidence: At every checkpoint provide exact tests (pass/fail/skip/not run), security/coverage evidence, dated docs, commit hashes, branch and remote verification. Report individual stage GO / CONDITIONAL GO / NO-GO; separate production NO-GO from development readiness.

7.8 KiB Raw Blame History