How to translate a WooCommerce store, page by page

A WooCommerce store is a WordPress site with a few pages that behave differently from the rest. Product and shop pages are ordinary content and translate like any other page. The cart, the checkout and the customer account are built for each shopper, partly by JavaScript, so their text and their links change while the visitor clicks around. A translation plugin that handles articles well can still leave a Spanish shopper with an English checkout.

The pages a WooCommerce store adds#

WooCommerce's setup wizard creates a Shop, a Cart, a Checkout and a My account page, along with an unpublished draft of a refund and returns policy. The Cart and Checkout pages hold WooCommerce's Cart and Checkout blocks, and My account holds the [woocommerce_my_account] shortcode. You can see which page plays which role under WooCommerce, Settings, Advanced, in the Page setup section. Products are their own post type, each with its own address.

Those pages fall into two groups for translation:

• Pages whose text is the same for every visitor: the shop, product categories, product pages, and the parts of the cart and checkout that say the same thing to everyone, such as headings and button labels.
• Text that exists for one shopper only: the lines in a cart, a shipping estimate, the fields a shopper fills in at checkout, an order history behind a login.

The first group is where a store's search traffic lands, so it is where translation pays off. The second group is where most of the problems are.

Product and shop pages#

LangRelay's plugin translates the page WordPress renders, so a product page arrives with everything on it: the title, the description, the short description, attribute labels, the theme's own text and anything a page builder added. The plugin's FAQ on WordPress.org says the same: product and shop pages are translated like any other page once their translation is approved.

Nothing becomes a separate post. Your product stays one product with one stock count, one price and one set of variations, and the Spanish version is served from the same post under /es/. When you edit the English description, the plugin reports the change about a minute later and LangRelay machine-translates only the new text. The rest of the approved Spanish page stays live, and the changed lines go live like any other translation: right away by default, unless the free checks hold them. Until then they show in English.

Each translated product page gets its own hreflang, canonical and html lang, and translated meta titles and descriptions, so search engines can index the Spanish product page on its own. By default it keeps the source path under the language prefix. You can give a product a Spanish address by hand in the LangRelay Dashboard, which is worth doing for the products that bring in most of your search traffic.

The cart, the mini-cart and the notices#

A Spanish shopper's path to the cart works like this today:

1. On /es/ product pages, the Add to cart button and its label are part of the translated page.
2. Clicking it shows WooCommerce's added-to-cart notice and fills the mini-cart with the product. That text is added by JavaScript after the page has loaded, so no server-side translation can reach it. LangRelay's script in the browser translates it when the same text already has an approved translation somewhere on your site, which for the product's name is its own product page.
3. The View cart link inside that notice is also added by JavaScript, with the English path. The browser script points it at the Spanish cart page when that page has a live translation.
4. On the cart page itself, the headings, labels and buttons that have approved translations are translated.

So a shopper on /es/ who adds a product sees its name and the notice's link in Spanish, and the browser script leaves everything the server delivered exactly as it was.

The browser script sends no page text to LangRelay and never sends the page's address. That matters on a store, because WooCommerce's order confirmation URL carries an order key in its query string.

Checkout#

The checkout needs the most care, because WooCommerce's block checkout builds most of itself in the browser. Headings and labels that have approved translations are covered. Text that is specific to one shopper, such as their saved address or the form fields WooCommerce fills in, can stay in the original language, and LangRelay's FAQ on WordPress.org says so. A few labels the block checkout draws while the page is still loading can stay in the original language too.

Before you launch a language, place a test order in it and read every screen, including the order received page and the email.

The customer account#

The account area sits behind a login. LangRelay finds a store's text by crawling it and by exploring it in a browser that clicks buttons, opens drawers and adds a product to a cart. That browser never submits a form, never signs in and never places an order, so text that only a signed-in customer sees, such as an order history table, is not discovered there and can stay in the original language.

What is coming for WooCommerce#

Two WooCommerce features are on LangRelay's roadmap. The plugin will:

• add the shopper's language prefix to the cart, checkout and account URLs WooCommerce builds itself, including account endpoints such as /es/my-account/orders/;
• record the language on each new order, so a later order email can use it.

Today a link to the cart in the page's HTML already follows the language when the cart page is translated. The roadmap item covers the addresses WooCommerce builds as it runs, such as the redirect after checkout.

How other WordPress plugins handle WooCommerce#

The main WordPress translation plugins all cover WooCommerce, with different setups:

• WPML includes WooCommerce support in its Multilingual CMS licence, €99 a year, and its Multilingual Agency licence, €199 a year, but not in Multilingual Blog. WPML also documents multiple currencies and payment gateways for WooCommerce stores, which LangRelay does not offer.
• Polylang needs its Polylang for WooCommerce add-on for a store, priced by Polylang from €99 a year. The core Polylang plugin is free on WordPress.org with no limit on the number of languages, and a Polylang Pro licence that is not renewed keeps working, without updates or support.
• TranslatePress lists WooCommerce among the things its plugin supports on WordPress.org, and like LangRelay it keeps one post per page. Its free plugin includes a front-end visual editor with a live preview, so a shop owner can translate a product page while looking at it.

WPML and Polylang store each translation as its own WordPress post, so a translated product is a second product linked to the first. LangRelay and TranslatePress keep one product and translate what it renders. Prices above were checked on each vendor's site on 2026-10-07. The comparison of WordPress translation plugins goes further, and WordPress multilingual without duplicating pages explains the two storage models.

A launch checklist for a translated store#

• Translate and check the shop, category and best-selling product pages first; they carry the search traffic.
• Make sure the cart and checkout pages are live in the language before you add a language switcher, so no shopper lands on an English checkout from a Spanish page.
• Put product and brand names in the glossary as Keep as source where they should not change.
• Place one test order per language and read the confirmation page and the email.
• Check one product page's source for the language's hreflang and lang.

The WordPress translation guide covers installing and connecting the plugin, and language switcher best practices covers where shoppers look for it. Language guides such as Spanish website translation cover register and regional variants. To go through your own store with us, book a demo.