[audit] LANGUAGE_CODE / gettext / Accept-Language not honored — SPA UI and translated verbose_name / action descriptions stay English

[MartinCastroAlvarez]

Adoption pain point

Zero references to `gettext`, `activate`, `Accept-Language`, or `LANGUAGE_CODE` in the API package (verified). A consumer running Django with:

```python
LANGUAGE_CODE = "es-ar"
USE_I18N = True
LANGUAGES = [("es", "Español"), ("en", "English")]
MIDDLEWARE = [..., "django.middleware.locale.LocaleMiddleware", ...]

class CuentaAdmin(admin.ModelAdmin):
class Meta:
verbose_name = _("Cuenta")
verbose_name_plural = _("Cuentas")

@admin.action(description=_("Marcar como pagado"))
def mark_paid(self, request, queryset): ...

```

...sees raw English strings in the SPA: the package name, action descriptions, `help_text`, `verbose_name`, even though every other surface in the app (legacy admin, frontend, error pages) is correctly translated.

What stock Django gets

Django's `LocaleMiddleware` activates the request's locale per Accept-Language header. The HTML admin auto-translates every `gettext_lazy` string at render time. Stock behavior; zero ModelAdmin config.

Suggested fix

Two pieces, both required:

API side. Activate the request locale (`django.utils.translation.activate(get_language_from_request(request))`) before computing the JSON payload, so any `gettext_lazy` proxies in `verbose_name` / `description` / `help_text` resolve to translated strings. `LocaleMiddleware` does this for the legacy HTML admin automatically — the API package needs to either keep `LocaleMiddleware` in the stack OR explicitly activate per request.

SPA chrome side. The SPA's own strings ("Add", "Search", "Loading…", "Save and continue editing", "Confirm delete", etc.) are hard-coded English in `@dar/web`. Internationalize via a small message catalog (`@dar/i18n` package) keyed off the active locale from a new `config.language` wire field.

Filed by

Audit triage 2026-05-30. Adoption blocker for any non-English-primary shop.

[MartinCastroAlvarez]

Scoped during 1.4.13 release. Biggest of the remaining audit items — multi-day cross-repo work. Two pieces:

1. API side: activate the request locale per request. Either rely on Django's LocaleMiddleware (which IS the standard mechanism and a consumer ALREADY has it in their stack for the rest of their app) — confirm the package's payload-building runs INSIDE the middleware's locale-activation context — OR explicitly activate(get_language_from_request(request)) at the top of every view. Verify with a test that posts an Accept-Language: es-ar header and checks the JSON contains the Spanish verbose_name.

2. SPA side: the chrome strings ("Add", "Search", "Save and continue editing", "Confirm delete", "Loading…", "…") are hard-coded English in @dar/web. Need:

   • A small i18n catalog (@dar/i18n package with en.json / es.json / etc.).
   • A config.language wire field on the registry payload (the active locale from get_language()).
   • A simple t('Add') helper resolving against the catalog.

Until shipped, the README's not-carry-through table flags this as a known gap. Non-English-primary shops should keep critical paths on /admin/ for now.

[MartinCastroAlvarez]

Swarm-collision note (2026-05-31, continuing): the django-admin-api repo has an in-flight branch fix/custom-user-tests-and-n-plus-1 already version-bumped to 1.0.11 (commit 4c45066 from earlier today). i18n needs API-side locale activation (verifying LocaleMiddleware chain or adding explicit activate(get_language_from_request(request)) in every view) before the SPA chrome can rely on translated payloads. Holding cross-repo coordination until that branch lands.

[MartinCastroAlvarez]

Partial progress (2026-05-31, session continuation): the wire-side half landed in PR #648 / SPA 1.6.0 — README now has a "Translated verbose_name / help_text / action descriptions (LocaleMiddleware)" section that documents the requirement for django.middleware.locale.LocaleMiddleware in the consumer's MIDDLEWARE stack. Verified: Django's LocaleMiddleware.process_request calls translation.activate(language) before the view runs, so the API package's gettext_lazy proxies on verbose_name / help_text / @admin.action(description=…) resolve to the active language at JSON-payload-build time. No API code change needed.

Remaining scope (this issue stays open for): the SPA's OWN chrome strings — "Add", "Search", "Save and continue editing", "Confirm delete", "Loading…", "Refresh", "Layout", "Customize", "Open in new tab", etc. — are still hard-coded English in @dar/web and the package layer JSX. That's the message-catalog work that scopes to:

1. A new @dar/i18n package with en.json + es.json (etc.) catalog files.
2. A t('key', defaultText) helper.
3. A new config.language wire field on the registry payload populated from get_language() (so the SPA picks the catalog matching the request's active locale).
4. Pass over every hard-coded string in apps/web/src + packages/**/src to wrap with t(…).

Roughly a full day of focused frontend work, no cross-repo dependency. Tracked for a future dedicated session.