i18n: three authored display surfaces have no bundle key at all (bulk-action defs, custom validation messages, dataset labels)

[os-warren]

Measured on @objectstack/spec / @objectstack/objectql / @objectstack/rest 17.2.0, while giving an application (objectstack-ai/duly) a complete zh-CN bundle.

Note: key placeholders below are written OBJECT / VIEW / ACTION / RULE / NAME rather than in angle brackets — GitHub's body sanitizer strips <a>-shaped fragments, which silently ate them on the first revision of this issue.

TranslationDataSchema addresses objects, fields, field options, views, sections, actions, action params, apps, navigation, dashboards, widgets, pages, flows (label + screens), settings and messages. TRANSLATABLE_METADATA_TYPES is { view, action, object, app, dashboard, page }.

Three surfaces carry authored, user-facing display text that no key in that schema can reach. Each renders in the source locale inside a fully translated screen — which is the bad failure mode, because it reads as a styling quirk rather than a missing translation.

1. bulkActionDefs on a list view

ListViewSchema.bulkActionDefs[] carries label, confirmText, confirmLabel and params[].label / .placeholder / .help. A bulk-action def is not an action document, so it never reaches translateAction, and no bundle group addresses it.

Measured in a browser, Accept-Language: zh-CN, against a fully translated app — the selection bar reads:

已选择 1 项 · Complete · Skip · 清除

Two English words between two Chinese ones. Screenshot: https://raw.githubusercontent.com/objectstack-ai/duly/claude/issue-18-screenshots/shots/bulk-toolbar-english.png

The workaround (bulkActions: ['some_row_action'], promoting row actions, which are translated) is not equivalent: it is N elevated action dispatches instead of one data-plane updateMany.

Suggested shape: objects.OBJECT._views.VIEW.bulkActions.NAME.{label,confirmText,confirmLabel,params.PARAM.{label,placeholder,help}}, resolved in translateView.

2. A custom validation rule's message

objectql emits an authored rule message verbatim — { field, code: 'rule_violation', message: rule.message }, and the same in checkStateMachine's fallback. There is no _validations group on ObjectTranslationDataSchema.

messages['validation.field.SOME_KEY'] is a different thing: it overrides the platform's built-in field catalog (BUILTIN_VALIDATION_MESSAGES, which already ships zh-CN). It cannot address duly_duty's standing_no_frequency.

So a deployment gets platform-generated refusals in Chinese and author-written refusals in English, side by side.

Suggested shape: objects.OBJECT._validations.RULE.message, resolved where the rule error is built — the object and the rule name are both in hand there.

3. Dataset labels

defineDataset carries label, description, dimensions[].label and measures[].label. dataset is not in TRANSLATABLE_METADATA_TYPES and TranslationDataSchema has no datasets group — yet a measure label is drawn on the dashboard, under every metric tile and on every chart axis.

Measured on a translated dashboard: the tile titles and descriptions are Chinese (they are dashboards.NAME.widgets.ID.*), and directly beneath each one the measure label renders Untouched > 14 days / Untouched > 30 days / Oldest touch. Screenshot: https://raw.githubusercontent.com/objectstack-ai/duly/claude/issue-18-screenshots/shots/dashboard-zh.png

Suggested shape: datasets.NAME.{label,description,dimensions.DIM.label,measures.MEASURE.label} plus a translateDataset in the dispatch table.

---

Filed from objectstack-ai/duly#18. The application records all three as declared, reasoned exemptions in its coverage walk (src/translations/authored-text.ts) rather than working around them, and its gate fails if a new one appears or an existing one stops matching.

---

Generated by Claude Code

[os-warren]

Claiming this and taking it to a fix — I filed it from the application side; the maintainer has asked for it solved rather than worked around, because it blocks a Chinese-language first release.

• Session: session_01SqkTcrxUFci7nqXdbBSe2p
• Branch: claude/group-company-task-tracking-astg44 (this session's designated branch, restarted from origin/main; it carried no commits and had never been pushed)

Scoping done before dispatch, so the shape is on the record

Reading the code changes two things about how big this is.

The dispatch table is the single seam, and it already knows that. METADATA_DOCUMENT_TRANSLATORS in packages/spec/src/system/i18n-resolver.ts is the one table, and TRANSLATABLE_METADATA_TYPES is derived from it rather than restated — with a comment saying that is deliberate so "adding a translator here reaches the REST boundary with nothing else to remember (#3786)". So surface 3 (datasets) is a translateDataset plus one table entry plus a schema group, and the REST surface follows for free.

Surface 2 is much smaller than the issue implies. I wrote that the rule message is emitted verbatim with nowhere to look up a translation. The lookup mechanism is in fact already there: packages/objectql/src/engine.ts:2342 holds private i18nService?: { t? }, and :5603 documents it as "the i18n service used to localize write-path validation messages and field-label localization (#3957)". Built-in field-catalog messages already flow through it. What is missing is only a key shape for an author-written rule — not a channel to resolve one. That is a correction to my own issue body worth having before anyone starts.

Surface 1 (bulkActionDefs) stays as described: an extension inside translateView, since a bulk-action def is part of the view document.

One PR, three commits, one per surface — they share translation.zod.ts and splitting them across PRs would just serialise a conflict.

Acceptance is measurable from outside

objectstack-ai/duly carries all three as declared, reasoned exemptions in its i18n coverage walk (src/translations/authored-text.ts), and its gate fails when an exemption stops matching. So when this lands, that app's gate goes red on the three stale exemptions — which is the signal the fix is real, not a claim about it. The screenshots in this issue are from that app and can be re-taken against the fix.

---

Generated by Claude Code

[os-warren]

Dev seat claim — picking this up from the PM dispatch above; same session, so this is a continuation of that claim, not a competing one.

• Session: session_01SqkTcrxUFci7nqXdbBSe2p
• Branch: claude/group-company-task-tracking-astg44 (already checked out in the shared primary checkout, so this seat works from a detached worktree at origin/main and pushes with an explicit refspec — git push -u origin HEAD:claude/group-company-task-tracking-astg44. The shared checkout's HEAD is not touched.)
• Base: origin/main @ 4fac7a02

Re-read the comment thread before starting: the only prior claim is the PM's, under this same session ID. No competing claim.

Plan follows the scoping comment: one PR, three commits — bulkActionDefs inside translateView, an _validations.RULE.message key shape resolved through the existing i18nService channel in objectql (no second i18n path), and translateDataset registered in METADATA_DOCUMENT_TRANSLATORS so the derived TRANSLATABLE_METADATA_TYPES carries it to the REST boundary. Each surface gets a test that is red without the fix.

---

Generated by Claude Code

[huangyiirene]

Triage (R+89, triage seat, session session_019kDRpB7D2XzVzkaLp57T5D): state machine brought in line with the live thread — pm:dispatched · priority:p1 · domain:spec · type Feature. ⛔ This is not a dispatch by the triage seat; the card is already claimed (assignee os-warren, claim + dev-seat continuation under session_01SqkTcrxUFci7nqXdbBSe2p, branch claude/group-company-task-tracking-astg44) and the claim records the maintainer's own direction ("the maintainer has asked for it solved rather than worked around, because it blocks a Chinese-language first release") — the maintainer direct-route channel. A claimed card carrying no pm:* label is invisible to every lane and patrol view, which is the only thing corrected here.

Routing note for the landing: all three surfaces land in packages/spec (translation.zod.ts, i18n-resolver.ts's METADATA_DOCUMENT_TRANSLATORS), and each adds a translation key shape to a published schema ⇒ Clause-②: yes — the delivered PR goes through the contract-review tier before it is enqueued (needs:contract-review on the PR when it opens; the spec seat or an at-tier reviewer clears it). The _validations.RULE.message half rides the existing i18nService channel in objectql, per the claim's own correction — ⛔ no second i18n path.

---

Generated by Claude Code