German is source of truth; EN/ES fully translated with no German residue. Auto-detects browser language (fallback German), persists choice, language switcher on all pages, localized formats/Clerk/legal. Scans store their language. Backend (T001-T003): language column on scans, openapi+codegen, ruleCatalogI18n, language threaded scans route -> analyzeSkill -> runStaticRule -> AI calls. Route/AI error messages localized via expanded i18n MESSAGES + reqLang(req) (?lang query -> Accept-Language header -> "de"). No German left in routes. Frontend (T004-T005): react-i18next framework, LanguageSwitcher, locale-aware format.ts, Clerk localizations. All page/component strings externalized to de/en/es locale area files across catalog, education, scan form/report/compare, history, dashboard, admin, legal pages. T006 verification + review-fix follow-up (this session): - Applied formatNumber to all visible metrics in scan-report (risk score, severity counts, security/privacy) and scan-compare (risk score, file count, diff counts); PDF/HTML export numbers formatted via Intl.NumberFormat(lng). - Fixed leftover `@workspace/n` import alias in i18n/index.ts -> real package `@workspace/api-client-react` (was failing workspace typecheck). - Verified: full `pnpm run typecheck` green; api-server tests 72/72 pass; curl confirms localized error responses (de/en/es) on scans route. Deviations: AI connection-test prompts left in German intentionally (sent to the model, not user-facing). proposeFollowUpTasks already created #52. Replit-Task-Id: 9f137230-db11-45dc-9276-4e5cbcceff03
1.2 KiB
1.2 KiB
| name | description |
|---|---|
| /api/rules localization | The static rule catalog endpoint must localize text by lang query param, not just scan findings. |
The DB rule catalog is seeded in German; runtime localization lives in localizeRule(ruleId, lang) (ruleCatalogI18n.ts). Two separate surfaces consume rules and BOTH must localize:
- Scan findings — localized inside the scan engine by the scan's stored language.
GET /api/rules— the public education/catalog section and the admin rules tab render the raw catalog. This endpoint must accept alangquery param and run each row throughlocalizeRule, else it leaks German into EN/ES UIs even when everything else is translated.
Why: UI string externalization alone is not enough — any API that returns catalog/domain text needs its own language plumbing. The "rules come from the API, already localized" assumption was false for the list endpoint (only findings were wired).
How to apply: Frontend passes { lang: currentLanguage() } to useListRules; because the calling components use useTranslation, a language switch re-renders, changes the query param, and refetches. When adding any new endpoint that returns rule/category/domain text, localize by an explicit lang param.