Un email de confirmation de commande arrive dans une langue différente de celle utilisée par le client pour finaliser son achat : c’est le symptôme le plus fréquent d’une boutique qui vend dans plusieurs langues sans avoir pensé la couche des emails transactionnels. Le catalogue est traduit, les pages sont traduites, mais les gabarits d’emails restent figés dans la langue par défaut du site.
Ce guide liste, dans l’ordre, les points à vérifier et les filtres à mobiliser pour surcharger ces gabarits selon la langue de la commande, sans installer d’extension supplémentaire dédiée à la traduction.
1. Identifier où est stockée la langue d’une commande
Sur un site multilingue construit avec des solutions comme Polylang ou une configuration de sous-domaines par langue, la langue effective au moment de la commande est généralement conservée en méta-donnée sur l’objet WC_Order, par exemple sous une clé du type _order_locale ou une clé propre à la solution de traduction utilisée. Avant toute surcharge de gabarit, il faut confirmer précisément quelle méta-donnée ou quelle fonction permet de retrouver cette langue a posteriori, car c’est elle qui pilotera le choix du gabarit.
Sans cette étape, toute tentative de surcharge revient à deviner la langue au moment de l’envoi, ce qui échoue dès que l’envoi d’un email est différé par une tâche planifiée.
2. Basculer la locale avant le rendu de l’email
WooCommerce restaure généralement la locale d’administration pendant la génération de ses emails, pour que le contenu corresponde à la langue configurée côté back-office plutôt qu’à celle du visiteur courant. Le point d’ancrage pour intervenir est le hook action_scheduler_run_queue ou plus directement les actions déclenchées autour de WC_Emails::send_transactional_email, combinées à un appel à switch_to_locale() avant l’envoi, puis à restore_previous_locale() juste après.
add_action( 'woocommerce_email_header', function ( $email_heading, $email ) {
$order = $email->object;
if ( $order instanceof WC_Order ) {
$locale = $order->get_meta( '_order_locale' );
if ( $locale ) {
switch_to_locale( $locale );
}
}
}, 5, 2 );
3. Surcharger le gabarit lui-même avec wc_get_template
Le filtre wc_get_template permet de rediriger WooCommerce vers un fichier de gabarit différent selon des conditions arbitraires, y compris la langue détectée. C’est le mécanisme le plus fiable pour proposer un texte entièrement réécrit plutôt que de compter sur une simple traduction de chaîne, notamment quand la structure du texte diffère d’une langue à l’autre.
add_filter( 'wc_get_template', function ( $template, $template_name, $args, $template_path, $default_path ) {
if ( 'emails/customer-completed-order.php' === $template_name ) {
$locale = determiner_langue_commande( $args['order'] ?? null );
$chemin_specifique = get_stylesheet_directory() . "/woocommerce/{$locale}/{$template_name}";
if ( file_exists( $chemin_specifique ) ) {
return $chemin_specifique;
}
}
return $template;
}, 10, 5 );4. Vérifier les chaînes qui ne passent pas par le gabarit
Certaines chaînes affichées dans un email — l’objet du message, le nom de l’expéditeur, certains libellés générés par des filtres comme woocommerce_email_subject_completed_order — ne sont pas dans le corps du gabarit et échappent donc à la surcharge précédente. Chacune dispose de son propre filtre nommé, qu’il faut traiter séparément avec la même logique de bascule de locale.
- Vérifier l’objet de chaque type d’email avec les filtres
woocommerce_email_subject_*. - Vérifier le pied de page défini dans les réglages, souvent laissé dans une seule langue par défaut.
- Tester l’envoi réel plutôt que le seul aperçu, l’aperçu n’exécutant pas toujours le même chemin de code que l’envoi planifié.
5. Tester avec une commande passée dans chaque langue
La seule vérification fiable consiste à passer une commande de test dans chaque langue prise en charge, puis à consulter l’email reçu ainsi que la version conservée dans les journaux d’envoi si l’hébergement en garde une trace. Un test réalisé uniquement depuis l’aperçu d’administration masque souvent les cas où la locale n’est pas correctement transmise à la tâche d’envoi.
Pour aller plus loin
Cette approche évite d’ajouter une dépendance supplémentaire pour un besoin somme toute circonscrit : les emails transactionnels. Elle demande un peu plus de rigueur dans le suivi de la locale associée à chaque commande, mais elle garde la main sur le texte final, ce qu’une simple traduction automatique de chaînes ne permet pas toujours de garantir avec la même précision.
