i18n: a source-string edit still leaves zh-CN / ja-JP / es-ES silently stale — and pinning `en` to the source makes the asymmetry sharper, not smaller (needs a maintainer decision)

[hotlong]

The half of #8721 its triage comment deliberately excluded, filed separately as that comment instructed ("If the work convinces you it is needed, file it separately and link back"). This one needs a product decision before any code, which is why it was kept out of that PR. Filed unassigned.

The gap

For the hand-authored apps / dashboards / pages bundles in packages/platform-objects/src/apps/translations/, nothing anywhere compares a translated locale against the source string it was translated from. Every gate over that half judges presence or ownership:

• app-nav-translation-parity.test.ts — a translation exists for every declared id, and none outlives its declaration. Key-set claims; a stale value satisfies both.
• pnpm check:i18n-coverage — ratchets untranslated labels. A translated-but-wrong label counts as covered.
• pnpm check:app-nav-i18n — judges the merged nav tree, again for presence of a label per locale.

So when a source string changes, three bundles keep serving the previous translation under a fully green build. That is exactly how widget_recent_events shipped its pre-conversion title in all four locales.

Why implementing #8721 makes this more pressing, not less

#8721 pins en.ts to the declared source verbatim, because en is a copy rather than a translation. That is strictly good on its own, and it changes the shape of the remaining exposure in a way worth stating plainly:

• Before: a source edit left all four bundles stale together. Wrong everywhere, but uniformly, and an English-speaking reviewer looking at the running app could see it.
• After: the same edit fails the build until en.ts is corrected, so en is right and zh-CN / ja-JP / es-ES are wrong. The drift becomes locale-specific and invisible to every reviewer who reads the product in English — which is every reviewer this repo has.

The gate does not create the drift; it removes the one accidental symptom that used to make it visible.

The decision this needs

What should a translated locale do when its source string changes underneath it? The three options are real and they are not interchangeable:

• A. Serve the stale translation (today's behavior, made explicit). Zero build friction; ships wrong text indefinitely; the failure is silent and locale-specific.
• B. Fall back to the source string when the translation is known-stale. Never wrong, sometimes English in a Chinese UI — the same degradation an untranslated key already produces, so it introduces no new failure mode. Needs a staleness signal to exist: a recorded source-hash per translated leaf, or equivalent.
• C. Fail the build until every locale is re-translated. Strongest guarantee, and it puts a four-locale translation task in front of every single-word source edit — including edits by agents who cannot judge the three target languages.

B and C both need the same missing machinery (a per-leaf record of which source string a translation was made from). A needs nothing and is what happens if this card is closed unfixed.

My reading, offered as input rather than a recommendation to adopt: B, gated by a recorded source hash, because it is the only option whose failure mode is a degradation the product already has a shape for, and because C's cost lands on exactly the contributors least able to pay it. But this is a product call about what users in non-English locales should see, and it should be the maintainer's.

Related: #8543 (the analogous hole on the generated side, which cannot occur there because en is rewritten every extract). Backlink: #8721.

[hotlong]

Triage — first grading (finding → decision box).

Verdict: needs-user-decision, domain:metadata kept, type Feature.

Why triage does not rule this one

The delegation gate requires all four facets pointing the same way; they do not (below). It also fails the mechanical boundary test independently: B and C both add machinery that does not exist today (a per-leaf record of which source string a translation was made from), and B changes what a user in a non-English locale is served. That is new capability, not a declared = enforced restoration — Feature, which sits on the manual floor whatever the confidence.

Four-facet card face

① Platform long-term coherence — today's behavior (A) is unstated rather than chosen, so making it explicit is coherent under any option. But B and C both add a permanent second artifact per translated leaf (the source hash) that must stay correct forever. Narrowing on one axis, growing on another.

② Measured business pull — zero measured, and the measurement is cheap and untaken. Nobody has counted how many translated leaves in the three bundles are out of parity with their sources right now. One historical instance is known (#8721's widget) and the work that produced this card is already correcting it.

③ AI-agent error-resistance — the facet that argues for acting, and the card's sharpest observation: once #8721 pins en to the source, drift stops being uniform and becomes locale-specific — invisible to every reviewer who reads the product in English, which is every reviewer this repo has. An agent editing one source string gets no signal that three bundles just went stale.

④ Startup scope discipline — C puts a four-locale translation task in front of every one-word source edit, landing on exactly the contributors (agents included) least able to judge the three target languages. B is cheaper but is still declare-and-maintain. A is remove: costs nothing, ships wrong text indefinitely.

③ pulls toward B/C; ② and ④ pull toward A/defer. Split ⇒ escalate.

What would most cheaply settle it

The direction is probably better picked by a measurement than in the abstract: survey the three bundles and count the translated leaves currently out of parity with their sources. One-off script, no new machinery, commits to no option.

• Count is zero and stays zero ⇒ A plus a named restart condition is defensible on ② and ④.
• Count is not zero ⇒ ③ has measured pull behind it and B stops being speculative.

Recorded as input to the ruling, not as a precondition for one — the card is in the box either way.

---

Generated by Claude Code

[os-zhuang]

Maintainer ruling (delegated adjudication; delegation 2026-08-15 verbatim 「决策你直接帮我做」, batch confirmed 「同意」)

Ruled: Option B — record the source hash at translation time; a hash mismatch marks the translation stale, and stale falls back to the source text.

Rationale (four-prism):

1. Platform coherence — the product already has a shape for "no usable translation": fall back to source. B classifies stale as equivalent-to-missing rather than inventing a third state.
2. Business pull — Option A (keep serving the stale translation) hands users information that is now wrong, the most expensive failure. Option C (fail the build) turns translation lag into a release blocker — worst possible tax on shipping cadence at this stage.
3. AI error-resistance — the source hash is a machine-decidable staleness criterion. An agent editing source copy does not need to remember to touch three translation files: staleness degrades automatically, and an updated translation (with the new hash) restores itself automatically.
4. Startup scope — no new pipeline, no new blocking gate; one recorded hash and one comparison.

Implementation notes for the dispatching seat:

• The hash is of the source string the translation was made from, recorded alongside the translation.
• Missing hash on an existing translation should be treated as legacy-trusted at migration time (one-time backfill from current source), not as stale — otherwise every existing translation degrades on day one.
• Pin: edit source → stale translations fall back to source; update one translation → that locale alone recovers.

Label flipped needs-user-decision → pm:queue. Not dispatched from the spec seat (dispatch freeze in force); any lane's seat may pick this up.

---

Generated by Claude Code