v1.7.0
Added
-
SPA chrome i18n message catalog (#630). The SPA's own user-visible strings ("Add", "Save", "Search", "Loading…", "Choose all", etc.) now flow through a message catalog hydrated at boot from the request's active locale.
- Server:
SpaIndexViewresolvestranslation.get_language()and renders<meta name="dar-language">. - SPA:
main.tsxreads the meta and callsloadCatalog(language)BEFORE the React root mounts — first paint already carries translated strings. - Component use:
import { t } from '@dar/ui'; <Button>{t('Save')}</Button>. Source-as-key (gettext convention): missing entry → returns the English source. Refactoring a JSX string doesn't require parallel catalog edits.
Catalogs shipped: English (placeholder; round-trips via source-as-key), Spanish, Portuguese (matches
pt-brvia stem fallback), French — each with ~40 high-visibility chrome strings. Adding a new language: drop a JSON file underpackages/ui/src/i18n/, import ini18n.ts, ship.Coverage proof-of-life: the shuttle widget from #627 (
@dar/form/ShuttleSelect.tsx) wraps its strings int(…). Remaining JSX strings stay English until reached — each migration is independent. - Server:
Closes the i18n chain
Together with the 1.6.0 LocaleMiddleware documentation, this completes the i18n story end-to-end: a consumer running Django with LANGUAGE_CODE = "es" + LocaleMiddleware sees translated verbose_name / help_text (via the API) AND translated SPA chrome (via this catalog).
Verification
- 14 new vitests in
i18n.test.ts - 3 new pytests in
test_active_language.py pnpm test— 216 / 216 ✓ (up from 202)poetry run pytest -q— 64 / 64 ✓ on Django 4.2.30 (up from 61)