Hilfe:Asiatische Schriften

Darstellungsprobleme und Schwierigkeiten mit dem Quelltext der Wiki-Seiten durch Zeichen aus asiatischen Schriften sollen vermieden werden.

Vorlagen

Grundsätzlich sollen alle Textpassagen mit außereuropäischen Schriftzeichen in Vorlagen eingebettet werden; selbst wenn es sich nur um einzelne Buchstaben handelt.

• Dadurch lassen sich fast alle Darstellungsprobleme bei Lesern der Artikel und Seltsamkeiten für Autoren vermeiden.
• Insbesondere ermöglicht die Sprachzuordnung die Versorgung mit passenden Webfonts.

In der Regel reicht dazu die Vorlage:lang aus.

• Soll auch der Sprachname gezeigt (und gleich verlinkt) werden, empfehlen sich Vorlagen aus einer speziellen Kategorie.
• Ist die Schreibrichtung Rechts-nach-Links, so sind spezielle Vorlagen erforderlich.

Bei modernem Griechisch und Russisch können die Leser den Artikel heutzutage wahrscheinlich auch ohne besondere Vorlagen lesen.

• Der guten Ordnung halber sollten aber auch diese Textpassagen in Vorlagen eingebettet werden, auch wenn es keine asiatischen Schriften sind – bei allen nichtlateinischen Schriften ist das günstig.
• Bei historischen Sprachvarianten und nichtrussischen kyrillischen Alphabeten ist das immer notwendig.

RTL: Rechts-nach-Links-Schriften

Abkürzung:
H:RTL

Bei den Rechts-nach-Links-Schriften, namentlich für arabische und hebräische Sprachen, sind spezielle Vorlagen erforderlich.

Diese (englisch Right-To-Left – RTL genannten) Schriften führen leicht zu Darstellungs- und Bearbeitungsproblemen.

RTL-Sprachen

Betroffen sind vor allem die nachstehenden Sprachen: <section begin="RTLtable" />

Schrift	Code	Sprache
Hebräisch	he	hebräisch aller Zeiten, einschließlich Ivrit
	yi	jiddisch
	hbo	Biblisches Hebräisch, Mischnisches Hebräisch
Arabisch	ar	arabisch
	arz	Ägyptisch-Arabisch
	az-Arab	aserbaidschanisch in arabischer Schrift
	bft	Balti
	fa	persisch
	glk-Arab	Gilaki in arabischer Schrift
	ku	kurdisch
	ckb	Sorani (zentral- oder südkurdisch)
	kk-Arab	kasachisch in arabischer Schrift
	kmr	kurmandschi
	ks-Arab	Kashmiri in arabischer Schrift
	ms-Arab	malaiisch in arabischer Schrift
	mzn	masanderanisch
	ota	osmanisch – türkisch in arabischer Schrift
	pa	Panjabi
	ps	paschtunisch
	sd-Arab	Sindhi
	ug	uigurisch in arabisch-persischer Schrift
	chg	tschagataisch
	ur	Urdu
	uz-Arab	usbekisch
Sonstige	syr	syrisch (Neuostaramäisch)
	syc	klassisch-syrisch
	arc	aramäisch
	dv	Dhivehi

<section end="RTLtable" />

RTL-Vorlagen

Die Vorlage:lang genügt für diese Sprachen nicht, weil darin die Schreibrichtung nicht berücksichtigt wird.

Alle zurzeit benötigten Vorlagen wurden angelegt.

• In der Kategorie:Vorlage:zur Schriftunterstützung (bidi) sind sie zusammengestellt.
• Sollte eine weitere Vorlage in einem Artikel erforderlich sein, kann sie kurzfristig anhand der Vorbilder erstellt werden.

Für größere Zitate sind eigene Vorlagen notwendig, um die Schreibrichtung und das Layout korrekt darstellen zu können.

Zur Notation der Vorlagenparameter siehe auch UBA im Quelltext.

Es gibt eine MediaWiki-Parserfunktion {{bidi:Text}} – sie soll nicht verwendet werden, da sie keinerlei Sprachzuordnung bietet und lediglich Marken vor und nach dem Text einfügt.

Bidi – Bidirektionales Steuerzeichen

In der deutschsprachigen Wikipedia werden Textpassagen in Rechts-nach-Links-Schreibrichtung in einem Kontext gezeigt, der Links-nach-Rechts geschrieben wird. Es kommen also beide Richtungen gleichzeitig vor, weshalb diese Texte auch bidirektional genannnt werden.

Ein Bidirektionales Steuerzeichen wäre eine in der Technik noch gebräuchliche Methodik, um Zweifelsfälle in der Interpretation des Textes zu beseitigen. Allerdings hat sie durch die Veränderung des Textes auch Nachteile und wird mittlerweile durch andere Spezifikationen abgelöst, zumindest was die autorendefinierten Ursprungstexte angeht. In diesen soll, anders als ggf. in den automatisierten Zwischenformen für die Ausgabe auf Bildschirm oder Papier, sowieso nur maximal eines der beiden Elementarzeichen LRM und RLM vorkommen.

In der deutschsprachigen Wikipedia ist das einzige Zeichen, das übergangsweise noch sinnvoll im freien Artikeltext auftreten kann, das als ‎ kodierte Zeichen zur Rückschaltung in die Schreibrichtung von links nach rechts. Es ist als HTML-Entität für alle sichtbar in den Quelltext einzufügen. Sobald die RTL-Vorlagen eingesetzt wurden, sind diese außerhalb der Vorlagen sinnfrei und sollten entfernt werden, um gespenstische Effekte zu vermeiden.

Die bidi-Steuerzeichen sind nicht bedeutungstragend. Demzufolge werden sie von der Mediawiki-Software aus den Seitennamen entfernt und bei der Bildung von Verlinkungen im Wikilink-Format ignoriert.

UBA: Unicode-Bidi-Algorithmus

Der Unicode-Bidi-Algorithmus wurde entwickelt, um die Zugehörigkeit von Zeichen zu dem von rechts nach links oder dem von links nach rechts geschriebenen Teil der Textpassage zu entscheiden.

Dabei geht es um „ambivalente“ Zeichen; also solche, die in beiden Richtungssystemen vorkommen können. Das sind Klammern, Satzzeichen, die Rechenzeichen +−×:= und Schrägstrich / wie auch Pipe | und möglicherweise Ziffern.

Je nachdem, ob sie der „rechten“ oder „linken“ Interpretation des Ursprungstexts zugeordnet werden, erscheinen die „am Ende“ stehenden ambivalenten Zeichen links vor oder rechts nach der fremdsprachlichen Passage.

Seit etwa 2010 wird der UBA verstärkt in den modernen Browsern wirksam. Das bedeutet, dass ein 2006 ordnungsgemäß dargestellter Wikitext heutzutage seltsam durcheinandergewürfelt erscheinen kann.

UBA in der Seitendarstellung

Angenommen, in einem Artikel würde der nachstehende Text erwartet:

Der bekannte Clown ליצן (* 1. April).

Dann kann es in modernen Browsern leicht zu folgender Darstellung kommen:

Der bekannte Clown 1 *) ליצן . April).

Grund ist, dass die Klammer ambivalent ist und in beiden Schreibrichtungen vorkommen kann. Der Browser setzt sie korrekt an das „Ende“ des hebräischen Textes (also nach links) und spiegelt sie. Desgleichen wird mit dem Sternchen verfahren, ggf. auch mit Ziffern.

Deshalb ist hier die Textpassage in eine RTL-Vorlage einzuschließen, die alles Weitere organisiert.

UBA in der Quelltextbearbeitung

Der gleiche Effekt wie vor kann auch beim Einfügen der Textpassage in die Vorlage auftreten, wenn das Eingabeformular im Browser ausgefüllt wird.

Angenommen, wir möchten den folgenden Text darstellen

Staat Israel (hebräisch ישראל) wurde

und dazu den nachstehenden Quelltext bearbeiten:

Staat Israel ({{heS|ישראל}}) wurde

Das kann bei der Bearbeitung erscheinen als:

Staat Israel ({{heS|({{ישראל wurde

Hier werden die abschließenden Klammern }} der Vorlageneinbindung gespiegelt und nach links gesetzt, genauso die einschließende runde Klammer.

Für den Autor kann die Bearbeitung im Quelltext dann sehr schwierig sein, weil die sichtbare Cursorsorposition nicht mehr mit der Stelle übereinstimmt, an der Zeichen eingefügt oder gelöscht werden. Grund ist, dass durch mangelhafte Programmierung die gewandelte optische Darstellung nicht mit der Zeichenposition im Formular synchronisiert wird.

Es ist daher ratsam, an das Ende des Parameters innerhalb der Vorlage noch ein ‎ zu schreiben:

Staat Israel ({{heS|ישראל‎}}) wurde

Damit wird auch für die nachfolgenden Autoren der UBA gebrochen: Hier hat nur noch das & beide mögliche Schreibweisen, die Zeichen lrm haben zweifelsfrei die Schreibrichtung von links nach rechts, sodass maximal das & an der falschen Stelle angezeigt werden kann. Bei korrekter Umsetzung aktueller UBA-Regeln geschieht auch das nicht, weil für dieses Zeichen in dieser Situation festgelegt ist, dass es die Schreibrichtung von links nach rechts der nachfolgenden Buchstaben lrm erben soll.

Auf eine Parameterzuweisung in einer Vorlage folgt entweder ein Pipe-Symbol oder die schließenden } – beide Zeichen können ambivalente Schreibrichtung haben, so dass auch ein nachfolgendes Pipe-Symbol an den Beginn des Textes gespiegelt werden kann.

Die Software schneidet bei Vorlagenparametern die Bidi-Zeichen an Anfang und Ende ab. Deshalb gelangt das Zeichen nicht in die weitere Textdarstellung und nicht in die dargestellte Seite.

Sollte die Entity einmal irrtümlich mitkopiert werden, ist es durchaus an sinnvoller Stelle und richtet keinen Schaden an.

Die Eingabefelder der Browser sind darauf ausgelegt, dass hier normaler Text für Mitteilungen und veröffentlichte Texte eingegeben wird, und wenden deshalb immer umfassender UBA darauf an. Syntaxkonstrukte mit doppelten Klammern sind in derartigen Texten nicht üblich.

Breitenlose Zeichen

In einigen Sprachen kommen unsichtbare „nullbreite“ Zeichen vor; oder im Quelltext nicht von normalen Leerzeichen unterscheidbare aber kaum sichtbar dargestellte Leerzeichen. Sie beeinflussen das Erscheinungsbild der angrenzenden Buchstaben. Vereinfacht könnte man sie sich als die Trennung zwischen Wörtern vorstellen, oder umgekehrt als die Bildung von Komposita aus benachbarten Wörtern.

Die breitenlosen Zeichen sind bedeutungsunterscheidend. Demzufolge werden sie von der MediaWiki-Software bei der Bildung von Seitennamen zugelassen und sind bei der Bildung von Verlinkungen im Wikilink-Format signifikant.

In der deutschsprachigen Wikipedia sind sie als HTML-Entität für alle sichtbar in Vorlagenparameter einzufügen.

Außerhalb der zwingend notwendigen Verwendungen – und dann zwangsläufig als Vorlagenparameter oder in Wikilinks – sollen sie nirgendwo im freien Artikeltext vorkommen; insbesondere nicht zu Hacks zum Erreichen von Nebeneffekten missbraucht werden. Sie sollten dort weitmöglichst entfernt werden, um gespenstische Effekte zu vermeiden.

Beteiligte Sprachen

Zeichen / Entity	Code	Sprache
‍ (Verbinder)	kn	Kannada
	ml	Malayalam
	sa	Sanskrit
	si	singhalesisch
‌ (Nicht-Verbinder: Bindehemmer)	bn	bengalisch
	fa	persisch
	kn	Kannada
	ml	Malayalam
	mr	Marathi
	mzn	Masanderanische Sprache
	te	Telugu
  (haarbreites Leerzeichen)	bo	Tibetische Sprache
	km	Khmer

CJK: chinesisch-japanisch-koreanisch

Die chinesisch-japanisch-koreanischen (CJK) Schriften verursachen technisch meist keine größeren Herausforderungen.

• Um an geeigneten Stellen einen Zeilenumbruch auszulösen, gibt es das wbr-Element.
• Alltägliche (oder „vereinfachte“) Schriftzeichen in den modernen Sprachen müssten unproblematisch sein. Bei klassischen Formen und regionalen Varianten kann es zu Schwierigkeiten mit Unicode kommen, weil diese Kodierungen größer als 65.500 haben können.

Zeichencodes

Die ursprüngliche Version von Unicode basierte auf 2¹⁶ = 65.536 Zeichen, auch als „Basis-Ebene“ bekannt. Die Kodierung eines Zeichens konnte mit zwei Bytes dargestellt werden. Viele Software-Systeme gehen bis heute von diesem Werteumfang aus. Die üblichen, verbreiteten modernen Sprachen werden mit Schriftzeichen aus diesem Bereich dargestellt.

Inzwischen wurde der Umfang auf mehr als 2²⁰ und damit mehr als eine Million Zeichen erweitert. Zur Speicherung der Nummer sind jetzt vier Bytes erforderlich.

• Die MediaWiki-Software kann mit dem vollen Umfang umgehen.
• Viele Skripte und Bots haben jedoch Schwierigkeiten, wenn im Quelltext Zeichen vorkommen, die jenseits der 65.500 liegen.

Es empfiehlt sich deshalb, sehr exotische Zeichen ab U+10000 in Form von numerischen HTML-Entities als 𐀀 bzw. 𐑪 im Quelltext zu notieren, wenngleich wir normalerweise die Direktdarstellung der Zeichen statt Entities verwenden. Der Quelltext entspricht dann in diesem Bereich sogar ASCII und verursacht keine Verarbeitungsprobleme. Erst später im Browser des Lesers wird das Entity dann wieder in den Zeichencode umgewandelt.

Alle unsichtbaren Zeichen und Sonderformen der Leerzeichen sollen stets als Entities für alle Bearbeiter sichtbar notiert werden, damit die Autoren nicht unbemerkt mit abweichenden Kodierungen arbeiten. Bei den Zielen von Interwiki-Verlinkungen mag die Kodierung im fremden Wiki übernommen werden.

HTML-Elemente

Drei Typen von Tags aus HTML kommen bei asiatischen Schriften hinzu:

• <wbr >
  • Es signalisiert, an welcher Stelle eine Kette von Schriftzeichen umbrochen werden darf, wenn die Zeile zu lang wird. Anders als bei europäischen Schriften wird jedoch kein Trennstrich eingefügt, was zwischen arabischen oder CJK-Zeichen auch nicht verständlich wäre.
  • Bei der Bildung eines SEITENTITEL würde <wbr /> ignoriert; ist also zulässig.
• Die Ruby-Notation ermöglicht zusätzliche Informationen mit den Elementen <ruby> und darin <rb> <rp> <rt> <rtc> – von der MediaWiki-Software wird <rbc> zurzeit nicht unterstützt.
• Nicht direkt verwendet werden sollen: <bdi> und <bdo>

SPUK: Syntax-Probleme unsichtbarer Kodierungen

Abkürzung:
H:SPUK

Die unsichtbaren Zeichen im Wikitext, namentlich „bidi“ und „nullbreit“, können ihrer Natur nach von den Autoren nicht wahrgenommen werden. Gleichwohl sind sie wirksam:

• In URL bewirken sie eine falsche Internet-Adresse, mit der der angefragte Webserver meist nichts anfangen kann, und deshalb eine kaputte Verlinkung.
• Zwischen den Elementen der Wikisyntax, etwa zwischen zwei Klammern, machen sie ihre Funktion unwirksam. Für die Bearbeiter ist das unerklärlich. (Die Ziele von Wikilinks sind nicht betroffen.)
• Im normalen Text erlauben sie seltsame Zeilenumbrüche mitten im Wort und ohne Trennstrich.

Vor allem verhindern sie aber alle Such- und Ersetzungsvorgänge; sei es interaktiv durch die Autoren oder aber mithilfe von Skripten und Bots. Es ist praktisch nicht möglich, für normale Textsuchen an beliebigen Stellen die unsichtbaren Zeichen zu berücksichtigen.

Besonders tückisch ist, dass sie beim Kopieren und Einfügen (C&P) aus irgendeiner Seite im Browser oder anderen elektronischen Texten unbemerkt mit übertragen und eingefügt werden. Dadurch verbreiten sie sich dann flächendeckend. Es wird angestrebt, dass in der Darstellung von Seiten der deutschsprachigen Wikipedia nirgendwo mehr unsichtbare Zeichen generiert werden, die dann kopiert werden könnten.

Nur spezielle Werkzeuge ermöglichen die Erkennung der geisterhaften Zeichen. Sie sollen deshalb, sofern beabsichtigt, stets als Entity in den Quelltext geschrieben werden.

Optische Präsentation

Webfonts

Die Schriftunterstützung (ULS) ermöglicht bei den mittels Sprachcode markierten Textpassagen in der Regel die Darstellung der Schriftzeichen in der fertigen Seite selbst bei den Lesern, die derartige Zeichensätze nicht installiert haben.

CSS

Die fremdsprachlichen Textpassagen können optisch gesondert dargestellt werden.

Die arabisch-hebräischen Zeichen erscheinen in unseren lateinisch verschrifteten Seiten so klein, dass für die Bedeutung wesentliche Merkmale kaum zu erkennen sind. Traditionell werden sie deshalb leicht vergrößert dargestellt. Außerdem können sie mit persönlichem Stil versehen werden.

Die projektweiten Vorgaben richten sich nicht nach Sprachen, sondern nach Schriftsystemen. Alle nichtlateinischen und über Vorlagen definierten Textfragmente erhalten eine class="Xabc" mit einem Code entsprechend ISO 15924.

In Kategorie:Vorlage:Schriftsystem-Unterstützung sind auch schriftspezifische Vorlagen aufgelistet, deren Dokumentation jeweils weitere Hinweise enthält; insbesondere sind hier alle Schriftsysteme aufgeführt, zu denen es eine projektweite Spezifikation gibt.

Außerdem tragen die Textfragmente aus der englischsprachigen Wikipedia übernommene Klassen-Selektoren:

• .arabic – wirkt auf ar, fa, ku, ckb, arz, az-Arab, ota, ps, ug, ur
• .hebrew – wirkt auf he, hbo, yi

Jede sprachspezifische Sequenz kann aber heutzutage auch mittels [lang="xy"] selektiert werden, wobei xy der Sprachcode ist.

Zur Umsetzung der persönlichen Gestaltungswünsche siehe WP:CSS.

Werkzeuge

• showScripts@ISO15924 – jedem Zeichen des Textes den Zeichencode und das Schriftsystem beigeben

Mehrere Benutzerskripte können mit unsichtbaren Zeichen umgehen:

• Benutzer:Schnark/js/antispoof – macht unsichtbare Zeichen im HTML-Dokument sichtbar und zeigt ihre Bedeutung als Tooltip.
• WSTM ersetzt bei der Quelltextbearbeitung praktisch alle Zeichen mit verborgener Bedeutung durch ein Entity oder löscht solche Zeichen an zweifelsfrei unsinnigen Stellen.
• autoFormatter@TMg wandelt Zeichen um; löscht bidirektionale Zeichen in ASCII-Kontext.
• wikEd zeigt bei der Quelltextbearbeitung unsichtbare Zeichen als orangefarbene Quadrate  mit Tooltip. Dieses Werkzeug scheint 2020 nicht mehr gepflegt zu werden und funktioniert womöglich nicht mehr im vollen Umfang.
• Benutzer:Schnark/js/diff – macht unsichtbare Zeichen in der Vergleichsdarstellung sichtbar und zeigt ihre Bedeutung als Tooltip.

Weitere Informationen

• Hilfe:Schriftunterstützung
• Wikipedia:Technik/MediaWiki/Sprachen – insbesondere zu Sprachcodes
• Wikipedia:Fremdsprachen – zum Arbeiten mit Sprachen allgemein

Extern:

• HTML-Seiten in arabischer, hebräischer und anderen von rechts nach links geschriebenen Schriften erstellen. (Tutorial) W3C (deutsch [umschaltend])
• Unicode controls vs. markup for bidi support. W3C, Steuerzeichen möglichst vermeiden (englisch)