Un fabricant de composants industriels nous a confié la refonte de son site vitrine, à diffuser en français, anglais, allemand et italien, avec des équipes commerciales locales capables de modifier elles-mêmes le contenu de leur langue. Elementor était déjà le choix du client pour sa facilité de prise en main ; notre travail a consisté à le faire cohabiter proprement avec WPML sur un projet à cette échelle.
Le résultat final fonctionne bien, mais pas sans quelques frictions qu’il vaut mieux anticiper avant de démarrer, plutôt que de les découvrir en cours de projet.
Traduire les templates Theme Builder
Premier point de friction : un header ou un footer construit avec le Theme Builder n’est pas automatiquement traduit par WPML. Chaque template doit être explicitement enregistré comme traduisible dans WPML > Réglages > Types de contenu personnalisés, puis traduit indépendamment, page par page, comme n’importe quel contenu.
- Header : un template par langue, avec son propre menu et ses propres libellés de bouton.
- Footer : idem, en particulier pour les mentions légales, différentes selon le pays visé.
- Les conditions d’affichage (Theme Builder) doivent être vérifiées par langue : une condition « Entire Site » s’applique globalement, mais l’association entre une traduction de template et la langue correspondante doit être confirmée manuellement la première fois.
Ce qui reste heureusement partagé : les classes globales
Bonne surprise du projet : les Global Colors et Global Fonts définis dans les Site Settings d’Elementor ne sont pas dupliqués par langue. Ils sont partagés au niveau du site entier, ce qui signifie qu’une mise à jour de la palette de couleurs de marque se propage instantanément sur les quatre langues, sans intervention supplémentaire. C’est un vrai gain de cohérence sur un projet multilingue, comparé à une approche où chaque langue aurait son propre jeu de styles à maintenir en parallèle.
Widgets et contenu dynamique : la traduction champ par champ
WPML fonctionne, avec Elementor, en dupliquant la structure JSON de chaque page pour chaque langue, chaque champ de texte devenant traduisible individuellement via l’éditeur de traduction avancé (WPML Translation Editor). Pour un widget simple (titre, texte), cela fonctionne sans réglage particulier. Pour des widgets à répéteur (comme une liste d’avantages avec icônes), il faut vérifier que chaque sous-champ du répéteur est bien exposé à la traduction — un oubli fréquent sur les widgets tiers mal packagés pour la compatibilité WPML.
Formulaires multilingues : le piège des actions after submit
C’est le point qui nous a demandé le plus d’ajustement. Un formulaire de contact Elementor Pro dupliqué automatiquement par WPML pour chaque langue génère, en réalité, des instances distinctes du widget, chacune avec son propre identifiant interne. Si les actions after submit (envoi d’e-mail, webhook CRM) référencent un identifiant fixe côté code personnalisé, elles doivent être adaptées pour fonctionner sur les quatre versions du formulaire, pas seulement la version française d’origine.
// Vérifier l'ID du formulaire courant plutôt que de le coder en dur
add_action( 'elementor_pro/forms/new_record', function( $record, $handler ) {
$form_name = $record->get_form_settings( 'form_name' );
if ( 'Contact' !== $form_name ) {
return;
}
// Le nom du formulaire reste stable même si le contenu est traduit
// contrairement à l'ID de widget, propre à chaque traduction
}, 10, 2 );
Notre solution retenue : filtrer sur le nom du formulaire (form_name), stable à travers les traductions si on prend soin de le nommer identiquement dans chaque langue, plutôt que sur un identifiant technique de widget qui diffère d’une traduction à l’autre.
Répartition des rôles avec les équipes locales
| Rôle | Peut modifier | Ne peut pas modifier |
|---|---|---|
| Commercial local | Texte de sa langue, images locales | Site Settings, templates Theme Builder |
| Webmaster central | Templates, Site Settings, formulaires | — |
Sur ce projet, limiter les droits WordPress des équipes locales au Translation Editor de WPML, sans accès à l’éditeur Elementor complet, a évité une bonne partie des incidents de mise en page constatés sur des projets multilingues précédents.
En résumé
Elementor et WPML cohabitent bien sur un site à quatre langues, à condition d’anticiper trois points : la traduction explicite de chaque template Theme Builder, la vigilance sur les répéteurs de widgets tiers, et la robustesse des actions after submit des formulaires face à la duplication d’identifiants entre langues. Les classes globales restent, elles, une vraie force de cette combinaison, en gardant la cohérence visuelle sans effort supplémentaire par langue.
