3 min read
Categories Guides

WooCommerce Product Attributes in WPML Imports

Attributes sit at the intersection of WooCommerce products, variation logic, taxonomy terms, and WPML/WCML language settings. A product can import successfully while the storefront selector still shows the wrong label or cannot resolve a variation.

The solution begins by separating two jobs: assigning attribute values to products and establishing the multilingual taxonomy relationships behind global attribute terms.

Global and local attributes are different

A global attribute such as pa_color is a WooCommerce taxonomy. Its terms can be reused across products, variations, filters, and archives. That makes global attributes the normal foundation for a catalog that needs consistent variation values.

A local attribute lives on one product. It can describe an item, but it is a weaker basis for multilingual variation logic and cross-catalog filtering because it is not the same reusable taxonomy structure.

Use one stable taxonomy key for the same business concept. If Color is pa_color, do not create a different attribute key for each language.

Choose shared or translated behavior deliberately

Shirely 1.3 keeps the shared global-attribute path as the default. This suits stores where the same operational terms are assigned across translated product records and WCML controls how they appear.

Product Matrix also provides an explicit Translate global attributes (WCML Matrix opt-in). Use it only when the attribute taxonomy is already configured as translatable in a supported WPML/WCML setup. Shirely does not change the site's WCML translation configuration for you.

That opt-in is scoped to Product Matrix. It should not be generalized into a claim that every import path automatically creates and manages the full WCML attribute-term lifecycle.

Prepare the taxonomy before the product batch

On staging, verify:

  • the global attribute exists in WooCommerce;
  • its taxonomy key is correct;
  • WPML/WCML knows whether it is translatable;
  • required terms and their language relationships are valid;
  • the same slugs or source identities do not point to unrelated concepts;
  • product filters and attribute archives behave as expected.

Fix taxonomy configuration before repeatedly changing product rows. A product import cannot compensate for an ambiguous or incorrectly configured global attribute.

Build variable products around stable SKUs

The parent product declares the attributes available for variations. Each variation needs its own SKU and one valid value for every variation attribute.

type,parent_sku,sku,title|en,title|de,pa_color,regular_price
variable,,TSHIRT-100,T-Shirt,T-Shirt,red|blue,
variation,TSHIRT-100,TSHIRT-100-RED,Red T-Shirt,Rotes T-Shirt,red,29.00
variation,TSHIRT-100,TSHIRT-100-BLUE,Blue T-Shirt,Blaues T-Shirt,blue,29.00

The exact delimiter and mapping depend on the source contract. The important structure is stable: one parent SKU, unique variation SKUs, and values that resolve to the intended global terms.

Test the complete buyer path

Import one variable parent with a few variations, then check:

  1. the parent product in every configured language;
  2. visible attribute labels and term values;
  3. the language switcher;
  4. every variation selection;
  5. the SKU, price, and stock shown after selection;
  6. attribute filters or archives exposed by the theme;
  7. a second import of the same sample.

A successful result count proves that rows were processed. It does not prove that translated term relationships and storefront JavaScript resolve every selection correctly.

Repeat imports and schedules need boundaries

Product rows are processed on every import. Stable product SKUs, parent SKUs, taxonomy keys, and term identity make repeat updates predictable.

Shirely 1.3 can save supported imports as Automation slots, but jobs that can change the same products, terms, or WPML/WCML groups should not overlap. Same-slot protection is not global serialization. Test with Run now, inspect Run History, and use system cron with WP-CLI when a large job needs a more predictable start than traffic-driven WP-Cron provides.

Use Shirely for the explicit product/variation assignment and the supported WCML Matrix opt-in. Use WooCommerce and WPML/WCML to configure and verify the surrounding taxonomy behavior.

Continue with the multilingual variable-product guide or the translated category workflow.