WooCommerce + WPML or Polylang: Why Most Chat Plugins Fail Multilingual Stores

If you sell across borders on WooCommerce, you're running WPML, Polylang, or TranslatePress. Maybe two of them on different sites. The translation layer is so common that store owners stop noticing it as a separate plugin. It's just how the store works.

Then a chat plugin gets installed and the cracks show within a day. The shopper on the French version of the store gets answers in English. Or the chat finds an English product and recommends it on a German page where the same product has a German URL. Or worst, the chat says a product exists, links to it, and the link 404s because the chat indexed the master language only.

I've watched this happen on multiple stores. The store owner files it as "weird chat behavior" and tries a different chat plugin. The new one breaks the same way. Most chat plugins were not designed for the way WordPress translation plugins store data, and the failures look identical from one vendor to the next.

How WPML, Polylang, and TranslatePress Store Data

This is the piece most chat plugins skip over. Each translation plugin uses a different model.

WPML: Separate Posts Linked by trid

WPML creates a new WP_Post for every translation. The original product, its French translation, and its German translation are three separate posts with three separate IDs. They're tied together through a translation ID (trid) in the wp_icl_translations table.

If a chat plugin queries wp_posts for products and stops there, it gets all three posts as separate products. The chat will index a French and English version as if they were two unrelated SKUs. Same image, different language, different ID. Pure data duplication, and the chat will recommend whichever language version it ranks highest in its embedding space, which is usually the master.

Polylang: Same Pattern, Different Tables

Polylang follows the same separate-post model as WPML, but stores its translation links in wp_term_taxonomy with a post_translations taxonomy. The grouping mechanism is different; the consequence for a naive chat plugin is the same. Each language version is a distinct post.

TranslatePress: Same Post, Translated at Render

TranslatePress takes the opposite approach. There's one post in wp_posts. The translations live in a separate wp_trp_dictionary_xx_YY table, keyed by the original string. When the storefront renders, TranslatePress swaps strings as the page builds.

A chat plugin that reads wp_posts sees the master language only. It never finds the French version because the French content lives in a string-replacement table the plugin doesn't query. The chat answers French shoppers from the English post. Sometimes the LLM translates on the fly; sometimes it doesn't. Either way, the experience is wrong.

The Three Multilingual Failure Modes

1. Indexing One Language and Translating the Rest at Runtime

The cheapest path for a chat vendor: index the master language, ask the LLM to translate the answer at conversation time. It works for greetings and category questions. It fails the moment a shopper types something specific.

"Avez-vous le sac à main en cuir noir taille moyenne?" The chat searches its English index for "leather handbag black medium." The English translation in the catalog might say "midsize." The vector search misses. The shopper gets a "I couldn't find that" message in French. The product is on the storefront in French.

You don't see this in chat dashboards because the conversation looks normal. You see it in the conversion data: French shoppers convert at half the English rate.

2. Indexing Each Translation as a Separate Product

The plugin reads wp_posts and indexes everything it finds. The chat ends up with three "Black Leather Handbag" entries (English, French, German), all with similar embeddings. When a shopper asks about it, the chat picks one at random or by language detection that doesn't always work.

The recommendation links to the master language URL. The shopper on the French site clicks through and lands on a 404 or on the English page in the middle of their French shopping flow. Trust gone.

3. Indexing Per Language But Linking Wrong on Recommendation

Some plugins do the harder work: detect the visitor's language from the page, route the query to the right language index. But when the chat returns a product card, it returns the URL from its index without routing it back through the translation lookup.

The chat says "Voici le sac" and links to /en/black-leather-handbag/ instead of /fr/sac-a-main-en-cuir-noir/. The link works, but the shopper now reads English on a French shopping flow. Some bounce immediately.

What Multilingual-Aware Chat Needs

For the chat to behave correctly on a WPML, Polylang, or TranslatePress store, four things need to happen:

1. Recognize the visitor's language from the page context. The widget needs to know the storefront language at conversation start, not guess from the message text. WPML and Polylang surface the active language as ICL_LANGUAGE_CODE or pll_current_language(). The widget should pass this to the chat backend on every session.
2. Index every translation as a language variant of the same product. Three URLs, one product, three sets of translated text. The chat searches across all variants but recommends the URL that matches the visitor's language.
3. Resolve translation grouping at sync time. When the plugin emits a webhook for a product save, it should walk the WPML trid or Polylang post_translations taxonomy, find every linked translation, and emit a single payload with all language versions. For TranslatePress, the plugin should query the dictionary tables and consolidate.
4. Swap the URL on recommendation. When the chat picks a product to recommend, it picks the URL that matches the visitor's language code, not the index hit's URL.

How Emporiqa Handles WPML, Polylang, and TranslatePress

The Emporiqa plugin auto-detects which translation plugin is installed and queries the right grouping mechanism. On product save, the plugin emits a single webhook for the product with a translations map: {en: {name, description, slug, url}, fr: {…}, de: {…}}. The chat indexes all three as one logical product.

The widget reads the page language from ICL_LANGUAGE_CODE (WPML), pll_current_language() (Polylang), or the TranslatePress URL prefix, and passes it on every conversation. The chat searches across all language variants and recommends with the matching URL.

If you've localized custom fields (ACF strings, attribute labels in non-standard places), the plugin exposes a filter:

add_filter('emporiqa_product_translations', function($translations, $product) {
    foreach ($translations as $lang => &$data) {
        $data['custom_label'] = pll_translate_string('Default Label', $lang);
    }
    return $translations;
}, 10, 2);

That filter runs once per product on save, so the chat index reflects whatever translation logic your store uses.

How to Test a Chat Plugin on Your Multilingual Store

Before you commit to a chat plugin on a WPML, Polylang, or TranslatePress store, run this five-minute test:

1. Open the storefront in your second language. If your store is English-master and French-secondary, navigate to /fr/.
2. Ask the chat a specific product question in French. Use a phrase that only matches the French product description, not the English. "Avez-vous une lampe de chevet en bois?" works if "bedside lamp wood" is how the English version reads.
3. Check the response language. The chat should answer in French, not English.
4. Click the recommended product link. The URL should be the French URL (/fr/...), not the master URL.
5. Repeat for any third language the store supports.

Any failure on those four points means the chat is breaking on translation. The store will leak conversion on every non-master-language session, and the chat dashboard won't show the loss because the conversation completed.

What This Doesn't Do

• Auto-translate untranslated content. If a product exists in English only and a French shopper asks about it, the chat will not invent a French version. It will tell the shopper the product isn't available in French and suggest the closest translated alternative. Stores that want auto-translation should run their translation plugin's machine-translation step first.
• Translate the chat widget UI. The widget supports 65+ languages, but the labels are picked from a fixed set. Custom UI strings (greeting, opener, prompts) need to be configured per language in the Emporiqa admin.
• Sync language-specific stock or pricing differences. If your store sets different prices per language (rare but real), expose that through the WordPress filter above. The default sync uses one price per product.

Why This Matters Most for Stores Selling in 3+ Languages

For a single-language store, multilingual handling is moot. For a store with English plus one secondary language, you might tolerate the runtime-translate model and not lose much. By the third language, the runtime translation cost compounds and the search-mismatch failures become visible in the bounce data.

If your store sells in three or more languages, the chat plugin you pick will quietly determine your conversion rate in your secondary markets. The five-minute test above is the cheapest way to know what you're getting before you sign a year of monthly fees.

Related reading: the cross-platform multilingual case in your German customers are leaving, the WC-specific failures around variable products, the HPOS migration impact, and surviving peak load. For the full WooCommerce setup walkthrough, see why most WooCommerce chat plugins get the architecture wrong.

Try the live demo at demo.emporiqa.com in any of 65+ languages, or install the plugin on a sandbox store with WPML or Polylang. Multilingual coverage is documented in the WooCommerce docs.