After reading the current code, this should not create a new i18n system. runtime/i18n already has typed catalogs, bundles, completeness checks, templates, formatting, plural, date, and number helpers. Diagnostics already have a centralized public code registry. runtime/api already has structured API error codes.
The remaining gap is integration: generated/runtime user-facing errors still mostly carry plain messages. Please add a narrow bridge from stable error code plus default message plus variables to the existing i18n catalog model, then use it for generated validation, action/API, auth/guard, and fragment error responses.
Acceptance:
- Reuse
runtime/i18n instead of inventing a second catalog system.
- Keep compiler diagnostics separate unless a user-facing runtime response explicitly needs one.
- Validation errors, expected handler errors, and generated JSON errors can expose a stable code and localized message.
- Examples avoid hard-coded translated error strings in Go handlers; Go returns codes/data and GOWDK-owned rendering uses the catalog.
After reading the current code, this should not create a new i18n system.
runtime/i18nalready has typed catalogs, bundles, completeness checks, templates, formatting, plural, date, and number helpers. Diagnostics already have a centralized public code registry.runtime/apialready has structured API error codes.The remaining gap is integration: generated/runtime user-facing errors still mostly carry plain messages. Please add a narrow bridge from stable error code plus default message plus variables to the existing i18n catalog model, then use it for generated validation, action/API, auth/guard, and fragment error responses.
Acceptance:
runtime/i18ninstead of inventing a second catalog system.