Console: `AddressField` sub-labels and placeholders are hardcoded English literals — an address field is untranslatable on any non-English console

[yinlianghui]

Summary

Field.address() renders through the console's AddressField, whose five sub-labels are English string literals with no t() call and no i18n key. On a Chinese console every address field shows five English labels in the middle of an otherwise fully translated form. An app has no way to change them: the labels do not correspond to any authorable field, so there is nothing for a translation bundle to key on.

Evidence

Fresh database, @objectstack/console 17.0.0-rc.1, browser locale zh-CN. The 「地址与位置」 tab of the new-account dialog, measured with getBoundingClientRect() so screen-reader-only text is excluded — every one of these is visibly rendered:

VISIBLE "Street Address"     @(89,390)  w=86
VISIBLE "City"               @(89,466)  w=23
VISIBLE "State / Province"   @(806,466) w=92
VISIBLE "ZIP / Postal Code"  @(89,542)  w=98
VISIBLE "Country"            @(806,542) w=46

Every other label on that dialog is Chinese — the tab strip, the field labels, the buttons — because those go through objects.<name>.fields.<field>.label in the translation bundle, which works correctly. These five do not.

Mechanism

AddressField in ui-components:

<Label htmlFor="street" className="text-xs">Street Address</Label>
<Input id="street" placeholder="123 Main St" … />
…
<Label htmlFor="city" className="text-xs">City</Label>
<Input id="city" placeholder="San Francisco" … />
…
<Label htmlFor="state" className="text-xs">State / Province</Label>

No useTranslation, no key lookup — the strings are inline JSX children.

The placeholders are worse than untranslated, they are US-specific: 123 Main St and San Francisco are shown to a Chinese user entering a Chinese address.

The read-only branch has the same problem in a different form — it joins the parts as street, city, state zipCode, country, which is US address order and produces a wrong-looking address for locales that order it differently.

Why an app cannot work around it

• The sub-labels are not fields on the object. billing_address is a single address column; there is no billing_address.street for a bundle to translate.
• There is no subLabels / partLabels property on Field.address().
• Replacing the widget is not possible from metadata.

The only "workaround" available to us is to stop using Field.address() and author five separate text fields, which loses the structured value, the geocoding, and the map view.

Suggested fix

1. Route the five labels through the console's own i18n bundle (keys like fields.address.street, .city, .state, .postalCode, .country). The bundle already ships zh-CN, ja-JP, es-ES, de, fr, pt, ru, ar, ko — the translations for these five words are trivial.
2. Localize or drop the US-specific placeholders.
3. Make the read-only formatter locale-aware rather than hardcoding US part order.

Related

• Detail page renders Field.address values as raw JSON — the display registry has a location formatter but no address one #5075 — the same field rendering as raw JSON ([Object]) on the detail page. Different symptom, same widget.

Filed from a downstream app (hotcrm-heimao), tracked there as issue #60.

[os-zhuang]

分诊:入队 pm:queue(已挂 repo:objectui)。

• 过时前提检查(objectui origin/main):packages/fields/src/widgets/AddressField.tsx 仍含硬编码 "Street Address" 等五个子标签,前提成立。
• 查重:objectui 侧无影子单。姊妹单 Detail page renders Field.address values as raw JSON — the display registry has a location formatter but no address one #5075(同 widget 的 display 侧)已按查重收敛进 Record detail page renders address fields as raw JSON — the display registry has a location formatter but no address one #5019,本单只管 input 侧 i18n 与 placeholder/只读格式的 locale 化。

本评论来自分诊座位 Routine(#5474 试点),不构成认领。

---

Generated by Claude Code