Un client opérant en France, en Belgique et en Suisse romande nous a confié la refonte de son site institutionnel sur un thème bloc, avec un contenu à décliner en trois langues via Polylang. Sur le papier, rien d’inhabituel pour une agence habituée aux sites multilingues. Dans les faits, l’éditeur de site introduit des subtilités qui méritent d’être connues avant de s’engager sur ce genre de projet.
Ce retour d’expérience ne prétend pas trancher entre Polylang et WPML dans l’absolu : il rapporte ce que l’on a observé sur ce projet précis, et sur un second projet plus modeste testé en parallèle avec WPML.
Les templates eux-mêmes ne se traduisent pas comme des articles
Premier constat, assez contre-intuitif : les templates et template parts d’un thème bloc, stockés comme des articles de type wp_template et wp_template_part, ne sont pas automatiquement pris en charge par les mécanismes de traduction habituels de Polylang, pensés à l’origine pour les articles et les pages. Sur ce projet, l’en-tête du site restait identique quelle que soit la langue sélectionnée, y compris pour des libellés censés changer.
Extraire les chaînes fixes des patterns
La solution retenue a consisté à sortir tout texte fixe des template parts (libellés de menu, mentions légales courtes, texte du bouton de recherche) pour les faire passer par des chaînes traduisibles enregistrées via register_block_pattern() et la fonction __(), plutôt que de les laisser en dur dans le contenu du template part. Cela demande une discipline supplémentaire par rapport à un thème classique, où __() s’utilise naturellement dans chaque fichier PHP.
register_block_pattern( 'mon-theme/bandeau-contact', array(
'title' => __( 'Bandeau de contact', 'mon-theme' ),
'content' => sprintf(
'<!-- wp:paragraph --><p>%s</p><!-- /wp:paragraph -->',
esc_html__( 'Contactez notre équipe', 'mon-theme' )
),
) );Le menu de navigation, un point de friction différent selon l’extension
Avec Polylang, chaque langue nécessite son propre menu de navigation créé séparément, puis assigné au bon emplacement via le bloc Navigation. Avec WPML, testé sur le second projet, la synchronisation des menus entre langues s’est révélée plus automatisée, mais avec moins de contrôle fin sur les libellés spécifiques à chaque langue quand ils divergeaient légèrement du menu source.
Ce qu’on a retenu de la comparaison
- Polylang demande plus de configuration manuelle mais laisse un contrôle total sur chaque menu.
- WPML automatise davantage, au prix d’ajustements parfois nécessaires après synchronisation.
- Aucune des deux extensions ne gère nativement, à cette date, la traduction complète des templates de l’éditeur de site.
Les gabarits par langue, une solution de contournement
Sur les rares templates où le contenu structurel devait réellement différer selon la langue (mentions légales localisées, par exemple), la solution retenue a consisté à dupliquer le template et à le sélectionner conditionnellement, plutôt que de chercher une traduction automatique de la structure elle-même. Une solution pragmatique, mais qui alourdit la maintenance si les langues se multiplient.
En résumé
Un site multilingue construit avec l’éditeur de site demande une préparation en amont plus poussée qu’avec un thème classique : la traduction ne se limite plus au contenu éditorial, elle touche aussi la structure elle-même si elle contient du texte fixe. Ni Polylang ni WPML n’ont, à ce jour, pleinement rattrapé cette spécificité des thèmes bloc, ce qui oblige à composer avec des solutions de contournement documentées et assumées dès le cahier des charges.
