WooCommerce multilingual: translate your store without WPML (2026)
Making a WooCommerce store truly multilingual means more than translating product titles. Cart strings, checkout flow, category pages, customer account pages, and order emails all need to work in each language. This guide covers what that actually requires, how the main approaches compare, and what you can skip.
What WooCommerce multilingual actually means
A fully multilingual WooCommerce store covers several distinct content areas:
Product pages
Product titles, short descriptions, full descriptions, and review text. The most content-heavy translation surface.
Category and tag pages
Category names, descriptions, and breadcrumb trails. These are also SEO-critical pages where translated content directly affects ranking.
Navigation
Menu items, header links, and footer navigation — usually the same strings as the rest of the WordPress theme.
Cart and checkout
WooCommerce ships dozens of UI strings: "Add to cart", "Proceed to checkout", field labels, validation messages, and shipping option text. These are PHP strings in WooCommerce core, not post content.
Order confirmation and account pages
Order status messages, "Thank you" page copy, and the customer account area (orders, addresses, account details).
Product variations and attributes
Variation labels like "Size", "Color", and their option values ("Small", "Medium", "Red") shown on product pages and in cart.
The three approaches
There are three main ways to make WooCommerce multilingual, each with a different model:
WPML + WooCommerce Multilingual plugin
Content duplication model: each product exists as a separate WordPress post per language. WPML links them. Translations are entered manually in the WordPress admin. Requires WPML, its WooCommerce multilingual workflow, and significant manual effort per product.
Polylang + Polylang for WooCommerce
Same content duplication model as WPML but at a lower license cost. The translation workflow is similarly manual — every product, category, and attribute requires a translated copy created in the admin. More affordable, but not less work.
Automatic translation (script tag)
A script added to the WordPress theme or via a plugin. No content duplication — the original product posts are unchanged. Eligible browser-rendered product, category, and cart text can be translated in place when a visitor switches language; checkout extensions and hosted payment pages require verification.
The WPML/Polylang problem for WooCommerce
The content duplication model creates a structural problem that grows with catalog size. Each product post must exist once per language — a separate WordPress post, a separate set of meta fields, and in WooCommerce terms, separate inventory and pricing if needed.
For a store with 200 products and 3 target languages: 600 database entries for products alone, before categories, tags, and attribute taxonomies. When you update a product description, you update it 3 times. When you add a new product, you create it 3 times.
Sync failures are common — updating the English version and forgetting the French copy means French customers see stale pricing or outdated descriptions until someone notices. WPML provides sync tools, but they add workflow overhead on every content update.
Polylang has the same structural issue. Lower cost, same maintenance burden.
How to add Lingvit to WooCommerce
Three steps:
- 1Install the Lingvit WordPress plugin from the WordPress plugin directory or upload the plugin ZIP in Plugins → Add New.
- 2In the Lingvit dashboard, create a project for your store. Copy the project ID shown in the setup screen.
- 3In WordPress admin under Settings → Lingvit, paste the project ID and select your target languages. Save. The plugin injects the script tag into every front-end page automatically.
No product posts are duplicated. Eligible product, category, and cart text can be translated at runtime and stored for reuse. Verify checkout extensions, payment-provider pages, and confirmation flows before publishing.
What gets translated automatically
Every text node rendered to the front end is translated. For a WooCommerce store, that covers:
| Content area | Translated automatically |
|---|---|
| Product titles and descriptions | Yes |
| Variation labels (Size, Color) and option values | Yes |
| Category and tag pages | Yes |
| WooCommerce cart strings ("Add to cart", "Subtotal") | Yes |
| Checkout flow strings and field labels | Yes |
| Order status messages | Yes |
| Customer account pages | Yes |
| Blog and content pages | Yes |
Scroll horizontally to view every column.
What you still need to handle separately
DOM-based translation only covers content rendered in the browser. Two areas fall outside that scope:
Transactional emails
WooCommerce sends order confirmation, shipping notification, and account emails from PHP server-side code. These are never rendered to a browser DOM. To translate them, configure per-language email templates in WooCommerce → Settings → Emailsor use a multilingual email plugin such as WooCommerce Multilingual Email or a similar solution that sends emails in the customer's locale.
Payment gateway and hosted pages
Stripe Checkout, PayPal hosted pages, and other off-site payment flows are served from the payment provider's domain. Their localization is controlled by the provider — most detect browser locale automatically. The WooCommerce checkout fields that precede the payment step are translated normally by Lingvit.
SEO for multilingual WooCommerce
Lingvit creates language-specific URLs for each language version of your store: /fr/shop/, /de/product/blue-chair/, etc. Each URL is independently indexable by search engines.
Hreflang tags are added automatically to every page, signaling to search engines which URL is the canonical version for each language and region. This prevents the original and translated URLs from competing with each other in search results.
Meta titles and descriptions are translated along with page content, so the translated language versions also have localized metadata in search results. Product schema (JSON-LD structured data) on each language URL includes the translated product name and description, enabling rich results in local search.
For WooCommerce category pages — which are often the highest-traffic SEO targets — translated category names and descriptions appear in the language-specific URLs, giving each version its own keyword relevance in the target language.
Frequently asked questions
- Does Lingvit work with Elementor product pages?
- Yes. Elementor renders HTML to the front end like any other page builder. Lingvit's MutationObserver handles Elementor-rendered content normally, including product page templates built with Elementor's WooCommerce widgets.
- What about Advanced Custom Fields (ACF) product fields?
- Yes, if the ACF field values are rendered to the front-end DOM. Fields displayed in product descriptions, tabs, or custom template areas are translated automatically. Fields used only in the WordPress admin or in server-side logic (custom emails, API responses) are not translated by Lingvit.
- Does Lingvit affect WooCommerce speed or performance?
- The script loads asynchronously and stored translations can be reused, but total performance depends on the page, browser, network, and widget delivery. Test representative product, cart, and checkout flows before launch.
Related guides
Translate your WooCommerce store
Simple monthly plans · Cached delivery included · Guided setup · Product pages, cart, and checkout.