Mehrsprachige strukturierte Daten.
Auf mehrsprachigen Websites werden strukturierte Daten in jeder Sprachversion eigens erzeugt, und die Sprache des Inhalts wird ausdrücklich angegeben.
Strukturierte Daten geben den Maschinen die Bedeutung der Seite an; auf einer mehrsprachigen Website muss auch angegeben werden, in welcher Sprache diese Bedeutung ausgedrückt ist. Andernfalls kann die Maschine die Beschreibung auf einer deutschen Seite für Türkisch halten.
Die Angabe ist einfach: Jeder Knoten trägt die Sprache seines Inhalts. In der Praxis gibt es aber zwei Fallen, und beide sind häufig.
Falle eins: in einer Sprache erzeugtes Schema
Der verbreitetste Fehler: das Schema einmal erzeugen und in allen Sprachen unverändert verwenden. Das Ergebnis: Die deutsche Seite liefert einen Schemablock mit türkischer Beschreibung. Auf dem Bildschirm Deutsch, in der Maschinenschicht Türkisch — die zwei Leser hören Verschiedenes.
Das richtige Verhalten ist, das Schema zusammen mit dem Inhalt zu übersetzen. Name, Beschreibung, Leistungsdefinition, Frage-Antwort-Blöcke — alles muss in der Sprache dieser Seite sein. Das erhöht die Übersetzungslast, aber andernfalls trägt das Schema falsche Information.
Auf dieser Website kommt das Schema aus dem Generator, und die Zeichenketten werden aus dem Sprachwörterbuch gelesen; das Schema der deutschen Seite trägt also die deutschen Zeichenketten. Ein Auseinanderlaufen ist strukturell unmöglich.
Falle zwei: sollen sich Identitäten nach Sprache teilen
Die Organisations- und Personenknoten werden in jeder Sprache erneut definiert. Die Frage: Sind das dieselbe Entität oder eigene Entitäten pro Sprache?
Die Antwort: dieselbe Entität. Eine in drei Sprachen erzählte Organisation wird nicht zu drei Organisationen. Die Identitäten dürfen sich deshalb nicht nach Sprache teilen — dieselbe feste Identität muss in jeder Sprache verwendet werden, damit die Maschine versteht, dass die drei Seiten von derselben Entität sprechen.
Die Seitenknoten dagegen sind pro Sprache getrennt: Jede Sprachversion trägt ihren eigenen Seitenknoten und gibt ihre eigene Adresse an. Also: eine Entität, viele Seiten.
- Organisation und Person — eine Identität, in allen Sprachen gleich. Die Zeichenketten werden übersetzt, die Identität nicht.
- Seitenknoten — pro Sprache getrennt; jeder gibt die eigene Adresse und Sprache an.
- Inhaltsknoten — Artikel, Leistung; pro Sprache getrennt und mit angegebener Sprache.
- Der Brotkrumenpfad — pro Sprache getrennt; die Etiketten tragen die Begriffe dieser Sprache.
Diese Trennung lässt den Graphen richtig lesen: Die drei Seiten in drei Sprachen erscheinen als drei eigene Seiten, die an dieselbe Organisation gebunden sind — nicht als drei eigene Organisationen.
Die Etiketten der Sozialkarten
Neben dem Schema gibt es noch eine Ebene fürs soziale Teilen, und auch sie trägt eine Sprachangabe. Das Etikett verlangt ein Format, das Sprach- und Ländercode verbindet — der Sprachcode allein gilt als ungültig.
Auch alternative Sprachversionen können angegeben werden: Eine Seite kann sagen, in welchen anderen Sprachen sie existiert. Auf dieser Website gibt jede Seite die eigene Sprache und die anderen zwei an — gemessen, und die Prüfsuite prüft das Format eigens.
Konsistenz zwischen Schema und Bildschirm
Die goldene Regel der einsprachigen Websites wird auf mehrsprachigen doppelt wichtig: Alles, was im Schema steht, muss auch auf dem Bildschirm stehen. Denn hier bestehen zwei Auseinanderlauf-Risiken zugleich — das der Information und das der SPRACHE.
Das zweite ist heimtückischer: Die Beschreibung im Schema kann die richtige Information tragen, aber in der falschen Sprache. Das wirft in einem Prüfwerkzeug keinen Fehler — das Werkzeug prüft die Sprache nicht —, aber ans Modell geht das falsche Signal, und die Seite kann mit Anfragen in der falschen Sprache zusammengeführt werden.
- Sind die Zeichenketten des Schemas in der Sprache der Seite — Beschreibung, Name, Frage-Antwort.
- Ist die Sprache an jedem Knoten angegeben — die Sprache des Inhalts muss ausdrücklich dastehen.
- Sind die Identitäten nicht nach Sprache geteilt — die Organisation ist in allen drei Sprachen dieselbe Entität.
- Sind die Seitenknoten pro Sprache getrennt — jede Version muss die eigene Adresse angeben.
- Sind die Sozialetiketten im Sprache-Land-Format — der Sprachcode allein ist ungültig.
- Steht jede Information des Schemas auch auf dem Bildschirm — ohne Ausnahme.
Der dritte und der vierte Punkt sind zusammen zu lesen, denn sie stellen die Trennung her: eine Entität, viele Seiten. Der Organisationsknoten trägt in allen drei Sprachen dieselbe Identität — die Zeichenketten übersetzt, die Identität fest. Die Seitenknoten sind getrennt, denn sie sind wirklich getrennte Seiten.
Auf dieser Website kommt das Schema aus dem Generator, und die Zeichenketten werden aus dem Sprachwörterbuch gelesen; das Auseinanderlaufen ist strukturell unmöglich. Die Prüfsuite misst auf jeder Route eigens das Vorhandensein der erwarteten Knoten und das Format der Sozialetiketten.
Übersetzungslast und Automatisierung
Wird klar, dass auch das Schema übersetzt werden muss, lautet die erste Reaktion meist „das ist viel Arbeit“, und sie ist berechtigt. Aber die Last ist real, wenn das Schema von Hand geschrieben wird — nahe null, wenn es aus dem Generator kommt.
Der Grund: Die Zeichenketten im Schema sind die ohnehin auf der Seite stehenden. Titel, Beschreibung, Leistungsname, Frage-Antwort — alles steht auch auf dem Bildschirm und ist bereits übersetzt. Das Schema schreibt sie nicht neu, es liest aus derselben Quelle.
Das ist zugleich die Begründung, warum das Schema aus derselben Quelle erzeugt werden muss wie der Inhalt: Derselbe Text, an zwei Orten gehalten, läuft früher oder später auseinander, und dann wird unklar, welcher der richtige ist.
Auf dieser Website kommt das Schema aus dem Generator, und die Zeichenketten werden aus dem Sprachwörterbuch gelesen. Wird ein Text aktualisiert, aktualisieren sich Bildschirm und Schema im selben Moment — denn beide schauen auf dieselbe Quelle. Die Übersetzungslast ist, jenseits der Inhaltsübersetzung selbst, null.
Ein letzter Rahmen: Das mehrsprachige Schema ist keine erschwerte Form des einsprachigen — dieselben Regeln gelten, nur eine Dimension kommt hinzu. Sind die Regeln bereits bekannt, ist die Sprachdimension eine kleine Zusatzlast; sind sie es nicht, macht die Sprachdimension das Problem sichtbar, erzeugt es aber nicht.
Eine letzte Umfangsnotiz: Der zu übersetzende Teil des Schemas sind nur die Freitextfelder. Typnamen, Feldnamen und Kennungen werden nicht übersetzt — sie sind Teil des Maschinenvokabulars und bleiben in jeder Sprache gleich.
Diese Unterscheidung wird bisweilen verwechselt, und es wird versucht, die Feldnamen des Schemas zu übersetzen; das Ergebnis ist ein ungültiger Block. Übersetzt wird der Wert, nicht der Schlüssel.
Ein Prinzip zum Schluss: Das mehrsprachige Schema sollte ein Nebenprodukt der Übersetzungsarbeit sein, keine Erweiterung. Richtig aufgebaut erzeugt es keine zusätzliche Übersetzungslast — es trägt die bereits übersetzten Zeichenketten in die Maschinensprache. Erzeugt es zusätzliche Last, wird das Schema vom falschen Ort gespeist.