Traduire des modèles Elementor et Divi sans casser les mises en page

Vous avez tout fait correctement. Vous avez acheté un thème premium, trouvé le fichier .po, l'avez traduit avec soin et avez téléversé le fichier .mo dans votre dossier de langues. Les chaînes dans l'en-tête du thème se mettent à jour correctement. Le pied de page s'affiche en espagnol. Votre processus de commande WooCommerce est localisé. Mais ensuite, vous ouvrez la page d'accueil et chaque titre, bouton et bloc de texte construit avec Elementor est toujours en anglais.

Vous vérifiez le fichier .po. Vous pouvez voir les chaînes anglaises dans le code. Vous retraduisez. Rien ne change. Vous videz les caches. Rien ne change. Vous vous persuadez que quelque chose est cassé jusqu'à ce que quelqu'un dans un forum vous fasse remarquer gentiment : Elementor (et Divi, et Beaver Builder, et Bricks) ne stockent pas le contenu dans des fichiers .po. Ils ne l'ont jamais fait. Vous vous êtes battu contre un problème qui n'est pas soluble avec l'approche que vous utilisez.

Ce guide explique pourquoi le contenu des constructeurs de pages est architecturalement différent du contenu des thèmes et des extensions, les deux chemins pour le traduire, et comment maintenir le balisage des widgets intact pendant la traduction afin que vos mises en page soigneusement conçues ne se désagrègent pas.

Pourquoi Elementor et Divi n'utilisent pas les fichiers .po

Les fichiers .po stockent les chaînes qui se trouvent dans le code – des appels comme __( 'Shop', 'mytheme' ) dispersés dans les modèles PHP. L'outil de construction WP-CLI peut extraire ces chaînes dans un modèle .pot, les traducteurs travaillent sur des fichiers .po, et les fichiers .mo compilés sont chargés à l'exécution.

Le contenu des constructeurs de pages est différent. Lorsque vous tapez "Bienvenue dans notre boutique" dans un widget de titre Elementor, ce texte ne se trouve dans aucun fichier PHP. Il est enregistré sous forme de JSON (Elementor) ou de blob de shortcode (Divi) dans la table wp_postmeta, associé à la publication où vous l'avez placé.

Où se trouve réellement le contenu des constructeurs de pages

Elementor stocke l'arborescence des widgets de chaque page dans les postmeta sous la clé _elementor_data. Ouvrez n'importe quelle publication dans la base de données et vous trouverez un tableau JSON décrivant chaque section, colonne et widget, avec les réglages et le contenu en ligne :

{
  "id": "a1b2c3",
  "elType": "widget",
  "widgetType": "heading",
  "settings": {
    "title": "Welcome to our store",
    "size": "xl",
    "header_size": "h1"
  }
}

Divi stocke le contenu de sa page sous forme de shortcodes intégrés dans post_content :

[et_pb_section][et_pb_row][et_pb_column type="4_4"]
  [et_pb_text]Welcome to our store[/et_pb_text]
[/et_pb_column][/et_pb_row][/et_pb_section]

Bricks, Beaver Builder et Oxygen suivent le même schéma avec leur propre format. Aucun de ces contenus n'est jamais affecté par les fichiers .po / .mo.

Ce qui se trouve dans les fichiers .po

L'extension du constructeur de pages elle-même contient des chaînes d'interface utilisateur – des étiquettes de boutons dans l'éditeur, des messages d'erreur, des notifications d'administration. Celles-ci se trouvent dans les fichiers .po et sont traduites par vos fichiers .mo dans wp-content/languages/plugins/. C'est généralement la raison pour laquelle les gens sont confus : ils traduisent des chaînes "Elementor" et voient l'interface utilisateur de l'éditeur en espagnol, mais le contenu réel qu'ils ont construit avec ces widgets reste en anglais.

Cette distinction est également la cause première de la moitié des tickets dans notre guide de dépannage pour les traductions qui n'apparaissent pas – le lecteur s'attend à ce que les fichiers .mo affectent le contenu qu'il voit sur le front-end, mais le contenu est dans la base de données, pas dans le code.

Ce que les fichiers .po couvrent réellement sur un site de constructeur de pages

Permettez-moi de tracer une ligne claire entre les deux afin que vous sachiez exactement ce que chaque type de fichier gère.

Les fichiers .po / .mo traduisent

• Les chaînes de modèle du thème : get_template_part, texte codé en dur dans header.php, footer.php, functions.php.
• Les chaînes de l'interface utilisateur des extensions : le processus de commande WooCommerce, les étiquettes d'administration Yoast, les étiquettes de champ Contact Form 7.
• L'interface utilisateur de l'extension du constructeur de pages : les boutons de l'éditeur Elementor, les messages de confirmation d'enregistrement Divi.
• Les chaînes dynamiques que les extensions affichent sur le front-end : WooCommerce "Ajouter au panier", "En rupture de stock", totaux du panier.

Les fichiers .po / .mo NE traduisent PAS

• Les titres, paragraphes, textes de boutons tapés dans les widgets Elementor.
• Les légendes d'images, les effets de survol, les titres d'accordéons à l'intérieur des modules Divi.
• Le contenu des modèles réutilisables, des sections globales, des blocs enregistrés.
• Les étiquettes CSS personnalisées ou les scripts en ligne à l'intérieur des widgets de constructeur.

C'est pourquoi la documentation des auteurs de thèmes sur la traduction est techniquement correcte mais souvent inutile pour les utilisateurs finaux. Notre guide sur comment localiser n'importe quel thème WordPress couvre en détail le côté thème – cet article reprend là où celui-ci s'arrête.

Deux chemins pour la localisation des constructeurs de pages

Il existe exactement deux façons de traduire le contenu des constructeurs de pages, et les deux présentent de réels compromis.

Chemin un : Dupliquer les pages par langue

Utilisez une extension multilingue comme WPML, Polylang ou TranslatePress. Elle crée une copie de chaque page par langue. Dans Elementor, vous dupliquez l'ensemble de la mise en page et échangez le texte sur chaque copie. Dans Divi, vous copiez le blob de shortcode et traduisez le texte entre les balises.

Avantages : Chaque langue peut avoir des mises en page conçues indépendamment (utile lorsque le texte traduit est plus long et casse votre design original). Compatibilité totale avec l'éditeur visuel du constructeur de pages.

Inconvénients : Échelle linéaire – 5 langues signifient 5 fois le travail de mise en page. Toute modification de design doit être appliquée 5 fois. La base de données grossit rapidement. La mise en cache devient plus difficile.

Chemin deux : Couche de traduction de chaînes

Certaines extensions (Polylang Pro, le module String Translation de WPML, TranslatePress) peuvent exposer des chaînes individuelles à l'intérieur des widgets de constructeur de pages pour la traduction, puis les échanger au moment du rendu. Vous maintenez une seule mise en page et l'extension traduit les chaînes sur place.

Avantages : Source unique de vérité pour la mise en page. Les modifications de design s'appliquent partout.

Inconvénients : Moins de flexibilité lorsque la longueur du texte traduit change radicalement. Certains widgets (complexes avec du contenu imbriqué, des listes dynamiques, des formulaires) n'exposent pas les chaînes clairement. Coût de performance par rendu.

Notre comparaison Polylang vs WPML vs TranslatePress couvre plus en détail les compromis de chaque extension.

Maintenir le balisage des widgets en sécurité pendant la traduction

Quel que soit le chemin que vous choisissez, le contenu traduit doit préserver le balisage structurel du constructeur. Si votre traducteur supprime un shortcode Elementor, remplace un attribut de données ou réorganise des balises imbriquées, le widget s'affiche de manière erronée.

Zones de danger Elementor

Les widgets Elementor intègrent des shortcodes et des balises dynamiques dans les réglages de texte. Le champ de titre d'un widget de titre peut contenir :

Welcome to <strong>our</strong> [user_name] store

Ce [user_name] est une balise dynamique – Elementor le remplace par le nom de l'utilisateur connecté au moment du rendu. Si la traduction le déforme, vous obtenez le texte littéral "[user_name]" affiché aux utilisateurs.

Les icônes à l'intérieur des boutons utilisent des attributs de classe qui ne doivent pas être traduits. Le texte alternatif de l'image est stocké séparément de l'URL de l'image. Les mises en page de colonnes utilisent des réglages spécifiques aux points d'arrêt (title_mobile, title_tablet) qui nécessitent une gestion individuelle.

Imbrication de shortcodes Divi

Les shortcodes Divi s'imbriquent profondément : [et_pb_section][et_pb_row][et_pb_column][et_pb_text]. Un traducteur qui traite le blob comme du texte brut encodera les crochets, traduira les valeurs d'attribut ou perdra les balises de fermeture. N'importe laquelle de ces actions corrompt le module et Divi refuse de le rendre.

Le modèle sûr

Pour l'un ou l'autre constructeur, la traduction doit :

1. Analyser le format du widget (JSON pour Elementor, AST de shortcode pour Divi).
2. Parcourir l'arborescence en identifiant uniquement les champs de texte visibles par l'utilisateur.
3. Verrouiller les shortcodes, les balises dynamiques, les attributs HTML et le CSS en ligne.
4. Envoyer uniquement les surfaces de texte au traducteur avec le contexte.
5. Réinsérer le texte traduit dans la structure originale.

C'est le même principe que notre moteur applique aux fichiers .po. Le guide pour traduire des fichiers .po sans casser les variables de code explique en détail les motifs %s et les espaces réservés – l'équivalent pour le constructeur de pages est les shortcodes et les balises dynamiques.

Un flux de travail hybride qui fonctionne réellement

Pour la plupart des équipes, la réponse pratique est de combiner les deux approches.

Étape 1 : Traduire l'interface utilisateur du thème et des extensions via les fichiers .po

Exportez les fichiers .pot de votre thème et des extensions clés (WooCommerce, Yoast, interface utilisateur du constructeur de pages). Traduisez-les une fois via un traducteur cloud qui respecte le format .po. Déposez les fichiers .mo compilés dans wp-content/languages/. Cela gère 80 % des chaînes d'interface de votre site avec un entretien quasi-nul.

Étape 2 : Choisir une extension multilingue pour le contenu dynamique

Installez Polylang ou WPML pour le contenu des articles, pages et produits. Configurez la structure des URL (/es/, /fr/) et les balises hreflang. Cela vous donne l'infrastructure pour le contenu de la base de données par langue.

Étape 3 : Dupliquer vos modèles de constructeur de pages de manière sélective

Pour les pages de destination à fort trafic, les pages d'accueil et le contenu marketing essentiel, dupliquez la page dans chaque langue et traduisez les widgets manuellement. Vous obtenez un contrôle total du design là où cela compte.

Étape 4 : Utiliser la traduction de chaînes pour les blocs répétés

Pour les sections globales, les modèles réutilisables et les CTA de pied de page qui apparaissent sur chaque page, utilisez la fonction de traduction de chaînes de votre extension multilingue. Mettez à jour à un seul endroit, échangez au rendu.

Étape 5 : Effectuer des contrôles de qualité

Le contenu traduit du constructeur de pages doit s'afficher sans décalage de mise en page. Les langues plus longues (allemand, russe) peuvent casser la largeur des boutons. Les langues plus courtes (chinois, japonais) laissent des espaces blancs gênants. Testez chaque modèle par langue avant de le mettre en ligne.

Pièges courants et comment les éviter

Quelques pièges qui apparaissent dans chaque projet de localisation de constructeur de pages.

Le texte alternatif de l'image ne se traduit pas

Elementor et Divi stockent tous deux le texte alternatif par instance de widget, et non dans la médiathèque. La traduction de l'image originale ne traduit pas le texte alternatif dans chaque widget qui l'utilise. Mettez à jour le texte alternatif dans chaque page dupliquée.

Formulaires et champs personnalisés

Les formulaires de contact intégrés dans les widgets de constructeur de pages ont leurs propres chaînes (étiquettes, espaces réservés, messages de validation). Consultez notre guide sur la traduction de Gravity Forms et Contact Form 7 pour le côté formulaire.

Widgets et modèles globaux

Les modifications apportées à un modèle global se propagent à toutes les pages l'utilisant, y compris les copies traduites. Cela peut être utile ou catastrophique selon que vous souhaitez un contenu partagé ou séparé. Décidez explicitement par modèle.

Expiration du cache de traduction

Les constructeurs de pages mettent en cache agressivement le HTML rendu. Après la traduction, purgez tous les caches, y compris le cache CSS d'Elementor (Elementor > Outils > Régénérer le CSS) et le cache CSS statique de Divi.

Tout mettre ensemble

Traduire un site construit avec Elementor ou Divi n'est pas plus difficile que de traduire un thème statique – cela nécessite simplement le bon modèle mental. Les chaînes de thème et d'extension vivent dans des fichiers .po et transitent via des fichiers .mo. Le contenu des constructeurs de pages vit dans la base de données et transite via des extensions multilingues ou une duplication manuelle. Mélanger les deux chemins est la source la plus courante de la frustration "pourquoi mes traductions ne fonctionnent-elles pas".

Le flux de travail qui l'emporte est ennuyeux : fichiers .mo statiques pour tout ce qui est dans le code, extension multilingue pour le contenu des pages, et curation manuelle pour les pages de destination à forte valeur ajoutée. Aucun outil unique ne gère les trois, et quiconque vous promet le contraire essaie de vous vendre quelque chose.

Prêt à traduire les fichiers .po de votre thème et de vos extensions sans casser le balisage des widgets ? Essayez SimplePoTranslate gratuitement – aucune carte de crédit requise. Téléchargez le .po, téléchargez les traductions sûres, déposez-les dans wp-content/languages/.