Observation
After #7731 (PR #7787), a sendTemplate call that names no locale reliably resolves the en-US template row — but the render pass still receives renderOpts.locale unset, so locale-sensitive format filters (e.g. {{ ts | datetime }}) format under the runtime locale, not the locale of the row being rendered. An en-US email body can carry zh-CN-formatted dates when the host runs zh-CN.
Surfaced by the #7731 dev during implementation (recorded in PR #7787's report and "Notes for the reviewer") and deliberately left untouched there: it is pre-existing behaviour, no contract speaks to it, and changing it would have been a second behaviour change riding a fix PR.
Where
packages/plugins/plugin-email/src/email-service.ts — sendTemplate resolves the row via the locale ladder but does not thread the resolved row's locale into the render options when the caller named none.
Why it is only a finding
No user report; the current behaviour is arguably defensible (format under the recipient's/runtime locale even when the template text is the en-US fallback) — deciding which locale should drive format filters (the resolved row's vs the caller's/runtime's) is a small product-semantics question, not a mechanical fix. If ruled "the resolved row's", the fix is one line plus pins.
Refs
Observation
After #7731 (PR #7787), a
sendTemplatecall that names nolocalereliably resolves the en-US template row — but the render pass still receivesrenderOpts.localeunset, so locale-sensitive format filters (e.g.{{ ts | datetime }}) format under the runtime locale, not the locale of the row being rendered. An en-US email body can carry zh-CN-formatted dates when the host runs zh-CN.Surfaced by the #7731 dev during implementation (recorded in PR #7787's report and "Notes for the reviewer") and deliberately left untouched there: it is pre-existing behaviour, no contract speaks to it, and changing it would have been a second behaviour change riding a fix PR.
Where
packages/plugins/plugin-email/src/email-service.ts—sendTemplateresolves the row via the locale ladder but does not thread the resolved row'slocaleinto the render options when the caller named none.Why it is only a finding
No user report; the current behaviour is arguably defensible (format under the recipient's/runtime locale even when the template text is the en-US fallback) — deciding which locale should drive format filters (the resolved row's vs the caller's/runtime's) is a small product-semantics question, not a mechanical fix. If ruled "the resolved row's", the fix is one line plus pins.
Refs
sendTemplaterenders the en-US default, not an arbitrary row (#7731) #7787 (where it surfaced; see "Notes for the reviewer")