Skip to content

[finding] i18n.zod.ts states "31" inline locale maps in two places; the measured count is 45 #14816

Description

@os-trump

Filed unassigned by the domain:cli seat while measuring #14749 (session session_016yfqQh2dBgPAymYd7xipza). Observation class — a stale figure in load-bearing schema prose, not a behaviour defect. Nothing here changes what parses or renders.

The drift

packages/spec/src/ui/i18n.zod.ts asserts the size of the inline-locale-map population twice, and both spellings say 31:

  • in the INLINE_LOCALE_KEY docblock — "Every inline map authored in this repo (31 of them, across three platform pages) uses en / zh-CN / ja-JP / es-ES, so the constraint costs no real authoring surface";
  • in the I18nLabelSchema docblock — "Three published platform pages author 31 of these and objectui resolves them (pickLocalized), so the map is a delivered capability".

Measured on origin/main at 5a5336b3: 45, not 31. The "three platform pages" half is still exactly right.

How it was measured

Two independent passes, agreeing:

  1. TypeScript AST. Collect every PropertyAssignment in packages/spec/src/**/*.zod.ts whose initializer roots at I18nLabelSchema (101 production declaration sites, 19 distinct prop names), then scan all 5,564 .ts/.tsx files for object literals sitting at one of those props whose keys all satisfy INLINE_LOCALE_KEY and whose values are all string literals. Authored product metadata: 45.
  2. Independent control, different tool: grep -c "'zh-CN':" over the three pages returns 33 + 6 + 6 = 45 (sys-user.page.ts, sys-organization.page.ts, sys-position.page.ts). The same pattern returns 0 on examples/app-showcase/objectstack.config.ts.

The neighbouring claim in the same sentence still holds: all 45 use exactly en / zh-CN / ja-JP / es-ES, so the constraint still costs no authoring surface — the argument is sound, only its number is stale.

Why it is worth a card rather than a silent fix

The figure is cited as evidence for a schema constraint, and it was read as authoritative during the #14749 measurement before being re-derived. A number in prose that no gate re-derives will drift again; the durable fix is probably not "write 45" but either dropping the count (the argument does not need it) or deriving it. Whoever takes this should decide which — writing 45 today buys one release of accuracy.

⚠️ When this drift began is NOT MEASURED: this checkout is shallow (736 commits, git rev-parse --is-shallow-repository = true), so the history that would date it is not present.

Not fixed in the #14749 branch on purpose — that card is a measurement unit forbidden from changing behaviour, and editing i18n.zod.ts pulls in the spec gate family and gen:schema for a prose-only change.

Context: #14749 (the measurement that found it), #5728 / #10492 / #9925 (the rulings the two docblocks record).

Generated by Claude Code

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions