fix(i18n): localize invite, magic-link, and recovery emails#1944
fix(i18n): localize invite, magic-link, and recovery emails#1944swissky wants to merge 2 commits into
Conversation
🦋 Changeset detectedLatest commit: 8f009d6 The changes in this PR will be included in the next version bump. This PR includes changesets to release 16 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
github-actions
Bot
added
review/needs-review
@emdash-cms/admin
@emdash-cms/auth
@emdash-cms/auth-atproto
@emdash-cms/blocks
@emdash-cms/cloudflare
@emdash-cms/contentful-to-portable-text
emdash
create-emdash
@emdash-cms/gutenberg-to-portable-text
@emdash-cms/plugin-cli
@emdash-cms/plugin-types
@emdash-cms/registry-client
@emdash-cms/registry-lexicons
@emdash-cms/sandbox-workerd
@emdash-cms/x402
@emdash-cms/plugin-ai-moderation
@emdash-cms/plugin-atproto
@emdash-cms/plugin-audit-log
@emdash-cms/plugin-color
@emdash-cms/plugin-embeds
@emdash-cms/plugin-field-kit
@emdash-cms/plugin-forms
@emdash-cms/plugin-webhook-notifier
commit: |
![emdashbot[bot]](https://avatars.githubusercontent.com/in/3255304?s=60&v=4){kind=small}
There was a problem hiding this comment.
The approach is sound: keep the auth package i18n-free by injecting final display strings, let the admin package own Lingui catalog resolution, and have EmDash core pick the locale from the site option or the requesting user's admin language. That separation matches the architecture and keeps the auth package backwards-compatible.
I checked the new/updated files, the export wiring between @emdash-cms/auth, @emdash-cms/admin, and emdash, the HTML-escaping changes in the email builders, the test files, and the changeset. The code is clean and the builders correctly fall back to English when no localized strings are passed.
One gap: the newly-added emdash core helper getEmailLocale implements the locale priority logic, but there is no unit or integration test in packages/core to exercise it. The existing tests cover the auth builders and the admin catalog resolution separately, but they do not prove that the site emdash:locale option wins over the request locale, or that the routes actually wire localized strings through. Per AGENTS.md's TDD convention, a bug fix should include a reproducing test for the new logic.
| export async function getEmailLocale(db: Kysely<Database>, request: Request): Promise<string> { | ||
| const options = new OptionsRepository(db); | ||
| const siteLocale = await options.get<string>("emdash:locale"); | ||
| // loadMessages falls back to English for unsupported codes, so a | ||
| // free-form option value degrades safely. | ||
| if (typeof siteLocale === "string" && siteLocale) return siteLocale; | ||
| return resolveLocale(request); | ||
| } |
There was a problem hiding this comment.
[needs fixing] This helper implements the locale-priority decision (site emdash:locale → request cookie/Accept-Language → English), but there is no test for it in packages/core/tests. The PR tests the auth builders and the admin catalog resolution in isolation, so the priority logic and route-level wiring are unverified. Add a unit test that stubs OptionsRepository and checks the fallback chain, or an integration test that sends an invite with a non-English site locale and asserts the email subject is localized.
| export async function getEmailLocale(db: Kysely<Database>, request: Request): Promise<string> { | |
| const options = new OptionsRepository(db); | |
| const siteLocale = await options.get<string>("emdash:locale"); | |
| // loadMessages falls back to English for unsupported codes, so a | |
| // free-form option value degrades safely. | |
| if (typeof siteLocale === "string" && siteLocale) return siteLocale; | |
| return resolveLocale(request); | |
| } | |
| export async function getEmailLocale(db: Kysely<Database>, request: Request): Promise<string> { | |
| const options = new OptionsRepository(db); | |
| const siteLocale = await options.get<string>("emdash:locale"); | |
| if (typeof siteLocale === "string" && siteLocale) return siteLocale; | |
| return resolveLocale(request); | |
| } |
There was a problem hiding this comment.
Added in 8f009d6 — tests/unit/api/email-locale.test.ts covers the full chain against a real test DB: site emdash:locale wins over cookie and Accept-Language, cookie wins when no site locale is set, Accept-Language matching (including region tags like es-ES), unsupported cookie values falling through, and the English default with no signals.
github-actions
Bot
added
review/awaiting-author
Review follow-up: unit-tests the site-locale -> cookie -> Accept-Language -> English fallback against a real test database.
github-actions
Bot
added
size/XL
review/needs-rereview
1 participant
What does this PR do?
System emails (user invites, magic-link sign-in, admin-initiated account recovery) were always sent in hardcoded English, bypassing the locale system entirely. On a site configured for German/Japanese/Arabic, invitees received English emails.
This PR routes the email copy through the admin's Lingui catalogs:
@emdash-cms/auth:buildInviteEmail()and the newbuildMagicLinkEmail()accept an optional strings object (InviteEmailStrings/MagicLinkEmailStrings) and fall back to the existing English copy — the auth package stays i18n-free and fully backwards compatible.@emdash-cms/admin: new server-side helpersgetInviteEmailStrings(locale, siteName)/getMagicLinkEmailStrings(locale, siteName)resolve the copy from the existing Lingui catalogs via module-scopemsgdescriptors (picked up bylocale:extracton merge).emdashcore: the invite, magic-link-send, and send-recovery routes resolve the email locale — site-wideemdash:localeoption first, then the requesting user's admin locale (cookie /Accept-Language), then English — and pass the localized strings through. Same trade-off WordPress makes: the recipient's language is unknowable, so the site's language is the best signal.Localized strings are HTML-escaped in the HTML email body like the site name already was.
Closes #915
Type of change
Checklist
pnpm typecheckpassespnpm lintpassespnpm testpasses (or targeted tests for my change)pnpm formathas been runmessages.pochanges except in translation PRs — a workflow extracts catalogs on merge tomain.AI-generated code disclosure
Screenshots / test output
New tests:
packages/auth/src/email-templates.test.ts(builder defaults, injected copy, HTML escaping — 6 tests) andpackages/admin/tests/locales/emails.test.ts(catalog resolution, site-name interpolation, unknown-locale fallback — 4 tests). All pass locally alongside the existing invite/magic-link suites.