Files
jobtrackingapp/docs/i18n/ERROR_STATE_KEY_REVIEW.md
T

2.3 KiB

Error-state translation inputs

2 November 2026. Twelve historical call sites reviewed through local state constructors; no runtime implementation changed or privileged action executed.

  • ApplicationAssets.tsx:104/887: AssetError.messageKey originates in the private assetError helper with literal/finite conditional arguments, or three explicit cover-AI source error constructors. Conflict status selects revisionConflict; API error text stays display data rather than a catalogue key. Shell is private to this module with AssetError props from these owners.
  • AdminSystemPage.tsx:333/448/449: ReadKind/ActionKind are bounded by four local read/action entry points; readNotice is called only with status/benchmark/maintenance/email. Error-key maps have fixed entries; success state is supplied only by four local literal runAction calls. API response bodies never supply kind/success keys. No maintenance/probe/email request was run by this review.
  • CareerProfilePage.tsx:508/509/865: stage/import-label maps already use Object.hasOwn with explicit generic or raw-text fallback. Run action errors are constructed from cancel/retry/accept/discard and conflict status, with fixed key literals; server error message remains data. No import processing or canonical profile mutation was executed.
  • GmailReviewPage.tsx:231 has two distinct translator calls, both fed by only three literal write-error constructors (save/sync/create). No real mail operation or provider access.
  • JobDiscoveryPage.tsx:229/230: error state receives only five literal keys from local catches, or null; the first call has a fixed unavailable fallback and the second is guarded by non-null state. No provider request or source grant implied.

All components obtain t from useI18n. Assertion verified 87 distinct relevant keys, including the import label/stage maps, in both catalogues. This is finite key/owner/control-flow review, not native translation quality, all message formatting or a security/operational pass.

Register schema 2 now uses immutable inventoryEntryIndex (bound to the original inventory hash) to distinguish the two identical Gmail expressions on the same line. All 74 supplemental indices are unique. Earlier file/line/expression fields remain for readability; they alone cannot identify same-line repeated calls. Reconciliation: 108 original + 74 supplemental = 182 resolved / 6 pending of 188.