Happening since August 16th.
TL;DR: B2BKing Core breaks WPML's translated product base slugs. Every product URL 404s in the five languages where the product base is translated (de/produkt, fr/produit, it/prodotto, es/producto, pl/produkt), while English and Dutch (which keeps the untranslated product base) work fine.
Translated taxonomy bases like /de/product-kategorie/ are unaffected, so it's specific to product post type rule generation. Nothing was changed on the site and these URLs worked for years, so it's a regression, most likely B2BKing rebuilding rewrite rules before WPML has applied its slug filters.
Deactivating B2BKing Core fixes it instantly; reactivating breaks it again. Permalink flushes and cache purges do nothing. Impact was 3,453 logged 404s and the whole DE/FR/IT/ES/PL catalogue unreachable. Also worth flagging: Core is on 5.2.30 while Pro is on 5.5.40.
Environment
WordPress 7.0.4 on Kinsta (nginx), WooCommerce, WP Rocket, Flatsome theme. WPML 4.9.7 with WPML String Translation and WooCommerce Multilingual. B2BKing Core 5.2.30.
Seven languages, English as default/original, using the "different languages in directories" negotiation mode with no directory for the default language. WPML's "Translate base slugs of custom post types and taxonomies" is enabled, and the product post type base is translated per language: de=produkt, fr=produit, it=prodotto, es=producto, pl=produkt. Dutch and English keep the untranslated product. WooCommerce product permalinks use the Custom base /product/.
Symptom
Every single product URL 404s in exactly those languages where the product base slug is translated. Languages where the base is not translated are completely unaffected. So /product/white-tufting-yarn-500g-wool/ and /nl/product/white-tufting-yarn-500g-wool/ both return 200, while the German, French, Italian, Spanish and Polish equivalents all return 404.
Requesting the untranslated base inside a translated language makes the loop visible: /de/product/… 301-redirects to /de/produkt/…, which then 404s. Likewise /de/?p=48914 redirects to the translated permalink and 404s, while /?p=48914 resolves fine. In other words WPML is generating the translated permalink correctly and redirecting to it canonically, but no rewrite rule exists to resolve it.
Importantly this is scoped to the post type base only. Translated taxonomy bases still work — /de/product-kategorie/garn/ returns 200 — and the translated shop page /de/alles/ returns 200. Only the translated product post type base fails to resolve.
Scale of impact: the Rank Math 404 Monitor logged 3,453 entries, almost entirely translated product URLs, with individual products at 20–180 hits each. The full DE/FR/IT/ES/PL catalogue was unreachable to customers and search engines.
This is a regression, not a misconfiguration
No configuration was changed by the team, and the /de/produkt/… structure had been live and working for years. All WPML/WCML settings were verified correct and unchanged: slug translation enabled, posts_slug_translation.types.product = 1, product base translated in every language in WooCommerce Multilingual → Store URLs, and the corresponding URL slug: product strings translated in String Translation.
Ruled out before bisecting
Re-saving Settings → Permalinks to flush rewrite rules had no effect. Purging WP Rocket for all languages and clearing all Kinsta caches had no effect. All results were verified with unique cache-busting query strings to prove the 404s were generated by PHP and not served from cache. A site snippet that called flush_rules() hourly was disabled, also with no effect.
Bisect result
Deactivating a batch of eight plugins restored all translated product URLs immediately. Reactivating them one at a time isolated the cause to B2BKing Core. The behaviour is reproducible in both directions: with B2BKing Core active, all five translated-base languages 404; deactivate it and all five return 200 without any permalink flush or cache purge in between.