- Allein mit dem HTML-Attribut
dir="auto"lassen sich in Eingabefeldern und Textbereichen RTL-Sprachen (rechts nach links) wie Hebräisch, Arabisch oder Urdu automatisch unterstützen - Bisher waren vor allem manuelle und komplexe Ansätze bekannt, etwa Listener zur Zeichenerkennung zu schreiben, Drittanbieter-Bibliotheken zu verwenden oder manuell auf
dir="right"umzuschalten - In den Suchergebnissen zu „textarea rtl“ wurde
dir="auto"nirgends erwähnt, wodurch das Problem fälschlicherweise als eines galt, das direktes Eingreifen erfordert - In der Praxis funktionierte es sofort korrekt, ohne separates Low-Level-Parsing von Sprache
- Eine kleine, aber große Änderung und ein zentrales Element der Internationalisierung (i18n), das darüber entscheiden kann, ob Nutzer weltweit eine App verwenden können
Die Schwierigkeit von RTL-Unterstützung
- Seit den Anfängen von Standard Notes gab es Anfragen zur Unterstützung von RTL-Sprachen wie Hebräisch, Arabisch und Urdu, doch die Umsetzung wurde aufgeschoben, weil sie schwierig wirkte
- Bei jeder Prüfung sah es nach Sprach-Parsing aus, bei dem Encodings wie Unicode und ASCII auf niedriger Ebene behandelt werden müssten, weshalb das Thema vermieden wurde
- Alle paar Monate kam dasselbe Thema wieder auf, aber jedes Mal gab es nur die gleichen Ratschläge
- Einen eigenen Zeichen-Parser schreiben
- Eine Drittanbieter-Bibliothek verwenden
dir="right"anwenden
Grenzen der Suche
- Selbst bei Suchen nach „textarea rtl“ oder „textarea right to left“ tauchte
dir="auto"in den Ergebnissen überhaupt nicht auf - Stattdessen erschienen Stack-Overflow-Antworten, die
dir="rtl"im Tag empfahlen, oder Drittanbieter-Bibliotheken von Twitter - Weil man sich auf die erste Suchergebnisseite verließ und das Problem als eines einstufte, das direktes Eingreifen erfordert, rutschte es in der Priorität immer weiter nach hinten
Entdeckung der Lösung
- Vor einigen Wochen wurde bei einer erneuten Suche in einem GitHub-Beitrag ein Kommentar gefunden: „Man muss dem textarea nur
dir="auto"hinzufügen“ - Ein Problem, für das ein Jahr lang nach einer Lösung gesucht wurde, war mit einer einzigen Zeile gelöst
- Beim eigenen Test funktionierte es fehlerfrei und perfekt
Anwendung
- Eingabefeldern und Textbereichen nur eine Attributzeile hinzufügen
<textarea dir='auto'> שלום, עתיד. </textarea>
- Die Textrichtung wird je nach Eingabewert automatisch erkannt
- Zur Referenz bietet die MDN-Dokumentation zum Attribut
direntsprechende Erklärungen
1 Kommentare
Hacker-News-Kommentare
Das ist zwar eine einfache Möglichkeit, das Textrendering in Eingabefeldern und
textareazu verbessern, aber dieselbe Behandlung ist auch für Elemente nötig, die den abgesendeten Text anzeigen.Und sobald man auf bidirektionalen Text stößt, etwa englische Produktnamen in einem arabischen Absatz, öffnet sich eine völlig andere Komplexität.
In Chrome gibt es derzeit einen Regressionsfehler, der das Rendern von RTL-Text in Eingabefeldern mit
dir='auto'beeinflusst; ein Fix wurde bereits ausgerollt und soll in der nächsten Version enthalten sein.MDN rettet einen immer: https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
Die Welt existiert auch außerhalb der USA, aber je nach Art der Website muss man das nicht zwingend unterstützen.
Ich bin weder Amerikaner noch englischer Muttersprachler, aber bei 99 % der Websites, die ich nutze, ist es überhaupt kein Problem, wenn sie keine RTL-Zeichen in Benutzernamen oder Beiträgen erlauben.
Wenn das nicht schon auf Browser- oder Betriebssystemebene gelöst wurde, sehe ich kaum eine Verpflichtung, das selbst unterstützen zu müssen.
Und nein, damit will ich nicht sagen, dass Minderheiten unterdrückt werden sollen.
Bei einer schnellen Suche findet man etwa 840 Millionen Englischsprachige; wenn man allein baut, wirkt es schon ziemlich okay, wenn man auch nur ein Zehntel der Welt erreichen kann.
Den Umfang zu erweitern, um mehr Menschen zu unterstützen, ist gut, aber keine Pflicht.
„Die erste Ergebnisseite von Google lügt nie“ — da steckt schon etwas drin, das bei der Problemlösung helfen könnte, aber man sollte sich besser vorher hinsetzen. Es könnte traurig werden.
„Die erste Ergebnisseite von Google lügt nie …“ war mit ziemlicher Sicherheit Satire, wenn man den späteren Satz „Google hat uns über die RTL-Unterstützung in Eingabefeldern belogen“ dazunimmt.
Leider ist sowohl die Website als auch das verknüpfte CodePen beim Rendern des Quelltexts ziemlich kaputt. Der Punkt steht an der falschen Stelle, während das gerenderte HTML okay ist.
Das scheint ein Scheitern des Unicode-Bidirektionalitätsalgorithmus zu sein, wie so oft.
Es bräuchte wohl einen speziellen Algorithmus, der den gesamten HTML-Tag, also alles zwischen
<und>, intern als atomare LTR-Einheit rendert, ohne dabei die Richtungswirkung auf umgebende Zeichen zu beeinflussen.In diesem Beispiel müsste der Algorithmus in der Lage sein, mitten in der Sequenz
.<die Richtung zu wechseln.Die Grundrichtung des Quelltextfragments ist LTR, aber wegen des hebräischen Texts sind die Richtungen gemischt.
Satzzeichen haben eine schwache Richtung, daher erscheint der Punkt am Ende des RTL-Abschnitts, und da die Grundrichtung LTR ist, bedeutet dieses „Ende“ rechts.
Um gemischt gerichtete Inhalte korrekt rendern zu erzwingen, muss man oft bidirektionale Steuerzeichen einfügen, die festlegen, wo bestimmte Richtungssegmente beginnen und enden.
In diesem Fall wäre das jedoch falsch, weil es das Rendering des eigentlichen Eingabebeispiels kaputtmachen könnte.
In dem Zusammenhang ist in den letzten Jahren auch die Unterstützung für logische Eigenschaften/Werte ausgereift.
Das sind Alternativen zu richtungsbasierten Eigenschaften wie
top/left/bottom/right, die sich an Änderungen der Inhalts- oder Textrichtung anpassen können.https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_logical...
leadingundtrailingunter iOS.Schön, dass das jetzt auch ins Web kommt; dadurch wird es deutlich realistischer, sprachunabhängige UIs zu bauen.
Wenn man nach
textareaund BiDi-Text in fast jeder Kombination sucht, die mir einfällt, ist https://www.w3.org/International/talks/1602-oman einer der oberen Treffer.Der Abschnitt „What if you don't know the direction in advance“ ist auch direkt darin: https://www.w3.org/International/talks/1602-oman/#advance
Das Problem ist, dass der Autor sich in diesem Bereich offenbar nicht gut auskannte und deshalb vermutlich nicht wusste, dass BiDi hier der richtige Suchbegriff ist. Das ist die Abkürzung für „bi-directional text“ und wird verwendet, wenn man keine bestimmte Schreibrichtung festlegen möchte.
Ich will ihm auch keinen Vorwurf daraus machen, dass er dachte, „die Suchergebnisse seien falsch“. Wenn man nach RTL sucht, sind diese Ergebnisse zwar korrekt, aber das kann man erst wissen, wenn man sich in dem Gebiet etwas besser auskennt.
Das zeigt die Grenzen der Abhängigkeit von Internetantworten. Das Internet weiß nicht, was ich nicht weiß.
Wenn man jemanden fragt, der schon lange mit BiDi arbeitet, ist eine der ersten Fragen wahrscheinlich: „Meinen Sie RTL oder BiDi?“
Wenn möglich, ist es besser, einen Menschen als Software zu fragen — besonders dann, wenn man sich in dem Gebiet nicht gut auskennt.
In diesem Zusammenhang wäre auch ein Link zum interessanten Attribut
dirnamesinnvoll, mit dem beim Absenden eines Formulars die Richtung einer Texteingabe mit übermittelt werden kann: https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes...Wenn ich Browser bauen würde, würde ich als Hinweis im öffentlichen Interesse geben: Wenn nichts anderes angegeben ist, sollte
dir="auto"angenommen werden.Wenn man weiß, dass der Benutzer in einer bestimmten Sprache eingibt, ist selbst das vielleicht nicht die beste Voreinstellung. Natürlich ist es immer noch besser, als die Richtung falsch festzulegen.
Etwas verwandt damit: Ich habe kürzlich gelernt, dass es in Vim
:set rlgibt, um Text von rechts nach links laufen zu lassen.Um zum Normalzustand zurückzukehren, verwendet man
:set norl.vim -A, das im arabischen Modus startet. Ich weiß nicht, wie man das benutzt; vermutlich verwendet es irgendeine Eingabemethode.:set td?