Files
jobtrackingapp/automation/prompts/I18N/03_I18N_02_FRONTEND_UI.md
T

4.4 KiB

I18N-02 — Comprehensive React UI and Accessibility Localisation

Objective

Remove hardcoded user-facing strings and achieve total namespace coverage of the accepted React application, including new CV, Dashboard and Admin interfaces. Do not infer translation completeness from number of files.

Tasks

  1. Inventory all routes and components at the current commit: sign-in/recovery, registration/onboarding, dashboard, jobs/Kanban/details, Career Profile, CV templates/builder/editor/undo-redo, CV import/review, letters, analytics, settings, subscription, admin processing monitor, help, and errors/empty/loading states. Translate visible chrome and accessible text, not user-entered data.
  2. Extract to stable, contextual message IDs, with descriptions for translators. Preserve ICU plural/select, variable type contracts and punctuation. No concatenated partial sentences. Test values containing special characters; no XSS introduced by translated rich text.
  3. Add safe language switching without losing unsaved edits, changing job search settings or restarting a CV import inadvertently. Persist via I18N-01 preferences; show current option native name and English equivalent; English must remain accessible.
  4. Handle German/Finnish label expansion, accented Latin, Greek/Cyrillic, Turkish casing, RTL layout readiness (only activate RTL where an approved locale warrants it). Use CSS logical properties when sensible, preserve keyboard focus and touch targets.
  5. Introduce developer checks for untranslated hardcoded literals, missing/unused message IDs, malformed interpolations, unlocalised aria-labels, fallback gaps and dynamic notifications. Avoid blindly translating component names, employers and user records.
  6. Test language changes with dirty forms and concurrent saves; preserve RD21 and CV revisions; update visual tests with representative long strings and pseudo-locales.

Checkpoints

I18N-02A string inventory/extraction; 02B critical account/job/CV flows; 02C dashboard/admin/settings/billing surfaces; 02D accessibility/responsive/localisation smoke; 02E full frontend regression.

Deliverables

docs/i18n/02/FRONTEND_MESSAGE_COVERAGE.md, UI_SCREENSHOTS.md, ACCESSIBILITY.md, LOCALE_SWITCHING.md, TEST_RESULTS.md; linter/CI missing-key checks and pseudo-localisation harness.

Acceptance

100% of required message IDs extracted for every affected surface; existing released locales stay complete; new draft language packs cannot leak into public selector; no loss of unsaved data; accessible and responsive. No auto-publishing drafts.


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.