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

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.