← All articles

Building a Multilingual WooCommerce Platform: What WPML Doesn't Tell You

WPML's documentation covers translating pages and products. It says much less about what happens when you add WooCommerce, RTL Arabic, LearnDash courses, and Stripe checkout into the same build. Here's what I ran into building a three-language (Arabic, German, English) e-learning and commerce platform from scratch, and how to plan for it before you start, not after something breaks in production.

RTL is not a CSS toggle you flip at the end

Arabic support means every layout decision — checkout steps, progress bars, price displays, navigation — needs to work mirrored, not just have direction: rtl applied to it. Icons with directional meaning (arrows, "next" buttons) need RTL-aware variants. Test the checkout flow specifically in Arabic before launch, not just the homepage — checkout is where broken RTL costs you a sale, not just a bad first impression.

Legal and invoicing content is not "just another translation"

For a German-market store, invoices, terms, and privacy pages aren't marketing copy you can approximate in translation — they're compliance documents with specific legal phrasing requirements per market. Route these through WPML like everything else, but budget separately for legally accurate translation rather than treating them as one more page in the content queue.

Automatic invoicing needs to respect the transaction language, not the site default

If a German customer buys in German, their invoice PDF should generate in German — automatically, not as a manual step. This sounds obvious until you're wiring WooCommerce, an invoicing plugin, and WPML together and discover the invoice plugin defaults to the site's primary language unless you specifically configure it to follow the order's language meta. Test this with a real purchase in each language before launch.

LearnDash + WPML: sync your course structure, not just the strings

Translating a LearnDash course isn't just translating lesson titles. Course structure, quiz logic, and completion certificates all need to exist per language, and progress tracking needs to work correctly regardless of which language version a student is enrolled through. Plan the course architecture with translation in mind from the start — retrofitting a single-language course structure into three languages after the fact costs far more than building it multilingual from day one.

Cookie consent needs real translation, not machine translation defaults

GDPR consent banners (Complianz and similar plugins) typically ship with machine-translated strings for non-primary languages. On a build serving Arabic, German, and English audiences, I had to manually correct the consent banner across all three languages and all three of the plugin's internal rendering paths — it wasn't one translation layer, it was three.

Plan the language-switch UX before you build pages

Where does a logged-in customer land when they switch languages mid-checkout? Does their cart survive the switch? Decide this during planning, not during QA — it changes how you structure the checkout flow, not just how you translate it.

The actual lesson

WPML handles the mechanics of translation correctly. Everything that breaks in a real multilingual WooCommerce build happens at the seams — where WooCommerce, LearnDash, payment processing, and legal compliance all need to agree on which language a specific customer is in, at a specific moment, and act accordingly. Plan for the seams, not just the translation.

Building or fixing a multilingual WordPress platform? This is exactly the kind of project I take on — see the WordPress Build package or book a free 30-minute call.