i18n: _views.VIEW.description is declared, walked and counted as covered but never rendered — plus three surfaces a bundle cannot address at all #16735

Filed from an app repo (objectstack-ai/hotclm, @objectstack/* 17.3.0, @objectstack/console as shipped) after translating it end to end into en + zh-CN — objectstack-ai/hotclm#32, PR objectstack-ai/hotclm#33. ⛔ Unassigned, ungraded; routing is triage's.

Four findings, filed together because they are one seam — the gap between what the i18n coverage walk addresses and what the console renders. Finding 1 is the serious one and would justify its own card; the other three are the same seam in its benign direction (nothing to address, so nothing claims coverage). Split if triage prefers.

Provenance. All four were measured in a browser by the card-11 implementation run, each with a stated repro. I reviewed the evidence and the reasoning and merged the PR on it; I did not personally re-drive these four, and I say so rather than implying otherwise. (I did independently re-measure a fifth, unrelated finding from the same run and found it inverted — see #16695 — so these are not offered as unexamined.)

Dedup: not possible from that session. search_issues returned total_count: 0 for the app's own repo even on a control term certainly present in an open issue's title, so the index was not answering. The run correctly reported these rather than filing them blind, and I am filing them with that caveat attached rather than claiming a duplicate check I did not get.

Finding 1 — a key that makes the coverage report read 100% while the screen stays English

objects.OBJECT._views.VIEW.description is:

• declared by ObjectTranslationDataSchema,
• walked by the coverage extractor (it is one of the keys os i18n check expects),
• authorable, and counted as covered once authored,
• and never read by the console.

Two legs in one session, zh-CN:

The label resolving from the same group is the control: the bundle is loaded, the object and view are addressed correctly, and the neighbouring key works. Only description is dropped on the floor.

Why this is worse than an untranslated string. It is a false negative in the platform's own gate. An app can author every declared key, watch os i18n check report zero missing, ship, and still have English descriptions on every list view in a zh-CN console — with no signal anywhere. The whole value of a coverage gate is that its zero means something, and this key makes the zero lie.

15 view descriptions in that app are affected. It worked around them with inline maps and kept the bundle entries, so a fixed resolver wins over the map and the duplication unwinds itself — but the next app will not know to do that.

Finding 2 — pages.NAME.components.* addresses nothing on a kind: 'slotted' page, and a tab label has no key on any page kind

let n = 0;
walkAddressedPageComponents(ContractDetailPage, (c) => (n++, c));   // -> 0

against 21 authored components and tab labels (@objectstack/spec 17.3.0). walkAddressedPageComponents is the traversal translatePage itself runs, so this is unresolvable rather than merely ungated.

Two independent causes, either sufficient on its own:

• its roots are regions[].components[], and a slotted page authors slots;
• its descent is properties.children, and a page:tabs carries properties.items[].children.

⇒ pages.contract_detail carries exactly two addressable keys, label and description, while 7 tab labels, 7 path stages, 7 related-list titles and 1 block label cannot be reached from a bundle at all. Worked around with 22 inline locale maps.

Finding 3 — dashboards.NAME has no group for globalFilters

The group is label · description · actions · widgets. A dashboard's global-filter labels and their option labels are not addressable — and the filter bar draws directly above the widget titles the bundle does translate, so the mixed-language result is maximally visible:

类别: 全部        Requesting Department: 全部
[six Chinese widget titles below]

5 filter labels + 29 option labels in that app. Worked around with inline maps.

Finding 4 — chart category labels from select options ignore the bundle on same-object dimensions, and there is no workaround

On dataset-backed charts, category and series labels drawn from a select field's option values render the inline English option label, while the identical values render the translation in the list grid on the same console.

The correlation is exact and is the useful part:

Same option values, same console, same session. Also affects a status funnel (Draft/Submitted/In Review/…) and a currency_code bar (EUR — Euro).

A widget has no authoring surface for category labels, so unlike 1–3 this one cannot be worked around. It is the residue left visible on two of that app's three dashboards.

Also worth knowing, not a finding

• authorWarnedTranslationGroups() returns exactly ['flows'] on spec 17.3.0, so flow screen copy is skipped by the extractor by design and is not translatable today. An app cannot gate on it; ours states that rather than trimming its requirement to fit.
• The coverage extractor emits objects.OBJECT._actions.* twice (once via config.actions, once via the object), so os lint reported 793 i18n/missing-* rows for 752 distinct keys. Cosmetic double-count.
• In a zh-CN console the Studio metadata-type list renders Dataset untranslated while every sibling type is translated (对象/视图/操作/仪表板/流程/页面/岗位/权限集/钩子). That is the metadataForm baseline the platform packages own, not an app string.

Boundaries

• One app, one console build, one dialect. Re-confirm before acting.
• ⛔ Nothing was patched in the platform; findings 1–3 are worked around with inline { en, 'zh-CN' } maps documented at each site, and finding 4 is left visible.
• Finding 1 is the one with a gate consequence. If only one of these is picked up, it should be that one.