Translating Webflow product variants: the problem, and where StoreLingo stands today

Product names and descriptions are the easy part of translating a Webflow store. Variants (a mug in three colours, a shirt in five sizes) are the hard part, because in Webflow they are separate records tied together by options. This post explains the structure and states plainly what StoreLingo does with variants today.

How Webflow stores a product with variants

A Webflow Ecommerce product is made of connected records:

1. The product. Name, description, slug and the other product fields, plus the definition of its options (for example "Color" with the values "Red" and "Blue").
2. The variants (SKUs). Each combination of option values is its own record with its own price, SKU code and stock.

The variant records point back at their product and at the option values they represent. That is what makes the option picker on a product page work.

Why variants are the hard part

Translating a product's name is a text change. Translating its variants means rebuilding that whole structure for the translated product: its own options with translated names and values, one variant record per combination, each linked correctly, with prices and stock decided per variant. If the links are wrong, Webflow can refuse to open the product in the Designer.

We know that last part first-hand. An early version of StoreLingo copied a field from the source product that pointed at the source's own variant, and the Designer then reported "Unable to open this product because a variant is missing" on the translated copy. StoreLingo no longer copies that field: it now builds the translated copy's own options and its own variant records.

What StoreLingo does today

• Product text. By default every text field that has text on at least one product is translated, and image alt text. In Settings you choose which. Slugs, SKU codes and identifiers are never translated.
• Every variant. The translated copy gets every variant of the source product. Per variant it takes the source's price, compare-at price, SKU code, images, dimensions and weight.
• Options. Option names and values ("Size", "Small") are translated like other fields and published with the product.
• Variant names. A variant name that Webflow generates (the product name plus its options) is not translated by itself: StoreLingo builds the translated name from the translated product name and options, the same way. A variant name you typed yourself can be translated in StoreLingo and is published.
• Publishing again. Re-publishing updates the translated fields, the options, and every variant's price, compare-at price, SKU code and images from the source. A variant added to the source is added to the copy. A variant removed from the source is removed from the copy; Webflow does not allow removing a product's default variant, so that one is set to stock 0. A source product you archive in Webflow gets an archived translated copy on the next publish.
• Stock. The translated copy is a separate product, so each of its variants has its own stock in Webflow. Stock sync is optional, set per site and off by default. When it is on, every translated variant takes its source variant's stock, and a stock change in one language is passed on to the others; two shoppers buying the last item in two languages at the same moment can both succeed. When it is off, StoreLingo does not read or change stock, except in one case: when you delete a variant from a source product, the next publish sets its translated copy out of stock and then deletes it, so it cannot be sold.

What this means for your store

The translated copy offers the same variants as the source product, with translated option names and values. When you change a price, a variant or an image on the source, StoreLingo picks up the change and marks the affected translations Needs review; the translated copy changes when you publish again. Before you turn on stock sync, decide whether the risk of selling the last item twice (two shoppers buying it in two languages at the same moment) is acceptable for your store.

The other parts of a product page that come from the page template, such as the "Add to cart" button and option labels typed into the Designer, are not translated by StoreLingo either. The cart and checkout pages, and the emails Webflow sends, stay as they are in Webflow.

Questions worth asking any tool about variants

1. Does the translated product get every variant, or only some?
2. Are option names and values translated, and where do the translations end up?
3. Is stock shared with the source product or separate?
4. When the source price changes, does the translated product's price follow?

For StoreLingo today the answers are: every variant; yes, published with the product; separate, with an optional stock sync that is off by default; yes, when you publish again. We would rather you know that before you start. Full publishing detail is in the publishing docs, and questions go to hello@storelingo.com.