4.9 KiB
I18N-05 — Multilingual Cross-Industry Job Discovery and Occupation Search
Objective
Provide language-aware international job discovery in partnership with INT-GLOBAL-JOBS-01. All occupations, not just tech. This stage handles language semantics and contracts; do not rebuild provider integrations already delivered by GJ-01–08.
Tasks
- Inspect accepted Global Jobs architecture, GJ-00 provider rights and GJ-01 country preferences. If GJ runtime not yet accepted, implement/test locale interfaces and synthetic provider fixtures, and mark live integration deferred rather than claiming release.
- Use authoritative occupation taxonomies (e.g. ESCO where permitted) to build multilingual occupation label/alias search, keyword autocomplete and exact-vs-related occupation selection. Test teachers, chefs, healthcare, retail, cleaning, manufacturing, logistics, finance, trades, office and software jobs. Don't infer professional licensure from a matching title.
- Distinguish user search text language, occupation concept ID, original ad language, optional translated summary language and UI locale. A query
teachershould be able to match approved related titles in the chosen target market only where the provider offers the data and matching has evidence. Show suggested aliases rather than silently broadening exact searches. - Language filters must support multiple ad languages independent of interface locale. Expose original description first; label source vs translated text, timestamp, incomplete details and provider-specific display restrictions. No scraping of FINN/Indeed/restricted providers; obey rights/retention/update/deletion.
- Locale-aware location names: preserve stable country/region/town IDs and display appropriate localized names/aliases without corrupting hierarchical Warwickshire→Warwick selection or Norway Vestfold/Bergen cases. Do not use translated free text as geolocation identity.
- Normalise metadata such as employment type, shifts, part-time, contract, salary/currency display, dates, seniority and qualifications without inventing missing fields. Job matching must distinguish evidence, inferred candidate suggestions and unverified requirements.
- Cross-language search tests across Norway, Sweden and UK initially, expandable to Europe. Ensure no profession is structurally excluded; demonstrate title ambiguity and multilingual names, regional variants, diacritics and provider language limitations.
Checkpoints
I18N-05A provider/ESCO contracts; 05B multilingual aliases/autocomplete; 05C ad language/detail presentation; 05D locale-aware geography and filters; 05E relevance and rights regression.
Deliverables
docs/i18n/05/OCCUPATION_LANGUAGE_MAP.md, SOURCE_RIGHTS_AND_LANGUAGES.md, SEARCH_LANGUAGE_SEMANTICS.md, GEO_DISPLAY_RULES.md, CROSS_INDUSTRY_TESTS.md.
Acceptance
Source rights respected, no invented full descriptions, no job filtering based on UI locale, region IDs stable, and all-sector synthetic corpus passes. Country-specific sources remain accurately gated.
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
maincontains 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.