Skip to content

useObjectLabel().viewDescription() has zero production call sites — the catalog translation path for a list view's description is declared, tested, and never invoked #7219

Description

@os-warren

Observation surfaced while fixing #7199. Filed as a finding, not a defect: the correct
resolution is a decision, not a mechanical fix.

Measured

packages/i18n/src/useObjectLabel.ts:488 declares:

viewDescription: (objectName: string, viewName: string, fallback?: string) => {
  const fb = fallback ?? '';
  const resolved = resolve(viewSuffixes(objectName, viewName, 'description'), fb);
  return resolved || undefined;
},

Convention NS.objects.OBJECTNAME._views.VIEWNAME.description. git grep viewDescription
over packages/, apps/ and examples/ returns, besides the declaration itself, only:

  • packages/i18n/src/__tests__/useObjectLabel-view.test.tsx (two call sites)
  • packages/app-shell/src/views/ObjectView.defaultViewIdentity.test.tsx (one call site)
  • one packages/i18n/CHANGELOG.md entry

Zero production callers. Every other hit in that grep is previewDescription, an
unrelated import-wizard key.

Why it stands out

Its two siblings on the same node are both wired up:

  • viewLabel is called by app-shell's ObjectView (breadcrumb / origin label).
  • viewEmptyState is called from inside the renderListView relay itself.

So a translation bundle can currently localize a view's label and its empty state, but a
_views.VIEWNAME.description entry authored in the same bundle resolves nowhere.

Why I did not wire it up under #7199

Two distinct vocabularies carry a view description and their precedence is unsettled:

  1. the authored value on the view entry, I18nLabel — a string or an inline locale
    map, resolved by pickLocalized / the spec's resolveI18nLabel;
  2. the catalog key above, resolved through the i18n bundle.

#7199 fixes (1) — relaying the authored value and resolving its locale map. Adding (2)
requires deciding which wins when both exist, which is exactly the "two readings, two
architectures" shape that should not be guessed at inside an unrelated fix. viewEmptyState
suggests catalog-over-authored is the house answer for this node, but emptyState is not
I18nLabel-typed, so it never had to answer the precedence question this key raises.

Possible dispositions

  • Wire it in, mirroring viewEmptyState's position in the relay, with a stated
    precedence rule.
  • Retire it under enforce-or-remove, if the authored I18nLabel value is considered the
    single intended channel now that it actually arrives.

Either is defensible; the pin tests would need retargeting for the second.

Generated by Claude Code

Activity

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

Metadata

Metadata

Labels

domain:uiobjectui ui stream: fix lands on the published library or apps — objectui execution seatfindingpm:dispatchedpriority:p3

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions