Une clinique vétérinaire disposant d’un site bilingue français-néerlandais recevait des plaintes occasionnelles de visiteurs néerlandophones qui recevaient, après avoir rempli le formulaire de prise de rendez-vous, un email de confirmation entièrement rédigé en français. Le formulaire lui-même, construit avec Gravity Forms, affichait pourtant correctement ses libellés en néerlandais sur la page grâce à une traduction manuelle des champs. Le problème se situait uniquement au niveau de la notification email envoyée après soumission, restée configurée sur son unique version française d’origine.
Gravity Forms, contrairement au contenu classique de WordPress, ne bénéficie d’aucune intégration native profonde avec Polylang. La traduction d’un formulaire complet demande une combinaison de plusieurs mécanismes distincts, chacun couvrant une partie différente du formulaire.
Traduire les libellés visibles du formulaire
Les libellés de champs, les textes d’aide et le texte du bouton de soumission ne sont pas automatiquement détectés par Polylang comme des chaînes traduisibles. La méthode recommandée consiste à enregistrer manuellement chaque chaîne avec la fonction pll_register_string(), généralement dans le fichier functions.php du thème enfant, ce qui rend ensuite chaque chaîne modifiable depuis Langues > Traductions des chaînes :
<?php
add_action( 'init', function() {
if ( function_exists( 'pll_register_string' ) ) {
pll_register_string( 'gf-label-nom', 'Votre nom', 'Formulaires', true );
pll_register_string( 'gf-label-email', 'Votre adresse email', 'Formulaires', true );
pll_register_string( 'gf-bouton-envoi', 'Envoyer ma demande', 'Formulaires', true );
}
} );Une fois ces chaînes enregistrées, elles apparaissent dans l’écran de traduction des chaînes de Polylang, où chaque langue active du site peut recevoir sa propre valeur traduite, injectée ensuite dynamiquement dans le rendu du formulaire via pll__() à la place du texte codé en dur dans la configuration du formulaire.
Traduire les messages de confirmation
Le message de confirmation affiché après soumission, configuré dans l’onglet « Confirmations » de Gravity Forms, se traduit selon la même logique, en enregistrant son contenu comme chaîne via pll_register_string() puis en l’affichant conditionnellement selon la langue courante détectée avec pll_current_language(). Une alternative plus simple, quand le nombre de formulaires reste faible, consiste à créer une confirmation distincte par langue directement dans l’interface Gravity Forms, avec une condition d’affichage basée sur un champ caché renseigné automatiquement selon la langue de la page.
Le point le plus critique : les notifications email
Les notifications email, celles envoyées à l’administrateur et celles envoyées en confirmation au visiteur, constituent le point le plus souvent oublié, précisément le cas rencontré chez ce client. Gravity Forms permet de dupliquer une notification existante et de lui appliquer une condition d’envoi. La méthode la plus fiable consiste à ajouter un champ caché au formulaire, rempli automatiquement à l’affichage avec la langue courante via un shortcode ou un script, puis à configurer chaque notification dupliquée pour ne s’envoyer que si ce champ correspond à la langue ciblée.
- Dupliquez la notification existante autant de fois qu’il y a de langues actives sur le site.
- Ajoutez une condition d’envoi basée sur le champ caché de langue pour chaque notification dupliquée.
- Traduisez intégralement le sujet et le corps de chaque notification dupliquée, y compris les libellés qui accompagnent les variables dynamiques comme
{Votre nom:1}. - Testez une soumission complète dans chaque langue avant de considérer la configuration terminée.
Attention aux variables dynamiques mal placées
Un piège fréquent lors de la traduction du corps d’une notification consiste à casser accidentellement une variable dynamique de Gravity Forms en modifiant son orthographe ou ses accolades pendant la traduction du texte environnant. Une variable comme {Adresse email:3} doit rester strictement identique, seul le texte qui l’entoure doit changer de langue. Je recommande de toujours tester l’envoi réel après traduction, plutôt que de se fier à une simple relecture visuelle du texte dans l’éditeur de notification.
Sur un formulaire multilingue, je considère la notification email comme un livrable à part entière, avec sa propre étape de recette, distincte de la simple vérification visuelle du formulaire affiché sur la page.
En résumé
Traduire un formulaire Gravity Forms sur un site multilingue avec Polylang demande de traiter séparément quatre éléments : les libellés visibles via pll_register_string(), le message de confirmation, et surtout les notifications email dupliquées avec des conditions d’envoi par langue. C’est ce dernier point, souvent négligé parce qu’invisible sur le site lui-même, qui cause le plus fréquemment des envois dans la mauvaise langue faute d’une recette de test complète après configuration.
