Falsch - Pfeilrichtung in RTL-Textkontexten

Merkmal
1

Dies hat nichts mit Bidi-Einstellungen in Discourse zu tun.

Wenn ich - > eingebe, wird es in ein Pfeilsymbol → umgewandelt, sodass A - > B als “A - > B” gerendert wird. Ziemlich cool.

Der Pfeil geht jedoch in RTL-Text in die falsche Richtung: א - > ב wird gerendert als: “א - > ב”, wobei der Pfeil in die falsche Richtung zeigt. (Wenn Sie dies in der Zukunft lesen, nachdem dieser Fehler behoben wurde, wurde dies als “א → ב” gerendert)

Beachten Sie, dass die Eingabezeichenfolge hier lautet:

Zeichen Name
א HEBRÄISCHER BUCHSTABE ALEF
LEERZEICHEN
- HYPHEN-MINUS
> GRÖSSER-ALS-ZEICHEN
LEERZEICHEN
ב HEBRÄISCHER BUCHSTABE BET

was Sie durch Kopieren der Zeichenfolge א - > ב in dieses Tool überprüfen können: https://unicodedecode.com/

Dies liegt daran, dass Pfeilsymbole in Unicode nicht Bidi-gespiegelt werden. Relevantes Dokument: https://www.unicode.org/L2/L2022/22026r-non-bidi-mirroring.pdf

Insbesondere haben Pfeil- und pfeilähnliche Zeichen oft ein Spiegelzeichen. Man könnte argumentieren, dass sie den Eigenschaftswert Bidi_Mirrored=Yes haben sollten, aber das tun sie nicht und können ihn jetzt auch nicht mehr erhalten.

Es gibt leider kein Bidi-umkehrendes Pfeilsymbol, was bedeutet, dass Sie, wenn Sie diese Ersetzung korrekt vornehmen möchten, die Bidi-Richtung des umgebenden Textes bestimmen müssen, um korrekt zwischen ← und → Pfeilen wählen zu können. Keine leichte Aufgabe.

1 „Gefällt mir“
2

@falco Ich würde argumentieren, dass dies tatsächlich ein Fehler und keine Funktionsanfrage ist. Die Ausgabe ist das genaue Gegenteil der Absichten und Erwartungen des Benutzers.

3

Gegeben, dass

Das bedeutet, wir müssten eine neue Funktion entwickeln, da wir derzeit der Unicode-Spezifikation folgen, weshalb ich es als Feature request neu kategorisiert habe.

Um Ihr Problem tatsächlich anzugehen, denke ich, dass dies leicht in einer Theme component mit unserer bestehenden api.decorateCooked API erledigt werden könnte.

2 „Gefällt mir“
4

Danke. Ich habe es nicht eilig, es in irgendeinem bestimmten Forum reparieren zu lassen, ich denke nur, dass dies in Discourse behoben werden sollte.

Ich möchte keine sinnlose semantische Debatte führen, daher belasse ich es dabei. Ich habe gesagt, was ich zu sagen hatte, ich denke, dies sollte als Fehler betrachtet werden, aber was Sie damit machen, liegt jetzt bei Ihnen.

Danke für Ihre Aufmerksamkeit und schnelle Antwort :slight_smile:

1 „Gefällt mir“
5

Nun… Ein Mann kann nur so viel widerstehen. Ich werde noch eines sagen (ich verspreche es). Soweit ich weiß, ermutigt die Unicode-Spezifikation nicht dazu, -\u003e in → umzuwandeln (und dieses Problem wäre einer der Gründe dafür), daher folgt diese bestehende Discourse-Funktion keiner Unicode-Spezifikation. Sie trifft eine falsche Annahme über Text und führt dabei diesen Fehler ein. So sehe ich das. (Die Funktion ist aber trotzdem nett)

Jetzt habe ich gesagt, was ich zu sagen hatte!

3 „Gefällt mir“
6

Wenn ich in einer von rechts nach links geschriebenen Sprache tippe, könnte ich hoffen, ‘Bindestrich’ gefolgt von ‘Kleiner als’ zu tippen und erwarten, dass es sich in einen Pfeil nach links umwandelt, wie hier: ←. Das scheint mir eine vernünftige Erwartung zu sein. Aber wenn ich ein Kleiner-als-Zeichen tippe, fügt der Composer ein Größer-als-Zeichen ein. Das war ziemlich unerwartet. Ist das der Fehler??

Ich stelle fest, dass eine RTL-Textbox (wie die Suchbox auf aljazeera.net) Zahlen und mathematische Symbole in LTR-Reihenfolge innerhalb des RTL-Textes einfügt. Das scheint natürlich genug zu sein. (Es tut dasselbe für lateinische Alphabetika)

Unten tippe ich „Kleiner als ist < und Größer als ist >“ in einem RTL-Kontext (ich weiß nicht, ob dies so funktionieren würde, wie es in einem RTL-Gebietsschema funktionieren würde):

‮Kleiner als ist < und Größer als ist >

3 „Gefällt mir“
7

Sie verwenden im Alltag keine von rechts nach links geschriebene Sprache, oder? An dem, was Sie beschrieben haben, gibt es keinen Fehler. Es gibt eine gewisse Mehrdeutigkeit in dem, was Sie gesagt haben, daher werde ich, um Verwirrung zu vermeiden, zuerst auf den zweiten Teil Ihres Kommentars eingehen.

Das ist genau so, wie es sein soll. Denken Sie darüber so nach:

Das Zeichen > bedeutet wörtlich „größer als“. Der String „A > B“ bedeutet „A ist größer als B“.

Ähnlich würde ich, um zu sagen „א ist größer als ב“, „ist größer als“ durch dasselbe Größer-als-Zeichen mit demselben Code U+003E ersetzen. Da der String jedoch vollständig von rechts nach links geschrieben wird, erscheint „א“ rechts von „ב“. Wenn das „Größer-als“-Zeichen wie in LTR gerendert würde, würde es angezeigt: א<ב, was „א ist kleiner als ב“ oder „ב ist größer als א“ bedeutet – die exakt entgegengesetzte Beziehung zu der beschriebenen.

Deshalb wird beim Rendern des Größer-als-Zeichens dieses visuell gespiegelt, wenn es in RTL steht. Aber das zugrunde liegende Zeichen und die dahinter stehenden Unicode-Daten sind immer noch das „Größer-als“-Symbol. Der String bedeutet immer noch „א ist größer als ב“.

Nun zurück zu Ihrer ersten Frage:

Wenn Sie Ihr Tastaturlayout auf eine von rechts nach links geschriebene Sprache (wie Hebräisch oder Arabisch) umstellen, würde die Tastenkombination Umschalt + , (die Taste mit dem aufgedruckten <) tatsächlich das „Größer-als“-Zeichen > eingeben. Dies würde in einem RTL-Kontext wie in der von Ihnen gefundenen Suchleiste als ;> angezeigt werden.

[Bearbeiten: Der nächste Absatz wurde geschrieben, als ich leicht missverstanden habe, was Sie sagten, Sie hätten getestet. Ich dachte, Sie würden in eine RTL-Box mit einer LTR-Tastatur eingeben, während Sie tatsächlich das Gegenteil taten. Hoffentlich habe ich Ihre Verwirrung trotzdem erklärt.]

Aber Sie verwenden immer noch ein lateinisches Tastaturlayout. Wenn Sie also diese Tastenkombination drücken, wird ein „Kleiner-als“-Zeichen < eingefügt. Aber es wird als ;< angezeigt, weil es in RTL bedeutet, dass das, was rechts steht, kleiner ist als das, was links steht.

Fazit: Das Zeichen ist dasselbe, aber seine Darstellung wird gespiegelt.

Wenn Sie verstanden haben, was ich bisher gesagt habe, werden Sie verstehen, dass dies -< oder in RTL ;-< ergeben würde, was ich nicht erwarte, dass es das ist, was Sie meinten.

Habe ich es erfolgreich erklärt oder habe ich Sie nur noch mehr verwirrt?

1 „Gefällt mir“
8

Wenn Sie der Meinung sind, dass Sie mit offiziellen Unicode-Dokumenten besser zurechtkommen, probieren Sie dieses aus: UAX #9: Unicode Bidirectional Algorithm Drücken Sie Strg+F für „mirror“ und Sie finden einige gute Beschreibungen und Beispiele.

1 „Gefällt mir“
9

Sie haben völlig Recht, ich springe ohne Erfahrung ein, und das auch noch mit einer lateinischen Tastatur!

Also sollte ich schweigen… aber ich sehe, dass, wenn ich (auf meiner lateinischen Tastatur) 3<6 in das Aljazeera-Suchfeld eingebe, ich Folgendes sehe:

image
image200×126 1.98 KB

Was wahrscheinlich zeigt, dass Sie Recht haben und ich falsch liege, und das sollte keine Überraschung sein!

2 „Gefällt mir“
10

Ganz und gar nicht! Wenn nur RTL-Benutzer über RTL-Fehler diskutieren und diese beheben dürften, wären wir viel schlechter dran! Ich habe diese Gelegenheit nur genutzt, um Sie in das Thema einzuführen. Es soll einige Zeit dauern, bis Sie sich damit auseinandergesetzt haben. Ich beantworte gerne weitere Fragen oder Neugierde, die Sie dazu haben.

1 „Gefällt mir“
11

Ich bin der Unicode-Mailingliste beigetreten, um eine Ergänzung zu Unicode vorzuschlagen, die in Fällen wie diesem eine Lösung wäre. Eine der Antworten, die ich erhielt, war diese:

(Ich:) Das Problem ist, dass diese Ersetzung (soweit ich weiß) außerhalb jedes Rendering-Kontexts erfolgt, wenn der Text nur eine Zeichencode-Sequenz ist. Es ist nicht sinnvoll zu wissen, in welche Richtung der Text geht. Manchmal ist es völlig unmöglich, wenn die Textrichtung vom Kontext abhängt, der zum Zeitpunkt der Ersetzung nicht verfügbar ist.

Das oben Gesagte ist streng genommen ungenau. Jedes ernsthafte Text-Rendering heutzutage erfordert eine Shaping-Engine wie HarfBuzz, und die Ligatur von „->“ in „→“ würde von einem solchen Shaper in Zusammenarbeit mit einer Schriftart, die Ligaturen unterstützt, durchgeführt werden. Die Shaping-Engine ist sich des bidi-Kontexts und des Skripts des von ihr geformten Textes bewusst und könnte daher im Prinzip den Pfeil spiegeln.

Sie sprechen von etwas wie diesem: GitHub - tonsky/FiraCode: Free monospaced font with programming ligatures

Erwägen Sie den Wechsel zum Ligaturenansatz anstelle einer blinden Zeichenersetzung. Ein weiterer vorteilhafter Vorteil wäre, dass beim Kopieren und Einfügen der Text immer noch „->“ anstelle eines Pfeils wäre.

Ich habe mich nicht mit den technischen Details der Implementierung befasst, das überlasse ich Ihnen, wenn Sie sich für diese Lösung entscheiden.

Bearbeiten: Nun, wenig überraschend, Fira Text ist insbesondere nicht für RTL konzipiert, daher ist das Rendering nicht optimal – aber zumindest zeigt es in die richtige Richtung! https://fonts.google.com/specimen/Fira+Code?preview.text=A%20->%20B,%20א%20->%20ב
Firefox:

image
image473×164 5.61 KB

Ich bin mir nicht sicher, ob es heute eine Schriftart gibt, die dies korrekt tut und explizit RTL/bidi unterstützt.

1 „Gefällt mir“
12

Interessanterweise erhalte ich in Chromium ein anderes Ergebnis:
~~Bearbeitung: Ich kann dies jetzt nicht reproduzieren und glaube, dass ich es falsch eingegeben habe, als ich diesen Screenshot gemacht habe.~
Bearbeitung: Und jetzt kann ich es wieder reproduzieren. Die Situation ist schlecht.

image
image524×165 5.86 KB

Es ist möglich, dass Browser-Rendering-Engines/Shaper dieser Aufgabe nicht gewachsen sind. Ich muss mehr untersuchen, und das ist nicht das, worauf ich mich gerade konzentrieren sollte…

Bearbeitung: Forenbeschränkungen zwangen mich, dies aus meiner vorherigen Antwort zu entfernen:
Als Referenz ist hier der Code, der für diese Ersetzung verantwortlich ist:

1 „Gefällt mir“
14

Wie ich bereits erwähnte, arbeite ich an einem Unicode-Vorschlag für dieses Problem. Dort erkläre ich das Problem gründlich und hoffentlich klarer als hier. Es ist noch in Arbeit, aber schaut es euch bitte an: Making sure you're not a bot! (Permalink)

Schaut euch insbesondere den Discourse-Abschnitt an.

Selbst wenn Unicode diesen Vorschlag annimmt (wenn ich ihn schließlich einreiche), wird es natürlich Jahre dauern, bis er breit genug implementiert ist, um zuverlässig zu sein, daher ist es kein guter Plan, darauf zu warten.