Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 26 additions & 0 deletions .changeset/i18n-inline-locale-map-population-count.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,26 @@
---
"@objectstack/spec": patch
---

`i18n.zod.ts` stops asserting a stale size for the inline-locale-map population.

Two docblocks in this file each stated that the repo authors 31 inline locale maps — the
`INLINE_LOCALE_KEY` rationale ("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") and the `I18nLabelSchema` form-2 note ("Three published platform pages
author 31 of these"). The measured population is 45: 33 in `sys-user.page.ts`, 6 in
`sys-organization.page.ts`, 6 in `sys-position.page.ts`.

The number is **dropped** at both sites rather than corrected to 45. Neither sentence's
argument needs a magnitude. The first turns on the universal — *every* authored map uses those
four tags — so the accept set is what makes the constraint free, not the size of the set. The
second turns on the map being authored on published platform pages *and* resolved by
`pickLocalized`; one authored-and-resolved map already refutes "a convention the runtime
ignores", so the count was never load-bearing there either. Writing 45 would buy one release of
accuracy in prose that is cited as evidence for a schema constraint, and the figure has already
drifted once with nothing noticing; deriving it would mean a permanent gate whose only job is
keeping a number in a comment true.

The measured half survives untouched at both sites: three platform pages author these maps, and
that is still exactly three. No schema arm, bound, default, `.describe()` string or export
changes; nothing an author can write is affected.
12 changes: 6 additions & 6 deletions packages/spec/src/ui/i18n.zod.ts
Original file line number Diff line number Diff line change
Expand Up @@ -93,9 +93,9 @@ import { strictObject } from '../shared/strict-object';
* inline locale map the resolver really honours is authorized, and the dead
* key-reference dialect stays rejected — declared = enforced in both
* directions, which is exactly the #4667 consistency the ruling asks for.
* 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.
* Every inline map authored in this repo (across three platform pages) uses
* `en` / `zh-CN` / `ja-JP` / `es-ES`, so the constraint costs no real
* authoring surface.
*
* The two retired spellings are rejected BY NAME, in any combination
* (#10492). An earlier revision of this comment argued the opposite — that the
Expand Down Expand Up @@ -238,9 +238,9 @@ export const InlineLocaleMapSchema: z.ZodType<
* `pages.<page>.components.<id>.label`, …) and resolved by
* `system/i18n-resolver.ts`.
* 2. **An inline locale map** — `{ en: 'Members', 'zh-CN': '成员' }`, picked at
* render time. Three published platform pages author 31 of these and
* objectui resolves them (`pickLocalized`), so the map is a delivered
* capability, not a convention the runtime ignores.
* render time. Three published platform pages author these and objectui
* resolves them (`pickLocalized`), so the map is a delivered capability,
* not a convention the runtime ignores.
*
* Form 2 is resolved **on this side too**, since #6765: `resolveI18nLabel` in
* `./i18n-label-resolver` is the shared `I18nLabel` → `string` resolver, pinned
Expand Down
Loading