Translate a WooCommerce store
POM Translate localizes one WooCommerce catalog without creating a product or order for every language. Product content, taxonomies, storefront requests, customer account routes, order language, and managed transactional emails each use the translation surface appropriate to their data.
Store catalog
Products retain one WordPress record. Their titles, long and short descriptions, supported custom fields, slugs, categories, tags, attributes, and variation labels can be rendered for the active POM locale. Prices, stock, SKUs, tax data, and other operational values remain shared.
Start with:
- WooCommerce requirements.
- Translate products.
- Complete variations, attributes, and product taxonomies.
- Verify shop and product URLs.
Buying journey
Cart, mini-cart, checkout, account, WC AJAX, and Store API output use the request locale. Locale-specific fragment keys prevent cached mini-cart HTML from one language being reused in another.
Test cart and checkout, notices, and My Account as one complete visitor journey.
Orders and email
Classic and block checkout save the normalized purchase locale on the order. POM Translate uses that snapshot when rendering supported customer emails and order-item text, with defined fallbacks for older orders.
The dedicated Translations → Other translations → WooCommerce emails workspace manages subjects, headings, additional content, and the shared footer. It supports placeholder validation, unsaved previews, explicit test recipients, and per-field POM AI drafts when available.
Continue with order language, the email overview, and background processing.
Important boundary
WooCommerce and extension interface messages shipped through gettext still require the corresponding language packs or exported PO/MO files. Dynamic customer or order data is not automatically registered as a translatable string.
Use WooCommerce troubleshooting to isolate catalog, request-locale, routing, or email problems.