HTTP-Header, Meta-Elemente und Sprachinformationen (W3C)

Frage

Sollten wir Sprachinformationen für HTML-Dokumente in HTTP-Headern und Meta-Elementen hinterlegen, und wie unterscheiden sich diese von Sprachattributen?

Hintergrund

Neben den lang- oder xml:lang-Attributen auf dem html-Start-Tag können auf eine HTML-Seite bezogene Sprachinformationen auch in Meta-Elementen und HTTP-Headern gefunden werden. Dieser Artikel befasst sich damit, wie diese verwendet (oder nicht verwendet) werden sollten.

Beachten Sie, dass Sie in jedem Fall die lang- oder xml:lang-Attribute auf dem html-Start-Tag gebrauchen sollten (wie im Fall <html lang="en">), ebenso wie überall sonst, wo auf der entsprechenden Seite ein Wechsel der Sprache vollzogen wird. Für weitere Informationen zum Einsatz von Sprachattributen beachten Sie bitte Angabe der Sprache in HTML.

Kurze Antwort

Der HTTP-Content-Language-Header kann dazu verwendet werden, Metadaten zum avisierten Publikum einer Seite zu liefern, und mehr als eine Sprache umfassen. Der Content-Language-Wert des http-equiv-Attributs auf dem meta-Element sollte nicht länger verwendet werden. Sie sollten ein Sprachattribut auf dem html-Start-Tag einsetzen, um die Standardsprache des eigentlichen Textes der Seite zu bestimmen.

Lange Antwort

Bevor wir die zu Beginn gestellte Frage beantworten, ist es wichtig, zwischen 1) der Verwendung von Datei-Metadaten, die das Publikum eines Dokuments betreffen, und 2) der Definition der Sprache, die zur Verarbeitung von Inhalten eingesetzt wird, zu unterscheiden.

Anschließend werden wir uns der HTTP- und Meta-Deklarationen sowie ihrer Vor- und Nachteile annehmen.

Datei-Metadaten spezifizieren: die Sprache des Zielpublikums

Metadaten, die die Sprache oder Sprachen des geplanten Publikums beschreiben, befassen sich mit dem Dokument im Ganzen. Solche Metadaten können für Suchfunktionen, das Ausliefern in der richtigen Sprache, Workflow-Management, Klassifizierung &c. verwendet werden. In Fällen einer Änderung der Sprache eines Dokuments sind Informationen hinsichtlich der Sprache des Zielpublikums jedoch nicht spezifisch genug, um Text zu verarbeiten (zum Beispiel in einer Form, wie es die Anwendung von Text-zu-Sprache, Style-Anpassungen, automatischen Schriftzuweisungen &c. benötigen würde).

Die Sprache des Zielpublikums umfasst nicht jede Sprache, die in einem Dokument verwendet wird. Viele Dokumente im Web beinhalten eingebettete Fragmente von Inhalten in anderen Sprachen, auch wenn sich das Dokument klar an Sprecher einer bestimmten Sprache richtet. So kann zum Beispiel ein deutscher Stadtführer für Peking nützliche Ausdrücke auf Chinesisch beinhalten, richtet sich aber dennoch an ein deutschsprachiges Publikum, kein chinesisches.

Es ist andererseits ebenfalls möglich, dass eine Seite dieselben oder »parallele« Inhalte in mehr als einer Sprache anbietet. So kann beispielsweise eine »zweigeteilte« kanadische Webseite Leser mit Inhalten auf Französisch in der einen, und dieselben Inhalte auf Englisch in der nächsten Spalte anbieten. In diesem Fall ist das Dokument gleichermaßen an Sprecher beider Sprachen gerichtet, und somit gibt es zwei Publikumssprachen. Diese Situation ist im Web nicht so verbreitet wie im Druckbereich, da es leicht ist, für unterschiedliches Publikum auf separate Seiten zu verlinken, aber sie tritt durchaus bei mehrsprachigen Communities auf. Ein weiterer Anwendungsfall ist ein Blog oder eine News-Seite, die sich ebenfalls an eine mehrsprachige Gemeinschaft richtet, und bei dem manche Artikel auf einer Seite in einer Sprache und die nächsten in einer anderen Sprache veröffentlicht werden. So kann ein Pandschabi-Forum beispielsweise in einem einzelnen Thread Beiträge auf Englisch, Hindi und Pandschabisch beinhalten.

Dann gibt es auch Seiten, auf denen navigationsbezogene Informationen wie der Seitentitel in der einen, die Inhalte aber in einer anderen Sprache vorliegen. Auch wenn dies nicht notwendigerweise das beste Vorgehen ist, ändert es nichts an der Tatsache, dass die Sprache des Zielpublikums üblicherweise der der Inhalte entspricht und damit unabhängig von der Sprache am Beginn des Dokuments ist.

Die Textverarbeitungssprache angeben

Wenn Sie eine Sprache zwecks Textverarbeitung angeben, deklarieren Sie die Sprache, in der ein bestimmter Textbereich verfasst wurde, so dass User-Agents oder Anwendungen, die Text verarbeiten (wie Sprach-Browser, Rechtschreibprüfungsprogramme, oder Stilverarbeitungsanwendungen), den entsprechenden Textbereich effektiv handhaben können. Somit sprechen wir notwendigerweise darüber, eine einzelne Sprache mit einem spezifischen Textbereich zu verknüpfen.

Diese Spezifität dient der Unterscheidung von Sprachangaben zur Textverarbeitung von Sprachangaben zum Zielpublikum. Während das Zielpublikum Sprecher von verschiedenen Sprachen umfassen kann, kann ein bestimmter Textbereich nur eine Sprache zur Zeit behandeln.

Das lang-Attribut (oder xml:lang) sollte benutzt werden, um die textverarbeitende Sprache Ihrer Inhalte anzugeben. Dies ist der Grund, warum Sie nur eine einzelne Sprache mit diesen Attributen angeben können.

Sprachen mithilfe des `meta`-Elements angeben (nicht empfohlen)

Der Gebrauch eines meta-Elements im Dokumentenkopf (head), das das http-equiv-Attribut auf Content-Language setzt, wird nicht ausdrücklich in der HTML-4.01-Spezifikation erwähnt. Dennoch entsprach es lange Zeit einer formlosen Richtlinie, auf diesem Wege die Sprache einer HTML-Seite zu deklarieren. Einige HTML-Editoren generierten solche Elemente automatisch, wenn der Autor das entsprechende Dialogfeld ausfüllte. Es folgt ein Beispiel, das die Sprache als Englisch angibt.

 <meta http-equiv="Content-Language" content="en">

Im Gegensatz zu den lang- und xml:lang-Attributen darf der Wert des content-Attributs eine kommaseparierte Liste von Sprachbezeichnern enthalten. Das folgende Beispiel gibt (mit gleicher Priorität) Deutsch, Französisch und Italienisch als Hauptsprachen an.

 <meta http-equiv="Content-Language" content="de, fr, it">

Falls der Name des meta-Elements als Hinweis nicht deutlich genug ist, sollte die Tatsache, dass sein Wert mehrere Sprachen annehmen kann, ausreichen, um anzuzeigen, dass sich dieses Element eher um Metadaten auf Dokumentebene dreht. Wenn Sie die Sprache eines Textbereichs auf nutzbringendere Weise angeben wollen, müssen Sie spezifischer sein – es kann nur eine Sprache gleichzeitig angegeben werden. Das meta-Element bietet in diesem Sinne einen Ort, an dem innerhalb des Dokuments Metadaten zur Sprache des Zielpublikums für das Dokument als ganzes ausgedrückt werden können.

Bis vor kurzem haben einige Browser diesem Meta-Element noch Aufmerksamkeit geschenkt. Dann haben einige der populären Browser damit begonnen, dieses Element, so kein Sprachattribut auf dem html-Start-Tag gesetzt war, dafür zu verwenden, die Standardsprache der Dokumentinhalte zu bestimmen (für was eben das Sprachattribut auf dem html-Start-Tag zuständig ist). Dies wurde von Browser zu Browser auf inkonsistente Weise implementiert und erwies sich daher als unzuverlässig.

Aufgrund der Vorgeschichte mit Konfusion und inkonsistenten Implementierungen, die diese Art der Deklaration umgibt, hat die HTML-Arbeitsgruppe 2011 entschieden, das meta-Element mit dem http-equiv-Attribut auf Content-Language gesetzt als nicht spezifikationsgerecht mit HTML einzustufen. Das bedeutet, dass Sie es in HTML 5 nicht länger verwenden sollten, und damit auch, dass es, auch wenn es in anderen Formen von HTML technisch nicht »illegal« ist, am besten auch nirgendwo sonst verwendet werden sollte.

HTML 5 hat jedoch Zugeständnisse hinsichtlich Abwärtskompatibilität gemacht. Wenn im Markup ein meta-Element mit dem http-equiv-Attribut auf Content-Language gesetzt und kein Sprachattribut auf dem html-Start-Tag vorliegt, darf ein Browser – muss er aber nicht – diese Information verwenden, um die Sprache des Textes auf der Seite zu »erraten«. Dies dient wie gesagt nur der Abwärtskompatibilität, und Sie sollten diese Lösung nicht mehr wählen. Verwenden Sie einfach ein Sprachattribut auf dem html-Start-Tag.

Eine Folge davon, dass HTML 5 das meta-Element aufgibt, um Sprachangaben zu treffen, ist, dass es nun keinen offensichtlichen Weg gibt, um Metadaten zu einem Dokument innerhalb des Dokuments selbst anzugeben. Zum Zeitpunkt des Verfassens dieses Artikels ist es schwer, Beispiele für die Verwendung solcher Metadaten zu finden, obwohl diese theoretisch nützlich für Content-Management-Systeme, Übersetzungsprozesse und ähnliches wären. Sprachinformationen können mittels eines HTTP-Headers übermittelt werden (wie wir im nächsten Abschnitt sehen werden), aber besagte Systeme und Prozesse werden durchaus von Servern angeboten, die keine speziellen Header übertragen, was Metadaten innerhalb der Dokumente nützlich macht.

Eventuell bietet ein anderer Ansatz wie RDFa eine Möglichkeit, solche Informationen in der Zukunft zu vermitteln.

Dublin Core auf dem meta-Element: Da HTML 4 wenige Bestimmungen vorgibt, wie das meta-Element verwendet werden sollte, ist es nicht üblich, aber möglich, Anwendungsfälle zu finden, in denen es verwendet wird, um Sprachinformationen mittels Dublin Core-Notation zu hinterlegen. Es scheint allerdings nicht so, dass auf diese Informationen von Browsern tatsächlich zugegriffen wird, und es ist unklar, zu welchem Umfang sie von anderen Anwendungen gebraucht werden.

 <meta name="dc.language" content="en">

Sprache im HTTP-Header spezifizieren

Sprachinformationen können außerdem im Content-Language-HTTP-Header vorgefunden werden, welcher vom Server mit Abfrage des Dokuments mit selbigem gesendet wird. Diese Informationen werden mit der entsprechenden Seite mittels Server-Einstellungen oder -Scripting verknüpft. Beachten Sie die letzte Zeile im untenstehenden Beispiel, welches die HTTP-Antwort auf diesen Artikel darstellt (Anmerkung des Übersetzers: auf den Originalartikel bezogen).

HTTP/1.1 200 OK
Date: Sat, 23 Jul 2011 07:28:50 GMT
Server: Apache/2
Content-Location: qa-http-and-lang.en.php
Vary: negotiate,accept-language,Accept-Encoding
TCN: choice
P3P: policyref="https://www.w3.org/2001/05/P3P/p3p.xml"
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8
Content-Language: en

Genauso wie im Fall von meta-Element mit seinem http-equiv-Attribut auf Content-Language gesetzt, kann der Wert des HTTP-Headers einer kommaseparierten Liste von Sprachdeklarationen entsprechen. Die HTTP-Spezifikation stellt klar, dass es das Ziel dieser Informationen ist, Metadaten über das Zielpublikum zu liefern.

Wenn keine Sprache auf dem html-Start-Tag angegeben wird, erkennen einige (aber nicht alle) der meistverbreiteten Browser den im HTTP-Header angegebenen Wert als den der Standardsprache des Textes auf der entsprechenden Seite an. Selbst in einem Browser, der so funktioniert, wird die gewonnene Information jedoch nur auf einige, nicht auf alle von Sprachinformationen betroffenen Funktionen angewandt. Die HTML-5-Spezifikation sagt, dass wenn kein lang-Attribut auf dem html-Tag angegeben wurde, und wenn kein meta-Element mit einem auf Content-Language gesetzten http-equiv-Attribut vorliegt, und wenn es nur eine einzige Sprachangabe in der HTTP-Header-Deklaration gibt, ein Browser diese Information verwenden darf, um die Standardsprache des Textes zu erraten.

Da Sie immer ein Sprachattribut auf dem html-Start-Tag verwenden sollten, und dieses Sprachattribut die Informationen im HTTP-Header immer überschreibt, wird dies jedoch zu einem wichtigen Punkt. Der HTTP-Header sollte nur dazu verwendet werden, Metadaten über das beabsichtigte Publikum des Dokuments als ganzem anzugeben, und das Sprachattribut auf dem html-Tag sollte eingesetzt werden, um die Standardsprache des Inhalts zu deklarieren.

Literaturhinweise

Erste Schritte: Sprachangaben im Web
Tutorial: Umgang mit Sprachangaben in HTML
Verwandte Links: HTML und CSS bearbeiten – Sprache – Metadaten zur Sprache des Zielpublikums deklarieren