# I18N-03 — Backend, Email, Notifications, Jobs and Operational Messages

## Objective
Localise backend-facing user messages, communication templates and async workflows so a European-language UI does not degrade to English-only email/error flows or misinterpret locale-dependent data.

### Tasks
1. Inspect ASP.NET APIs, validation errors, typed error codes, authorization messages, scheduled background jobs, mail providers/templates, reminders, application status events, strategy generation, import processing, admin diagnostics and Python sidecar responses.
2. Prefer stable machine-readable error codes with localisation on the presenting client; localise truly server-rendered communications at source. Do not return translated unstructured errors as API contracts relied on by frontend automation.
3. Persist locale selection *at event creation* (or establish explicit current-preference policy) so queued email, reminders and background events render deterministically even if language changes later. Preserve UTC timestamps internally and localise display based on timezone/locale.
4. Translate email subject, preview, button, footer and accessible plain-text parts for account verification, password reset, application reminders, import results and relevant notifications. Validate safe escaping in HTML and text; do not accidentally translate tokens, URLs, codes, user CV content or email addresses.
5. Make plural/time/number formatting consistent across .NET, React and Python; design locale-aware error detail for admin logs while keeping immutable invariant error codes. Avoid PII in logs; don't create a multilingual free-text search dependency on logs.
6. Pricing, billing and legal messages must use approved market-specific wording and actual tax/currency entitlements; require legal/owner review. Language selection must not change payment currency or jurisdiction.
7. E2E test delivery in isolated Mailpit/test setup, queue retries, wrong/missing locale, recipient locale, cancellation, language change mid-queue, and tenant isolation.

### Checkpoints
I18N-03A backend errors/contracts; 03B email templates; 03C queued events/notification consistency; 03D billing/legal boundary and full integration tests.

### Deliverables
`docs/i18n/03/BACKEND_ERRORS.md`, `EMAIL_TEMPLATES.md`, `QUEUED_LOCALE_POLICY.md`, `BILLING_LEGAL_GATES.md`, `TEST_RESULTS.md`.

### Acceptance
Critical user communication is localised for each activated locale; all error codes remain stable; no secret/PII leakage; critical legal and billing copy remains blocked pending human approvals. Actual test results and source branch recorded.

---

### 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.