Repository navigation
[approvals] Unify the approval-status vocabulary across i18n bundles (zh "待处理"→"待审批", my_pending view label; humanize the en status options) #7232
Description
Part of #7213 (problem 4: three vocabularies for one request).
Facts (verified on origin/main, 2026-08-10)
- Object-metadata bundle (plugin-approvals; served to every surface that renders
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. - The en bundle ships raw enum values as labels:
en.objects.generated.ts:43-49(pending: "pending",approved: "approved", …) — unhumanized, unlike zh/ja/es. - These files are
.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)
- zh-CN status options:
pending: 待审批(the change);approved: 已批准,rejected: 已拒绝,recalled: 已撤回,returned: 已退回修改(verify current values; keep whatever already matches). - zh-CN
my_pendingview label:待我审批(was 我的待办); align the empty-state wording accordingly. - en status options:
Pending/Approved/Rejected/Recalled/Returned; enmy_pendinglabel stays "My Pending". - ja-JP / es-ES: align the view label with the nav wording where it diverges (
ja-JP.ts:21承認待ち,es-ES.ts:21Aprobaciones pendientes); do not invent translations beyond this glossary.
Acceptance criteria
- A
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. - en no longer shows raw enum values as labels.
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
- Sharing one key-space across the three layers (that is the objectui#2763 rebuild's outcome); objectui-side
approvalsInbox.*wording (already the canonical wording); nav-metadata changes (separate sub-issue of [approvals][console] 「待我审批」有三个并存入口、三套不同 UI —— 其中 sys_approval_request 原生视图是无决策动作的开发者原始表 #7213).
Activity
os-zhuang commentedon Aug 10, 2026
Claim: PM loop round 1 (maintainer-directed dispatch for #7213)
Session:
session_01L9U1G2piXmYrhYQX96XUyvBranch:
claude/issue-7232-approval-status-vocabWorktree:
objectstack-issue-7232Domain:
domain:servicesFile 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 packageContainer & 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
os-zhuang commentedon Aug 10, 2026
ACCEPT — PR #7271 (review by the epic PM session, verified against GitHub, not the report):
pending待处理→待审批,my_pending我的待办→待我审批 (+ empty-state), en statuses humanized, ja/es view labels aligned to the nav wording. Status values untouched.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.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.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
fix(plugin-approvals): unify the approval-status vocabulary across th…
fix(cli,spec,i18n): default-locale bundle tracks the source; promote …