Multilingual Stores: Which Translation Plugins Work With AI Search?

If your WordPress or WooCommerce store runs in 2+ languages, AI search behavior depends entirely on which translation plugin you use. Some pair well with Queryra out of the box. Others mix languages in search results until we ship dedicated support. This post is the honest status — what works today, what's coming, and what to do if you can't wait.

A store owner installed Queryra last week and uninstalled three days later. The deactivation note said:

> *I have a store with two languages and do not want to receive mixed results.*

That's a fair complaint. The store ran on WPML — Bulgarian and English. Queryra indexed every translated post as a separate record (which is correct), but didn't filter results by the visitor's active language. So someone shopping in Bulgarian saw English results sprinkled in. Useless, slightly insulting, and an instant uninstall.

We could have hidden behind "multilingual support is on the roadmap." Instead — this post. If you run a store in two or more languages, you deserve a clear answer before you install.

When a French shopper types *crème hydratante* and gets back a mix of French moisturizers and English ones, three things happen:

• The results feel sloppy — the kind of thing you'd expect from a hobby site, not a store you're about to give your card to
• The shopper has to mentally filter the wrong language out, which is friction nobody signed up for
• Trust drops. If the search can't speak my language, what else doesn't work?

For a store owner running localized SEO and customer service, this is a dealbreaker. Single-language queries on a single-language store work great with AI. The trouble starts the moment you add a second language to the same WordPress install.

Before the status table, a quick technical note — because the answer depends on how each plugin stores translations.

Model A: Separate posts (WPML, Polylang)

Each translated version is a separate row in wp_posts with its own ID. So a product with English, French, and German has three IDs in the database. Plugins link them via a translation group ID in a helper table.

For Queryra, this means three records per product, one per language. Without a language filter at search time, the AI sees them as three different things and may return any of them.

Model B: One post with translations stored separately (TranslatePress, Weglot)

One row in wp_posts. The translations live in a custom table (TranslatePress) or a JavaScript layer (Weglot), and the right version is rendered based on URL or visitor language.

For Queryra, this means each language version comes through with the right content already attached — the plugin handles language selection at render time, before the data hits us.

The difference is everything for AI search compatibility.

Here's where each plugin stands:

If you're shopping for a translation plugin and AI search matters, TranslatePress and Weglot are both safe picks today. They handle multilingual stores differently (TranslatePress stores translations in a custom database table; Weglot stores them on its cloud — both keep a single canonical post per item in WordPress), but both pair cleanly with Queryra. More on Weglot specifically.

When a visitor lands on /en/ and types *crème hydratante* in French, Queryra returns the English moisturizers — not the French ones. Why? The visitor is browsing the English version of your store. Switching them to French results would yank them off the page they're shopping on.

The rule: the active URL prefix wins, not the query language.

• Visitor on /en/ → English results, regardless of how the query was typed
• Visitor on /pl/ → Polish results, even if they search *écharpe rouge*
• Visitor on /de/ → German results, no exceptions
• Visitor on /bg/ → Bulgarian results — even if a French shopper accidentally lands there

This is the right behavior for stores. A French-speaking visitor on the English site is probably checking prices, shipping, or product specs — not signaling they want to switch languages mid-flow. They want their query understood (the embedding model handles 50+ languages out of the box) but the results need to stay where they are.

If you *want* to redirect visitors to their language version, that's a navigation concern — handled by the translation plugin's language switcher or your theme's geolocation logic, not by search.

Five-minute version:

1. Pretty Permalinks must be on — Settings → Permalinks → anything except "Plain." TranslatePress uses URL-based language switching (/fr/, /de/) which needs pretty permalinks.
2. Add languages in TranslatePress — Settings → TranslatePress → set default + translation languages. Translate posts and products in the front-end editor.
3. Sync your records to Queryra — Dashboard → Sync. TranslatePress keeps a single canonical post per item (translations live in custom database tables), so a 100-product store stays at 100 records regardless of how many languages you add. Multilingual queries are handled by Queryra's parser at search time — a Polish shopper typing kurtka wodoodporna matches the same canonical product as an English shopper typing waterproof jacket.
4. Test from the front-end — open in incognito, switch language with the TranslatePress switcher, run a search. Results should appear in the active language only. If you see mixed results, re-sync once more.

For the full guide with FAQ and edge cases: TranslatePress integration docs.

If you're already on WPML or Polylang and can't switch, here's the honest situation.

Option 1 — Wait 2-3 weeks. We're actively working on language detection at sync (using apply_filters('wpml_post_language_details') for WPML and pll_get_post_language() for Polylang) plus a lang filter at search time. When ready, you flip a toggle and language-aware results just work. No re-sync, no setup. Roadmap pages: WPML, Polylang.

Option 2 — Run a separate Queryra account per language. Sync only that language's posts to each account, swap the API key based on the visitor's active language. Brittle and doubles your record count, but works as a stopgap if you absolutely can't wait.

There isn't a clean third option today. Queryra's REST API doesn't expose a language field on records or a lang filter at search — that's exactly the v1.3 work. If you've been told otherwise (including by us in earlier docs), it was wrong and we've corrected it.

On Weglot: unlike WPML and Polylang, Weglot already works without waiting — see the Weglot integration guide for the recommended setup.

A few "workarounds" we've seen suggested elsewhere — none of them work well:

• "Just sync only one language and hide the rest from search" — sometimes recommended, but breaks the second language entirely. Customers in the hidden language get zero results.
• "Use language as a synonym list" — keyword-search trick that doesn't translate to semantic AI. The embedding model handles meaning, not literal substitution.
• "Run two Queryra accounts, one per language" — technically possible, doubles your record limit cost, and the language switch from your front-end has to swap API keys at runtime. Brittle and expensive.

The right answer is language-aware filtering at the API level. That's the work in progress.

Concrete dates, not "soon":

• WPML support — 2-3 weeks. Detection of active WPML license, per-language indexing tags, and a language filter on search. Targets WPML Multilingual Blog, CMS, and Agency tiers.
• Polylang support — 2-3 weeks. Same approach, using Polylang's hooks. Free and Pro tiers both supported.
• Magento module — 6-8 weeks. Native module with multi-store and multi-language support out of the box (since Magento has both built-in).

Weglot already works today — Queryra's multilingual parser handles queries natively, regardless of how Weglot renders translations. See the Weglot integration guide for the recommended setup.

The feature work tracks the Queryra status page on GitHub — if you want to follow along, that's the source of truth.

• Single-language store — AI search works in any language. No special setup. The 50+ language embedding model handles queries in any tongue automatically.
• TranslatePress / Weglot (multilingual store) — both work today. Both keep one canonical post per item (TranslatePress in custom database tables, Weglot on its cloud). Queryra's multilingual parser handles cross-language queries against that single record.
• WPML / Polylang (multilingual store) — currently mixes languages. Native support shipping in 2-3 weeks.
• Can't wait? — accept mixed results temporarily, or run a separate Queryra account per language as a stopgap.

If you tried Queryra on a multilingual store and uninstalled, this is on us. We're shipping the fix.