fix(i18n): render I18nLabel objects at the 13 remaining sites

[yinlianghui]

Fixes #4167

Part of #4163

Part 1 only for #4163 — the thirteen render sites. Part 2 (what Studio should offer for authoring a per-locale label) stays unclaimed and pending design, so #4163 is Part of rather than Fixes. #4167 is closed in full.

MAIN HEALTH — this PR is the rest of the rc.6 train, collapsed into one landing. PR #4169 (the rc.5 to rc.6 spec bump) merged to main at 38ab5054f and left main's CI red: Type Check (check:spec-symbols, 8 symbols) and Test shards 2/3 (spec-parity + doc tests). The fixes lived in the remaining train cars, which were stacked branches. This PR is no longer stacked — it is based on main and carries all of it.

What this PR now delivers

Three layers, in the order they were built:

1. fix(deps): triage the 14 rc.6 spec-symbol collisions and refresh the console parity exemptions (#4167) #4189 / issue Track the @objectstack family at 17.0.0-rc.6 — the adaptation surface beyond what objectstack#7100 could carry #4167 — the 14 rc.6 spec-symbol collisions triaged, console parity exemptions refreshed, record-picker inputs published. This is what repairs main's check:spec-symbols red. PR fix(deps): triage the 14 rc.6 spec-symbol collisions and refresh the console parity exemptions (#4167) #4189's auto-merge was disarmed by the PM and its content lands here instead; that PR should be closed unmerged once this one lands.
2. fix(i18n): render I18nLabel objects at the 13 remaining sites #4208 / issue I18nLabel now admits an inline per-locale map — audit every read the compiler cannot see, and give Studio a way to author one #4163 part 1 — the thirteen I18nLabel render sites. This is what repairs the resolveActionParams typetest TS2322s.
3. New here — the rc.6 residual fixes that neither car covered, because the tests that catch them landed on main after the train was built. Detailed below.

The merge into main, and what conflicted

git merge origin/main (merge, not rebase — shared history with an open PR). Main had moved on by 3 commits, including #4222 and #4218. Five conflicts:

file	resolution
packages/app-shell/src/layout/AppSidebar.tsx	branch side. The train renamed the local resolver resolveI18nLabel to resolveKeyedI18nLabel (the #4167 collision triage); utils/index.ts and every other call site already carry the new name post-merge.
packages/app-shell/src/layout/UnifiedSidebar.tsx	branch side, same rename.
packages/layout/package.json	branch side. The train moved @objectstack/spec from devDependencies to dependencies (layout now imports the spec resolver at runtime); main still had it in devDependencies.
pnpm-lock.yaml	branch side — one hunk, the exact mirror of the layout/package.json move. pnpm install then reported "Lockfile is up to date".
packages/fields/src/widgets/AddressField.tsx	semantic conflict, resolved as a hybrid — see below.

The one conflict that was not a text conflict

Both sides changed AddressValue, in ways that were individually correct and jointly incoherent:

• main (fix(detail): inline-edit an address as sub-fields, not a text box reading [Object] #4222) extracted AddressValue / LegacyAddressValue / readPostalCode / formatAddress out of the widget into a new pure module ./address-format, so the display cell renderer and the widget share one formatting rule.
• this train (Track the @objectstack family at 17.0.0-rc.6 — the adaptation surface beyond what objectstack#7100 could carry #4167) stopped declaring AddressValue and imported it from @objectstack/spec/data, because rc.6 publishes that exact name and the local copy declared five of the seven parts (countryCode and formatted were missing).

Taking either side alone loses the other's point, and taking main's side alone reopens main's red: the declaration simply moves to address-format.ts, where check:spec-symbols still sees a local declaration of a name the spec owns. The resolution keeps both — address-format.ts (the new home of the definition) imports the type from @objectstack/spec/data, and AddressField.tsx re-exports through that module rather than bare. The from clause matters: the guard deliberately skips a re-export carrying a relative path ("whatever it points at gets judged at its own declaration site") but treats a bare export type { AddressValue } as a second local declaration.

The residual red set — measured on the combined tree, before and after

Neither train car fixed these. Both were verified red on the merged tree before being fixed, and the reverse verification below puts them back.

1. QUICK_REFERENCE.md still quoted rc.5 — 3 failures. The "Current Release" block stated ^17.0.0-rc.5 for both @objectstack/spec and @objectstack/client, while all three manifests it names as its own anchors declare ^17.0.0-rc.6. Its pin test (scripts/__tests__/quick-reference-current-release-4143.test.ts) landed on main after the train was built, so no car ever ran against it. Fix: the two rows. The third failure was the block's own "no un-derived literal" assertion, which fell out with them.

2. recordDetailsInputs.spec-parity.test.ts:123 — 1 failure, and NOT about sections. The premise check found the real cause, which is worth stating because it is the opposite of what the failure looks like. Both fixtures in the object-sections case carried layout: 'custom'. layout was removed from record:details in spec 17.0.0 (objectstack#6946, ADR-0087 D2), and rc.6 gave the key a named never rejection:

expected: "never", code: "invalid_type", path: ["layout"]
message: `record:details` property `layout` was removed in @objectstack/spec 17.0.0

So the object-form fixture failed on layout while its sections were perfectly valid. Worse, and invisibly: the id-list fixture directly above it kept PASSING — it asserts only that the parse fails with code invalid_type, and layout's own rejection satisfies both without the parse ever reaching sections. That assertion was green for a reason unrelated to what it claims to test. Dropping the key puts both verdicts back on sections (issues now resolve to path sections.0 / sections.1), and the id-list case additionally pins the issue path, since a bare code cannot tell the two rejections apart. This is a test-fixture fix only; no plugin-detail source was touched.

The file's header prose was also updated — it opened "Under layout: 'custom' sections are the ONLY source of the body", a sentence about a key that no longer exists.

---

Local gate ladder

Run on the final tree (5f5543316). NODE_OPTIONS=--max-old-space-size=4096, --maxWorkers=2 / --concurrency=2, every heavy step under flock /tmp/os-heavy-verify.lock. Vitest invoked from the repo root (objectui#3378).

1. Build closure

$ pnpm exec turbo run build --concurrency=2
 Tasks:    44 successful, 44 total
  Time:    4m47.376s

2. Type-check — both commands

$ pnpm exec turbo run type-check --concurrency=2
 Tasks:    78 successful, 78 total
  Time:    2m58.327s

Ten packages define a tsconfig.typetests.json, and in every one the package script is tsc --noEmit && tsc -p tsconfig.typetests.json, so the 78/78 covers both commands rather than only the first. Explicit receipts for the three the change touches most directly:

$ (packages/app-shell)    npx tsc -p tsconfig.typetests.json   -> EXIT=0
$ (packages/plugin-detail) npx tsc -p tsconfig.typetests.json  -> EXIT=0
$ (packages/fields)        npx tsc --noEmit                    -> EXIT=0

3. check:spec-symbols — the gate that is red on main

$ node scripts/check-spec-symbol-derivation.mjs
✅  spec symbol derivation: 1229 files scanned against 4834 spec export names;
    14 declared dialects, 3 untriaged collisions in 1 packages.   EXIT=0

The 3 untriaged collisions are the pre-existing DEBT ledger, unchanged by this PR and non-fatal by design. For contrast, the same gate on the tree mid-merge, before the address-format resolution:

❌  a spec-named symbol is hand-written, not derived:
    • @object-ui/fields declares 1 spec-named symbol the spec already owns:
        re-export `AddressValue`  packages/fields/src/widgets/AddressField.tsx:17

4. Tests

$ pnpm exec vitest run --maxWorkers=2 packages/app-shell/ packages/react/ packages/types/ \
    packages/plugin-list/ packages/plugin-designer/ packages/layout/ packages/components/ \
    packages/plugin-dashboard/ packages/fields/ packages/core/ packages/plugin-detail/ \
    packages/data-objectstack/ scripts/
 Test Files  871 passed (871)
      Tests  10524 passed | 1 skipped (10525)
   Duration  954.99s

$ pnpm exec vitest run --maxWorkers=2 apps/console/
 Test Files  33 passed (33)
      Tests  345 passed (345)

apps/console is run separately and deliberately: it owns the repo-wide registry-inputs-spec-parity.test.ts gate, which the merge touched.

5. Reverse verification of the residual fixes

Predicted direction, stated before running: reverting the two residual files turns the quick-reference test red on 3 cases (Spec row, Client row, un-derived-literal) and recordDetailsInputs red on 1. Taken out with git checkout HEAD -- ... and a scoped patch file, never git stash. Confirmed exactly:

⎯⎯⎯ Failed Tests 4 ⎯⎯⎯
 FAIL  quick-reference-current-release-4143.test.ts > quotes the `@objectstack/spec` range the manifests declare
   AssertionError: QUICK_REFERENCE.md must state the spec range as "^17.0.0-rc.6"
 FAIL  quick-reference-current-release-4143.test.ts > quotes the `@objectstack/client` range the manifests declare
   AssertionError: QUICK_REFERENCE.md must state the client range as "^17.0.0-rc.6"
 FAIL  quick-reference-current-release-4143.test.ts > contains only version literals this test derives from a manifest
   AssertionError: ... states ["^17.0.0-rc.5","^17.0.0-rc.5"], which no manifest in this tree produced
 FAIL  recordDetailsInputs.spec-parity.test.ts > the spec really takes OBJECT sections
   AssertionError: expected false to be true

 Test Files  2 failed (2)
      Tests  4 failed | 13 passed (17)

One honest correction to the prediction: the reverted recordDetailsInputs failure lands on the original objectForm.success assertion, not on the new path assertion — reverting the file necessarily removes the new assertion along with the fix. Restoring returns to 17 passed (17).

6. ESLint on changed files

$ pnpm exec eslint <61 changed .ts/.tsx/.mjs files>
✖ 589 problems (0 errors, 589 warnings)

0 errors. The warnings are the pre-existing no-explicit-any convention in packages/types/src/objectql.ts and the _Assert… unused-type-alias pattern in the spec-symbol-batch6 type tests.

7. i18n + byte gates

$ pnpm run check:control-bytes
✅ check-control-bytes: OK (scanned 3933 tracked text file(s); skipped 85 binary).

$ pnpm run check:i18n-keys
Every in-scope call-site key resolves against the en pack (2811 keys), every literal inline
defaultValue matches the value the pack serves, every call site passes exactly the arguments
that value has holes for, and no call site carries a literal fallback beside itself.

$ pnpm run check:i18n-drift
Compared the ten locale packs at 6314e87f2 (merge-base with origin/main) with the working
tree: 0 en value(s) changed. No en value changed in this range.

8. Changesets

The train's three changesets are already in the branch and cover every released package this PR touches:

• .changeset/spec-symbol-collisions-rc6-4167.md — minor for types, core, react, app-shell, layout, fields, components; patch for plugin-designer. @object-ui/fields is already covered here, and still accurately: the AddressValue re-sourcing it describes survives the merge, relocated into address-format.ts.
• .changeset/record-picker-sort-limit-empty-text-4167.md — minor for components.
• .changeset/i18nlabel-render-sites-4163.md — patch for the five render-site packages.

No new changeset: of the three residual fixes, one is a repo doc (QUICK_REFERENCE.md), one is test-only (plugin-detail), and the third is a re-export form change in @object-ui/fields whose published type is unchanged and whose package is already covered minor.

---

Original #4163 part-1 detail, retained

What changed upstream

@objectstack/spec 17.0.0-rc.6 widened I18nLabel from string to string | Record< string, string >, so an author may inline a per-locale map — label: { en: 'Owner', 'zh-CN': '负责人' } — anywhere the spec accepts a display label. (Angle brackets spaced throughout this body so GitHub's sanitizer does not eat them; tsc printed them unspaced.)

PR #4169 repaired eight such sites. Thirteen more were invisible to it for a mechanical reason worth restating: the five packages involved build through vite/rolldown, not tsc, so turbo run build never type-checks their sources. Only turbo run type-check compiles them. A bump can therefore be build-green, test-green, and still carry a double-digit type-error count in exactly the packages that render labels.

package	what an author can now write and see
@object-ui/layout	NavigationArea.label — area switcher button + tooltip
@object-ui/plugin-list	ViewTab.label — pill row, dropdown trigger, menu items
@object-ui/plugin-dashboard	DashboardWidget.title — card heading + title attribute
@object-ui/plugin-designer	DashboardWidget.title — widget card + preview tile
@object-ui/app-shell	ActionParam.label and each ActionParam.options[].label

The two edges that are decisions, not mechanics

1. DashboardEditor.tsx:231 is an authoring WRITE, not a read. Resolving a map into a single-line text input and writing e.target.value back would collapse every other locale on the first keystroke — an author who opened a dashboard to move a widget and happened to focus the title field would silently destroy the translations. So the write is guarded, not cast: a map-valued title renders resolved and read-only, and the stored map survives an unrelated edit-and-save round trip untouched. The type error dies from the guard. This is the same conservative branch #4169 took on DashboardWidgetInspector, and it is a placeholder that cannot lose data — not the answer. The answer is #4163 part 2.

2. @object-ui/layout carries no i18n dependency by design. Its whole i18n story is injection (NavigationRenderer takes t and the label resolvers as arguments), and AppSchemaRendererProps exposes no locale, no t, and no context carrying one. So it calls the producer's own resolver — resolveI18nLabel from @objectstack/spec/ui — rather than hand-rolling a resolution that could drift, and runs it at the spec's documented "no locale known" default (en). Stated rather than hidden: an area labelled with a map renders its en entry, not the viewer's language. That is strictly better than [object Object], and it is a floor — the day a consumer needs per-viewer area labels, the fix is to thread a locale in as a prop, and this call is the one place it lands. No new package dependency.

Anti-drift: two resolvers over one vocabulary, now pinned

layout and app-shell call the spec's resolveI18nLabel; the three plugin packages sit inside objectui's i18n tree, already hold the live UI language, and call pickLocalized (which answers '' on a miss, which is what a text node wants, where the spec's answers undefined).

Two functions over one vocabulary is exactly the drift the ruling warns about, and the harm is not a crash — it is the same authored map rendering one locale on the runtime dashboard and a different one in the designer's preview of that same dashboard, with every type and every other test green. Nothing compared them, so this PR adds packages/plugin-list/src/__tests__/i18nLabel-resolver-parity.test.ts: all six limbs of the rule (exact tag, base, regional sibling, default, en, any), asserted on both functions from one table, with the single permitted difference (the miss spelling) normalized in one named place and pinned in both directions.

Also in this PR

Four plugin-list type-test assertions re-pointed at ViewTabParsed. rc.6's …Input-alias retirement moved the bare ViewTab onto the input side, so following the NAME left them comparing the authoring side against itself — passing on nothing. Same swap #4189 avoided for ThemeInput/Theme, different package. Invisible until now because type-check is tsc --noEmit && tsc -p tsconfig.typetests.json and the && never reached that project while TabBar.tsx was red.

---

Generated by Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
objectui	Ignored		Aug 11, 2026 5:09am