fix(platform-objects): translate the Setup nav_sso_providers nav entry in all four locales

[os-zhuang]

Fixes #6659

The gap

@objectstack/plugin-auth contributes an SSO Providers entry into the Setup app's group_access_control (sys_sso_provider, priority 250, auth-plugin.ts:552), and no locale bundle carried a label for it. A deployment with an external IdP wired therefore rendered SSO Providers in English inside an otherwise fully translated Setup menu.

Premise re-measured on the fresh base (origin/main ea1d9165d, i.e. after #6767 rewrote parts of these files):

probe	en	zh-CN	ja-JP	es-ES
nav_sso_providers	0	0	0	0
nav_positions (control)	1	1	1	1

The declaring contribution had not drifted — still auth-plugin.ts:552.

The change

Option 1 of the issue only. The union-aware gate (option 2) is deliberately not built.

locale	label
en	SSO Providers
zh-CN	SSO 提供方
ja-JP	SSO プロバイダー
es-ES	Proveedores SSO

Each matches that locale's existing sys_sso_provider.pluralLabel (already in the generated object bundles), since the nav entry opens exactly that object's list view — so the menu and the page it opens read the same words. Placed inside the Access Control block, between nav_record_shares and nav_api_keys, matching the contribution's priority 250.

Why no gate caught it, measured both ways

pnpm check:app-nav-i18n (#5750) boots the real composition and asserts every merged Setup nav id carries a label in every locale — and plugin-auth spreads its navigationContributions in only when authManager.isSsoWired() is true. In the composition that gate boots, this entry is never contributed, never merged, never judged. The gate's own header already declared that bound; this PR is the first concrete specimen of it.

Reverse verification, with the expected direction decided up front. The interesting half is that the gate is predicted not to move — that is the issue's central claim, not a gap in the verification. Measured with the four labels taken back out (git checkout origin/main -- the four locale files, then rebuilt):

check	predicted	measured
new pin case	red x4	red x4 — expected [ 'nav_sso_providers' ] to deeply equal [], one per locale
check:app-nav-i18n	green, unchanged	OK (10 contributor(s), 53 merged setup nav id(s), 4 locale(s), every id labelled in every locale) — byte-identical to the run with the labels present

That second row is the point: the gate reports "every id labelled in every locale" while all four locales are missing this one. So the id is pinned by hand in setup-nav-dead-key-tombstone.test.ts, as the converse of the #6660 tombstone it now sits beside — one list holds ids whose label must be gone, the other ids whose label must stay. The two are the two halves of one ledger, and the file header says so, including the bound that this package can assert only the label half (plugin-auth depends on it, so it cannot be imported from here — the same import direction that put the boot gate in packages/cli).

Also in scope (declared in the claim — cli-seat veto welcome)

packages/cli/scripts/check-app-nav-i18n.mjs header, comment only, no logic edits. Its closing sentence said "the dead apps.setup.navigation keys that exist today are tracked separately" — those four keys were removed by #6767, so that half-sentence is now false. Rewritten to point at where Setup's reverse direction is actually decided (the two hand-kept lists), keeping the still-true claim intact: the gate makes no reverse assertion, because from one composition a dead key and a gated-off contribution are indistinguishable.

One more citation was falsified by this PR and corrected in the same file it lives in: the tombstone header said "Making that gate union-aware is tracked as #6659". After triage, #6659 tracks the missing label and the union-aware gate is explicitly a separate, unbuilt card — leaving that line would point future readers at a closed issue for work never done.

Verification

All foreground, heavy runs under flock /tmp/os-heavy-verify.lock with a 4 GB heap cap.

pnpm --filter @objectstack/platform-objects test    11 files, 289 passed
pnpm --filter @objectstack/platform-objects typecheck / @objectstack/cli typecheck   clean
pnpm check:app-nav-i18n     OK (10 contributors, 53 merged ids, 4 locales)
pnpm check:i18n             OK (9 packages, all bundles in sync)
pnpm check:i18n-coverage    OK (12 configs, 660 baselined, none new)
pnpm lint                   exit 0
pnpm check:nul-bytes        OK (6321 files)
pnpm check:doc-authoring    OK (373 files clean)

check:i18n-coverage first reported COULD NOT MEASURE — @objectstack/connector-mcp had no build output because the earlier build was scoped to @objectstack/cli.... That is the gate's documented fix: pnpm build, not a finding; it is green above after building the CI package set.

No skip-changeset label: this PR ships a changeset (.changeset/sso-providers-nav-label.md, patch on @objectstack/platform-objects).

---

中文摘要

plugin-auth 只有在外部 IdP 接通时才会向 Setup 的「访问控制」分组贡献 nav_sso_providers,而四个语言包都没有它的标签,所以接了 SSO 的部署会在一个已完全翻译的菜单里显示英文的 SSO Providers。本 PR 按裁决只做方案一:补齐四个语言的标签,措辞与各语言 sys_sso_provider.pluralLabel 保持一致。

check:app-nav-i18n 只启动一个组合,被条件关掉的贡献根本不会被合并,因此结构上看不到这个 id —— 已双向实测:删掉四个标签后该 gate 仍然输出完全相同的 every id labelled in every locale,而新增的 pin 用例四个语言全红。所以这个 id 改为手工 pin 在 setup-nav-dead-key-tombstone.test.ts,与 #6660 的墓碑互为反面:一份列「必须消失」的 id,一份列「必须保留」的 id。

未实现方案二(让 gate 具备 union 感知)—— 按裁决那是独立的、面向维护者的卡片。

[vercel]

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

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
objectstack	Ignored		Aug 8, 2026 5:37pm

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/platform-objects.

2 hand-written doc(s) reference the affected code and may need an implementation-accuracy re-verification:

• content/docs/plugins/packages.mdx (via @objectstack/platform-objects)
• content/docs/ui/setup-app.mdx (via @objectstack/platform-objects)

Advisory only. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs origin/main → pass the list as args.docs.