# Notification de formulaire envoyée dans la langue de l’administrateur

> Un candidat postule en anglais, l'e-mail de confirmation qu'il reçoit est en français. Diagnostic d'un contexte de langue perdu lors de la soumission d'un formulaire.

- Auteur : WordPress Développement
- Publié le : 2024-02-22
- Mis à jour le : 2024-02-22
- Catégorie : Multilingue
- URL : https://www.wpmoderne.fr/multilingue/notification-formulaire-langue-administrateur/

## L’essentiel

- switch_to_locale ne s'applique pas automatiquement aux envois différés
- Le hook d'envoi tourne parfois hors du contexte de la requête initiale
- Capturer la langue au moment de la soumission, pas à l'envoi

`Notification: Nouvelle candidature reçue` : c'est ce sujet, en anglais dans le corps mais avec un texte de confirmation entièrement en français, que recevait un candidat après avoir postulé sur la version anglaise d'un site de recrutement. Le formulaire lui-même s'affichait pourtant correctement dans sa langue.

Ce type de décalage entre l'expérience visible et l'e-mail reçu revient régulièrement sur les sites multilingues qui utilisent un plugin de formulaire couplé à Polylang, et mérite qu'on comprenne précisément où la langue se perd en cours de route.

## Symptôme : un formulaire traduit, une notification qui ne l'est pas

Le formulaire de candidature, construit avec un constructeur de formulaires classique, affiche bien ses libellés et ses messages de validation dans la langue du visiteur grâce aux chaînes enregistrées dans Polylang String Translation. Mais l'e-mail de notification envoyé au candidat, lui, est systématiquement rédigé dans la langue par défaut du site, quelle que soit la langue de la page où le formulaire a été rempli.

Le même comportement touche parfois l'e-mail interne envoyé au recruteur, mais dans l'autre sens : il souhaiterait recevoir la candidature toujours en français, indépendamment de la langue utilisée par le candidat, ce qui complique encore le diagnostic si on ne distingue pas les deux flux.

## Diagnostic : l'envoi ne tourne pas dans le contexte de la requête

La cause technique tient à la manière dont WordPress gère la locale active. La fonction `get_locale()` renvoie la locale déterminée pour la requête en cours, mais l'envoi de l'e-mail se fait souvent via une action différée (`wp_mail` déclenché sur un hook `init` tardif, une tâche planifiée, ou un traitement asynchrone du plugin de formulaire). Or rien ne garantit que cette action différée conserve le contexte linguistique de la page où le formulaire a été soumis.

> L'essentiel à retenir : switch_to_locale ne s'applique pas automatiquement aux envois différés ; Le hook d'envoi tourne parfois hors du contexte de la requête initiale ; Capturer la langue au moment de la soumission, pas à l'envoi

Dans le cas observé ici, le plugin de formulaire stockait bien la langue de soumission dans une méta de l'entrée, mais son moteur de templating d'e-mail interrogeait `get_locale()` au moment de l'envoi plutôt que de relire cette méta, et l'envoi se produisait après un rechargement de contexte où `get_locale()` retombait sur la langue par défaut du site.

### Reproduire le bug en local

Pour confirmer l'hypothèse, il suffit de placer un `error_log( get_locale() )` juste avant l'appel à `wp_mail()` dans le hook d'envoi du plugin, et de comparer sa valeur avec celle affichée sur la page au moment de la soumission. Un écart entre les deux confirme la perte de contexte.

## Correctif : encapsuler l'envoi avec switch_to_locale

La fonction cœur `switch_to_locale()` existe précisément pour ce cas : elle force temporairement WordPress à charger les traductions d'une locale donnée, indépendamment de la requête en cours, puis `restore_previous_locale()` revient à l'état précédent une fois l'envoi terminé.

```
add_action( 'gform_after_submission', function ( $entry, $form ) {
    $langue_soumission = rgar( $entry, 'langue_formulaire' );
    switch_to_locale( $langue_soumission );

    wp_mail(
        $entry['1'],
        __( 'Confirmation de candidature', 'mon-theme' ),
        mon_theme_generer_corps_email( $entry )
    );

    restore_previous_locale();
}, 10, 2 );
```

La clé est de capturer la langue de soumission dès la réception du formulaire (via `pll_current_language()` au moment où l'utilisateur valide), de la stocker avec l'entrée, puis de la relire explicitement avant l'envoi plutôt que de faire confiance à `get_locale()` à ce stade tardif.

## Prévention : ne jamais faire confiance à la locale ambiante lors d'un envoi différé

Tout traitement asynchrone (file d'attente, tâche planifiée, webhook) doit recevoir explicitement la langue à utiliser plutôt que de la déduire du contexte d'exécution. C'est une règle générale au-delà des formulaires : dès qu'un envoi ou un traitement se déclenche en dehors de la requête initiale du visiteur, la langue doit voyager avec la donnée, pas avec l'environnement d'exécution.

> La locale ambiante n'est fiable que pendant la requête qui l'a définie. Passé ce cadre, il faut la transporter explicitement, jamais la deviner.

## En résumé

Ce bug illustre un principe simple à retenir sur tout site multilingue : la langue d'un visiteur n'est pas une propriété globale et permanente de l'environnement WordPress, c'est une donnée de contexte qui doit être capturée au bon moment et transmise explicitement à chaque traitement qui en a besoin, y compris et surtout les envois différés.