How to Import a Multilingual WooCommerce Catalog with WPML, CSV and XML

Importing a WooCommerce catalog in more than one language involves more than transferring product names, descriptions, prices and images. A product row can be imported successfully and still lack a language assignment or a connection to its translated versions. This distinction is central to a reliable WPML multilingual product import: the underlying importer brings catalog data to the destination site, while the WPML processing step uses language metadata to assign languages and connect related rows.

The safest approach is to prepare the destination site and source files first, test a small representative batch, import taxonomies before products when separate files are used, preserve the required WPML fields, and run the WPML import or wiring step only after the base import is complete. The exact interface and behavior can vary by WPML, WooCommerce and importer versions, so the workflow should be verified on a staging site or a verified backup before changing a production catalog.

What WPML Multilingual Product Import Actually Does

A multilingual import has two related but separate jobs. The first is the normal data-import operation. It creates or updates WooCommerce products and may also process categories, tags, attributes, images, variations and other mapped data. The second job is language processing. WPML reads preserved language information, assigns each imported row to the appropriate language and connects translation rows with their source product.

Two stages of the workflow

In the first stage, the selected importer processes the CSV, XML or another supported file structure. At this point, the catalog may exist in the database without a completed multilingual relationship. In the second stage, after the underlying importer has finished, the administrator runs the WPML import or wiring step. This is when WPML uses the language metadata to establish language assignments and translation links.

This separation explains why a product can appear to be imported but still be shown in the default language or have Draft status. Those states can be temporary before the WPML step is completed. They should not, however, be treated as proof that every import has succeeded. Importer compatibility, field mapping, configured languages and the contents of the source file still need to be checked.

Pre-Import Checklist for a Multilingual WooCommerce Catalog

Preparation reduces the risk of importing a large catalog with incomplete language relationships. Begin on the destination site, because WPML must already know which languages are available. The target languages should be configured before the import starts. If a language is absent from the destination configuration, the corresponding rows cannot be handled as intended by the documented workflow.

Destination site and source-file checks

Next, identify the exact import workflow. WPML documents workflows involving WP All Import Pro, the native WooCommerce CSV importer, the standard WordPress importer and custom CSV or XML pipelines with manually added language columns. These options do not necessarily behave identically. A custom pipeline may require explicit mapping, while a supported tool may add or preserve language information through its integration.

Before touching an existing catalog, use a staging site or a verified backup. Check SKU uniqueness and the identifiers used to group translations. Also review product IDs, taxonomy relationships, images, variations and the intended update behavior. Do not assume that an import should overwrite existing products simply because the file contains matching-looking rows.

For a large catalog, prepare a small batch containing simple products, variable products, categories, attributes and translated rows. This test should confirm that the importer creates the expected content, preserves the WPML metadata and resolves taxonomy relationships. Only then should the full catalog be considered.

• Configure all required target languages in WPML on the destination site.
• Confirm that the selected importer and WooCommerce workflow are appropriate for the intended file.
• Inspect SKU and translation-group consistency before importing.
• Test the process on staging or on a verified backup.

Required CSV and XML Language Columns

For a custom CSV or XML workflow, WPML documents three language-related columns. They are _wpml_import_translation_group, _wpml_import_language_code and _wpml_import_source_language_code. These fields are not interchangeable. Each has a separate role in identifying the relationship between a source product and its translations.

Column	Purpose	How to use it
_wpml_import_translation_group	Groups language versions of the same content	Use one shared identifier for all language rows of one product; WPML recommends the product SKU for products
_wpml_import_language_code	Identifies the language of the current row	Set it according to the language represented by that row
_wpml_import_source_language_code	Identifies the original language	Use it on translation rows; leave it empty for source-language rows

These requirements apply to the custom-file workflow. Supported import tools may add language information automatically, but the resulting file and mapping should still be inspected. A correctly structured source file is not enough if the importer drops the columns or maps them to the wrong destination fields.

How translation-group values connect product rows

The translation-group value is the link shared by every language version of one product. The source-language row and its translated rows must carry the same group identifier, while different products must not share that identifier. For products, WPML documentation recommends using the product SKU as the group value. This makes SKU consistency especially important when a catalog contains multiple language files.

The group value does not replace the product’s regular catalog data and does not itself identify the language. It only tells WPML which rows belong to the same translation group. The language of each row is supplied separately by the language-code column.

Language code versus source language code

_wpml_import_language_code describes the language of the row being imported. A source product row therefore receives the code for the original language, while a translated product row receives the code for its own translation language. _wpml_import_source_language_code has a different purpose: on a translation row, it identifies the language of the original product. For a row in the source language, this field remains empty.

Variable products with translated labels for custom attributes have an additional documented field: _wpml_import_wc_local_attribute_labels. Treat this as a specific requirement for the relevant variable-product case, not as a replacement for the three core language columns. Before importing, verify the spelling of every column, the values in representative rows and the mapping assigned by the importer.

Recommended Import Order: Taxonomies, Products, and Translations

When taxonomies and products are stored in separate files, import the required taxonomies first. This can include product categories, tags and attributes. Products can then refer to terms that already exist on the destination site. After the taxonomy stage, import products and other content that depends on those terms.

If language-specific files are used, process the files for all languages before running the WPML wiring step. The wiring stage should follow the completed base imports, not interrupt them. This gives WPML the rows and preserved metadata it needs to assign languages and connect translations.

Separate taxonomy files and language files

The recommended sequence for separate files is therefore practical rather than universal: create the taxonomy foundation first, import the product data next, process the language files, and then run WPML Export and Import or the relevant wiring step. Check the result with a small batch before scaling up.

A single native WooCommerce CSV may handle product categories inside the product file differently from a workflow with separate taxonomy files. Do not transfer the separate-file sequence mechanically to every importer. The important check is whether the product-to-term relationships are resolved correctly and whether the chosen workflow preserves the language metadata required by WPML.

1. Import separate categories, tags and attributes when the workflow stores them in separate files.
2. Import products and other content that references those terms.
3. Complete the files for the different languages before wiring.
4. Run the WPML language-assignment and translation-linking step after the base imports.

Mapping WPML Metadata in the Importer

Mapping determines whether the information in the source file survives the import. For products, the three language columns must be mapped as the language-related custom fields expected by the selected workflow. When taxonomies are imported separately, their corresponding information may need to be mapped as term metadata. Product fields and taxonomy term metadata are different destinations and should not be treated as one generic mapping.

Product fields and taxonomy term metadata

With tools such as WP All Import Pro or similar workflows, verify that product language metadata is assigned to custom fields and taxonomy information is assigned to the appropriate term metadata. The exact labels can vary by installed versions and importer configuration. If the importer does not preserve these values, WPML cannot use them during wiring even if the original CSV or XML looked correct.

After the base import of the test batch, inspect the imported records. Confirm that the translation-group value is present and consistent, that each row has the expected language code, and that translation rows contain the source-language code. Also check that taxonomy terms are attached to the expected products. Correct these mappings before running the full catalog import rather than repairing hundreds of records afterward.

• Map product language columns to the custom fields required by the workflow.
• Map taxonomy language information to term metadata when the importer requires it.
• Verify preserved values after the base import and before WPML wiring.
• Repeat the test with translated and variable products where those cases are part of the catalog.

Run the WPML Wiring Step and Troubleshoot Default-Language or Draft Products

Once the importer has completed the underlying catalog import, run the WPML import or wiring step. This step is what allows WPML to read the language metadata, assign the imported rows to their configured languages and connect translation rows to their source products. It is not a substitute for the base import and should not be expected to create correct relationships when the metadata was omitted or lost during mapping.

Verification after WPML processing

Review the result after WPML finishes processing. Open representative source products and translations and check the assigned language, the connection between language versions and the presence of expected categories, tags and attributes. Also verify the storefront behavior for the configured languages and the language switcher. Do not publish or expose the full catalog until these checks show that the relationships and taxonomy assignments are working as intended.

For a larger catalog, compare the result with the test batch. A successful wiring step should be evaluated together with the base import: products must contain the expected data, translation groups must connect the right rows, and language assignments must not cross between separate products.

Diagnostic sequence for default-language and Draft status

If products remain in the default language, begin with the destination configuration. Confirm that the intended target languages already exist in WPML. Next, inspect the source file for all three required custom-workflow columns and confirm that their values are correct. Then check whether the importer mapped product fields and taxonomy term metadata correctly.

After that, confirm that the base importer actually completed and that the WPML wiring step was run afterward. Before wiring, WPML documents that imported content can temporarily appear under the default language and products can remain in Draft status. In the documented workflow, this may be an interim state rather than proof of a failed import.

If the products are still incorrect after wiring, examine importer compatibility and the actual file mapping. Unsupported or differently integrated importers may behave differently, and products may require manual publishing after the wiring step. Do not assume every Draft product has the same cause. A particular diagnosis requires checking the file, configured languages, preserved metadata, mapping, completed import and compatibility of the selected tool.

1. Check that all target languages are configured on the destination site.
2. Check the three WPML language columns and their row values.
3. Check custom-field and term-metadata mapping.
4. Confirm that the base import finished before wiring was run.
5. Confirm that the importer supports the intended WPML workflow.
6. Review language assignments, translation links and taxonomy relationships before publishing.

A multilingual WooCommerce catalog import is most reliable when its stages are kept separate. Configure the destination languages, prepare and test the file, import separate taxonomies before products when required, preserve the WPML metadata, map product fields and term metadata correctly, and run the WPML wiring step after all base imports. The three core custom CSV or XML columns connect each row to its language and translation group, while the optional attribute-label field applies to the documented variable-product case. Default-language placement or Draft status can be temporary before wiring, but persistent problems require a review of configuration, mapping, file contents and importer compatibility. Test a representative batch before the full catalog. Explore our WordPress plugins, WooCommerce extensions, themes and membership plans to find the right tools for your website.