« Merci pour votre commande » s’affichait en français dans l’email reçu par un client allemand, sur une boutique d’articles de sport vendant ses produits en France, en Allemagne et aux Pays-Bas via WooCommerce et Polylang. Le client avait pourtant navigué et passé commande entièrement en allemand, du premier clic jusqu’au paiement.
Ce cas ne traite pas des emails de relance de panier abandonné, qui suivent un mécanisme différent : il se concentre uniquement sur l’email de confirmation immédiate, envoyé au moment de la validation de la commande.
Symptôme : une incohérence entre navigation et email reçu
Le client avait navigué en allemand, ajouté des produits au panier en allemand, réglé sa commande en allemand, et pourtant reçu un email de confirmation entièrement en français. Le site n’affichait ce comportement que de manière intermittente, ce qui a rendu le diagnostic initial plus difficile : certains clients allemands recevaient bien leur email en allemand, d’autres non.
- Navigation et paiement affichés correctement en allemand pour tous les clients concernés
- Email de confirmation tantôt en allemand, tantôt en français, pour des clients ayant suivi le même parcours
- Aucune erreur PHP visible dans les journaux du serveur
Diagnostic : la langue capturée au mauvais moment
L’extension de traduction enregistrait la langue de la commande via le hook woocommerce_new_order, en lisant la valeur retournée par pll_current_language() à cet instant précis. Le problème est que ce hook se déclenche dès la création de la commande en base de données, à l’état « en attente de paiement », c’est-à-dire potentiellement avant que le client n’ait terminé de choisir sa langue de manière définitive, notamment s’il avait changé de langue en cours de navigation entre l’ajout au panier et le paiement.
Sur les commandes où le client changeait de langue en cours de session (par exemple en cliquant sur un lien partagé en français avant de basculer manuellement vers l’allemand), la langue capturée à la création de la commande correspondait à celle du tout premier passage sur le site, pas à celle réellement active au moment du paiement.
Reproduire le bug pour le confirmer
Pour reproduire le comportement, j’ai simulé le parcours d’un client arrivant via un lien français, naviguant deux pages, puis changeant explicitement de langue vers l’allemand avant de finaliser sa commande. L’email de confirmation reçu était bien en français, confirmant que la langue avait été figée trop tôt dans le parcours.
Correctif : capturer la langue à la validation, pas à la création
Le correctif a consisté à déplacer la capture de la langue du hook woocommerce_new_order vers le hook woocommerce_checkout_order_processed, qui se déclenche juste après la validation finale du paiement par le client, au moment où la langue active reflète réellement son dernier choix :
add_action( 'woocommerce_checkout_order_processed', function( $order_id ) {
update_post_meta( $order_id, '_langue_commande', pll_current_language() );
}, 10, 1 );
Ce changement de hook, une seule ligne modifiée dans le code existant, a suffi à résoudre l’incohérence : la langue enregistrée correspond désormais systématiquement à la langue active au moment exact où le client valide sa commande, et non plus à celle du tout premier chargement de page.
Prévention : tester le changement de langue en cours de parcours
La leçon la plus utile de ce cas concerne les tests eux-mêmes : la plupart des tests de bout en bout sur un site multilingue vérifient un parcours dans une seule langue, du début à la fin, sans jamais simuler un changement de langue en cours de route. Or c’est précisément ce scénario, statistiquement rare mais bien réel, qui révèle les hooks capturés trop tôt.
Depuis ce cas, j’ajoute systématiquement un scénario de test avec changement de langue en cours de parcours, en plus des scénarios classiques à langue unique.
Bilan de ce correctif
Ce bug n’était ni un défaut de Polylang ni un défaut de WooCommerce, mais une hypothèse implicite incorrecte dans le code de la boutique : supposer que la langue active à la création d’une commande reste identique jusqu’à sa validation. Sur un site multilingue, tout hook qui capture un état utilisateur (langue, devise, panier) doit être choisi en fonction du moment précis où cet état doit être définitif, pas du moment où il est techniquement le plus simple à lire.
