You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)
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 (
useFieldTranslationplusFIELD_DEFAULTSinpackages/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:
AddressFieldplaceholder 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 bycheck:i18n-drift, and Latin-script "translations" need anuntranslated-identity-4376allowlist 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:AddressFieldsub-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/redoLabeldefaulting to English)