finding(fields): widget-local diagnostics are hard-coded English while the package already carries a locale channel #6755

Filed unassigned by the dev seat implementing objectui#6716, as an out-of-scope finding. Recording, not choosing.

Dedup before filing: repo-scoped REST list of the 243 open issues, grepped for ObjectField / parseError / Invalid JSON / untranslated-widget-message wordings — no match. A control word (LocationField) hit three cards in the same sweep, so the read was sound.

What

A field widget's OWN diagnostic — the message it renders for input it refused — is a string literal in the source, while the same package has a locale channel that 11 of its 55 widgets already use (useFieldTranslation plus FIELD_DEFAULTS in packages/fields/src/widgets/useFieldTranslation.ts, backed by ten locale packs).

Measured on f40389731:

• packages/fields/src/widgets/ObjectField.tsx:69 — setParseError("Invalid JSON"), rendered at :89. Pre-existing.
• packages/fields/src/widgets/LocationField.tsx — the two refusal sentences added by objectui#6716, rendered the same way. Same shape, deliberately copied from the precedent above.

So a zh / ja / ar user who mistypes a coordinate or a JSON blob is told why in English, inside a product whose labels, gate hints and validation copy are all translated. This is not the AGENTS.md rule #-1 case (that requires user-facing text to BE English in the codebase, which it is); it is the case where a translatable surface was never routed through the channel that exists for it.

Why it may matter, and why it is NOT obviously worth doing

Both directions are recorded so triage does not have to re-derive them:

• FOR: these are the only sentences in a field row that a locale cannot reach, and the count is small and bounded today (2 widgets, 3 sentences), so the cost of keying them is small too.
• AGAINST: the AddressField placeholder decision (objectui#4028, in that file's comment) refused exactly this move for its five placeholders and gave reasons that partly apply here — keying costs pack entries in ten languages, each bound afterwards by check:i18n-drift, and Latin-script "translations" need an untranslated-identity-4376 allowlist entry. The counter-argument is that these are SENTENCES a user must read to recover from a refusal, not example data, which is the category Console: AddressField sub-labels and placeholders are hardcoded English literals — an address field is untranslatable on any non-English console #4028 said the packs do carry.

Not measured: whether any customer deployment runs a non-English locale on these two widgets. That is the pull question, and it is triage's.

Related

objectui#6716 (the card that added the second instance and made the class visible) · objectui#4028 (the placeholder decision that reasoned about the same trade in the same package) · objectui#4752 (the same class in @object-ui/components: undoLabel / redoLabel defaulting to English)