Skip to content

fix(showcase): put the remaining eight authored validation messages on the translation channel - #14709

Merged
os-musk merged 3 commits into
mainfrom
claude/issue-14518-showcase-authored-validation-translations
Sep 2, 2026
Merged

fix(showcase): put the remaining eight authored validation messages on the translation channel#14709
os-musk merged 3 commits into
mainfrom
claude/issue-14518-showcase-authored-validation-translations

Conversation

@os-musk

@os-musk os-musk commented Sep 2, 2026

Copy link
Copy Markdown
Collaborator

Fixes #14518

What

showcase_account declares seven author-written validations[].message and showcase_task one, and none of them had an objects.OBJECT._validations.RULE.message entry. An authored message is emitted verbatim without one, so on a zh-CN session those refusals arrived in English beside the platform's own — which have shipped zh-CN since #3957 — two languages inside one 400 VALIDATION_FAILED envelope.

#14311 fixed the same defect for showcase_project (PR #14517, bbbac0fc4); its scope was one wizard, so these eight were left behind. This adds en + zh-CN entries for all eight and replaces the per-object pin with a bundle-wide one.

The nested-conditional subtlety, verified against the code

churn_reason_consistency is a conditional with both branches. Its own message never reaches a caller: checkConditional (packages/objectql/src/validation/rule-validator.ts) either returns nothing, returns unevaluableRuleError — which builds its own sentence and ignores rule.message — or delegates to the branch, and authoredRuleMessage keys on the branch's rule.name. The source says so in its own words: "rule.name is the address — including a nested conditional branch's own name, since the branch is the rule whose message the caller sees." rule-validator.test.ts pins it (addresses a nested conditional branch by the BRANCH's own name).

So churn_reason_present and churn_reason_absent each get their own entry — translating only the wrapper would have translated the one sentence nobody reads. The wrapper's entry is kept anyway, so the bundle mirrors the declared rule set 1:1 and the pin can ask for every declared name rather than re-deriving objectql's dispatch in a test.

The pin is bundle-wide, not per-object

The card offered a choice and the stronger option fits inside the declared file surface, so it is taken. The replaced test covered showcase_project only — which is exactly how these eight rotted. The new one, in the same file:

  • walks the composed stack (stack.objects + stack.objectExtensions), the reachability principle seed.test.ts documents — an extension's validations merge into the target at registration, so they are addressed under extend;
  • descends into conditional branches, and names churn_reason_present in its premise test so the recursion cannot silently stop mattering;
  • asks the question for every locale i18n.supportedLocales claims, rather than a hardcoded pair;
  • pins the default-locale entry to the authored sentence verbatim. The bundle wins over rule.message in every locale, en included, so a drifted en entry turns the object's own message into dead text no reader ever sees;
  • requires a non-default locale to differ from the source, and to actually contain Chinese where the locale is a zh one.

A newly declared rule without a translation now fails here instead of rotting.

Not lifted into packages/lint. The triage suggested establishing whether validate-translation-references could carry this first. It cannot as it stands, and the reason is itself a defect: that rule builds its _validations universe from a flat walk of objects[].validations[], so it reports a nested branch's correct entry as an orphan — measured, filed as #14700. packages/lint is outside this card's declared file surface, so it is filed rather than fixed here.

Scope

examples/app-crm is untouched — the card declines to assume the CRM demo is meant to be localised, and this PR does not answer that question either.

Verification

All readings on c194fe53e (final HEAD, origin/main merged in).

Gates — re-derived on the final tree with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands: 30 commands. 28 exit 0. Two exit 3, which is each gate's own distinct "NOT MEASURED" code, not a finding and not a red:

  • check-test-completeness.mjs — the family names it with no argument and there is no saved turbo run test log to hand it; its own text says "the local reading for this gate is NOT MEASURED. It is not a red."
  • scripts/pm/check-half-states.mjs"no reading at all… treat this exit as an unread instrument" (it needs a board read this container's REST channel refuses).

Testspnpm --filter @objectstack/example-showcase run typecheck && run test: 27 files, 375 tests, all passing. tsc --noEmit --listFiles confirms all four edited files are in the typecheck program (1 hit each) rather than excluded.

Reverse verification — the new pin was made to go red twice, from a committed tree, each mutation confirmed on disk by grepping the specific text before and after, each restore proven by blob-hash equality against the HEAD blob plus an empty git diff HEAD. The subject is source (vitest transforms the app's TypeScript directly, no dist/ on the path), so no rebuild leg applies here.

  1. Delete the zh-CN entry for the nested branch churn_reason_present (anchor 1 before, 0 after) — 2 failed / 6 passed, naming zh-CN: objects.showcase_account._validations.churn_reason_present.message. This is also the proof the walk descends into branches: a flat walk would not have missed it.
  2. Replace the zh-CN task message with the English source (old anchor 0 after, injected text 1 on disk) — 1 failed / 7 passed: "showcase_task.task_status_flow in zh-CN is a copy of the source".

ESLint — narrowed to the changed paths rather than the repo-wide pnpm lint, and the narrowing is measured, not assumed: the population is eslint's own verdict per file from --format json (5 entries — the four .ts files linted clean, the changeset reported by eslint as "File ignored because no matching configuration was supplied"), and the repo runs one eslint.config.mjs that never enables type-aware linting for any file (no parserOptions.project, no typed @typescript-eslint rules — stated and measured with a positive control at eslint.config.mjs:327), so nothing in this diff can move the verdict on a file it does not touch. CI runs the full sweep regardless.

Changeset

Derived rather than assumed: examples/app-showcase is private: true and pnpm check:published-files is green, but .changeset/config.json sets privatePackages: { version: true }, and the closest analogue — 450f3e5a8, an examples-only showcase zh-CN translation PR — carried "@objectstack/example-showcase": patch. So this carries one too, and skip-changeset is not applied.

Filed, not fixed

🤖 Generated with Claude Code

Generated by Claude Code


Generated by Claude Code

…n the translation channel

`showcase_account` declares seven author-written `validations[].message` and
`showcase_task` one, and none had an
`objects.<o>._validations.<rule>.message` entry. An authored message is
emitted VERBATIM without one, so on a zh-CN session those refusals arrived in
English beside the platform's own, which have shipped zh-CN since #3957 — two
languages inside one `400 VALIDATION_FAILED` envelope.

Both nested `conditional` branches get their own entry. `checkConditional`
delegates to the matching branch and renders THAT branch's message, addressed
by the branch's own `name`, so `churn_reason_consistency`'s own sentence is
structurally unreachable; translating only the wrapper would have translated
the one sentence nobody reads. Its entry is kept so the bundle mirrors the
declared rule set 1:1 and the pin can ask for every declared name rather than
re-deriving objectql's dispatch.

The pin is now BUNDLE-WIDE rather than per-object. The per-object version this
replaces covered `showcase_project` only, which is exactly how these eight were
left behind; the new one walks the composed stack's objects and object
extensions, descends into conditional branches, and asks the question for every
locale `i18n.supportedLocales` claims — so a newly declared rule without a
translation fails instead of rotting. It also pins the default-locale entry to
the authored sentence verbatim: the bundle wins in every locale, `en` included,
so a drifted `en` entry turns the object's own message into dead text.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0112hMx9hjJ9BgB28X97DS68
…ion-message translations

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0112hMx9hjJ9BgB28X97DS68
@github-actions github-actions Bot added size/m documentation Improvements or additions to documentation tests tooling labels Sep 2, 2026
@os-musk
os-musk marked this pull request as ready for review September 2, 2026 20:31
@os-musk
os-musk enabled auto-merge September 2, 2026 20:31
@os-musk
os-musk added this pull request to the merge queue Sep 2, 2026
Merged via the queue into main with commit af44044 Sep 2, 2026
34 checks passed
@os-musk
os-musk deleted the claude/issue-14518-showcase-authored-validation-translations branch September 2, 2026 21:14
os-trump pushed a commit that referenced this pull request Sep 2, 2026
…#14709

#14709 put the remaining eight authored validation messages on the showcase's
translation channel, moving the `objects.OBJECT._validations.RULE.message`
population this branch is the first to walk. Re-derived with the repo's own
tooling (`node scripts/check-i18n-coverage.mjs --update`), never by hand.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016yfqQh2dBgPAymYd7xipza
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

documentation Improvements or additions to documentation size/m tests tooling

Projects

None yet

2 participants