Faux - → direction de la flèche dans les contextes de texte RTL

Fonctionnalité
1

Cela n’a rien à voir avec les paramètres bidi dans Discourse.

Lorsque je tape -\u003e, cela est converti en un caractère flèche →, donc A -\u003e B s’affiche comme « A -\u003e B ». Plutôt cool.

Cependant, la flèche va dans le mauvais sens dans le texte RTL : א -\u003e ב s’affiche comme : « א -\u003e ב » avec la flèche allant dans le mauvais sens. (Si vous lisez ceci dans le futur après que ce bug ait été corrigé, cela s’affichait comme « א → ב »)

Notez que la séquence de caractères d’entrée ici est :

Caractère Nom
א LETTRE HÉBRAÏQUE ALEPH
ESPACE
- SIGNE MOINS-SUPÉRIEUR
\u003e SIGNE PLUS GRAND QUE
ESPACE
ב LETTRE HÉBRAÏQUE BET

ce que vous pouvez vérifier en copiant la chaîne א -\u003e ב dans cet outil : https://unicodedecode.com/

C’est parce que les caractères fléchés ne se reflètent pas en bidi dans Unicode. Document pertinent : https://www.unicode.org/L2/L2022/22026r-non-bidi-mirroring.pdf

En particulier, les caractères fléchés et similaires aux flèches ont souvent chacun un caractère miroir. On pourrait soutenir qu’ils auraient dû avoir la valeur de propriété Bidi_Mirrored=Yes, mais ce n’est pas le cas, et ils ne peuvent plus l’obtenir.

Il n’existe malheureusement pas de caractère flèche qui inverse le sens bidi, ce qui signifie que si vous souhaitez effectuer cette substitution correctement, vous devez déterminer la direction bidi du texte environnant pour choisir correctement entre les flèches \u003c- et -\u003e. Ce n’est pas une tâche facile.

1 « J'aime »
2

@falco Je soutiendrais que c’est bien un bug, pas une demande de fonctionnalité. La sortie est l’exact opposé des intentions et des attentes de l’utilisateur.

3

Étant donné que

Cela signifie que nous devrions créer une nouvelle fonctionnalité, car nous suivons actuellement la spécification Unicode, c’est pourquoi je l’ai recatégorisé comme une demande de #fonctionnalité.

Passons maintenant à la résolution de votre problème. Je pense que cela pourrait être facilement fait dans un #composant-thème, en utilisant notre API existante api.decorateCooked.

2 « J'aime »
4

Merci. Je ne suis pas pressé de le faire réparer dans un forum particulier, je pense juste que cela devrait être corrigé dans Discourse.

Je ne veux pas entrer dans une dispute sémantique inutile, donc je m’arrêterai là. J’ai dit ce que j’avais à dire, je pense que cela devrait être considéré comme un bug, mais ce que vous en faites dépend maintenant de vous.

Merci de votre attention et de votre réponse rapide :slight_smile:

1 « J'aime »
5

Eh bien… Un homme ne peut résister que jusqu’à un certain point. Je dirai une dernière chose (je le promets). Pour autant que je sache, la spécification Unicode n’encourage pas la conversion de -\u003e en → (et ce problème en serait une des raisons), donc cette fonctionnalité existante de Discourse ne suit aucune spécification Unicode. Elle fait une fausse hypothèse sur le texte et introduit ce bug dans le processus. C’est ainsi que je le vois. (La fonctionnalité est toujours sympa cependant)

Maintenant, j’ai dit ce que j’avais à dire !

3 « J'aime »
6

Si je tape dans une langue de droite à gauche, je pourrais espérer taper « tiret » suivi de « inférieur à » et m’attendre à ce que cela se convertisse en une flèche vers la gauche, comme ceci : ← . Cela me semble une attente raisonnable. Mais, lorsque je tape un inférieur à, le compositeur insère un supérieur à. C’était assez inattendu. Est-ce cela le bug ?

Je remarque qu’une zone de texte RTL (comme la zone de recherche sur aljazeera.net) insère des chiffres et des symboles mathématiques dans l’ordre LTR dans le texte RTL. Cela semble assez naturel. (Il en va de même pour les lettres latines)

Ci-dessous, je vais taper « inférieur à est < et supérieur à est > » dans un contexte RTL (je ne sais pas si c’est ainsi que les choses fonctionneraient dans une locale RTL) :

‮inférieur à est < et supérieur à est >

3 « J'aime »
7

Vous n’utilisez pas un script de droite à gauche dans la vie de tous les jours, n’est-ce pas ? Il n’y a pas de bug dans ce que vous avez décrit. Il y a une certaine ambiguïté dans ce que vous avez dit, donc pour éviter toute confusion, je vais d’abord aborder la deuxième partie de votre commentaire.

C’est exactement comme cela que cela est censé fonctionner. Pensez-y de cette façon :

Le caractère > signifie littéralement « supérieur à ». La chaîne « A > B » signifie « A est supérieur à B ».

De même, pour dire « א est supérieur à ב », je remplacerais « est supérieur à » par le même caractère supérieur à avec le même code U+003E. Cependant, comme la chaîne est entièrement RTL, « א » apparaît à droite de « ב ». Si le caractère « supérieur à » était rendu de la même manière qu’en LTR, il s’afficherait : א<ב, ce qui se lit « א est inférieur à ב » ou « ב est supérieur à א » – la relation exactement opposée à celle décrite.

C’est pourquoi lors du rendu du caractère supérieur à, il est visuellement inversé lorsqu’il est en RTL. Mais le caractère sous-jacent, et les données Unicode qui le soutiennent, sont toujours le symbole « supérieur à ». La chaîne signifie toujours « א est supérieur à ב ».

Revenons maintenant à votre première question :

Si vous changez la disposition de votre clavier pour une langue RTL (comme l’hébreu ou l’arabe), alors la combinaison de touches Maj + , (la touche avec < imprimé dessus) taperait en fait le caractère « supérieur à » >. Cela serait rendu comme ;>`<; dans un contexte RTL, comme dans la boîte de recherche que vous avez trouvée.

[Edit : le paragraphe suivant a été écrit lorsque j’ai légèrement mal compris ce que vous aviez dit avoir testé. Je pensais que vous tapiez dans une boîte RTL avec un clavier LTR, alors que vous faisiez en fait le contraire. J’espère avoir quand même répondu à votre confusion.]

Mais vous utilisez toujours une disposition de clavier latine, donc lorsque vous appuyez sur cette combinaison de touches, elle insère un caractère « inférieur à » <. Mais il est rendu comme ;`<; car en RTL, il signifie que ce qui est à droite est inférieur à ce qui est à gauche.

En bref : le caractère est le même, mais son rendu est inversé.

Si vous avez compris ce que j’ai dit jusqu’à présent, vous comprendrez que cela donnerait -\u003c ou en RTL ;-\u003c;, ce qui, je ne pense pas, est ce que vous vouliez dire.

Ai-je réussi à l’expliquer ou vous ai-je simplement rendu plus confus ?

1 « J'aime »
8

Si vous pensez que vous feriez mieux avec des documents Unicode officiels, essayez celui-ci : UAX #9: Unicode Bidirectional Algorithm faites Ctrl+F pour « mirror » et vous trouverez de bonnes descriptions et exemples.

1 « J'aime »
9

Vous avez tout à fait raison, je me lance sans expérience, et en plus avec un clavier latin !

Je devrais donc me taire… mais je vois que si je tape (sur mon clavier latin) 3<6 dans la boîte de recherche d’aljazeera, je vois ceci :

image
image200×126 1.98 KB

Ce qui montre probablement que vous avez raison, et que j’ai tort, et cela ne devrait pas surprendre !

2 « J'aime »
10

Pas du tout ! Si seuls les utilisateurs RTL étaient autorisés à discuter et à corriger les bugs RTL, nous serions bien plus mal lotis ! J’ai juste profité de cette occasion pour vous présenter le sujet. Il faut un certain temps pour s’y habituer. Je serai heureux de répondre à toutes vos autres questions ou curiosités à ce sujet.

1 « J'aime »
11

J’ai rejoint la liste de diffusion Unicode pour proposer un ajout à Unicode qui serait une solution dans des cas comme celui-ci. L’une des réponses que j’ai reçues était la suivante :

(Moi :slight_smile: Le problème est que ce remplacement est effectué (pour autant que je sache) en dehors de tout contexte de rendu, lorsque le texte n’est qu’une séquence de codes de caractères. Il n’est pas raisonnable de savoir dans quelle direction va le texte. Parfois, c’est complètement impossible, si la direction du texte dépend d’un contexte qui n’est pas disponible au moment du remplacement.

Ce qui précède est, à strictement parler, inexact. Tout rendu de texte sérieux de nos jours nécessite un moteur de mise en forme, tel que HarfBuzz, et la ligature de « - > » en « → » serait effectuée par un tel moteur en coopération avec une police qui prend en charge les ligatures. Le moteur de mise en forme est conscient du contexte bidi et du script du texte qu’il met en forme, il pourrait donc en principe refléter la flèche.

Ils parlent de quelque chose comme ceci : GitHub - tonsky/FiraCode: Free monospaced font with programming ligatures

Envisagez de passer à l’approche de la ligature au lieu d’un remplacement aveugle de caractères. Un autre avantage discutable serait que, lors d’un copier-coller, le texte serait toujours « - > » au lieu d’une flèche.

Je n’ai pas examiné les détails techniques de la mise en œuvre, je vous laisse cela si vous choisissez d’utiliser cette solution.

Edit : eh bien, sans surprise, Fira Text en particulier n’est pas conçu pour le RTL, donc le rendu est incorrect - mais au moins il pointe dans la bonne direction ! https://fonts.google.com/specimen/Fira+Code?preview.text=A%20->%20B,%20א%20->%20ב
Firefox :

image
image473×164 5.61 KB

Je ne suis pas sûr qu’il existe aujourd’hui une police qui fasse cela correctement et qui prenne explicitement en charge le RTL/bidi.

1 « J'aime »
12

Fait intéressant, j’obtiens un résultat différent dans Chromium :
Mise à jour : Je ne peux plus reproduire cela, donc je pense que j’ai mal tapé lors de la capture d’écran.
Mise à jour : Et maintenant, je peux le reproduire à nouveau. La situation est mauvaise.

image
image524×165 5.86 KB

Il est possible que les moteurs de rendu/façonneurs de navigateur ne soient pas à la hauteur de cette tâche. Je devrai enquêter davantage, et ce n’est pas sur quoi je suis censé me concentrer en ce moment…

Mise à jour : les limites du forum m’ont obligé à supprimer ceci de ma réponse précédente :
Pour référence, voici le code responsable de ce remplacement :

1 « J'aime »
14

Comme je l’ai mentionné, je travaille à proposer une solution Unicode pour ce problème. J’y explique le problème en détail, et j’espère plus clairement que je ne l’ai expliqué ici. C’est encore en cours de développement, mais n’hésitez pas à y jeter un œil : Making sure you're not a bot! (lien permanent)

Plus précisément, consultez la section Discourse.

Bien sûr, même si l’Unicode accepte cette proposition (quand je la soumettrai enfin), il faudra des années pour qu’elle soit suffisamment mise en œuvre pour être fiable, ce n’est donc pas une bonne idée d’attendre cela.