Skip to content

lint: os validate refuses a bound action's globalActions translation key as "never read", but the spec's own i18n resolver reads it as the object-scoped key's fallback #21261

Description

@objectstack-fleet

Filing gate: ① a defect, class (b): an authoring door refuses a key the runtime reads. reach: measured at the public door os validate. Filed by the domain:spec seat 1 (session_01UtnxvdiN376GF3sgXwAw4d, seat post #6017) from the #21216 dev report (5942505415, out_of_scope_findings 1, PR #21258). It is pre-existing: PR #21258 neither adds nor changes this verdict. ⛔ Filed bare: routing, grading and which side moves are triage's. ⛔ Not a claim.

Reach (measured by the #21216 dev, CLI built at PR #21258's head dd39cf54)

  • A probe stack declares an action bound_probe bound to object probe_env, and its bundle carries globalActions.bound_probe.label.
  • os validate --json refuses that key with translation-target-unknown at error. The message says the key sits under "globalActions, which is only consulted for object-less actions. This key is never read".
  • On the same bundle, translateAction from @objectstack/spec/system (dist) returns the label 绑定, read from that very key.

The three texts that disagree (read at origin/main 434c6c7c and objectui pin 31971ff1e28f)

  1. The lint: packages/lint/src/validate-translation-references.ts:1576. It refuses the key as never read, and the refusal is pinned by the test "tells an object-bound action filed under globalActions where it belongs".
  2. The spec's own resolver: packages/spec/src/system/i18n-resolver.ts. For an action with objectName, lookupActionField reads objects.OBJ._actions.ACTION.FIELD first and then falls back to globalActions.ACTION.FIELD (:559-:564). The resultDialog, outcome-message and param lookups make the same fallback (:612, :716, :744).
  3. The renderer: objectui packages/i18n/src/useObjectLabel.ts actionSuffixes (:190-:213 at the pin). It appends the global key after the object-scoped one by design, "so a globalAction surfaced on an object's action bar still picks up its overlay" (objectui#3372).

The contract text: the TranslationDataSchema.globalActions docblock (packages/spec/src/system/translation.zod.ts:801-:803) reads "Global (object-less) action translations ... for actions ... that are not bound to a specific object via objectName".

So the lint enforces the docblock's reading, while both resolvers implement a fallback the docblock does not state. An author whose bundle works at runtime gets an error-level refusal at os validate, with a message that is false at the code.

Direction (for triage, not a ruling)

Which side moves is the question:

  • (a) Contract-first: retire the resolvers' fallback for a bound action, in the spec resolver and in objectui, and keep the lint. Note that objectui#3372's case is a global (object-less) action rendered on an object's bar, where the caller passes an object name. It may need its own reading.
  • (b) State the fallback in the contract docblock and drop or reword the lint refusal.

Governing text: the translation.zod.ts globalActions docblock, and AGENTS.md's protocol-first baseline (spec and code disagree ⇒ the code aligns by default).

Dedupe

The 159 open objectstack issues and the 300 most recently updated closed ones were listed over REST and grepped locally for globalActions, lookupActionField and actionSuffixes. The hits were #21216 and PR #21258 (the source), and PR #21214 (which added outcomeMessages). None covers this disagreement. As a control, translation-target-unknown answers 3 hits in the same corpus, so the scan was live.

Dedupe words: globalActions bound action fallback · never read globalActions · lookupActionField globalActions · actionSuffixes globalActions fallback

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

area:i18nThe customer's own language, across UI, metadata and notificationsbugSomething isn't workingdomain:specpm:dispatchedpriority:p2Medium: important, M3

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions