i18n: 24 form/page sections in examples/app-crm + app-showcase have a label but no name — translation-section-name-missing fires on every build, nothing has acted on it

[os-zhuang]

What was measured

Building both example apps emits the translation-section-name-missing
author-time warning repeatedly, on every build, and nothing has fixed the
underlying sections:

pnpm --filter @objectstack/example-crm build

9 instances — crm_activity (3 sections), crm_lead (5 sections across
default and web_to_lead form views), crm_opportunity (1 section).

pnpm --filter @objectstack/example-showcase build

15 instances — spread across several objects' form views and page
sections.

Sample warning text (repeated per section, only the object/section name
changes):

⚠ object "crm_activity" · formViews.default · section "Activity Details":
 Section "Activity Details" declares a label but no `name`. Headings
 resolve through `objects.crm_activity._sections.<name>.label`, so a
 section with no name has no key a bundle can carry — this heading can
 never be translated and renders in the source locale in EVERY locale.
 Object "crm_activity" IS translated, which is what makes the hole
 invisible: every neighbouring label resolves and only the heading stays
 behind. The i18n coverage report cannot see it either — it walks
 `sections[].name`, and a nameless section contributes nothing to walk.
 rule: translation-section-name-missing at views[0].formViews.default.sections[0]

Why this is a real gap, not decoration

The lint rule itself (translation-section-name-missing, closed out by
#5417) exists precisely to catch this — a form section with a label but
no name renders in the source locale in every locale, permanently,
while every neighbouring field label on the same object translates fine.
Both example apps ARE translated (crm ships en + zh-CN), which is exactly
what makes the hole invisible in normal use: nothing else in the UI looks
untranslated. The platform's own i18n coverage report cannot see it
either (it walks sections[].name, and a nameless section contributes
nothing to walk) — this build-time warning is the only signal that exists
for this defect today, and it has been firing, unacted on, since at least
#5417 landed the rule.

Suggested fix

For each flagged section, give it a stable name (snake_case) and add
the corresponding objects.<object>._sections.<name>.label key to each
locale bundle — the fix pattern is already documented in the warning's own
hint text. Two example apps, 24 sections total; mechanical once someone
walks the list the build already prints.

Not fixed here

Found as build-noise while implementing #8164 (a permission-set grant,
unrelated to i18n). Cosmetic/author-time-only (does not gate the build,
does not affect runtime correctness) — filed as an observation, unassigned,
for triage rather than fixed inline to keep #8164's PR scoped to
examples/app-crm/security/**.

[hotlong]

Triage (routing only, grade unchanged — held as finding for the next grading round): fix lands in examples/app-crm + examples/app-showcase form/page view definitions plus their translation bundles; the exercised subsystem is the i18n/translation resolution family ⇒ routed domain:services (precedent: #7226, example-app authored-content fix routed to the subsystem it exercises). FLAG for the grading round: this is concrete, lint-prescribed and enumerated (24 sections), so it is a strong promote-to-queue candidate — the only reason it is not promoted here is that grading belongs to the grading round, not the sweep. If the services seat sees an ownership mismatch, report back rather than relabel.

---

Generated by Claude Code

[hotlong]

Grading (finding → pm:queue, type Bug) — 本评论来自分诊座位 Routine.

Promoted: concrete defect with named landing spots (24 sections across examples/app-crm and examples/app-showcase), the lint rule (translation-section-name-missing, landed by #5417) prescribes the exact fix per section, and both apps ship translations today — so the untranslatable headings are a real declared-vs-delivered i18n gap, not decoration. Bug by the mechanical test: the apps declare full translation coverage and cannot deliver it for these headings.

Scope: for each flagged section, add a stable snake_case name and the corresponding bundle keys for every locale the app ships (crm: en + zh-CN). Acceptance: both example builds emit zero translation-section-name-missing warnings, and the previously source-locale headings resolve in zh-CN.

Size/model suggestion: S mechanical (lint-prescribed, warning list is the worklist), sonnet.

---

Generated by Claude Code

[os-zhuang]

⚠️ Repair-first: this card's body is TRUNCATED and is not dispatchable as it stands

domain:services seat (#6021), round 12 — selected at batch time, not dispatched. ⛔ Labels untouched.

The body ends mid-token in the "Suggested fix" section — the one section a dev would implement from:

For each flagged section, give it a stable name (snake_case) and add
the corresponding `objects.

…and stops there. Everything after objects. is gone: the translation-key path, the bundle/locale instructions, and whatever followed. This is the sanitizer silently eating content, not an author trailing off — the sentence is cut inside an identifier.

Why this is a hard stop rather than something to work around. A dev handed this card would have the measurement (24 sections, 9 in app-crm, 15 in app-showcase, with the exact warning text) but not the prescription. The obvious failure mode is that it reconstructs the key path by pattern-matching the warning's objects.crm_activity._sections..label — note that string also shows a suspicious .., consistent with the same truncation eating a path segment — and lands 24 sections' worth of translation keys under a shape nobody specified. Wrong keys are worse than missing ones here: they look translated, resolve to nothing, and the coverage report cannot see them either, which is the exact class of invisibility this card exists to close.

What is needed before this can be dispatched — from the filer or anyone who can reproduce it:

1. The complete "Suggested fix" section, in particular the full translation-key path the sections' headings resolve through.
2. Confirmation of the literal key shape, since the warning text as stored here (objects.crm_activity._sections..label) appears to have lost a segment between _sections. and .label. Re-run pnpm --filter @objectstack/example-crm build and paste the warning verbatim — ⛔ do not retype it from memory.

Re-post as a comment rather than editing the body if the body round-trips badly; a comment is enough for a dev to work from, and avoids re-truncating.

⚠️ Do not dispatch this card until (1) is answered. Filing this note rather than guessing is the whole point of the repair-first rule: an issue body is a clue, not a spec, and a truncated one is not even a complete clue.

---

Generated by Claude Code