Separate dropdown options from localized attribute labels
A translated field label, a dropdown option, and a product's chosen value are separate records. Model them separately to prevent incorrect language and option behavior.
In this guide
Name the three layers
For a fictional SurfaceFinish field, the definition tells the system that the field exists. Its localized label tells an editor what the field is called. Controlled options such as matte and gloss have their own stable codes and localized display values. A product then stores a selected option or value.
Changing a label should not change the stored option code. Translating an option should not rewrite a product record.
Design stable option codes
Use a stable, non-display code such as matte, then supply a translated display value per supported locale. Reject duplicate codes within the attribute and reject a product assignment whose option is not defined for that attribute. Do not use translated labels as keys.
surface-finish-fixture.json json
{
"attributeCode": "SurfaceFinish",
"labels": { "en-US": "Surface finish", "fr-CA": "Finition de surface" },
"options": [
{ "code": "matte", "labels": { "en-US": "Matte", "fr-CA": "Mat" } },
{ "code": "gloss", "labels": { "en-US": "Gloss", "fr-CA": "Brillant" } }
]
}Verify fallback deliberately
Test a product with each option, an empty value, and a locale that lacks an option translation. Define whether the declared patch should show a fallback, hide the value, or reject publication. Record the observed result instead of assuming it matches the Admin label behavior.
References and further reading
Bring your next engineering question.
Need help making catalog data work across locales?
Independent guidance from GCG. Znode is a trademark of its owner. Examples use fictional data and are not official platform documentation. Suggest a correction.