Un client du secteur de l’import-export a demandé l’ajout d’une version arabe à son site déjà bilingue français-anglais, quelques jours après la sortie de WordPress 5.6. Dès la première prévisualisation, le menu principal s’affichait décalé hors de son conteneur, les icônes de réseaux sociaux pointaient dans le mauvais sens visuel, et le bouton d’appel à l’action du panier restait collé au bord gauche de l’écran alors que tout le texte se lisait de droite à gauche. Le thème, correctement traduit au niveau du texte par Polylang, n’avait jamais été pensé pour un sens de lecture inversé.
Ce cas se produit sur la quasi-totalité des thèmes qui n’annoncent pas explicitement une compatibilité RTL (Right To Left) dans leur documentation. Le texte s’inverse correctement grâce au navigateur, qui applique automatiquement le sens de lecture selon l’attribut dir du document, mais la mise en page construite en CSS classique, avec des propriétés comme margin-left ou float: left, reste figée dans le sens gauche à droite.
Comment WordPress déclare le sens de lecture
WordPress ajoute automatiquement l’attribut dir="rtl" sur la balise <html> lorsque la langue active du site est une langue s’écrivant de droite à gauche, comme l’arabe, l’hébreu ou le persan. Cette détection repose sur la fonction is_rtl(), qui vérifie la valeur retournée par le fichier de traduction chargé (le fichier .mo déclare cette information dans ses métadonnées). Sur un site multilingue avec Polylang, cette bascule se produit automatiquement à chaque changement de locale via switch_to_locale(), à condition que le fichier de langue arabe soit correctement installé.
WordPress charge également, si le thème le propose, une feuille de style spécifique nommée rtl.css, automatiquement enfilée à la place ou en complément du style.css principal lorsque is_rtl() renvoie vrai. C’est précisément l’absence de ce fichier qui causait l’effondrement de la mise en page chez ce client : le thème premium utilisé ne fournissait aucun fichier rtl.css.
Reconstruire la mise en page avec les propriétés logiques CSS
Plutôt que de dupliquer intégralement la feuille de style en inversant manuellement chaque left en right, j’ai privilégié les propriétés CSS logiques, qui s’adaptent automatiquement au sens de lecture déclaré par le document :
.bouton-panier {
margin-inline-start: 1rem;
padding-inline: 1.5rem 1rem;
border-inline-start: 2px solid var(--couleur-accent);
}Avec ces propriétés, margin-inline-start pointe vers la gauche en français et vers la droite en arabe, sans qu’aucune règle supplémentaire ne soit nécessaire. Cette approche, documentée par la MDN sur les propriétés logiques CSS, réduit considérablement le volume de code à maintenir par rapport à une feuille rtl.css complète et dupliquée.
Les cas qui résistent aux propriétés logiques
Certains éléments ne peuvent pas être corrigés uniquement par des propriétés logiques : les icônes directionnelles (une flèche « suivant » qui doit visuellement pointer vers la gauche en arabe), les carrousels dont le sens de défilement JavaScript reste câblé en dur, et les mises en page en float plutôt qu’en Flexbox ou Grid, qui ne suivent jamais automatiquement le sens de lecture. Sur ce projet, le carrousel de la page d’accueil, construit avec une bibliothèque JavaScript tierce, a nécessité une configuration explicite de son option de sens de défilement selon la langue active.
- Flexbox et Grid gèrent nativement l’inversion de direction via la propriété
directionhéritée du document. - Les mises en page en
floatdoivent être migrées ou corrigées au cas par cas, sélecteur RTL par sélecteur RTL. - Les polices arabes demandent souvent une hauteur de ligne légèrement supérieure pour un rendu confortable des diacritiques.
Tester avec un vrai contenu arabe, pas du texte de substitution
Un piège fréquent consiste à tester la mise en page RTL avec du texte latin simplement inversé visuellement par la propriété dir, sans jamais vérifier avec un vrai contenu arabe. Les mots arabes ont des longueurs et des formes de caractères très différentes du français, ce qui peut révéler des débordements de texte invisibles avec un contenu de test générique. Sur ce projet, un titre de section qui tenait sur une ligne en français prenait deux lignes en arabe, cassant l’alignement vertical d’une grille de cartes.
Je ne valide jamais une adaptation RTL avec du texte de substitution : le vrai contenu, fourni par un locuteur natif ou un traducteur professionnel, révèle systématiquement des cas que le texte de test ne montre jamais.
Notre verdict
Ajouter une langue RTL à un site WordPress existant demande un audit CSS complet du thème, pas seulement une vérification du texte traduit. Les propriétés logiques CSS couvrent la majorité des cas de mise en page moderne construite en Flexbox ou Grid, mais les composants interactifs comme les carrousels et les icônes directionnelles nécessitent une correction manuelle au cas par cas. Un test avec du contenu arabe réel, et non un texte de substitution, reste la seule façon fiable de valider le résultat avant mise en production.
