Repository navigation
[approvals] Unify the approval-status vocabulary across i18n bundles (zh "待处理"→"待审批", my_pending view label; humanize the en status options) #7232
Description
Activity
Claim: PM loop round 1 (maintainer-directed dispatch for #7213)
Session:session_01L9U1G2piXmYrhYQX96XUyv
Branch:claude/issue-7232-approval-status-vocab
Worktree:objectstack-issue-7232
Domain:domain:services
File surface:packages/plugins/plugin-approvals/src/translations/**,packages/plugins/plugin-approvals/scripts/i18n-extract.config.ts(or the true label source it extracts from), related tests in the same package
Container & model: M, mode:subagent, model: opus
Serial constraints cleared: batch mate #7231 lands in objectui (different repo). #7234 (pm:blocked, same parent) also touches plugin-approvals but rides a later round after #7231 merges — not in this batch. No in-flight claim or open PR on plugin-approvals translations per search at claim time.
Generated by Claude Code
ACCEPT — PR #7271 (review by the epic PM session, verified against GitHub, not the report):
- Shipped: the four plugin-approvals bundles now carry the [approvals] Unify the approval-status vocabulary across i18n bundles (zh "待处理"→"待审批", my_pending view label; humanize the en status options) #7232 glossary — zh
pending待处理→待审批,my_pending我的待办→待我审批 (+ empty-state), en statuses humanized, ja/es view labels aligned to the nav wording. Status values untouched. - Mechanism finding recorded: the dispatch's "fix at the extraction producer" hypothesis was half-falsified with two-directional probes —
os i18n extractowns bundle structure, leaf values are hand-maintained and--merge-preserved; en's raw labels trace toField.selectnormalizing bare enum strings to label=value. Correct handling. - Net-new pin, not a flip: nothing pinned this wording anywhere (which is how three layers drifted). The new
approval-status-vocabulary.test.tsasserts through the real resolvers (proving the bundle is reached), adds a raw-enum-leak ratchet across four locales, and — the load-bearing part — a cross-package parity case tying this plugin'smy_pendinglabel to platform-objects'nav_account_approvalslabel for zh/ja/es, so either layer reworded alone goes red. Reverse verification 5/6 red in the predicted direction. - File surface: 6 files, all inside the claim; changeset present; no releases/ADR paths. CI verified per-job: 25 check runs, ESLint / TypeScript Type Check / Test Core (3) / Dogfood gates (3+CLI) / Temporal Conformance all success, zero failures.
- Residual, deliberately not changed (scope boundary of this card, flagged in the PR body): ja-JP
status.options.pendingis 保留中 while 承認待ち is used elsewhere in the same bundle — a one-line follow-up if the ja status word should align too; left for triage to grade.
Next: PR flipped ready + queued. Once it lands, #7234 (account/setup nav →
approvals:inbox) dispatches — both its upstreams (objectui#4071 merged; this PR, same-package serialization) will then be satisfied.
Generated by Claude Code
- Shipped: the four plugin-approvals bundles now carry the [approvals] Unify the approval-status vocabulary across i18n bundles (zh "待处理"→"待审批", my_pending view label; humanize the en status options) #7232 glossary — zh
Part of #7213 (problem 4: three vocabularies for one request).
Facts (verified on origin/main, 2026-08-10)
sys_approval_request):packages/plugins/plugin-approvals/src/translations/zh-CN.objects.generated.ts:44haspending: "待处理"; themy_pendingview is named "我的待办" (around:88-95). The Approvals Inbox (objectuiapprovalsInbox.*) and the account-app nav label (packages/platform-objects/src/apps/translations/zh-CN.ts:21) say 待我审批 / 待审批 for the same things — three vocabularies with no shared keys.en.objects.generated.ts:43-49(pending: "pending",approved: "approved", …) — unhumanized, unlike zh/ja/es..generated.ts; there is an extraction config atpackages/plugins/plugin-approvals/scripts/i18n-extract.config.ts, andcheck:i18n/check:i18n-coverage/check:app-nav-i18nrun in lint.yml. Work through the pipeline if it is the source of truth (verify first); if the files turn out to be hand-maintained despite the name, edit directly and record the evidence in the PR body.Canonical glossary (align to the Approvals Inbox wording)
pending: 待审批(the change);approved: 已批准,rejected: 已拒绝,recalled: 已撤回,returned: 已退回修改(verify current values; keep whatever already matches).my_pendingview label:待我审批(was 我的待办); align the empty-state wording accordingly.Pending/Approved/Rejected/Recalled/Returned; enmy_pendinglabel stays "My Pending".ja-JP.ts:21承認待ち,es-ES.ts:21Aprobaciones pendientes); do not invent translations beyond this glossary.Acceptance criteria
sys_approval_requestrow rendered through the generic object surfaces uses the same zh status word (待审批) as the Approvals Inbox — problem 4 of [approvals][console] 「待我审批」有三个并存入口、三套不同 UI —— 其中 sys_approval_request 原生视图是无决策动作的开发者原始表 #7213 closed at the bundle level.translations/bundle-ownership.test.ts,approval-vocabularies.test.ts, and any pinned label expectations updated (flipped pins keep bearing load — assert the new wording, do not delete assertions);check:i18n/check:i18n-coveragegreen; changeset present (user-visible).Out of scope
approvalsInbox.*wording (already the canonical wording); nav-metadata changes (separate sub-issue of [approvals][console] 「待我审批」有三个并存入口、三套不同 UI —— 其中 sys_approval_request 原生视图是无决策动作的开发者原始表 #7213).