vendredi 25 septembre 2026

À propos

Contact

Multilingue

Traduire les attributs et variations de produits WooCommerce sans tout dupliquer

Un produit à variations perd la correspondance de ses attributs une fois traduit. Voici la configuration qui garde tout synchronisé entre langues.

Par Clément Hadrot • 18 juin 2024 • 5 min de lecture • Aucun commentaire
Traduire les attributs et variations de produits WooCommerce sans tout dupliquer

Le produit vendait un vêtement décliné en trois couleurs et six tailles, soit dix-huit variations possibles en théorie. Sur la version française du site, tout fonctionnait normalement : chaque combinaison de couleur et de taille correspondait à une variation commandable, avec son propre stock et son propre prix. Sur la version anglaise, en revanche, seules quatre combinaisons sur dix-huit restaient sélectionnables ; les autres affichaient un message indiquant que la combinaison n’était pas disponible, alors que le stock existait bien côté administration.

Ce type de panne trouve presque toujours sa source dans la configuration des attributs globaux WooCommerce et leur traduction, un point plus subtil qu’il n’y paraît une fois qu’on entre dans le détail de la structure de données sous-jacente.

Comment WooCommerce structure attributs et variations

Un attribut global WooCommerce (par exemple « Couleur ») est stocké comme une taxonomie personnalisée, dont chaque valeur possible (« Rouge », « Bleu », « Vert ») est un terme de cette taxonomie. Une variation de produit se définit ensuite comme une combinaison précise de termes, un pour chaque attribut utilisé (une couleur et une taille pour l’exemple ci-dessus), reliée en base de données via l’identifiant de ces termes.

C’est ce lien par identifiant de terme qui pose problème en contexte multilingue : quand WPML traduit un terme de taxonomie, il crée un nouveau terme distinct par langue, avec son propre identifiant. Si la variation de produit reste reliée à l’identifiant du terme original (la version française), elle devient invisible ou incohérente dès que le visiteur navigue sur une autre langue, où ce terme précis n’existe pas sous cet identifiant.

L'essentiel à retenir : Un attribut global mal configuré casse la correspondance entre variations traduites ; La traduction doit porter sur les valeurs, jamais sur la structure de l'attribut ; Un test systématique en façade évite les combinaisons impossibles à commander

Le diagnostic sur ce projet

La vérification a porté sur la table wp_woocommerce_attribute_taxonomies et sur les termes associés à chaque variation, via l’écran d’édition du produit en mode développeur. Sur les termes de couleur, la traduction anglaise existait bien, correctement liée dans WPML. Sur les termes de taille, en revanche, seule une partie des tailles avait été traduite, les tailles manquantes n’ayant simplement jamais été créées côté anglais lors de la configuration initiale du site.

Résultat : toute variation combinant une couleur traduite avec une taille non traduite devenait incohérente sur la version anglaise, WooCommerce ne trouvant pas de correspondance complète pour reconstituer la combinaison attendue.

La configuration correcte, étape par étape

  1. Vérifier, pour chaque attribut global utilisé par le produit, que tous ses termes (toutes les valeurs possibles) sont traduits dans toutes les langues actives, pas seulement les valeurs déjà utilisées par un produit existant.
  2. Dans WPML → Réglages, confirmer que la synchronisation des taxonomies de produit est activée pour les attributs concernés, afin que WPML propose automatiquement la traduction de chaque nouveau terme créé.
  3. Une fois les termes traduits, ouvrir chaque traduction du produit et vérifier, dans l’onglet « Variations », que WooCommerce reconstitue bien l’intégralité des combinaisons attendues, sans case manquante.
  4. Synchroniser le stock et le prix de chaque variation traduite avec sa variation d’origine, via l’option de synchronisation proposée par WPML pour les champs numériques qui doivent rester identiques entre langues.

Ce qu’il ne faut jamais faire

  • Créer manuellement un nouvel attribut global distinct par langue plutôt que de traduire l’attribut existant : cela casse tout lien de synchronisation et double la maintenance future.
  • Traduire uniquement les valeurs déjà utilisées sur les produits existants, en laissant les autres valeurs de l’attribut non traduites : le jour où un nouveau produit utilise une de ces valeurs oubliées, le même problème resurgit.
  • Modifier le prix ou le stock d’une variation traduite indépendamment de l’originale sans avoir explicitement désactivé la synchronisation : WPML peut écraser cette modification lors d’une resynchronisation automatique ultérieure.

La règle qui évite ce genre de panne : traduire un attribut global signifie traduire l’intégralité de ses valeurs possibles dès sa création, jamais au fil de l’eau selon les produits ajoutés.

Un test systématique qui aurait évité l’incident

Le contrôle qui manquait sur ce projet est simple à mettre en place : pour chaque produit à variations, parcourir chaque langue en façade et tenter de sélectionner systématiquement toutes les combinaisons possibles d’attributs, en vérifiant qu’aucune ne renvoie un message d’indisponibilité inattendu. Sur un catalogue de plusieurs centaines de produits, cette vérification manuelle devient vite impraticable ; un script de test peut alors interroger l’API WooCommerce pour comparer automatiquement le nombre de variations actives entre la langue source et chaque traduction.

// Comparaison simplifiée du nombre de variations entre langues
$product_fr = wc_get_product(1234);
$product_en = wc_get_product(apply_filters('wpml_object_id', 1234, 'product', true, 'en'));

$variations_fr = count($product_fr->get_children());
$variations_en = count($product_en->get_children());

if ($variations_fr !== $variations_en) {
    error_log("Écart de variations détecté sur le produit {$product_fr->get_id()}");
}

Pour aller plus loin

Ce même principe — un attribut global correctement traduit dans toutes ses valeurs avant utilisation — s’applique à toute taxonomie personnalisée liée à un système de combinaisons, pas seulement aux attributs WooCommerce natifs. Toute extension ajoutant ses propres taxonomies pour générer des variantes de contenu mérite le même contrôle avant mise en production sur un site multilingue.

En résumé

Le problème rencontré ici ne venait ni d’un bug de WooCommerce ni d’un bug de WPML, mais d’une traduction incomplète des valeurs d’attribut, invisible tant que le produit n’était pas testé combinaison par combinaison sur chaque langue. La leçon retenue : traduire un attribut global doit toujours être une opération complète, jamais partielle, sous peine de variations fantômes qui ne se révèlent qu’au moment où un client tente réellement de passer commande.

Partager :

À propos de l'auteur

Clément Hadrot

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi