An attribute filter that works perfectly in the default language and shows zero products, or no filter widget at all, in a WPML secondary language is a documented WooCommerce + WPML interaction — not a broken translation. WPML’s own errata traces it to the product attributes lookup table not populating for translated products. A 2025 support case shows the documented workaround doesn’t always finish the job, because some theme filter widgets query that data their own way. InstantFilter builds its index from the same product data regardless of language, with no separate lookup table to leave empty.
What is the WPML + lookup table bug, exactly?
WPML’s own errata page states it plainly: “WooCommerce is planning to release the new product filtering by attributes in WooCommerce 6.3. However, this table is not populated automatically for products in secondary languages.” That table is wc_product_attributes_lookup, the index WooCommerce 6.3 introduced to speed up attribute filtering. WPML logs the bug as resolved in WPML Multilingual & Multicurrency for WooCommerce version 5.0.0, released in 2022 — updating that add-on to a current version fixes the root population issue for most stores.
Until you can update, WPML documents a two-step manual workaround: regenerate the lookup table per product, in the secondary language, under WooCommerce → Status → Tools after switching the admin language switcher — or disable the table entirely under WooCommerce → Settings → Products → Advanced by unchecking “Enable table usage,” which forces WooCommerce back onto its older taxonomy-query path for every language.
Why doesn’t disabling the lookup table always fix it?
Because a theme’s own filter widget can query attribute data independently of whichever path WooCommerce core falls back to. A detailed September 2025 support thread lays out exactly this: a store running WoodMart 7.5.1 and WooCommerce 6.5.5 with WPML had working color and size filters in English, but zero counts for the same filters in Arabic. The store owner followed WPML’s documented steps in order — synced attribute translations, duplicated products into Arabic, disabled the lookup table per the errata, regenerated it anyway, and ran WPML’s own troubleshooting tools to re-sync taxonomies and fix term counts. None of it changed the Arabic counts.
What did work, in the same thread: replacing WoodMart’s built-in layered-nav widget with a different filter plugin. The store owner’s own diagnosis holds up: “This suggests the data exists but the WoodMart widget (or its integration with WPML) isn’t picking it up… Filter Everything bypasses this by building its own queries.” The underlying WPML/WooCommerce population bug from the 2022 errata was already addressed upstream; this case shows a theme-specific widget can still have its own, separate blind spot for translated attribute data, surviving every fix WPML documents for the original issue.
Two details from that same thread are worth noting because they rule out the usual suspects. The store owner “cleared all caches (WooCommerce transients, theme cache, server cache) after each change,” so this wasn’t a stale-cache artifact masking a real fix. And the size filter and color filter didn’t fail identically — size rendered as a dropdown in Arabic instead of the swatches shown in English, while color stayed blank, which pointed at per-attribute rendering logic inside the widget rather than one single root cause for every attribute at once. That kind of partial, attribute-by-attribute symptom is itself a signal you’re looking at a widget-specific bug, not a blanket data problem.
What’s the actual fix path, in order?
Start with WPML’s own resolved thread for a similar symptom — a filter widget missing or showing “There are no products with the selected attributes” in a secondary language. WPML support’s fix there: go to WooCommerce Multilingual → Attributes tab, select the attribute, and click “Synchronize attributes and update product variations.” The same thread adds the check that catches most remaining cases: “If the translated terms have 0 product count, please make sure you translate the products belonging to each term” — a translated attribute term with no translated products attached to it will always show a zero count, independent of any lookup-table bug.
If synchronizing attributes and translating every product behind each term still leaves a theme’s own widget blank, treat that as a separate, plugin-specific bug rather than retrying the WPML workaround — the WoodMart case above shows that path can dead-end, and the working fix was a different filter plugin, not a different WPML setting. Document which fix actually resolved it before moving on: a future WPML or theme update could reintroduce the same symptom, and knowing whether the original cause was data (untranslated products), configuration (table disabled or not regenerated), or widget code (a theme-specific query path) decides which update to watch for.
Is this the same bug as “no products matched your selection” on variable products?
No — related symptom, separate bug, separate WPML errata entry. A different, older WPML errata documents a variable-product page in the second language showing “Sorry, no products matched your selection. Please choose a different combination.” when a shopper picks variation options, reported against WPML Multilingual & Multicurrency for WooCommerce 4.7.5. That bug lived in how the plugin posted the selected attribute slug back to WooCommerce for matching against a variation, not in the archive-page lookup table at all — the documented workaround at the time was editing class-wcml-attributes.php directly to stop translating the slug before the match. Both bugs produce “nothing found” in a secondary language, but one is an archive-filter count and the other is a single-product variation match; confirm which page type shows the problem before applying either fix.
How do you tell this apart from a plain translation gap?
Check three things before assuming it’s the lookup-table bug. First, does the single product page show the correct attribute in the secondary language? If yes, the attribute term itself is translated correctly, and the gap is specific to the archive filter. Second, does WooCommerce → Status → Tools show the lookup table as fully regenerated for that language? A partial regeneration looks identical to the WPML bug but has the separate fix covered in this cluster’s page on a stuck regeneration. Third, does every product under that attribute term actually have its own translation published, not just a translated taxonomy term? WPML’s own guidance names this exact gap: a translated term with untranslated products behind it reports zero, correctly, because there is nothing translated to count.
Does InstantFilter have this failure mode?
No, because InstantFilter doesn’t read wc_product_attributes_lookup in any language. Its own index builds from the product and attribute data WordPress and WPML already expose for whichever language is active, during InstantFilter’s own sync step — there’s no separate per-language population step that can silently skip a secondary language, and no theme-widget-specific query path that could diverge from it. That doesn’t remove the need to translate every product behind a term correctly; a term with no translated products will still show zero, in any filter architecture, because there’s genuinely nothing to count. It does mean a store won’t separately need to track whether a lookup table populated correctly per language on top of that — one less moving part to audit when a multilingual catalog launches a new language, and one less place for a theme widget to quietly diverge from the data underneath it.
Keep going
The lookup table has more than one failure mode across this cluster.
- When the table finishes but filtering is still slow
- When regeneration never finishes at all
- The request behind every filter click
- Why WooCommerce filters get slow
- Pricing and trial
