Ce qui casse vraiment quand on construit un site en arabe

La plupart des équipes découvrent que leur site ne fonctionne pas en arabe le jour de la mise en ligne. La bascule elle-même est triviale : on règle la direction du document et le texte s'écoule dans l'autre sens. Ce dont personne ne vous prévient, c'est la deuxième catégorie de problèmes, celle qui ne lève aucune erreur et semble plausible sur une capture d'écran, mais laisse la page discrètement orientée du mauvais côté. Voici cette liste, écrite en construisant et en livrant un site en anglais, en arabe et en français à la fois.

Pourquoi ma mise en page casse-t-elle quand je passe en arabe ?

Parce que direction: rtl n'inverse que le flux du texte, et l'essentiel d'une mise en page n'est pas du flux de texte. Elle retourne correctement l'ordre de lecture du contenu en ligne et l'alignement par défaut des blocs. Elle ne fait absolument rien à un élément positionné avec left: 5px, à une image cadrée avec object-position, à une keyframe qui translate d'un pourcentage négatif, ou à une icône dessinée vers la droite. Chacun de ces éléments conserve sa direction physique pendant que tout l'entoure s'inverse : la page devient contradictoire en interne plutôt que visiblement cassée. C'est pourquoi ces bugs survivent aux relectures : la capture semble correcte, et seule une personne lisant l'arabe remarque que le curseur du sélecteur est sous la mauvaise option.

Une partie, et c'est précisément la partie qui n'a jamais été difficile. Webflow applique automatiquement le droite-à-gauche sur les sites publiés pour les locales arabe, persane, hébraïque, ourdoue et yiddish. Next.js demande un attribut sur l'élément html. L'une comme l'autre vous donne un flux de texte correct et rien d'autre dans cette liste, car la plateforme ignore lesquelles de vos icônes encodent une direction, lesquelles de vos images ont un sujet plutôt qu'une texture, et lesquelles de vos keyframes présupposaient une mise en page filant vers la gauche. Considérez le RTL automatique comme le début du travail, pas comme la fonctionnalité. Ce qu'il vous achète réellement, c'est que tout problème restant vit dans votre propre code, là où vous pouvez le corriger.

Pourquoi mes chiffres sortent-ils à l'envers en arabe ?

L'algorithme bidirectionnel d'Unicode les réordonne, et il fait exactement ce pour quoi il a été conçu. Dans un paragraphe droite-à-gauche, un plus ou un pourcent en fin de chaîne est un caractère neutre : l'algorithme résout donc sa position d'après la direction environnante, pas d'après l'ordre de saisie. 100+ s'affiche +100, et 50% devient %50. Les chiffres eux-mêmes restent dans le bon ordre ; seul le symbole accolé se déplace. Le correctif consiste à dire à l'algorithme que le nombre est un îlot autonome, avec direction: ltr et unicode-bidi: isolate sur le span qui le porte. Ajoutez font-variant-numeric: tabular-nums si la valeur s'incrémente, sinon les chiffres tressautent à mesure que leur largeur change.

Faut-il aussi retourner les icônes ?

Retournez celles qui signifient une direction, et rien d'autre. Une flèche vers la diapositive suivante, un chevron dans un fil d'Ariane, un bouton retour : celles-là encodent une direction et doivent basculer avec la mise en page. Un logo, un bouton lecture, un cadran d'horloge ou une coche, non, et les retourner va de l'erreur au franchement gênant. Le piège, c'est que la règle vers laquelle on se tourne est une règle générale, et les règles générales attrapent ce que l'on ne visait pas. Un sélecteur assez large pour retourner toutes les flèches finira par retourner le logo d'un partenaire, le jour où quelqu'un en dépose un dans ce conteneur. Limitez le miroir à une classe appliquée délibérément, jamais à tous les SVG d'un sous-arbre inversé.

Pourquoi mon bandeau défilant sort-il de l'écran en arabe ?

Parce que la keyframe le déplace dans une direction fixe alors que la mise en page part désormais du bord opposé. Un bandeau de logos anime normalement vers translate3d(-50%) : la piste commence au bord gauche, file vers la gauche, et une moitié dupliquée rend la boucle continue. Inversez le document et la piste commence au bord droit, mais l'animation file toujours vers la gauche : elle s'éloigne du viewport et laisse derrière elle un vide qui grandit. Les pourcentages dans une transform se résolvent sur la boîte de l'élément, pas sur la direction d'écriture : rien de la bascule ne les atteint jamais. Il vous faut une seconde keyframe se terminant à plus 50 pour cent, et une règle qui ne la sélectionne qu'en droite-à-gauche.

Pourquoi la personne sur ma photo est-elle hors cadre en arabe ?

Parce que object-position déplace la fenêtre de recadrage et non le sujet, et que les deux se déplacent en sens inverse. Celui-ci est assez contre-intuitif pour être dit platement : pour ramener dans le cadre un sujet situé à droite du centre, vous augmentez la valeur X, ce qui déplace la fenêtre vers la droite et emporte donc le sujet vers la gauche. Une mise en page inversée veut généralement la valeur opposée à celle qui fonctionnait en gauche-à-droite. Comme un portrait légèrement décalé se lit encore comme un portrait, c'est la défaillance la plus susceptible d'atteindre la production sans être vue. Vérifiez le recadrage de chaque image ayant un sujet plutôt qu'une texture, et vérifiez-le dans la vraie locale au lieu d'imaginer la bascule.

Quelles propriétés CSS utiliser à la place ?

Utilisez les propriétés logiques, qui se résolvent d'après la direction d'écriture et non d'après l'écran. Écrite ainsi, la majeure partie d'une mise en page bascule correctement sans aucun CSS spécifique à la direction, et c'est là le vrai objectif : non pas une seconde feuille de style, mais une feuille unique qui n'a jamais dépendu de la direction. Tenez une liste des propriétés sans équivalent logique, car ce sont exactement celles qui demanderont une surcharge manuelle plus tard. Les transforms, object-position, background-position, les angles de dégradé et tout ce que pilotent des keyframes restent physiques, et c'est pourquoi chaque problème évoqué plus haut appartient à ce groupe plutôt qu'aux marges et aux espacements.

• margin-left devient margin-inline-start, et margin-right devient margin-inline-end.
• padding-left et padding-right deviennent padding-inline-start et padding-inline-end.
• left et right deviennent inset-inline-start et inset-inline-end.
• text-align: left devient text-align: start, et float: right devient float: inline-end.
• Aucun équivalent logique n'existe pour transform, object-position, background-position ou les angles de dégradé. Ceux-là exigent une règle droite-à-gauche explicite.

L'arabe a-t-il besoin d'une autre police ?

Oui, et pas seulement pour la couverture des glyphes. L'arabe est une écriture liée : chaque lettre change de forme selon ce qui l'entoure, si bien qu'une fonte doit porter les formes initiale, médiane, finale et isolée, plus les ligatures entre elles. Une famille latine qui inclut par hasard quelques glyphes arabes les rendra le plus souvent déliés, à la mauvaise graisse optique, ou les deux. Associez une vraie famille arabe à votre famille latine et déclarez les deux dans la même pile. Deux conséquences découlent de l'écriture elle-même. L'arabe ne connaît pas la césure en milieu de mot, puisque les lettres d'un mot sont liées : une colonne étroite qui coupe l'anglais débordera. Et les chaînes traduites égalent rarement la longueur de leur source, ce qui veut dire que chaque bouton et chaque champ mérite un test dans les deux langues.

Comment tester réellement un build droite-à-gauche ?

Lisez-le dans la vraie locale, sur un vrai appareil, avec quelqu'un qui lit la langue. Tout ce qui reste en deçà est une vérification partielle. Une comparaison de captures ne détectera pas un logo inversé, car un logo inversé reste un objet en forme de logo dans un espace en forme de logo. Une suite de régression visuelle ne détectera pas un nombre rendu +100, car ce sont trois glyphes corrects dans un ordre plausible. L'outillage automatisé gagne sa place sur la moitié mécanique du travail : repérer dans la feuille de style les propriétés physiques écrites en dur avant qu'elles ne partent en production. Les défaillances qui survivent jusqu'à la production sont sémantiques, et une personne qui lit l'arabe les trouve en une minute. Inscrivez cette relecture au budget du build plutôt que de la demander en faveur après coup.