# switch_to_locale : changer la langue d’un email transactionnel à la volée

> Comment générer un email de commande dans la langue du client, indépendamment de la langue configurée dans l'administration WordPress.

- Auteur : WordPress Développement
- Publié le : 2022-05-12
- Mis à jour le : 2022-05-12
- Catégorie : Multilingue
- URL : https://www.wpmoderne.fr/multilingue/switch-to-locale-email-transactionnel-langue/

## L’essentiel

- switch_to_locale bascule les traductions chargées
- restore_current_locale annule proprement le changement
- Utile pour les tâches en tâche de fond

« Pourquoi mon client italien reçoit-il un email de confirmation de commande en français, alors que le site affiche bien la boutique en italien ? » C'est la question posée par un développeur qui gérait une boutique multilingue sous WooCommerce, et la réponse tient dans une fonction du cœur de WordPress trop souvent ignorée : `switch_to_locale()`.

Comprendre cette fonction évite un piège classique des sites multilingues : confondre la langue de navigation d'un visiteur avec la langue active du processus PHP qui génère un email en tâche de fond, souvent bien après que le visiteur a quitté la page.

## Le problème que switch_to_locale résout

Quand WordPress charge une page, il détermine une langue (la locale) et charge les fichiers de traduction correspondants une seule fois, au début de la requête, via `load_default_textdomain()` et les appels à `load_plugin_textdomain()` de chaque extension. Un email de commande WooCommerce est généralement envoyé pendant la même requête HTTP que celle qui affiche la page de confirmation, ou lors d'un webhook déclenché en arrière-plan, hors de tout contexte de navigation. Dans ce dernier cas, WordPress charge la locale par défaut de l'administration, pas celle du client.

- La locale d'une requête est déterminée une fois, en général au tout début du chargement
- Un email envoyé en tâche de fond hérite de la locale de l'administrateur, pas du client
- Sans intervention, le contenu de l'email peut donc être dans la mauvaise langue

## Ce que fait réellement la fonction

`switch_to_locale( $locale )` recharge en mémoire les fichiers de traduction pour la locale demandée, sans changer la locale globale de l'utilisateur connecté ni celle affichée dans l'interface d'administration. Techniquement, elle réinitialise le tableau interne des traductions chargées (`$l10n`) et déclenche à nouveau les hooks `load_textdomain` pour la nouvelle langue, avant de restaurer un drapeau interne qui indique que l'on est en contexte de « changement de locale ».

> L'essentiel à retenir : switch_to_locale bascule les traductions chargées ; restore_current_locale annule proprement le changement ; Utile pour les tâches en tâche de fond

Ce mécanisme est exactement celui qu'utilisent en interne les extensions de traduction sérieuses lorsqu'elles génèrent un contenu dans une langue différente de celle de la session en cours, par exemple pour un flux RSS filtré par langue ou un email transactionnel.

### La fonction miroir : restore_current_locale

Chaque appel à `switch_to_locale()` doit être suivi, une fois le contenu généré, d'un appel à `restore_current_locale()`. Cette fonction remet en mémoire la locale d'origine de la requête, pour que la suite du code (l'affichage de l'écran d'administration, par exemple) ne se retrouve pas coincée dans la mauvaise langue.

## Utilisation typique avec un email de commande

Voici le squelette d'une fonction qui génère le contenu d'un email dans la langue du client, en supposant que cette langue est stockée en tant que métadonnée de la commande :

```
function generer_email_commande( $commande_id ) {
    $langue_client = get_post_meta( $commande_id, '_langue_commande', true );

    if ( $langue_client && get_locale() !== $langue_client ) {
        switch_to_locale( $langue_client );
    }

    $sujet = __( 'Votre commande a été confirmée', 'mon-theme' );
    $corps = generer_corps_email( $commande_id );

    if ( $langue_client && get_locale() !== $langue_client ) {
        restore_current_locale();
    }

    return array( 'sujet' => $sujet, 'corps' => $corps );
}
```

L'astuce consiste à enregistrer la langue du client au moment de la commande, dans une métadonnée dédiée, plutôt que de se fier à la locale active au moment de l'envoi de l'email, qui peut avoir changé entre-temps si l'envoi est différé.

## Les pièges à éviter

Le premier piège consiste à oublier l'appel à `restore_current_locale()` : le code qui s'exécute ensuite dans la même requête continue avec la mauvaise langue chargée, ce qui produit des bugs difficiles à reproduire parce qu'ils dépendent de l'ordre d'exécution.

Le deuxième piège concerne la disponibilité des fichiers de traduction : `switch_to_locale()` ne fonctionne que si les fichiers `.mo` pour la locale demandée existent réellement sur le serveur. Sans eux, la fonction bascule silencieusement, mais les chaînes restent affichées dans la langue source faute de traduction disponible.

## Bilan technique

Pour tout contenu généré hors du contexte normal de navigation (emails transactionnels, exports PDF, tâches planifiées), `switch_to_locale()` associée à `restore_current_locale()` constitue la bonne pratique du cœur de WordPress, indépendamment de toute extension de traduction installée. C'est une fonction peu documentée dans les tutoriels grand public, mais centrale dès qu'un site multilingue doit produire du contenu automatisé cohérent avec la langue du destinataire.