3 min read
Categories Guides

Why Your WPML Language Switcher Shows the Wrong Product

A language switcher can look healthy on the shop page and still fail on one product. The translated page may open a different item, fall back to the default language, or return a 404. In most cases, the switcher is revealing a relationship problem rather than causing it.

WPML needs to know that the current product and its translated records belong to the same translation group. If that link is missing or points at stale content, the switcher has no reliable destination.

Understand the four pieces WPML needs

WPML stores translation relationships in its own data model, including icl_translations. For each product, page, post, or taxonomy element, the important pieces include:

  • the element type;
  • the local element ID;
  • the language code;
  • the translation group ID, often called the trid.

Every language version has its own WordPress ID. The shared translation group is what tells WPML those separate records represent the same product.

Do not copy a trid or post ID from another store and assume it is portable. Those values describe local database state.

Common causes of the wrong destination

The visible symptom can come from several different mistakes:

  • language versions were imported as independent products rather than connected translations;
  • a translated product was deleted or replaced, leaving stale relationship data;
  • the product was assigned the wrong language;
  • separate language files lost their shared identity during import;
  • a translated slug or permalink changed, while caches still hold an older URL;
  • translated categories are correct, but the product translation itself is not.

Start with one broken product. Opening the entire database first usually creates noise.

Diagnose it from the WordPress interface

On staging, open the default-language product and inspect its WPML language panel. Confirm that every expected language has an existing translation and that editing each translation opens the intended product.

Then check:

  1. the language assigned to every product version;
  2. the SKU and stable source identity;
  3. the front-end URL for each language;
  4. the language switcher in both directions;
  5. category archive links to that product;
  6. whether the issue remains after the relevant site cache is cleared.

If the WordPress interface already shows the wrong translation partner, the front-end switcher is behaving consistently with bad source data.

How a structured import prevents the problem

Shirely Matrix Mode keeps related language values in one row shape:

sku,title|en,title|de,description|en,description|de
DRILL-100,Power Drill,Bohrmaschine,18V drill,18V Bohrmaschine

When WPML is active, Shirely creates or updates the language records and assigns their WPML relationships through WPML-aware import paths.

Use SKU as the normal cross-store product key. Matrix ID / External ID can provide stable identity for multilingual Matrix work. Avoid depending on WordPress post IDs from another installation.

For categories, source_id and parent_source_id describe a portable hierarchy. A product relationship fix should not be confused with a category hierarchy fix; test both separately.

Repair through supported workflows

Before changing anything, take a database backup and reproduce the issue on staging. If only a few products are affected, correct their WPML language and translation connections through supported WordPress/WPML interfaces.

For an import-created problem, correct the source identifiers or Matrix structure and test a narrow re-import. Do not repeatedly rerun the same ambiguous file, and do not begin by deleting rows directly from icl_translations on production. WPML's relationship table is connected to wider state; a casual SQL delete can create a second problem.

Verify the fix like a visitor

After repair, check more than the edit screen:

  • switch from every language version to every other available version;
  • open the product from translated category archives;
  • test desktop and mobile navigation;
  • confirm the canonical and visible language are correct;
  • check variable selections if the product has variations;
  • repeat the import once on staging to prove identity remains stable.

A fixed switcher should stay fixed after the next catalog update. That is why the source key and import structure matter as much as the immediate repair.

For deeper context, read the WPML icl_translations table guide and the practical WPML product import workflow.