[Feature request] Localize nested Address element values per site

[romainpoirier]

Problem

On a multilingual Craft CMS site, an Addresses field can be configured with the site translation method, but the values of its nested native Address element cannot be maintained independently per site.

This includes the native address attributes that editors see in the Address UI, such as:

• organization;
• addressLine1, addressLine2, and addressLine3;
• locality, administrativeArea, and postalCode;
• fullName and other native address attributes.

This is useful when the same physical address needs language-specific presentation, such as an organization name, a localized/transliterated locality, or editorial address lines.

Current behavior

• The Addresses field is a container for nested address elements owned by the parent element.
• craft\fields\Addresses::supportedTranslationMethods() includes the site method.
• The nested craft\elements\Address class inherits craft\base\Element::isLocalized(), which returns false.
• The native values above are stored on the nested Address record, so setting the parent field to site does not make them independently translatable per site.

Addresses also support custom fields through the shared Address field layout. The request should define and document the expected behavior for those custom fields as well: they should either follow the selected shared/per-site Address mode, or clearly document any separate translation-method rules. The request does not assume that custom fields currently behave identically to native Address attributes.

Expected behavior

Please consider an explicit, backwards-compatible localization mode for Addresses that allows nested Address values to be localized per site when the owner and field are configured for it, while preserving the current shared-value behavior by default.

The implementation should preserve:

• country-specific address formats and validation;
• shared country-code semantics where appropriate;
• Craft Commerce and user address-book compatibility;
• an explicit opt-in or migration path for existing projects;
• clear behavior for both native Address attributes and custom fields in the shared Address field layout.

A possible UI could expose Shared and Per site modes, with clear rules for native fields and custom fields.

Documentation and source

• Addresses field documentation
• Address element documentation
• Addresses field source
• Address element source
• Element base localization source

Thank you for considering this for multilingual sites.