Traduction des formulaires sur Tilda : pourquoi c'est plus compliqué qu'il n'y paraît
Dans cet article : pourquoi les formulaires sur Tilda ne sont pas traduits par les outils standard, ce qui ne fonctionne pas avec Weglot et Linguise, comment les formulaires sont structurés dans Zero Block, pourquoi le texte après l'envoi reste dans la langue d'origine et comment tout cela est résolu au niveau du serveur. Plus une liste de contrôle à vérifier avant de livrer le site au client.
Le client demande un site multilingue sur Tilda. Vous connectez la traduction, vérifiez les pages — tout semble correct.
Mais ensuite, vous ouvrez le formulaire de contact : les noms des champs sont en russe, le bouton « Envoyer », le message d'erreur « Remplissez le champ ». Tout cela sur une page anglaise.
C'est ainsi que fonctionnent la plupart des solutions de traduction Tilda. Et ce n'est pas un bug d'un service spécifique, mais un problème architectural.
Pourquoi les formulaires sur Tilda sont traduits différemment
Le texte ordinaire sur une page Tilda est statique. Il est intégré dans le HTML, et le traducteur peut le trouver, le remplacer, le livrer à l'utilisateur. Tout est prévisible.
Avec les formulaires, c'est une autre histoire. Tilda les génère via JavaScript : après le chargement de la page, le script crée dynamiquement les champs, les noms de champs, les astuces à l'intérieur des champs et les boutons. Au moment où le traducteur essaie de trouver le texte, il n'est pas encore sur la page. Ou il est déjà là, mais il est immédiatement remplacé par les scripts de Tilda.
C'est ce qu'on appelle contenu dynamique, et c'est ce qui brise la plupart des solutions de traduction. Google reconnaît officiellement, le rendu JavaScript pose des problèmes même pour l'indexation, les traducteurs de navigateur sont confrontés aux mêmes limitations.
Google reconnaît officiellement, le rendu JavaScript pose des problèmes même pour l'indexation, les traducteurs de navigateur sont confrontés aux mêmes limitations.
Outre les noms de champs, le formulaire contient plusieurs catégories d'éléments :
messages d'erreur lors du remplissage (« Entrez un email valide », « Champ obligatoire »)
texte après l'envoi, « Merci, nous vous contacterons »
indices à l'intérieur des champs avant le remplissage
légendes des cases à cocher, y compris l'accord sur le traitement des données
bouton d'envoi
Chacun de ces éléments nécessite un traitement distinct, et chacun a ses propres particularités techniques.
Cas particulier : les formulaires dans Zero Block
Tilda permet de créer des formulaires de deux manières : via des blocs standard et via Zero Block (un constructeur visuel avec une liberté totale de mise en page). Techniquement, ce sont des implémentations différentes, et leur logique de fonctionnement diffère.
En pratique, cela signifie que si la traduction fonctionne pour les formulaires standard, cela ne garantit pas un fonctionnement correct pour les formulaires dans Zero Block. Certains éléments peuvent ne pas être traduits ou être traduits de manière imprévisible. Ce n'est pas une exception, mais une conséquence de la façon dont Tilda est conçu : une même fonctionnalité est implémentée de plusieurs manières indépendantes.
Ce qui ne fonctionne pas chez les concurrents
Weglot
Weglot est conçu pour traduire le contenu HTML statique d'une page. Étant donné que les formulaires Tilda sont créés dynamiquement via JavaScript, leur contenu n'est pas toujours traité, ce qui peut laisser les formulaires dans la langue d'origine.
Vous pouvez essayer de contourner le problème via l'« éditeur visuel » de Weglot — ajouter manuellement les éléments du formulaire à traduire. Cela fonctionne partiellement : les champs principaux seront traduits, mais les messages d'erreur et le texte après l'envoi resteront non traduits. De plus, chaque modification du formulaire sur Tilda doit être réécrite manuellement dans Weglot.
Linguise
Linguise utilise une couche supplémentaire côté navigateur. Il fonctionne mieux avec le contenu dynamique, mais reste dépendant des particularités du chargement des formulaires dans Tilda. En conséquence, la traduction peut être instable : sur certaines pages, les formulaires s'affichent correctement, sur d'autres — partiellement ou avec des omissions, selon la configuration des blocs.
Solutions personnalisées
Certaines agences résolvent le problème manuellement : elles dupliquent la page pour chaque langue, créent des formulaires distincts avec des champs traduits. C'est une approche fiable, mais elle nécessite de maintenir plusieurs copies des formulaires et de les synchroniser à chaque modification, ce qui augmente les coûts de main-d'œuvre.
Comment la traduction de formulaires fonctionne dans Multify
Multify fonctionne comme un proxy inverse entre l'utilisateur et le site web : la requête passe par les serveurs Multify, où le contenu est traduit côté serveur, et le résultat final est déjà livré au navigateur de l'utilisateur.
Au lieu de capturer les éléments créés dynamiquement sur la page, Multify intercepte les réponses de Tilda et traduit le contenu sur le serveur. L'utilisateur reçoit déjà le HTML traduit, et les scripts Tilda affichent le formulaire dans la bonne langue.
Tous les éléments du formulaire sont traduits :
noms des champs
indices à l'intérieur des champs avant le remplissage
bouton d'envoi
messages d'erreur lors du remplissage
texte après envoi
légendes des cases à cocher
La logique des formulaires Tilda n'est pas altérée : les intégrations avec amoCRM, Bitrix24 ou tout autre CRM continuent de fonctionner. Les données sont envoyées comme d'habitude.
Une histoire à part : le consentement au traitement des données
Il y a un élément de formulaire qui nécessite une attention particulière : la case à cocher de consentement au traitement des données personnelles.
Sur un site en russe, il renvoie généralement à la « Politique de confidentialité » avec un texte conforme à la loi 152-FZ. Sur un site allemand ou un site destiné à un public européen, il s'agit déjà du RGPD, et les exigences de formulation sont juridiquement différentes: le consentement doit être explicite, distinct pour chaque finalité, sans cases à cocher pré-remplies.
Ce n'est pas une simple traduction de texte. C'est une localisation du contenu juridique — le remplacement d'un contexte juridique par un autre.
Multify traduit le texte de la case à cocher comme un contenu ordinaire. Mais la formulation juridique correcte pour un marché spécifique doit être préparée par l'équipe. Cela dépasse le cadre de la traduction automatique.
Conseil pratique : si vous lancez un site pour un public européen, préparez un texte de consentement distinct pour la version linguistique et transmettez-le comme « traduction manuelle » — la plupart des outils sérieux prennent en charge la redéfinition de lignes individuelles.
Texte après l'envoi du formulaire
Un autre point où tout se brise : le message que l'utilisateur voit après avoir cliqué sur le bouton.
Techniquement, il n'apparaît pas comme un texte statique, mais comme le résultat d'un événement après une réponse réussie du serveur. De nombreux traducteurs ignorent cet état : la page est traduite, mais le message « Merci pour votre demande, nous vous rappellerons dans les 30 minutes » reste en russe.
Pour un utilisateur qui a rempli le formulaire en anglais, cela ressemble à un échec, surtout s'il ne lit pas le russe.
Dans Multify, le texte après l'envoi est traduit avec le reste du contenu du formulaire, car la traduction s'applique à tous les états de la page, et pas seulement au chargement initial.
D'ailleurs, dans une boutique en ligne sur Tilda, le processus de commande est aussi une soumission de formulaire. Les mêmes champs, les mêmes messages d'erreur, le même texte de confirmation. Tous les mêmes problèmes de traduction, mais le coût de l'erreur est plus élevé.
Pourquoi Weglot traduit tout le site, mais pas les formulaires Tilda ?
Weglot fonctionne avec le HTML qui est déjà présent sur la page au moment du chargement. Les formulaires Tilda sont créés dynamiquement via des scripts — leur contenu n'existe pas encore lorsque Weglot parcourt la page. C'est pourquoi il ne les voit tout simplement pas.
Si je duplique la page pour chaque langue, les formulaires seront-ils traduits ?
Oui, cela fonctionne. Vous créez une page distincte avec un formulaire dans chaque langue et vous faites basculer les utilisateurs entre elles. L'inconvénient est que toute modification du formulaire nécessite une mise à jour manuelle de toutes les copies. Pour deux langues, c'est tolérable, pour cinq, c'est déjà un sérieux problème de maintenance.
Les données du formulaire sont-elles transmises correctement après la traduction ?
Oui. La traduction n'affecte que le texte affiché : noms de champs, astuces, boutons. Les données que l'utilisateur saisit dans les champs sont transmises telles quelles — nom, e-mail, téléphone sont envoyés au CRM sans modification. Les intégrations avec amoCRM, Bitrix24, Google Sheets continuent de fonctionner.
Est-il possible de définir manuellement le texte pour un élément de formulaire spécifique ?
Oui. Dans Multify, vous pouvez définir manuellement la traduction pour n'importe quelle chaîne. C'est particulièrement utile pour les textes juridiques : consentements, politiques, clauses de non-responsabilité, où la traduction automatique pourrait ne pas tenir compte du contexte juridique local.
Conclusion
La traduction des formulaires sur Tilda n'est pas une simple « sélection de la langue dans les paramètres ». C'est une tâche distincte avec plusieurs niveaux de complexité : création dynamique d'éléments, états en cas d'erreurs, contenu juridique, différentes implémentations d'une même fonctionnalité.
La plupart des outils la résolvent partiellement ou pas du tout. Si la traduction des formulaires est critique pour votre projet, vérifiez cela en premier lieu, avant de connecter et de configurer tout le reste.
Découvrez à quoi ressemble votre site dans une autre langue
Laissez un lien — nous vous montrerons une démo directement sur votre site.