finding: a no-locale sendTemplate resolves the en-US row but renders format filters under the runtime locale — renderOpts.locale stays unset

[huangyiirene]

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

• email-template-render (b): sendTemplate with no locale renders an arbitrary locale instead of the en-US default #7731 / PR fix(plugin-email): a no-locale sendTemplate renders the en-US default, not an arbitrary row (#7731) #7787 (where it surfaced; see "Notes for the reviewer")
• Filed unassigned by the services seat (recording, not claiming) per the filing discipline.

[os-zhuang]

Triage: finding + domain:services.

• Classification: observation-class per the filer's own framing — no user report, current behaviour defensible, and the open half is a small product-semantics question (which locale drives format filters: the resolved row's or the runtime's). Held, not queued; the findings-triage channel grades it. If the semantics get ruled, the fix is one line plus pins and promotes cleanly.
• Routing anchor (verified on origin/main @ 098b629): packages/plugins/plugin-email/src/email-service.ts:1152 — ...(input.locale ? { locale: input.locale } : {}) — renderOpts.locale indeed stays unset when the caller names none, while the row-resolution ladder above it (:1121–1127) resolves a concrete row. plugin-email ⇒ domain:services.
• Dedup: the parent fix email-template-render (b): sendTemplate with no locale renders an arbitrary locale instead of the en-US default #7731 (PR fix(plugin-email): a no-locale sendTemplate renders the en-US default, not an arbitrary row (#7731) #7787) is in flight and deliberately excludes this; no other card covers renderOpts locale threading. Distinct from GET /meta/email_template can collapse an i18n bundle back to one row — the list merge dedups by (package, name), no locale #7774 (list-merge dedup by locale) — different surface.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code

[hotlong]

Findings-round escalation: needs-user-decision (domain:services, type Bug). The prior triage already said "if the semantics get ruled, the fix is one line plus pins and promotes cleanly" — this is that ruling request; holding longer only re-defers a cheap binary.

Premise (re-checked, with re-check command)

git grep -n "input.locale ? { locale: input.locale }" origin/main -- packages/plugins/plugin-email → email-service.ts:1185: when the caller names no locale, the template row resolves to en-US but renderOpts.locale stays unset, so format filters (dates, numbers, currency) render under the runtime locale inside an en-US template.

Question

When a no-locale sendTemplate resolves a template row, should format filters render under (A) the resolved template row's locale, or (B) the runtime locale (status quo)?

Recommendation: A — bind renderOpts.locale to the resolved row's locale.

• Platform long-term coherence: A makes the template row the single locale authority — one artefact, one locale, no split-brain output. B keeps two independent locale sources in one rendered message.
• Measured business pull: one measured mixed-locale render path (this card); no user report yet — which is why this is a cheap confirm, not an incident.
• AI-agent error-resistance: deterministic, artefact-bound locale beats ambient-dependent output an AI author cannot predict from the template alone.
• Startup scope discipline: A is a one-line fix plus pins once ruled; no new surface either way.

Veto/confirm is sufficient; on A, the services seat dispatches directly.

本评论来自分诊座位（scheduled session session_01DLzE5XVRASxFotEU1h9cjH），不构成认领。

---

Generated by Claude Code

[hotlong]

Maintainer ruling recorded — Option A adopted. Provenance: maintainer, 2026-08-12 (live, in the PM session that ran this findings round), replying to the round report that tabled this card's four-lens recommendation: 「同意你的决策」. The recommendation adopted is the one in this round's escalation comment above.

Binding ruling: a no-locale sendTemplate binds renderOpts.locale to the resolved template row's locale — the template row is the single locale authority; mixed-locale rendering (en-US template + runtime-locale format filters) is a defect, not a feature.

Dispatch constraints (services seat): one-line fix at the email-service.ts seam (locate by symbol — line anchor drifted to ~:1185) + pins asserting: (a) no-locale call rendering a resolved en-US row formats dates/numbers under en-US; (b) an explicit input.locale still wins. needs-user-decision → pm:queue swapped in the same write as this record.

本评论来自分诊座位（scheduled session session_01DLzE5XVRASxFotEU1h9cjH），不构成认领。

---

Generated by Claude Code