The base dispatchNotification is locale-agnostic by design: it
forwards title and message to every sender verbatim. Several
call-sites (admin alerts, deploy webhook, Telegram test routes,
reminder-check) compose bodies in English without consulting
User.locale, leaving recipients with mismatched copy.
Introduce dispatchLocalisedNotification next to the base dispatcher.
The helper resolves the recipient's User.locale (falls back to the
project default when missing, unsupported, or unreadable), calls
getServerTranslator(locale).t on both the title and message keys
with optional params, and delegates to dispatchNotification with the
composed strings. Missing translation keys fall back to the raw key
and log a wide-event warning so ops can spot bundle drift.
Locale resolution is intentionally restricted to the persisted
User.locale column. The helper runs from background jobs and webhook
handlers where the request context may not belong to the recipient
(an admin alert resolves the admin's locale, not the affected user's),
so cookies and Accept-Language are out of scope.
Forward-compat scaffolding: an optional channel selector
('telegram' | 'email') is accepted and forwarded as
metadata.preferredChannel so call-sites can declare intent today;
the dispatcher continues to fan across every enabled channel until a
follow-up wires routing.
Tests:
- notifications/__tests__/admin-locale.test.ts drives the helper
through de / fr / null / unsupported / missing-row locale paths,
the missing-translation-key fallback, the event-type and metadata
pass-through, and a Prisma-throws path that must not propagate.
Bundle keys referenced by this commit (B6 will land the JSON edits):
- notifications.admin.*
- notifications.user.*
Marc-André Bombeck