Shopify multilingual product options: translate labels, keep the formula

Shopify multilingual product options are the part most merchants forget after they turn on a second locale. Product title, description, and checkout follow Markets. The configurator on the product page does not: shoppers still see “Width (cm)”, “Hem finish”, and “Upload artwork” in English. They guess the unit, type inches into a centimetre field, or leave. Your formula was never the bug. The copy around it was.

Shopify can translate native variant options. It cannot, by itself, translate calculator fields that are not `ProductOption` resources. This article maps that gap, why cloning a product per language backfires, and how Options Price Calculator stores one formula and many label sets — one per published storefront language.

Native translation stops at three options

Localization and translation is the official path: add languages in the admin, assign them to a market, publish them. Buyers see the published locale; missing strings fall back to the shop default. Translate & Adapt (or a compatible app) covers product copy, theme strings, and the GraphQL types `PRODUCT_OPTION` and `PRODUCT_OPTION_VALUE` — the name of a native option and each value. “Color” can render as “Couleur”; “Navy” as “Marine”.

That only applies inside Shopify’s own ceiling. Adding variants still allows three options and 2048 variants per product. A typed length, a file, a fourth finish, or a surcharge checkbox is not a variant option. Threads such as Translate & Adapt App Is Not Working treat free-text or non-standard values as a separate job: category-linked options often flow through automatically; custom values must be translated per product, and many app fields never appear in Translate & Adapt at all. Developers in How to translate product variants options name and value using GraphQL had to switch from deprecated `PRODUCT_VARIANT` keys to `PRODUCT_OPTION_VALUE` IDs — still only for native options. Color Product Option Value Translation Issue shows storefronts that keep English swatch names after a CSV upload, even on Dawn.

Theme line item properties (`properties[Width]`) persist text on the order. They do not change the price, and they are not translatable product options. If you already sell with dynamic product options, every extra field is another string that stays in the source language until the app owns translations.

Workarounds that look cheaper than they are

Split the catalog by language. “Banner — EN” and “Banderole — FR” each get three native options. You inherit duplicate URLs, split reviews, and a French visitor who lands on the English handle from ads. Price changes ship twice.

Paste JSON into Translate & Adapt. Some option apps dump labels into one metafield. You copy the blob, translate only the human strings, and pray the structure survives. One broken quote and the form dies. That does not scale when you add a field next week.

Locale forks in Liquid. `if request.locale == 'fr'` works until the next theme update or a third language. Validation, dropzone copy, and loader text are the strings teams skip. The formula still lives nowhere useful.

Leave the form in English. Fine for a specialist B2B buyer. Weak for a consumer market where “Minimum value is 40” is the only error they see after a failed add-to-cart.

None of these give you localized UI plus one pricing formula. That is the bar for Shopify multilingual product options that actually convert.

What Options Price Calculator translates

Options Price Calculator is Built for Shopify (listing: 5.0 from 25 reviews). Multilingual support is a Starter feature ($9.99/month). Conditional logic, the font picker, Product Personalizer live preview, and the real-time price breakdown are Premium ($14.99/month). Do not treat those as included on every plan.

Translations live in the Translations tab of each calculator — not inside Translate & Adapt:

• Language tabs are taken from locales that are enabled and published on the shop (Markets / Languages). Unpublished locales do not appear.

• The storefront language is detected automatically. Missing copy falls back to English.

• Translation rows exist only for fields that are on that calculator. Remove a swatch and those entries disappear.

Per field you can translate: label, placeholder, option labels (dropdown, radio, swatch, color picker, font picker), rich-text HTML, divider headings, checkbox checked/unchecked text stored on the line item, and — on Premium — Font Picker headings plus customizer placeholders for live preview.

System copy includes the final-price label, upload loader, file-upload button/dropzone/count/size messages, and computed-property labels. Validation covers required fields, number min/max, file limits, and min/max price. Tokens such as `{min}`, `{max}`, and `{count}` are filled by the app.

The formula keeps using field keys. French shoppers read “Largeur” and “Hauteur”; the builder still has:

``` product_price + (width * height) ```

or a setup charge from the formula examples:

``` product_price + 25 + (width * height) ```

You do not translate variables. You translate what humans read. One calculator, one variant link, many locales.

Example: made-to-measure blinds for EN and FR

Keep inventory variants for what is actually stocked — say fabric collection A/B. Everything else is a field:

1. Number `width` — EN “Width (mm)”, FR “Largeur (mm)”

2. Number `height` — “Drop (mm)” / “Hauteur (mm)”

3. Swatch `slat` — “Slat colour” / “Couleur des lames”, each colour with a numeric value

4. Radio `control` — “Control side” / “Côté de commande”

5. File upload — button “Upload a window photo” / “Télécharger une photo de la fenêtre”

Price: `product_price + (width * height / 1000000 * 89) + slat`. A French shopper sees French labels and the same live total. The order carries the translated checkbox/status strings; fulfillment still keys off `width`, `height`, `slat`. No second product, no variant per language.

A Premium conditional (higher rate above 2000 mm) can sit next to a rich-text note that you also translate in the same tab. Docs advice: translate every active language, keep labels short, put hints in placeholders, and re-check rich text wrapping per locale. Multiple calculators each have their own wording — useful when blinds are in millimetres and fabric is sold by the metre.

Getting it on the product page

1. Publish the target language in Shopify and attach it to the market. No published locale, no OPC tab.

2. Install Options Price Calculator. The Free plan is 20 uses (always free on a develop store). Multilingual support starts at Starter.

3. Add the theme app extension on the product template — How to Add the Extension to the Product Page.

4. Build fields and the formula in the source language first. Do not rename keys after you have traffic; translations follow the current field set.

5. Fill Translations for every published locale, including errors and upload strings.

6. Switch languages on the storefront: empty strings fall back to English, the price stays identical, cart and checkout keep the same configuration.

Server-side price validation is a global safety setting, not a translation feature. It still matters when the same calculator serves several markets.

Wrap-up

Shopify multilingual product options are not a fourth native option and not a cloned product. Platform translation covers three variant options; calculator copy lives in the app, per published locale, while the formula stays on keys.

Install Options Price Calculator and let shoppers configure in their language — without doubling the catalog.