Locales and translations

Translations provide language-specific content for an existing resource. A translated product keeps the same product and variant IDs, so language changes do not duplicate prices, inventory, or order relationships.

Locale and market are separate

A locale selects language-specific fields where supported. A country and currency select commerce context. Changing the locale alone does not change the cart’s currency or choose another store. Keep these settings separate even when your storefront usually changes them together.

Use the resource’s translation contract

Configure supported locales, make the intended ones active, and choose the default. Each translation associates an entity ID with a field key, locale code, and value. Use the keys exposed by the resource’s translatable content rather than inventing localized metafields for native names and descriptions.

Optional translations can be missing. Verify the requested locale and the project’s fallback behavior with representative content, and let the UI tolerate missing optional fields. Do not assume every field uses the same fallback or that translating a name also translates the slug.

Plan for content changes

Keep the source field and its translations in the same editorial workflow. A changed product description may make an existing translation outdated even though the translation remains valid data. Track that review in your content process.

Follow Translate catalog content for writes and verification. Use bulk operations and jobs for file-based translation workflows.