`metadataForms` translation slot has a full resolver and zero producers anywhere in the repo — the same blind spot `globalActions` had before #4015

[os-zhuang]

Closing as invalid — my central claim was wrong, and the cause was a truncated grep.

I claimed metadataForms had "zero producers anywhere in the repo". It has producers, and they are exactly where check-i18n-coverage.mjs said they were:

• packages/platform-objects/src/metadata-translations/index.ts exports MetadataFormsTranslations, a real TranslationBundle populating the slot in four locales:

  export const MetadataFormsTranslations: TranslationBundle = {
   en: { metadataForms: enMetadataForms },
   'zh-CN': { metadataForms: zhCNMetadataForms },
   'ja-JP': { metadataForms: jaJPMetadataForms },
   'es-ES': { metadataForms: esESMetadataForms },
  };

• backed by committed, hand-editable generated bundles — apps/translations/{en,zh-CN,ja-JP,es-ES}.metadata-forms.generated.ts
• re-exported from packages/platform-objects/src/index.ts
• gated by pnpm check:i18n, which fails when a committed bundle drifts from a fresh extract
• and covered by metadata-forms-vocabulary.test.ts

So the comment I called stale —

the platform metadata-form baseline is folded away (it is owned and translated by platform-objects)

— is accurate. Nothing to fix, and the "either the surface is untranslated or the slot is dead weight" dilemma I posed was a false one: neither is true.

How I got it wrong

I ran a repo-wide grep for metadataForms and piped it through head -15. grep -r walks in filesystem order, not alphabetical, so the 16 platform-objects matches fell past the cutoff and I read the truncated 15 lines — all from spec and rest — as the complete result set. The actual count is 88 matches, 16 of them in platform-objects.

A count would have been safe. A truncated listing read as exhaustive was not, and "zero producers" is precisely the kind of claim that needs the former.

I also verified this wasn't a history artifact: packages/platform-objects/src/metadata-translations/index.ts existed at the commit I swept.

What survives

#4015's finding stands. Re-running the sweep correctly (rg --pcre2, no truncation, over every authorable TranslationData slot the resolver reads):

slot	producer files
objects	113
settings	23
apps	21
dashboards / pages	13 each
messages	12
settingsCommon	4
validationMessages	3
metadataForms	2
globalActions	2

globalActions's two hits are the showcase specimen added in #4015 and packages/lint/src/validate-translation-references.ts, which validates the slot rather than producing it. So before #4015 it genuinely had no producing bundle — that claim was correct.

Why I'm not building the proposed ratchet

The "≥1 producer per authorable slot" gate I suggested would be green on arrival: every slot has producers. Its sole motivating example (globalActions) is already fixed by #4015, and the case for it in this issue rested on a finding that turned out to be my own analysis error. Shipping a CI gate justified that way is worse than not shipping it — it would carry a rationale that does not survive reading.

If a producer-side gate is still wanted on its own merits, it's a small script and worth deciding deliberately rather than as a follow-on to a retracted finding. Happy to write it if someone wants it; I'd rather not smuggle it in under this issue.

Sorry for the noise.