Ein selten diskutiertes Thema bei Markup-Sprachen ist das Markup von Sprachen. Dabei geht es nicht nur darum wie man Sprachen auszeichnet, sondern wie man überhaupt an die Sprachinformation gelangt? Fehlendes oder falsches Language Tagging kann viele Probleme für Barrierefreiheit und Typografie bereiten. Aber kann man nicht einfach die richtige Sprache einstellen und die Sache ist erledigt? Ganz so einfach verhält es sich leider nicht.
Vielleicht ohne es zu ahnen haben viele die Anzeichen von fehlerhaftem Language Tagging schon selbst bemerkt: Man hat sich wirklich Mühe gegeben, aber die Rechtschreibprüfung unterstreicht unerbittlich jede Zeile rot. Die automatische Silbentrennung im E-Book-Reader macht vieles, aber nicht die Worte nach den orthografischen Regeln trennen. Man will sich einen Artikel vorlesen lassen, aber der merkwürdige Akzent der synthetischen Stimme lässt ungute Erinnerungen an die letzte Konferenz wach werden.
Falsches Language Tagging kann viele Ursachen haben. Die meisten Fehler geschehen schon beim Verfassen des Manuskripts. Selbst wenn die Textverarbeitung die Sprache des Dokuments richtig erkannt hat, können durch Copy & Paste aus dem Web falsche Spracheinstellungen übernommen werden. Diese Nachlässigkeit unterläuft Autor:innen häufig bei Zitaten und Literaturapparaten. Bei den Arbeiten meiner Student:innen kann es aber auch ein Indiz für einen freizügigeren Umgang mit der Übernahme von Gedanken anderer darstellen.
Auch beim Satz ist es ein beliebter Fehler, für fremdsprachige Passagen nicht das entsprechende Wörterbuch im Absatzformat auszuwählen. Dann wird die deutsche Silbentrennung auf einen französischen Text angewendet, was einem vielleicht nicht gewahr wird, wenn man der Sprache nicht mächtig ist.
Probleme können auch bei der Datenkonvertierung entstehen, etwa wenn die Tools die Sprachinformationen nicht auswerten oder die Hautsprache einfach voreingestellt ist, so wie manche im Auslandsurlaub von Deutsch als lingua franca nicht abrücken wollen. Nicht zuletzt kann auch Outsourcing falsches Language Tagging begünstigen, vor allem wenn „Handarbeit“ inbegriffen ist. Wenn die XML-Daten in Pune oder Manila manuell im Editor in der Nachtschicht ausgezeichnet werden, dann kann das Auswirkungen auf die Qualität haben.
Aber wie sieht Language Tagging eigentlich in den Daten aus? Bei XML gibt es das xml:lang-Attribut und bei HTML heißt es einfach nur lang. Der Inhalt ist ein Sprachkürzel nach dem ISO-639-1-Standard, das bei Bedarf auch um einen Country Code (ISO-3166-1) ergänzt werden kann. Für britisches Englisch hieße der Wert dann en-GB. Die Hauptsprache wird festgelegt, indem man das Attribut an das Wurzelelement schreibt, während jedes Element mit einer anderen Sprache auch ein Attribut erhält, wie in diesem Beispiel:
<html xmlns="http://www.w3.org/1999/xhtml" lang="de-DE">
<head>
<title/>
</head>
<body>
<p>Die Ampel hat eine rote Glühbirne.</p>
<p lang="fr-FR">Le feu a une ampoule rouge.</p>
</body>
</html>
Bei Language Tagging sollte man bei der Verarbeitung mit XSLT und XProc achtsam sein. Im Gegensatz zu Namespaces wird der Sprachkontext beim Kopieren und Einfügen nicht immer erhalten: Wenn ein Element über ein Elternelement mit xml:lang="en" aber kein eigenes xml:lang verfügt, dann ist die Spracheinstellung folglich Englisch. Fügt man das Element aber in einen anderen Kontext ein, wo ein Elternelement mit xml:lang="de" steht, dann wechselt es seine Sprache nach Deutsch. Eine kleine XProc-Demonstration wie man Language Tagging unbedacht verändern kann, habe ich mal in dieses Gist gepackt.
Nachdem nun geklärt ist, wie Language Tagging aussieht, stellt sich die Frage, wie man überhaupt zu den Sprachinformationen gelangt? Dafür gibt es drei Methoden:
- Sprache auszeichnen
- Spracheinstellungen mitführen
- Sprache erkennen
Sprache auszeichnen
Wenn man Sprache explizit im Dokument taggt, dann weist man einem Dokument und/oder einer Passage in einem Dokument explizit eine Sprache zu. Das kann in Word oder InDesign z.B. mit Formaten geschehen, die in ihrem Namen explizit die Sprache mit sich führen wie Absatz_en für einen englischsprachigen Absatz.
Diese Methode hat den Vorteil, dass man bereits im Formatnamen sieht, welche Sprache eingestellt ist. Allerdings wird es bei vielen Sprachen schnell aufwändig und unübersichtlich, weil man ein typografisches Format für jede Sprache duplizieren muss. Wenn man nicht sauber mit Formatvererbung arbeitet, können kleine Formatänderungen schnell in eine Kaskade von Korrekturen münden. Zudem steigt mit der Zahl der Formate und Sprachen der Aufwand, diese auszuzeichnen und zu implementieren.
Spracheinstellungen mitführen
Bei diesem Weg würde man die Spracheinstellungen aus Word oder InDesign übernehmen. Beide Anwendungen speichern die Sprachinformationen des Dokuments und, falls diese davon abweichen, auch für die Absatz- und Zeichenformate. Hier ist mal ein gekürztes Beispiel, wie wir die Sprachinformationen mit CSSa und xml:lang-Attributen im XML mitführen.
<?xml version="1.0" encoding="UTF-8"?>
<hub xmlns="http://docbook.org/ns/docbook"
xmlns:css="http://www.w3.org/1996/css"
xml:lang="de-DE">
<info>
<css:rules>
<css:rule name="Citation" xml:lang="fr-FR"/>
</css:rules>
</info>
<para>Ein Klassiker des Franglais von Jean Loup Chiflet:</para>
<para role="Citation"><phrase xml:lang="en-EN">Sky My Husband!</phrase> Ciel Mon Mari!</para>
</hub>
In der Theorie klingt das zunächst einfach und in der Praxis hat sich für uns diese Methode meistens bewährt. Allerdings gibt es auch hier Untiefen, die man ausloten muss. Bei Dokumenten aus Microsoft Word habe ich oft feststellen müssen, dass die Hauptsprache falsch eingestellt ist. Dann findet sich an jedem Absatz eine abweichende Sprachinformation und an diesen Stellen müsste ein Satzsystem oder Screenreader immer einen Sprachwechsel vornehmen.
Die überflüssigen Sprachwechsel haben wir eingehegt, indem wir die Hauptsprache danach festlegen, welche Sprache über die meisten Zeichen im Dokument verfügt. Aber das löst noch nicht das eingangs angesprochene Problem, wenn irgendwo die falsche Sprache hinterlegt wurde.
Sprache erkennen
Wenn man davon ausgeht, dass sich die erste Methode sehr aufwändig gestaltet und die zweite Methode keine vollständige Sicherheit birgt, dann drängt sich die Frage auf, warum man die Erkennung der Sprache nicht einfach dem Computer überlässt?
Nun kann man bestimmte Sprachen wie Hebräisch oder Arabisch anhand ihrer Zeichen erkennen. Diese Methode scheidet aber bei vielen lateinischen und asiatischen Sprachen aus, die viele gemeinsame Zeichen miteinander teilen. Hier kann uns aber das sogenannte Natural Language Processing (NLP) weiterhelfen, wo es darum geht, wie ein Computer menschliche Sprache „versteht“. NLP umfasst viele Gebiete, u.a. auch Texte zu analysieren oder gar zu generieren. In unserem Fall reicht uns aber die Erkennung der verwendeten Sprache aus, so wie man bei Google Translate auf Sprache erkennen klickt.
Inzwischen gibt es viele Open-Source-Bibliotheken, die mit neuronalen Netzen Sprachen identifizieren können. So bietet Google z.B. seinen Compact Language Detector v3 (CLD3) als Open Source auf GitHub an. Mein Kollege Jan Schilbach verwendet diesen z.B. für die Erkennung der Sprache in Literaturangaben mit unserem Referenzenstrukturierer Struki™.
Weil XProc-Prozessoren wie Morgana und XML Calabash in Java implementiert sind, habe ich mir ein paar Java-basierte NLP-Bibliotheken angeschaut und Lingua als XProc-Erweiterungs-Step für XML Calabash implementiert. Den Step kann man wie folgt in seine XProc-Pipeline einbinden:
<?xml version="1.0" encoding="UTF-8"?>
<p:declare-step xmlns:p="http://www.w3.org/ns/xproc"
xmlns:c="http://www.w3.org/ns/xproc-step"
xmlns:tr="http://transpect.io"
version="1.0">
<p:output port="result" sequence="true"/>
<p:option name="string" select="'This is just a test.'"/>
<p:option name="langs" select="'latin'"/>
<p:import href="lang-declaration.xpl"/>
<tr:lang>
<p:with-option name="string" select="$string"/>
<p:with-option name="langs" select="$langs"/>
</tr:lang>
</p:declare-step>
Als Output erhält man dann die Sprache in einem handlichen c:result-Dokument:
<c:result xmlns:c="http://www.w3.org/ns/xproc-step"
lang="ENGLISH" iso-639-1="en" iso-639-3="eng"/>
Dergestalt könnte man z.B. überprüfen, ob das Language Tagging in der Datei von dem durch die KI erkannten abweicht. Aber auch hier gibt es leider ein paar Grenzen. Zunächst verbraucht das Laden und Anwenden der Language Models ziemlich viel Speicher. Man muss also ausreichend Hardware auf die Software werfen, damit es funktioniert. Die Erkennung von kürzeren Textfragmenten ist nach Angaben der Entwickler:innen recht ungenau. Meine karge Freizeit lässt auch keine tiefgreifenden Analysen zu, wie gut die Modelle bei weniger verbreiteten Sprachen funktionieren. Aber es wäre schon hilfreich, wenn man mit Schematron überprüfen könnte, ob die im Format gesetzten Sprachen mit den via KI erkannten übereinstimmen und Unterschiede den Nutzer:innen melden kann.
Letzlich stellt das noch keine fertige Lösung dar, sondern eher einen Werkstattbericht. Aber die Verwendung des korrekten Language Taggings ist für uns recht bedeutsam, damit unsere Satzsysteme die korrekte Silbentrennung verwenden und Barrierefreiheit und Silbentrennung in EPUB und PDF sichergestellt ist. Vielleicht wird Language Tagging auch irgendwann überflüssig, wenn immer mehr Anwendungen mit NLP-Technologien auf Language Detection setzen? On verra bien!