Ajoutez `dir="auto"` à vos champs de saisie et zones de texte

• Le simple attribut HTML dir="auto" permet de prendre automatiquement en charge dans les champs de saisie et les zones de texte les langues RTL (de droite à gauche) comme l’hébreu, l’arabe ou l’ourdou
• Jusqu’ici, on ne connaissait que des approches manuelles et complexes : écrire un écouteur de détection de caractères, utiliser une bibliothèque tierce ou basculer manuellement avec dir="right"
• Aucune occurrence de dir="auto" n’apparaît dans les résultats de recherche pour « textarea rtl », ce qui a entretenu l’idée qu’il s’agissait d’un problème nécessitant une intervention directe
• En pratique, une fois appliqué, cela fonctionne immédiatement correctement sans analyse bas niveau de la langue
• Petit changement en apparence, mais élément clé de l’internationalisation (i18n) qui détermine si des utilisateurs du monde entier peuvent réellement utiliser une application

---

La difficulté du support RTL

• Depuis les débuts de Standard Notes, des demandes de prise en charge des langues RTL comme l’hébreu, l’arabe et l’ourdou revenaient, mais l’implémentation paraissait difficile et a donc été repoussée
• À chaque examen, cela semblait impliquer un travail d’analyse linguistique bas niveau autour d’encodages comme Unicode ou ASCII, ce qui conduisait à l’éviter
• Le sujet revenait tous les quelques mois, mais les mêmes conseils revenaient systématiquement
  • écrire soi-même un parseur de caractères
  • utiliser une bibliothèque tierce
  • appliquer dir="right"

Les limites de la recherche

• Même en cherchant « textarea rtl » ou « textarea right to left », dir="auto" n’apparaît jamais dans les résultats
• À la place, on tombe sur des réponses Stack Overflow recommandant d’utiliser dir="rtl" sur la balise, ou sur la bibliothèque tierce de Twitter
• En se fiant uniquement à la première page de résultats, le problème a été considéré à tort comme nécessitant une intervention directe, et a donc continué à être relégué dans les priorités

Découverte de la solution

• En relançant les recherches il y a quelques semaines, un commentaire sur GitHub a révélé qu’il suffisait d’ajouter dir="auto" à un textarea
• Un problème dont la solution était recherchée depuis un an a été réglé avec une seule ligne
• Après test, cela fonctionne parfaitement sans défaut

Comment l’appliquer

• Il suffit d’ajouter une seule ligne d’attribut aux champs de saisie et zones de texte
  • <textarea dir='auto'> שלום, עתיד. </textarea>
• La direction du texte est déterminée automatiquement selon la saisie
• À noter : la documentation MDN sur l’attribut dir fournit des explications à ce sujet

[GN⁺]

Commentaires sur Hacker News

• C’est bien un moyen simple de corriger le rendu du texte dans les champs de saisie et les textarea, mais il faut appliquer le même traitement aux éléments qui affichent le texte soumis.
  Et dès qu’on rencontre du texte bidirectionnel, par exemple un nom de produit en anglais dans un paragraphe en arabe, on ouvre un tout autre niveau de complexité.
  Chrome a actuellement une régression qui affecte le rendu du texte RTL dans les champs de saisie avec dir='auto', mais le correctif a déjà été déployé et devrait être inclus dans la prochaine version.

  • Issue Chromium associée : https://bugs.chromium.org/p/chromium/issues/detail?id=147072...

• MDN nous sauve toujours : https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...

• Le monde existe aussi en dehors des États-Unis, mais selon la nature du site, il n’est pas forcément nécessaire de le prendre en charge.
  Je ne suis ni américain ni anglophone natif, mais 99 % des sites que je fréquente n’auraient aucun problème à ne pas autoriser les caractères RTL dans les noms d’utilisateur ou les posts.
  Si ce n’est pas résolu au niveau du navigateur ou du système d’exploitation, je considère que je n’ai guère l’obligation de le prendre en charge.
  Et ce n’est pas un appel à opprimer les minorités.

  • J’y repense chaque fois que je réfléchis à la prise en charge d’autres langues dans mes projets personnels.
    Une recherche rapide donne environ 840 millions d’anglophones ; quand on développe seul, pouvoir servir seulement 1/10 du monde paraît déjà plutôt correct.
    Élargir le périmètre pour aider davantage de gens, c’est bien, mais ce n’est pas une obligation.
  • Si la prise en charge d’un cas d’usage de niche est simple et demande peu de maintenance, autant l’ajouter pour le plaisir.

• « La première page de résultats Google ne ment jamais » : il y a quelque chose à dire qui pourrait aider à résoudre le problème, mais vous feriez mieux de vous asseoir d’abord. Vous risquez d’être triste.

  • On dirait que cette phrase a été prise au pied de la lettre.
    L’expression « La première page de résultats Google ne ment jamais… » était presque certainement sarcastique, vu la phrase qui suit : « Google nous a menti sur la prise en charge du RTL dans les champs de saisie ».

• Malheureusement, le site web comme le CodePen lié rendent assez mal le code source. La position du point est incorrecte, alors que le HTML rendu est correct.
  On dirait que c’est l’algorithme bidirectionnel Unicode qui échoue, comme souvent.
  Il faudrait sans doute un algorithme spécial qui rende une balise HTML — c’est-à-dire tout ce qui se trouve entre < et > — comme une unité atomique intrinsèquement LTR, sans influencer la direction des caractères autour.
  Dans cet exemple, l’algorithme devrait pouvoir changer de direction au milieu de la séquence .<.

  • Ici, l’algorithme bidirectionnel Unicode n’échoue pas : il fonctionne comme prévu.
    La direction de base du fragment de code source est LTR, mais elle se mélange à cause du texte hébreu.
    La ponctuation a une directionnalité faible, donc le point apparaît à la fin du segment RTL ; et comme la direction de base est LTR, cette « fin » signifie la droite.
    Pour forcer un rendu correct de contenu à directions mixtes, il faut souvent insérer des caractères de contrôle bidirectionnels indiquant où commence et où se termine chaque segment directionnel.
    Mais dans ce cas, cela pourrait casser le rendu de l’exemple de saisie réel, donc ce ne serait pas approprié.

• Dans le même registre, la prise en charge des propriétés/valeurs logiques a mûri ces dernières années.
  Elles remplacent les propriétés dépendantes de la direction comme top/left/bottom/right et peuvent s’adapter aux changements de direction du contenu ou du texte.
  https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_logical...

  • Ce genre de concept est standard depuis longtemps sur les plateformes mobiles. Par exemple leading et trailing sur iOS.
    C’est agréable de le voir arriver sur le Web, et cela rend la création d’UI indépendantes de la langue beaucoup plus réaliste.

• Si je cherche textarea et du texte BiDi dans presque toutes les combinaisons auxquelles je peux penser, https://www.w3.org/International/talks/1602-oman apparaît parmi les premiers liens.
  C’est aussi directement dans la section « What if you don't know the direction in advance » : https://www.w3.org/International/talks/1602-oman/#advance
  Le problème, c’est que l’auteur ne connaissait pas bien ce domaine et ne savait apparemment même pas que le bon terme de recherche était BiDi. C’est l’abréviation de « bi-directional text », utilisée quand on ne veut pas spécifier une direction d’écriture particulière.
  Je ne lui reprocherais pas non plus d’avoir pensé que « les résultats de recherche étaient faux ». Si l’on cherche RTL, ces résultats donnent bien la bonne réponse, mais on ne peut pas le savoir avant d’en apprendre un peu plus sur le sujet.
  Cela montre les limites de la dépendance aux réponses trouvées sur Internet. Internet ne sait pas ce que je ne sais pas.
  Si vous demandez à quelqu’un qui travaille depuis longtemps avec BiDi, l’une de ses premières questions sera probablement : « Vous parlez de RTL ou de BiDi ? »
  Quand c’est possible, mieux vaut demander à des personnes plutôt qu’à du logiciel. Surtout quand on ne connaît pas bien le domaine.

  • Plutôt que de traiter « ce domaine » comme un pré carré avec du jargon d’initiés et de rabaisser l’auteur, on peut aussi voir positivement le fait qu’il ait rendu ce problème plus visible.

• Il vaudrait aussi la peine d’ajouter un lien vers dirname, un attribut intéressant qui permet d’inclure la directionnalité d’une saisie texte lors de la soumission d’un formulaire : https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes...

• Si vous concevez un navigateur, petit message d’intérêt général : en l’absence d’indication explicite, considérez que c’est dir="auto".

  • Les contrôles de formulaire recevant une saisie utilisateur sont une sorte de document séparé, donc cette valeur par défaut peut y être plus raisonnable, mais ce serait une très mauvaise valeur par défaut pour tous les éléments.
    Si vous savez que l’utilisateur saisit dans une langue donnée, ce n’est peut-être pas non plus le meilleur défaut. Cela dit, c’est mieux que de le spécifier incorrectement.

• Dans un registre un peu lié, j’ai récemment découvert que Vim a :set rl, qui fait aller le texte de droite à gauche.
  Pour revenir à la normale, on peut utiliser :set norl.

  • Waouh, c’est assez sympa, et c’est étonnamment amusant d’essayer de taper comme ça en anglais aussi. J’y ai passé plus de temps que prévu.
  • Les vieux Vim ont aussi vim -A, qui démarre en mode arabe. Je ne sais pas comment ça s’utilise ; j’imagine que ça utilise une sorte de méthode de saisie.
  • Et :set td ?