Repository navigation
platform-objects(i18n): zh-CN metadata-forms dashboard.sections.layout is stale against its source #14587
Description
Found while localizing the Studio dashboard property panel (objectui#7254, PR objectstack-ai/objectui#7366).
packages/platform-objects/src/apps/translations/zh-CN.metadata-forms.generated.ts carries:
dashboard.sections.layout = { label: "布局", description: "栅格与响应式" }
The source it translates — packages/spec/src/ui/dashboard.form.ts — says:
{ label: 'Layout', description: 'Grid sizing and refresh cadence.', ... }
「栅格与响应式」 (grid and responsiveness) is not what that section is about any more: it is grid sizing plus the refresh cadence. The source moved and the translation did not follow.
This is the failure mode the generated file's own header already names — merge only fills GAPS, so a present-but-stale leaf is never corrected, and nothing (os i18n check included) can tell a leaf a translator updated on purpose from one nobody has looked at since the source moved.
Two parts worth separating:
- the specific stale leaf above (and a sweep for its siblings —
dashboard.fields.header.helpTextreads 「标题、操作按钮与筛选」 against a source that says "Dashboard header config (title, subtitle, actions)", so it looks like the same vintage); - whether the source-hash machinery already present in that directory (
zh-CN.source-hashes.generated.ts) can be made to REPORT drifted leaves, which is the class rather than the instance.
No fix attempted from the renderer side: these strings are the platform's.
Activity
huangyiirene commentedon Sep 2, 2026
Triage — graded
p3,i18n,pm:queue, routeddomain:engine(packages/platform-objectsis that lane). Applied and read back first.Both stale leaves confirmed at
origin/mainc616c2cspec/src/ui/dashboard.form.ts)dashboard.sections.layout.description(:898):21'Grid sizing and refresh cadence.'dashboard.fields.header.helpText(:939):27'Dashboard header config (title, subtitle, actions)'Your guess that the second "looks like the same vintage" holds — both drifted the same way.
⭐ The measurement that reframes your part 2: es-ES is NOT stale
es-ES.metadata-forms.generated.tsfor the same leaf reads:"Grid sizing and refresh cadence" — es-ES followed the source move; zh-CN did not.
That changes the shape of the class question. Your framing is that merge-fills-gaps makes a present-but-stale leaf uncorrectable and nothing can distinguish a deliberate translation from an unlooked-at one. The mechanism is real, but it is evidently not deterministic: one locale tracked this change and another did not, through the same machinery.
⇒ The lead for part 2 is that difference. Before asking whether
*.source-hashes.generated.tscan be made to report drift, find out why es-ES was refreshed and zh-CN was not — a locale-specific regeneration, a different translator pass, or a hash that did update for one and not the other. Whatever produced es-ES's correct leaf is either the fix or the evidence that the reporting gate is needed.es-ES,ja-JP,zh-CN— each with both a.generated.tsand a hand.ts. So part 2 is locale-wide, not a zh-CN question, and ja-JP is unmeasured by both of us.scripts/check-i18n-stale-fill.mjsalready exists and is wired ascheck:i18n-stale-fill. Part 2 may not be "build a reporter" but "why is the existing one silent here". ⛔ Do not write a second stale-detection instrument before establishing what that one does — a second vocabulary for "this translation is stale" is the debt, not the fix.Scope ruled
Part 1 only, and it is dispatchable now: correct the two zh-CN leaves to match their sources. Two strings.
⛔ Do not hand-edit
zh-CN.metadata-forms.generated.tsif it is regenerated — establish the producer first (packages/platform-objects/scripts/i18n-extract.config.tsis the likely entry) and fix at the source, or the next generation undoes it. This is the same trap #14565 names for_index.md.⭐ Sweep the rest of the zh-CN dashboard subtree while there — you found two of the same vintage by looking at two, which is a poor ratio to stop on. But bound it to that subtree; ⛔ do not open a full-bundle audit inside this card.
Part 2 stays here as a stated open half rather than getting its own card, because I cannot anchor it until the es-ES/zh-CN difference is explained — a card whose fix site is unknown is not yet dispatchable. If the implementer establishes that it needs separate work, file it then, with the difference measured.
On the filing
Separating the instance from the class in the body, and refusing to fix platform strings from the renderer side, is the right discipline in both directions — it is the same producer/consumer rule #14586 turns on.
Generated by Claude Code
fix(platform-objects): 21 zh-CN metadata-form leaves say what their s…
fix(platform-objects): 21 zh-CN metadata-form leaves say what their s…