How to Make a Multilingual WooCommerce Store: Products, Menus, and Checkout (2026)

A customer can read your pizza description in Spanish, choose a size, and still abandon the order when checkout suddenly switches to English. That’s the difference between translating a few pages and building a multilingual WooCommerce store that actually works.

The tricky part isn’t usually the headline text. It’s the topping selector, the pickup instructions, the payment error, and the confirmation email sent after someone has already paid. For restaurant stores, those details also determine whether the kitchen prepares the right food.

A good multilingual setup keeps language consistent while preserving one reliable source of truth for products, prices, inventory, and orders. Here’s how to approach it in 2026.

What Needs Translating in a WooCommerce Store?

Browser translation changes what an individual visitor sees. It doesn’t give your store published language versions, editable translations, or language-specific URLs that search engines can discover. It also won’t reliably handle your customer emails or a payment screen hosted elsewhere.

A multilingual WooCommerce store manages those language versions deliberately. Customers can choose their language, move between equivalent pages, and complete an order without having to decipher the original wording.

Start by mapping the entire journey. Navigation includes header links, search, category names, footer links, and mobile menus. On restaurant websites, “menu” means two different things: the website navigation and the food catalog. Both need attention.

Product content extends beyond descriptions. Translate variation names, dietary labels, topping groups, ordering instructions, availability messages, and buttons generated by your ordering extensions. “Choose up to three toppings” is a purchasing rule, not decorative copy.

Then follow the transaction through cart notices, delivery zones, pickup instructions, checkout fields, payment messages, account screens, and password-reset emails. Include refund, privacy, delivery, and cancellation policies, with professional review where legal obligations require it.

A simple translation inventory helps:

• Record each screen or message and the plugin or theme that produces it.
• Assign a translation method: product editor, string translation, plugin setting, or external service.
• Name the reviewer and track whether the translated version has been tested.

Multiple languages don’t require multiple currencies. A restaurant serving English- and Spanish-speaking customers in the same city can keep every price in euros. Currency conversion introduces separate pricing, rounding, payment, and reporting decisions; leave it out unless the business actually needs it.

Choose a Translation Plugin That Works with Your Store

WPML, TranslatePress, and Polylang-based setups take different approaches. The relevant comparison isn’t simply how many languages each supports. It’s how translations interact with your specific WooCommerce extensions.

Licensing, automatic translation allowances, and compatibility change. Treat the following as a workflow comparison, not a live pricing quotation; confirm current requirements in each product’s documentation before purchasing or publishing a compatibility claim.

WPML: managed translations with WooCommerce integration

WPML organizes translations around connected content, translation jobs, and string translation. Its WooCommerce integration coordinates multilingual product data and store behavior. This is the configuration used for the worked example below, not a claim that every WooCommerce extension supports it.

A complete store setup generally requires a paid WPML package that includes WooCommerce support and String Translation, typically the Multilingual CMS or Agency tier, plus the WooCommerce integration component. Automatic translation uses credits; included allowances and additional costs depend on the current plan and translation engine.

TranslatePress: visual translation of rendered pages

TranslatePress uses a front-end visual workflow: translations are edited in the context of the displayed page. Its free version supports one additional language; multiple additional languages and multilingual SEO capabilities require the appropriate paid components.

Automatic translation costs depend on the service or allowance being used. A visible page translation still doesn’t prove that dynamic checkout errors, emails, or externally hosted payment screens are covered. Those need separate verification.

Polylang-based WooCommerce setups: linked language content

Polylang manages linked language versions of WordPress content. WooCommerce requires the paid Polylang for WooCommerce extension; the free core plugin alone isn’t a complete multilingual store setup. Polylang Pro or a bundle may be relevant for additional workflow features.

Don’t assume automatic translation is included throughout the stack. Check the current edition, supported integrations, and any external translation charges separately.

Before settling on an architecture, list your theme, product add-ons, restaurant ordering tools, SEO plugin, payment gateways, and checkout type. Check documented compatibility for the versions you’re installing, particularly Checkout Blocks versus classic checkout. Then verify it on staging. A general “WooCommerce compatible” statement doesn’t establish that a JavaScript topping selector or custom pickup field translates correctly.

Set Up Your Languages, URLs, and Language Switcher

Build the configuration on staging first

Take a database and file backup, then create a staging copy. Block public access where possible, prevent indexing, route emails to a test inbox, and disable live payments and automatic printing. A staging order shouldn’t send a mystery pizza to the kitchen.

For the WPML example, the usual stack is WPML Multilingual CMS, String Translation, and the integration commonly known as WooCommerce Multilingual & Multicurrency. Install compatible releases through the supported installation process for your license. Component names and packaging can change, so follow the current setup wizard rather than an old screenshot.

A practical setup sequence looks like this:

1. Confirm the language your existing content actually uses, and select it as the original language.
2. Add one secondary language initially. Finish its ordering journey before adding several more.
3. Complete the WooCommerce integration setup, including the required shop, cart, checkout, and account page translations.
4. Select your URL structure and translation publication preferences.
5. Translate a small pilot catalog and run test orders before processing the full menu.

Give each language a stable URL

Language directories are usually straightforward for a single store: the original product might use /product/margherita/, with its Spanish equivalent under /es/product/margherita/. Translated product slugs and URL bases depend on configuration; they aren’t required simply to make a language directory work.

Separate domains can also represent languages, but they add DNS, certificate, analytics, and cookie considerations. For a local restaurant, directories are often the simpler operational choice. Decide early rather than changing indexed URLs after launch.

Make language selection obvious and usable

Use readable names such as “English” and “Español,” not flags alone. Languages don’t map neatly to countries. The switcher should work with keyboard navigation, have a visible focus state, and remain easy to tap on a narrow mobile screen.

Place it somewhere customers can find before ordering. Test whether switching from a product takes them to its translated equivalent, and whether changing language preserves their cart. Don’t assume either behavior without testing your configuration.

Choose fallback behavior deliberately. Depending on post-type settings, untranslated products may display original-language content or disappear from the secondary-language catalog. Neither is a substitute for publishing critical translations. Avoid forced browser-language redirects that override customer choice, and check that the document’s language attribute reflects the selected language.

[IMAGE: Mobile WooCommerce restaurant menu in English and Spanish, showing a text-based language switcher, matching product pages, and the same euro prices]

Translate Products, Restaurant Menus, and Ordering Options

Use one representative product as your test case. A plain product with no options is too easy; pick something that exercises the store’s real ordering rules.

Consider a Margherita pizza priced at €12, with a large variation at €16 and an extra-mozzarella option costing €2. Its content includes a description, a “Pizza” category, size attributes, dietary information, and a note asking customers to select pickup or delivery at checkout.

Translate meaning while keeping commercial data connected

Create the linked Spanish translation through the configured translation workflow. The product name may remain “Margherita,” while “Size,” “Regular,” and “Large” become “Tamaño,” “Mediana,” and “Grande,” subject to review for the restaurant’s intended audience.

Translate product categories and global attribute terms as well as the description. Local, product-specific attributes may follow a different editing path. Check that the translated product contains the expected variations and that each selection resolves to the correct purchasable item.

Keep prices, SKUs, and inventory governed by the integration’s supported synchronization behavior rather than editing translations as unrelated products. Review its settings and documentation for stock and variation data. Custom fields need their own treatment; a numeric preparation time may be copied, while its explanatory text needs translation.

With a single-currency setup, changing languages shouldn’t turn the €16 large pizza into a differently priced product. Test a purchase from each language and confirm that stock is reduced against the same linked inventory. If stock is managed per variation, test that level specifically.

Find the text outside the product description

Toppings and modifiers often live in product add-on settings, custom fields, option records, or JavaScript interfaces. They may not appear automatically in the product translation editor.

Identify the owner of each missing string. Check the extension’s multilingual instructions, then inspect the translation system’s string search or custom-field controls. Some settings require registration for translation; others need a documented integration. Avoid blindly marking every custom field as translatable, especially serialized configuration or internal identifiers.

For restaurant operations, FoodMaster is a practical starting point when you need a WooCommerce restaurant ordering system with delivery, pickup, and QR table ordering. It also includes POS, kitchen display, and automatic printing capabilities. Validate its exact translation workflow with your installed versions rather than assuming every ordering screen or printed field translates automatically.

Review food language with extra care

Machine translation can produce a useful first draft. It shouldn’t approve allergen statements. Have a qualified reviewer check ingredients, allergen declarations, cross-contact warnings, and dietary claims against the restaurant’s actual recipes and procedures.

“Vegan option available” is not the same as “vegan.” Nor does “no gluten-containing ingredients” establish that preparation is safe for someone with coeliac disease. Translate the precise claim the business can support, not a shorter phrase that sounds nicer.

Finally, test modifier rules in both languages: minimum selections, maximum selections, required options, and surcharges. A translated topping label means little if its €2 charge disappears at checkout.

Translate Checkout, Customer Accounts, and Order Emails

WooCommerce language packs supply many standard interface translations. They don’t cover all custom checkout copy, extension-generated messages, or text entered in your store settings. That last stretch deserves its own review.

Inspect checkout in its actual operating state

Test both an empty cart and a populated one. Then trigger missing-field errors, invalid coupons, unavailable delivery addresses, sold-out items, and payment failures using supported test methods. Validation messages often reveal untranslated strings that a normal purchase never exposes.

Check shipping method titles, local pickup wording, preparation estimates, order notes, and payment instructions. “Shipping address” may be technically understandable but awkward for a restaurant offering only counter pickup. Keep the wording accurate for the selected fulfillment method.

Checkout Blocks and classic checkout render parts of the interface differently. Confirm which one your store uses and test the active implementation, including dynamically loaded fields. Translating a classic checkout page doesn’t establish coverage for a block-based checkout.

If you offer gratuities, a WooCommerce checkout tipping option such as Tipping – Add Order Tip for WooCommerce adds another set of labels to inspect. Verify the preset or custom amount wording, checkout compatibility, and how the tip appears in order details and emails.

Check the payment provider boundary

Hosted payment screens and authentication challenges may use the gateway’s locale parameter, the customer’s browser language, or provider-controlled settings. Your WordPress translation plugin cannot necessarily control them.

Run sandbox payments in each language and observe that handoff. Also verify where customers land after payment or cancellation, and whether the return page keeps the language they selected.

Follow the order beyond the thank-you page

Translate account navigation, order history, address forms, password-reset messages, and essential policy pages. Open policy links from the translated checkout itself; a translated policy hidden elsewhere won’t help.

Test customer emails for guest and registered purchases, including processing, completion, and refund messages. Some integrations track the order language, but custom templates and third-party email tools may behave differently. Test messages triggered later by an administrator, too.

The kitchen has a different requirement: consistent fulfillment information. Establish a staff-readable naming convention, retaining SKUs and option identifiers where supported. If bilingual tickets are necessary, confirm that capability rather than assuming it. A translated storefront must still produce an unambiguous large Margherita with extra mozzarella for the correct pickup time.

[IMAGE: Multilingual test-order review showing Spanish checkout and confirmation email alongside a staff-readable kitchen ticket with pizza size, topping surcharge, and pickup time]

Check Multilingual SEO and Test an Order in Every Language

Translated content needs discoverable URLs, accurate language signals, and useful search snippets. It doesn’t need three different plugins injecting competing tags into the same page.

Inspect SEO output, not just dashboard settings

Translate product and category SEO titles, meta descriptions, and relevant image alternative text. Use phrases customers actually use in that language; a literal translation of an English keyword isn’t always how local diners search. Keep location names, opening hours, and ordering promises accurate.

Confirm that published language pages return successfully and aren’t blocked by robots rules or a leftover staging noindex setting. Each equivalent page should have appropriate hreflang references, including reciprocal references and itself. Hreflang identifies language or regional alternatives; it doesn’t translate content or guarantee indexing.

Distinct translated pages generally need self-referencing canonical URLs. Pointing all Spanish pages’ canonicals to English versions sends conflicting signals about which pages should be indexed. Inspect the rendered output from your translation and SEO integrations before adding custom fixes.

Check XML sitemaps for the intended indexable language URLs and follow a sample of their links. If your plugins already generate hreflang, canonicals, or sitemap language information, don’t add duplicate implementations. Also inspect product structured data so displayed names, availability, prices, and currency remain consistent with the page.

Run a repeatable launch checklist

Place a complete order in every language on mobile and desktop. Use at least one variable product with a paid modifier, and test each fulfillment method. Record expected results so the same checks can be repeated after updates.

• Confirm that mobile navigation and the language switcher are usable and preserve the intended destination.
• Check language persistence through product selection, cart, checkout, payment, and account pages.
• Verify variation prices, modifier charges, taxes, delivery fees, tips, and the final total.
• Confirm shared stock behavior and translated out-of-stock messages.
• Trigger checkout errors and verify payment return and cancellation pages.
• Inspect customer emails, staff notifications, kitchen displays, and printer output.
• Test logged-out browsing with caching enabled; exclude transactional pages and ensure cached content doesn’t mix languages.
• Follow menu, policy, password-reset, and email links for broken destinations or untranslated pages.

After launch, include translation review whenever recipes, prices, policies, or ordering rules change. The goal isn’t merely a store with a language switcher. It’s a store where customers understand what they’re ordering—and the team receives exactly the information needed to fulfill it.