Comment traduire Gravity Forms dans WordPress : champs, Notifications, Confirmations, logique conditionnelle
Découvrez comment traduire chaque partie d’un formulaire Gravity Forms sur votre site WordPress dans toutes les langues parlées par vos visiteurs. Ce guide couvre les étiquettes de champs, les champs de tarification, les Options de liste déroulante, les messages de validation par champ, les Confirmations, les Notifications avec routage, la logique conditionnelle et les modules complémentaires d’intégration qui absorbent les soumissions. Il vous guide à travers le flux de travail de Gravity Forms avec WPML et le module complémentaire GFML.
Avant de commencer
Installez et activez ces extensions :
- Gravity Forms.
- WPML et WPML Traduction de chaînes.
- GFML – Gravity Forms Multilingual (le module complémentaire couvert par cette page).
Créez le formulaire dans Gravity Forms dans la langue source de votre site. Ajoutez tous les champs que vous souhaitez (champs de tarification, structure paginée, logique conditionnelle, Notifications et Confirmations) avant d’envoyer le formulaire à la traduction. Vous pouvez toujours modifier le formulaire plus tard et retraduire les différences.
Tout traduire automatiquement s’en charge pour vous
Si l’option Tout traduire automatiquement est activée sur votre site, vous n’avez pas besoin d’envoyer manuellement le formulaire à la traduction. WPML détecte les formulaires nouveaux et mis à jour avec le reste de votre contenu et les traduit en arrière-plan. L’étape d’insertion dans la page ci-dessous s’applique toujours, mais l’étape consistant à envoyer le formulaire à la traduction est automatique. Le reste de cette page décrit le processus manuel pour les sites utilisant Traduire une partie : vous choisissez quoi traduire (ou pour les formulaires que vous souhaitez traduire avant la file d'attente automatique).
Envoyez le formulaire à la traduction
- Ouvrez WPML > Traductions > Tableau de bord.
- Développez la section Gravity Forms.
- Cochez le formulaire que vous souhaitez traduire.
- Choisissez une méthode de traduction : PTC (recommandé), votre traducteur ou Traduire moi-même.
- Cliquez sur Traduire.
Le formulaire, ses champs, ses Options, ses Notifications, ses Confirmations et ses messages de validation par champ sont tous regroupés dans la même tâche de traduction. Les traducteurs les voient sous forme de lignes libellées dans l’Éditeur de traduction avancé.
Insérez le formulaire dans vos pages traduites
Gravity Forms s’intègre dans une page ou un article, généralement via le bloc Gravity Forms ou le shortcode [gravityform id="X" title="false"]. La façon dont vous gérez l’insertion multilingue est ce qui surprend le plus les clients, voici donc la règle :
Utilisez le même bloc ou shortcode sur chaque version linguistique de la page. Ne créez pas un formulaire distinct par langue.
Le flux de travail :
- Créez le formulaire une fois dans votre langue source.
- Envoyez le formulaire à la traduction (ou laissez Tout traduire automatiquement s’en charger).
- Insérez le formulaire sur la page dans la langue source à l’aide du bloc Gravity Forms ou du shortcode
[gravityform]. - Traduisez la page via WPML > Traductions > Tableau de bord de la même manière que vous traduiriez n’importe quelle autre page. L’intégration du formulaire est préservée dans la page traduite.
- Lorsqu’un visiteur arrive sur la page traduite, GFML affiche automatiquement le formulaire dans la langue du visiteur : même ID de formulaire, même shortcode, contenu traduit.
Vous n’avez pas besoin d’un ID de formulaire différent par langue. Vous n’avez pas besoin de changer de shortcode selon la langue. La traduction est liée au formulaire source ; l’extension de liaison résout la version dans la bonne langue au moment de l’affichage, en fonction de la langue de la page.
L’exception : lorsque vous souhaitez réellement des formulaires différents par langue. Certains sites ont besoin de formulaires structurellement différents selon la langue (champs différents, logique différente, et pas seulement un texte différent). Dans ce cas, créez des formulaires Gravity Forms distincts (un par langue) et insérez le shortcode de chacun sur la version linguistique correspondante de la page à l’aide de l’éditeur WordPress pour cette traduction. C’est la seule situation où les shortcodes diffèrent d’une langue à l’autre.
Piège lié aux constructeurs de pages
Si votre page est construite avec Divi, Elementor ou un autre constructeur de pages qui enveloppe les shortcodes dans son propre module de texte, le shortcode peut ne pas toujours survivre proprement à la traduction. Si la page traduite affiche le formulaire dans la langue source, ouvrez la page traduite dans le constructeur de pages et réinsérez-y le bloc ou le shortcode du formulaire. L’éditeur de blocs natif de WordPress et l’éditeur classique ne présentent pas ce problème.
Les étiquettes de champs et les Options se traduisent avec les champs de tarification et de produit
Chaque étiquette de champ, espace réservé, Option de liste déroulante, choix de bouton radio, étiquette de case à cocher et contenu de champ HTML apparaît dans la tâche de traduction. Pour les champs de tarification spécifiques à Gravity Forms (Produit, Quantité, Total, Expédition), les étiquettes se traduisent également (« Quantity » devient « Quantité »), tandis que le traitement numérique sous-jacent reste intact. Les champs de liste, les signatures numériques et les téléversements de fichiers se traduisent de la même manière. Les champs Choix multiple et Choix d'image (types de champs de Gravity Forms 2.9) se traduisent à partir de GFML 1.8.3.
Formulaires paginés et formulaires conversationnels
Pour les formulaires paginés, chaque en-tête de page et titre de saut de page se trouve dans la tâche de traduction. La logique conditionnelle qui s’étend sur plusieurs pages survit à la traduction. Les valeurs de choix restent alignées d’une langue à l’autre, de sorte que les règles d’affichage/masquage continuent de s’exécuter sur les mêmes données. Les formulaires conversationnels (le mode à une question à la fois) traduisent chaque invite et chaque transition. Choisissez une version linguistique, parcourez le flux conversationnel et confirmez que chaque étape se lit naturellement avant de publier.
Messages de validation par champ
Chaque champ dans Gravity Forms possède son propre paramètre de message de validation dans l’onglet Avancé du champ : le texte affiché lorsque la validation échoue. Chacun d'eux apparaît sous forme de ligne dans l’Éditeur de traduction avancé.
Si vous ne voyez pas de message de validation par champ dans la tâche de traduction, le champ utilise probablement le message par défaut de Gravity Forms (défini dans Formulaires > Paramètres > Paramètres du formulaire) plutôt qu’un remplacement par champ. Vous pouvez soit définir un message personnalisé par champ et renvoyer le formulaire à la traduction, soit traduire le message par défaut global via WPML Traduction de chaînes.
Confirmations : texte, redirection et page
Gravity Forms prend en charge trois types de Confirmations et tous les trois fonctionnent de manière multilingue :
- Les Confirmations de type Texte se traduisent en ligne. Modifiez la Confirmation dans la langue source dans Gravity Forms > renvoyez le formulaire à la traduction > le texte traduit apparaît pour chaque langue.
- Les Confirmations de type Page pointent vers une page WordPress. Traduisez cette page via le flux de travail normal de traduction de pages de WPML ; le visiteur voit la version linguistique qui correspond à son contexte.
- Les Confirmations de type Redirection envoient le visiteur vers une URL après la soumission. L’URL elle-même est traduisible par langue. Définissez une URL de remerciement différente pour chaque langue dans l’Éditeur de traduction avancé.
Notifications et routage des Notifications
Chaque Notification de Gravity Forms se traduit par langue : E-mail du destinataire, Nom de l'expéditeur, Sujet, modèles de corps de message et balises de fusion. Le corps de la Notification utilise les balises de fusion de Gravity Forms ({Name}, {Email}, {All Fields}) et celles-ci se résolvent correctement après la traduction. Les règles de routage des Notifications envoient différentes soumissions à différents destinataires en fonction des valeurs des champs. Elles survivent à la traduction car les valeurs de choix sous-jacentes restent alignées d’une langue à l’autre.
Après la traduction, envoyez une soumission de test dans chaque langue et confirmez que la Notification arrive dans la langue du visiteur avec les bonnes substitutions de balises de fusion.
Logique conditionnelle sur les valeurs de choix traduites
La logique conditionnelle sur les choix textuels (boutons radio, cases à cocher, listes déroulantes) continue de fonctionner à travers les traductions car GFML maintient un mappage des valeurs entre les étiquettes sources et traduites. Le visiteur voit « Pas encore » en français ; la valeur sous-jacente reste « Not yet » ; la règle conditionnelle continue de s’exécuter sur « Not yet ».
La seule chose qui interrompt la logique conditionnelle : modifier l’étiquette de choix dans la langue source après la traduction sans renvoyer le formulaire à la traduction. Le mappage devient obsolète. Corrigez cela en renvoyant le formulaire : GFML met à jour le mappage des valeurs.
Modules complémentaires d’intégration : Mailchimp, ActiveCampaign, HubSpot, Zapier, Slack, Webhooks
Les modules complémentaires de Gravity Forms qui transmettent les soumissions à des services tiers (Mailchimp, ActiveCampaign, HubSpot, Zapier, Slack, Webhooks et autres) reçoivent les saisies traduites du visiteur. Le nom et le message d’un visiteur français arrivent en français à destination. Les étiquettes de liste mappées, les étapes de pipeline et les noms de canaux se traduisent également s’ils existent en tant que chaînes de texte au niveau du formulaire.
Si votre intégration utilise des valeurs de champ plutôt que des étiquettes (par exemple, le mappage d’une valeur de liste déroulante à une liste Mailchimp), la valeur reste canonique dans toutes les langues afin que le mappage ne soit pas interrompu.
Pièges courants
- Les étiquettes de choix ne se traduisent pas dans les e-mails de Notification. Renvoyez le formulaire à la traduction après avoir modifié les étiquettes dans la langue source. Si le problème persiste, vérifiez que GFML est à jour. Il s’agissait d’un problème récurrent sur les anciennes versions et il est suivi sur les fils de discussion du forum.
- Le style du bloc de formulaire semble incorrect sur les pages traduites. Régression de style connue : consultez la page des errata. Solution de contournement : utilisez l’intégration standard par shortcode
[gravityform]plutôt que le bloc de formulaire en attendant un correctif. - Le formulaire affiche « There is nothing to translate » (Il n'y a rien à traduire) alors qu’il y a manifestement du contenu à traduire. Il s’agit généralement d’un problème de cache du Tableau de bord. Actualisez la page, ou renvoyez le formulaire à la traduction depuis l'article qui l'intègre.
- La logique conditionnelle cesse de s’exécuter dans les formulaires traduits. Une étiquette de choix a été modifiée dans la langue source après la traduction. Renvoyez le formulaire à la traduction pour actualiser le mappage des valeurs.
Écrit par Amir · Dernière mise à jour le 2 juillet 2026
Écrit par Amir · Dernière mise à jour 2 juillet 2026