Vorlage Diskussion:Zitat-yi

Schreibrichtung automatisch

Umseitig steht: „… lesbarer darstellen, da die Schreibrichtung (linksläufig) ein- und abgeschaltet wird.“

Bedeutet dies, dass das ‎ nach dem Text entfallen kann? (Hintergrund: Bei Vorlage:He und Vorlage:HeS wird in den Kopiervorlagen ein ‎ angegeben!)

Gruß, --Wi-luc-ky (Diskussion) 16:23, 16. Aug. 2019 (CEST)

Entfällt nicht, und steht nicht aus Langeweile da; Grund: UBA.

H:RTL erklärt mehr.

Das ‎, das im Quelltext steht, kommt jedoch bei unseren Lesern überhaupt nicht an.

VG --PerfektesChaos 16:25, 16. Aug. 2019 (CEST)

Danke, PerfektesChaos.

Wenn der Unicode-Bidi-Algorithmus das ‎ erfordert, wäre eine Streichung wie hier von Androl wieder rückgängig zu machen?

Ich verstehe nicht, warum in der Doku steht, dass die linksläufige Schreibrichtung abgeschaltet wird. Die VL macht das dann wohl nicht automatisch, sondern nur mit eingefügtem ‎?

Sollte die Doku dann nicht wie bei VL:He und VL:HeS um ‎ ergänzt werden, damit Klarheit geschaffen wird?!

Gruß, --Wi-luc-ky (Diskussion) 17:22, 16. Aug. 2019 (CEST)

Editieren nur um es rückgängig zu machen lohnt nicht, weil es von den anderen Textelementen in der Umgebung und dem Browser des nächsten Beabeiters abhängt, ob es zu einem übergriffigen UBA käme. Allerdings folgen in aller Regel Pipe-Symbol und Klammern, und die haben ambivalente Schreibrichtung.

Serienmäßig sollte es im Rahmen anderer Änderungen überall eingebaut werden.

Für die Textsequenz wird tatsächlich die umgebende Schreibrichtung explizit abgeschaltet; allerdings nicht mehr wie vor zehn oder zwanzig Jahren üblich gewesen mittels eingefügter Steurzeichen, die beim C&P mit übertragen werden würden, sondern mittels modernerer HTML-Elemente, die explizit für den Bereich der Textsequenz die Schreibrichtung vorgeben, dabei jedoch gleichzeitig einen freilaufenden UBA in der Darstellung beim Leser begrenzen.

Das ‎, das im Quelltext steht, dient nur noch der Begrenzung des UBA bei der Bearbeitung des Wikitextes, gelangt aber nicht in das dargestellte Dokument.

Die Einzeldokumentation dieser Blockzitate oder überhaupt unterschiedlicher Einzelvorlagen hat in der bisherigen Machart wahrscheinlich keine lange Zukunft mehr; deshalb habe ich sie aus der Pflege der Altbestände herausgenommen. Gerade um dieses Exemplar hier hatte es besonders nervtötendes und ressourcenvergeudendes Theater gegeben. Das Pflegebudget für diese Vorlage ist überzogen. Wenn du etwas zur momentanen Doku hinzufügen möchtest, kannst du das in Analogie zu Vorlage:yi und Vorlage:yiS machen. Da es jedoch hier keinen Abschnitt für Beispiele gibt, passt es nicht ganz analog.

VG --PerfektesChaos 17:48, 16. Aug. 2019 (CEST)

Zu Beginn des RTL-Textes muss, laienhaft gesprochen, die RTL-Schreibrichtung eingeschaltet werden und am Ende wieder abgeschaltet, damit die normale LTR-Schreibrichtung wieder gilt. Das geschieht aber nicht mit ‏ und ‎, die Zeichen tun etwas ganz anderes.

Das ‎ hat im Quellcode keine Bedeutung für den Artikel, für alles, was im Artikel angezeigt wird, ist die Vorlage da, die kann das perfekt. Aber angeblich gibt es Browser, die den Bidi-Algorithmus im Quelltext nicht perfekt beherrschen, und für die soll das ‎ dafür sorgen, dass der Quelltext "richtig" angezeigt wird. Dass das nicht so ganz 100%ig sein kann, habe ich gerade in einer Korrektur des Textes auf der Hilfeseite versucht darzustellen. Trotzdem kann das ‎ dort den Schaden verringern, den der Browser erzeugt. Man sollte sich aber vielleicht überlegen, in welchem Verhältnis so eine (hässliche Pseudo-)Lösung zu dem tatsächlichen Umfang des Problems steht. Gibt es denn Erfahrungswerte, welche Browser unter welchen Umständen die Klammern falsch anzeigen?

In dem Artikel, den du ansprichst, wo ich das lrm entfernt habe (oh, der einzige Artikel, der diese Vorlage benutzt!), stand das lrm am Ende der Zeile, dort hat es wirklich keinen Zweck. Es gibt ein paar Tausend Artikel, in denen das lrm an der gewünschten stelle steht, meine letzten Bearbeitungen waren eher bei den Artikeln, wo sie an völlig willkürlicher Stelle stehen. Dabei waren vielleicht auch ein paar Bearbeitungen wie die hier, wo sich die Bearbeitung eigentlich nicht lohnt. --androl ☖☗ 18:12, 16. Aug. 2019 (CEST)

• Das steht hier alles nicht aus Langeweile, sondern weil sehr viele Autoren mit verzweifelten Beschwerden aufliefen, da sie gemischte Textsequenzen und Vorlageneinbindungen nicht mehr bearbeiten konnten, nachdem vor knapp einem Jahrzehnt die ersten Browser anfingen den UBA umzusetzen. Wobei ein Wikitext 2006 mal korrekt eingegeben wurde, auch korrekt dargestellt wurde, und dann eines Tages anfing rumzuspinnen.
  • Mindestens die Firefox-Familie fliegt mir sonst um die Ohren.
  • Diverse andere Browser waren auch dabeigewesen; kann ich mich aber nicht mehr dran erinnern. Wohl Chrome und was von Microsoft.
  • Die hier verwendete Methode wirkt.
  • Die Browser-Generationen verwenden unterschiedlich alte UBA; haben den teils einmalig um 2015 implementiert aber darauf verzichtet, den jemals an irgendwelche Neuerungen anzupassen.
• Wir machen eine ganz einfache Regel für Autoren auf:
  • Wo eine RTL-Textsequenz aufhört, da setze immer ein ‎ dahinter, um Bruch zu vermeiden. Basta.
  • Hochphilosophische Erörterungen, ob und warum man in diesem einen Artikel ausnahmsweise das mal unterlassen könne oder nicht, sind völlig fehl am Platz und kapiert niemand.
  • Irgendwelche Spitzfindigkeiten, wenn aber dies und nicht jenes und daran zukünftig auch niemand etwas ändern würde dann könnte jedoch unter Berücksichtigung von der und der UBA-Regel Stand 2019 auf dieser und jener Seite an der und der Stelle auch mal – das lassen wir hübsch bleiben.
  • Klare, simple Regeln: Auf RTL-Textsequenz folgt ‎ – diskussionslos.
  • Und wenn dann wieder an der Einbindung was verändert wird, dann soll das wieder rückgängig und also doch oder hin und her?
• Die Doku https://www.unicode.org/reports/tr9/ ist früher hinsichtlich der Einstufung von Zeichen nicht sehr eindeutig gewesen.
  • Table 4. Bidirectional Character Types zählt auf:
    • Strong LRM: most alphabetic, syllabic, Han ideographs, non-European or non-Arabic digits,
    • Ein & ist ein et ist ein primär buchstabenähnliches Zeichen. Zumindest in den frühen Implementierungen war es als Buchstabe eingestuft worden. Diese Browser-Implementierungen sind derzeit bei unseren Autoren wirksam.
• Die verbesserte Implementierung https://www.unicode.org/reports/tr9/ mit mehr Details kennt die Regel N2 für neutrale Zeichen, zu denen &|#@ gehören (nicht aber die Klammern).
  • Diese N2 besagt in Kurzfassung für uns: Steht ein neutrales Zeichen in der Abfolge RTL → N → LTR, so wird N als zu L gehörig betrachtet, falls der umgebende Rahmen ltr ist.
  • Heißt für Hebräisch: AlephBeth‎ – Das lrm ist explizit LTR, die AlephBeth wären RTL. Das & bleibt da wo es ist und wird nicht gespiegelt. Unsere embedding direction ist LTR für den Inhaltsbereich der Seiten, und damit das Bearbeitungsfeld.
  • Für deutschsprachige Benutzer ist das gesamte Dokument <html dir="ltr" lang="de"> und vererbt das auf alle nachfolgenden Elemente.
  • Sollte die Sprache der Benutzeroberfläche auf eine RTL-Sprache eingestellt sein, so ist das Portal in dieser Schreibrichtung dargestellt, jedoch wird bei uns: <textarea dir="ltr" name="wpTextbox1" lang="de">
  • Aus vorgenannten Gründen war deine Einfügung auf H:RTL auch schlicht falsch und zu entfernen.
• Egal, ob nach den Algorithmus-Klassifikations-Versionen aus Mitte der 2010er Jahre oder Stand 2019 funktioniert das Entity also genau wie beabsichtigt.
  • Die Neufassungen des Algorithmus und der Klassifikation wurden so ausgearbeitet, dass sie kompatibel sind zu dem, was nach naheliegender Interpretation der ersten UBA-Versionen implementiert wurde und offenkundig erstrebenswerte Ergebnisse lieferte.
  • Die Veränderung der Hilfeseite war damit unbegründet und zurückzusetzen.
• Unabhängig davon, was Bearbeiter sehen würden, funktioniert es trotzdem, da die tatsächliche Anordnung der Zeichen sich nicht ändert, sondern nur die Optik.
• Sollte eines Tages berichtet werden, dass Browser trotzdem Ärger machen, und dies über mehrere Versionen bei einem wichtigen Browser problematisch bleibt, so würden wir uns weitere Gegenmaßnahmen überlegen.
• Beim C&P von irgendwoher werden gelegentlich unsichtbare Bidi mitgenommen, und irgendwo in den Quelltext eingefügt. Siehe H:SPUK. Sie stehen vielleicht zwischen lateinischen oder griechischen Textabschnitten. Damit man sie überhaupt sehen und suchen kann, werden sie gelegentlich von unsichtbar in HTML-Entity umgewandelt, und wenn kein RTL davorsteht, können und sollen diese Entities dann auch manuell gelöscht werden.

VG --PerfektesChaos 15:14, 17. Aug. 2019 (CEST)