skillguard/.agents/memory/rules-endpoint-localization.md
amertensreplit 2236ad179d Add DE/EN/ES multilingual support to SkillGuard (Task #49)
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
2026-06-13 09:05:57 +00:00

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:

  1. Scan findings — localized inside the scan engine by the scan's stored language.
  2. GET /api/rules — the public education/catalog section and the admin rules tab render the raw catalog. This endpoint must accept a lang query param and run each row through localizeRule, 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.