3 min read
Categories Guides

WPML vs Polylang for WooCommerce: What Shirely Supports

There is no useful one-word answer to “WPML or Polylang?” Both belong to the multilingual WordPress ecosystem, but a store should choose around its existing stack, translation process, and extension compatibility.

For Shirely users, however, the compatibility answer is precise: Shirely's multilingual Matrix workflows support WPML. Shirely does not claim Polylang compatibility.

Why the plugin choice changes an import workflow

A translated WooCommerce product is not simply one product with several text fields. The multilingual plugin maintains the relationship between language-specific records, their language codes, and associated taxonomy data.

Shirely's Matrix Mode is built around WPML's model. A row can carry values such as title|en, title|de, and description|pl; when WPML is active, Shirely creates or updates the language versions and connects them through WPML-aware paths.

Polylang and its WooCommerce extension have their own supported data model and operating workflow. Similar user-facing features do not make the internal integrations interchangeable. A tool that writes WPML relationships should not be assumed to write Polylang relationships correctly.

Choose the multilingual layer before the importer

If a store is new, decide the multilingual platform first. Review:

  • which languages and currencies the business needs;
  • how translators will work;
  • compatibility with the theme and WooCommerce extensions;
  • category, attribute, stock, and variation behavior;
  • how existing content would be migrated;
  • who will maintain the setup after launch.

Only then choose an import workflow that explicitly supports that stack.

If your store already runs WPML, Shirely can participate in the catalog workflow. If it already runs Polylang, do not plan to activate Matrix Mode and hope that the translation connections transfer automatically. That would require a separate, tested migration plan.

What Shirely expects in a WPML workflow

For multilingual products and categories, prepare a CSV or Google Sheet with stable identifiers and explicit language suffixes. For example:

sku,title|en,title|de,regular_price
DRILL-100,Power Drill,Bohrmaschine,149.99

Shared operational values remain single columns. Translated copy gets language-specific columns. WPML must be active, and the language codes in the source need to match languages configured on the destination.

Categories need more than translated names. source_id and parent_source_id let the source describe a hierarchy without depending on local WordPress term IDs.

When you do not need either integration

Shirely's standard, non-multilingual workflows do not require WPML. You can import and export ordinary WooCommerce products, posts, pages, categories, orders, customers, coupons, and reviews within their supported field contracts.

WPML becomes necessary for Shirely when you use Matrix Mode and other WPML-specific multilingual behavior. If your file contains one language and you do not need translation relationships, adding a multilingual plugin does not improve the import.

How to make the decision safely

Do not test with a single simple product. Use staging and include:

  • a simple and variable product;
  • a translated parent and child category;
  • a product image;
  • shared price and stock values;
  • translated product text;
  • a repeat import that updates an existing record.

Then check the products in every language, category archives, language-switcher destinations, variations, and the second-run result.

The important question is not which product wins a generic comparison. It is whether your chosen multilingual stack and import process produce a catalog your team can maintain.

For the supported path, start with Shirely's WPML import overview and the detailed documentation.