Frage zu Meta-Daten / Meta-Tags

[fragenkopf]

Guten Tag Forenteilnehmer,

:)

ich setze gerade für eine Bekannte zum Freundschaftspreis eine Website um.

Da ich die HTML/XHTML-Umsetzung nicht täglich mache muss ich mich in manches immer wieder reinarbeiten.

Heute: Meta-Tags.

:)

Ich habe diese aufgrund der Informationen hier (und anderswo) und aus einem alten Dokument eines anderen Projekts übernommen.

Die Seite ist 5-sprachig. Deswegen habe ich bei der aktuellen Site mehr auf Sprachangaben geachtet als sonst.

Als ich nun mit diversen Meta-Checkern im Web überprüfen wollte ob das was ich da metagetaggt habe auch was taugt war ich überrascht und verwirrt.

Manche sagen mir ich hätte keine language-tags!?

Ich ging davon aus diese korrent angegeben zu haben.

z. B.

<meta http-equiv="content-language" content="de">

Bei der Recherche bin ich aber auch darauf gestoßen dass manche der Meinung sind die Sprache sollte so angegeben werden:

<meta name="language" content="de">

Ist beides richtig? Wo ist der Unterschied?

Ich bin etwas verwirrt deswegen.

Hier in der SELFHTML-Doku steht nichts von
<meta name="language" content="de">

Vielleicht kann ja von Euch jemand Lichts ins Dunkel meines Kopfes bringen?

[Gunnar Bittersmann]

@@fragenkopf:

nuqneH

Die Seite ist 5-sprachig.

?? Die Seite oder die Website?

<meta http-equiv="content-language" content="de">

Die Sprache(n) de Zielpublikums. Die Sprache des Texts/Textabschnitts wird mit @lang (@xml:lang) angegeben.

Vielleicht kann ja von Euch jemand Lichts ins Dunkel meines Kopfes bringen?

http://www.w3.org/International/tutorials/language-decl/#Slide0060

Qapla'

[fragenkopf]

@@fragenkopf:

nuqneH

Die Seite ist 5-sprachig.

?? Die Seite oder die Website?

Die Website ist fünfsprachig

einzelne Seiten dann einsprachig.

:)

<meta http-equiv="content-language" content="de">

Die Sprache(n) de Zielpublikums. Die Sprache des Texts/Textabschnitts wird mit @lang (@xml:lang) angegeben.

Hmmm. Besucher die sich über die Navigation zu den französischen Seiten begeben haben bekommen html-Dokumente mit kompletten französischen Texten. Ohne irgendwelche Textabschnitte in anderen Sprachen.

Zielpublikumssprache = Sprache des Textes (komplett).

Merci.

[Gunnar Bittersmann]

@@fragenkopf:

nuqneH

Hmmm. Besucher die sich über die Navigation zu den französischen Seiten begeben haben

Da sollen sie möglichst automatisch hinkommen, ohne vorher eine anderssprachige Seite zu Gesicht zu bekommen. (Der verlinkte Artikel ist selbst ein Beispiel dafür, du wirst ihn vermutlich automatisch auf deutsch angezeigt bekommen.)

Zielpublikumssprache = Sprache des Textes (komplett).

Also beides angeben: Zielpublikumssprache per meta @http-equiv="content-language"; Sprache des Textes per html @lang/@xml:lang.

In HTML5 ist ersteres übrigens gegenwärtig nicht mehr vorgesehen. Angesichts der Beratungsresistenz der HTML5-Macher ist es auch zweifelhaft, ob sich das noch zum Bessern ändert.

Qapla'

[molily]

Zielpublikumssprache per meta @http-equiv="content-language"; Sprache des Textes per html @lang/@xml:lang.

In HTML5 ist ersteres übrigens gegenwärtig nicht mehr vorgesehen. Angesichts der Beratungsresistenz der HTML5-Macher ist es auch zweifelhaft, ob sich das noch zum Bessern ändert.

Vielleicht gibt es gute Gründe dafür?

In der Praxis hat diese Angabe meines Wissens keinen Wert. Sie fließt nicht in die Content-Negotiation ein. Content-Language drückt nicht aus, ob das Dokument in weiteren Sprachen verfügbar ist, und wenn ja, in welchen der Server das Dokument vielleicht ausgeliefert hätte, wenn der UA andere Sprachen akzeptiert hätte. Es ist kein »Vary: Accept-Language«.

Wenn man angeben will, dass ein spezifisches Dokument auch in anderen Sprachen verfügbar ist, sollte man brauchbare Metadaten angeben. Damit lassen sich solche Verhältnisse exakt ausdrücken:

<link href="http://www.example.org/nl/" rel="alternate DC.relation" hreflang="nl">

<a href="http://www.example.org/nl/" rel="alternate DC.relation" hreflang="nl" lang="nl">Deze pagina in het Nederlands</a>

Hier ist klar, dass eine Alternativ-Version in einer anderen Sprache vorliegt, und der Nutzer kann sie öffnen.

Zu was hingegen nützt http-equiv=Content-Language? Es gibt wohl wenige Fälle, wo Content-Language überhaupt von html@lang abweicht und mehrere Spachen angegeben werden, weil das Dokument tatsächlich gleichwertig für Sprecher beider Sprachen interessant ist (z.B. weil derselbe Text im selben Dokument in mehreren Sprachen steht - aber warum sollte man das tun?).

Daher sehe ich das bloß als recht überflüssige, sehr unkonkrete Metadaten; aber ich lasse mich gerne vom Gegenteil überzeugen. Warum sollte ich sie angeben, mal angesehen davon, dass es möglich ist?

Mathias

[Gunnar Bittersmann]

@@molily:

nuqneH

Zu was hingegen nützt http-equiv=Content-Language?

Die Frage stellt sich wohl bei so ziemlich allen Metadaten. Und irgendwann sind sie doch mal nutzlich.

Warum sollte ich sie angeben, mal angesehen davon, dass es möglich ist?

Die Frage stellt sich anders: Warum sollst du sie nicht angeben können, wenn du es für sinnvoll erachtest?

Warum maßt sich die WHAT WG an, das Web neu zu erfinden und Bestehendes abzuschaffen, nur weil die den Sinn nicht erkennen?

Übrigens kann man die Sprache(n) des Zielpublikums natürlich weiterhin im HTTP-Header angeben, lediglich die HTTP-EQUIV-Angabe im Dokument soll in HTML5 nicht mehr möglich sein. Sinnvoll?

Und ich hab auch gerade keine Lust, mich durch die schwer verdauliche Kost der HTML5-Spec zu wühlen und nachzusehen, wie sich ein HTML5-Parser verhalten soll, wenn er doch auf verbotenes <meta http-equiv="Content-Language" content="de"> stößt.

Qapla'

[molily]

Warum maßt sich die WHAT WG an, das Web neu zu erfinden und Bestehendes abzuschaffen, nur weil die den Sinn nicht erkennen?

Man sollte nicht nur Fragen stellen, sondern ihnen auch auf den Grund gehen.

Es war nicht die WHATWG, sondern die W3C HTML WG hat hier ganz offiziell nach ihren geltenden Verfahren entschieden:
http://lists.w3.org/Archives/Public/public-html/2011Mar/0398.html

Das Grundproblem hier scheint zu sein, dass
1. viele bestehende Dokumente http-equiv="Content-Language" entgegen der in HTTP spezifizierten Bedeutung, stattdessen im Sinne von html@lang zur Angabe der Textsprache verwenden,
2. viele UAs http-equiv="Content-Language" in diesem Sinne verarbeiten, um die Textsprache zu extrahieren, wenn html@lang nicht angegeben ist.

Grundfrage ist also, wie mit dieser Situation umzugehen sei.

Es gab drei Change Proposals mit Abstimmung, wobei Ian Hickson gleich zwei entgegengesetzte vorgelegt hat. Zu allen hat sich auch die W3C I18n WG ausgelassen (bist du da nicht aktiv und sitzt näher an der Quelle?).

Übrigens kann man die Sprache(n) des Zielpublikums natürlich weiterhin im HTTP-Header angeben, lediglich die HTTP-EQUIV-Angabe im Dokument soll in HTML5 nicht mehr möglich sein. Sinnvoll?

Sie sind in der Praxis eben nicht äquivalent (s.o.). Und waren es vermutlich auch nie (http-equiv war ursprünglich als Anweisung für HTTP-Daemons gedacht, wurde aber nie so verarbeitet).

Natürlich kann man sich hier auf den Standpunkt stellen, den UAs einfach vorzuschreiben, dass sie die Spracherkennung auf Basis von http-equiv="Content-Language" ausbauen sollen, wie es die I18n WG getan hat:

»We would prefer that the CP [to let multiple language tags continue to be legal] be modified so that browsers must not guess at the default language for the page by looking at the HTTP headers and/or meta elements. This would result in a CP that does not remove or change the http-equiv information (as the "non-conforming" CP proposes) but would render it harmless.«

Aber das würde vor allem dazu führen, dass unzählige Sites plötzlich bspw. nicht mehr von Screenreadern vorgelesen werden können, weil nur http-equiv="Content-Language" angeben. Kein UA wird das, was momentan ein wichtiges Feature ist und von Webautoren tausendfach eingesetzt wurde, plötzlich ausbauen. Das nur als Vorgeschmack auf die langen und kontroversen Diskussionen in der HTML WG.

Alles in allem ist das eine sehr verfahrene Situation, in der jede Entscheidung einige Vorteile hat und gleichzeitig schwerwiegende Probleme nach sich zieht. Ehrlich gesagt finde ich die von den Chairs getroffene Entscheidung recht salomonisch. Sie soll die Webautoren darauf hinweisen, dass UAs diese Angabe gänzlich unterschiedlich und nicht im Sinne von HTTP verarbeiten und dass die Dokumentsprache gefälligst korrekt in html@lang angegeben werden soll.

Gleichzeitig können vorhandene Implementierungen http-equiv="Content-Language" verwenden, um die Sprache von Dokumenten ohne html@lang festzustellen (so war es ja auch halbwegs in HTML 4.01 spezifiziert). Insofern ist http-equiv="Content-Language" nun »deprecated« (auch wenn es den Begriff in HTML5 nicht gibt): Es wird von einem HTML-Parser in der verbreiteten Weise verstanden, ist aber nicht konform.

Die I18n WG hat sich im Übrigen damit einverstanden erklärt:

»It really is a requirement that HTML5 clearly specify if (and if so, how the) HTTP Content-Language and/or the Content-Language pragma is assigned to html@lang when html@lang is itself not present. The I18N WG could accept language specifying the assignment of the (unmodified) Content-Language syntax header/pragma to html@lang, as long as such an assignment were completely unambiguous, although we really would prefer that no such linkage is created.«

Wie offensichtlich geworden sein sollte, soll mit dieser Enscheidung nicht den Webautoren eine Möglichkeit genommen werden, Metadaten auszudrücken. Wäre http-equiv="Content-Language" bloß eine harmlose Meta-Angabe, deren Verwendung keinerlei negative Folgen hätte, bestünde tatsächlich kein Grund zum Handeln. Das ist aber nicht der Fall. Das wusste ich auch nicht und habe mich daher nur zu der Sinnhaftigkeit der Angabe der Sprache des Zielpublikums ausgelassen. Diese Bedeutung hat http-equiv="Content-Language" in der Praxis aber nicht, was mir nicht bekannt war.

Und ich hab auch gerade keine Lust … nachzusehen, wie sich ein HTML5-Parser verhalten soll, wenn er doch auf verbotenes <meta http-equiv="Content-Language" content="de"> stößt.

Ein einfaches Strg + F »Content-Language« über die Spec oder die WG Decisions wäre natürlich auch zu schwierig gewesen.

Fürs Protokoll:
http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#attr-meta-http-equiv-content-language
vgl. auch http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#attr-lang

Kurz gesagt:
Ist kein html@lang angegeben und enthält http-equiv="Content-Language" einen einzigen Language-Tag, so verwende diesen als Dokumentsprache.

Also das, was viele UAs derzeit tun, was viele Webautoren bisher erwartet haben und worauf viele existierende Dokumente vertrauen. Aber: Da die verbreitete Verwendung inkonsistent mit der Definition von Content-Language in HTTP ist und die Verarbeitung durch UAs inkonsistent ist, ist es nun nicht konform, die Angabe zu machen.

Mathias

[molily]

<meta http-equiv="content-language" content="de">

Die Sprache(n) de Zielpublikums. Die Sprache des Texts/Textabschnitts wird mit @lang (@xml:lang) angegeben.

Wie kann sich der Text in einem Dokument an ein Publikum wenden, das nicht die Sprache des Textes versteht?

Okay, also die in @lang angegebene Sprache taucht sinnvollerweise immer in Content-Language auf.

Damit zudem Sprecher anderer Sprachen zum Zielpublikum gezählt werden können und die Sprache somit in Content-Language aufgeführt werden kann, sollte ein signifikanter Teil des Dokument-Textes in deren Sprache verfasst sein.

Solche Fälle sind doch unglaublich selten, oder? Da fällt mir höchstens ein mehrsprachiger poetischer Text ein, der von Sprechern beider Sprachen halbwegs verstanden werden kann. Oder der Text richtet sich an Menschen, die beide Sprachen beherrschen. Letzteres trifft wohl auf viele philologische Texte zu, z.B. ein deutscher Text über englische Literatur, dabei sind große Textteile in @lang=en.

Der andere besagte Fall – derselbe Text in mehreren Sprachen in einem Dokument – würde man in der Praxis vermeiden, indem man mehrere Dokumente anlegt und per Content-Negotiation die gewünschte Version ausliefert.

Wenn Content-Language nur angibt, was ohnehin in @lang steht, kann man es auch weglassen.

Mathias

[Gunnar Bittersmann]

@@molily:

nuqneH

Okay, also die in @lang angegebene Sprache taucht sinnvollerweise immer in Content-Language auf.

Nicht immer.

Da fällt mir höchstens ein mehrsprachiger poetischer Text ein, der von Sprechern beider Sprachen halbwegs verstanden werden kann.

Oder der Sinn der Seite besteht gerade darin, Original und Übersetzung gegenüberzustellen (Beispiele).

Der andere besagte Fall – derselbe Text in mehreren Sprachen in einem Dokument – würde man in der Praxis vermeiden

Sollte man, ja. Leider findet man auch Beispiele von mehrsprachigen Seiten, auf denen derselbe Inhalt in verschiedenen Sprachen neben-/untereinander geklatscht wurde und sich der Nutzer das für ihn Verständliche erst aus einem Wust von ihm unverständlichem Inhalt raussuchen muss.

Qapla'

[Cheatah]

Hi,

Guten Tag Forenteilnehmer,

:)

interessante Absatzmarkierung ;-)

Manche sagen mir ich hätte keine language-tags!?

Die Formulierung hast Du vermutlich geändert - ein "language-tag" wäre nämlich <language>, und das ist wohl nicht gemeint. Interessant wäre also, was Dir das jeweilige Prüfsystem exakt mitgeteilt hat.

Ich bin etwas verwirrt deswegen.

Gunnar meinte übrigens die Attribute im <html>-Tag.

Cheatah

[Gunnar Bittersmann]

@@Cheatah:

nuqneH

ein "language-tag" wäre nämlich <language>

Oh, mal wieder eine der seltenen Gelegenheiten, dir zu widersprechen. ;-)

Ein „language tag“ (ich hab das mit „Sprachkennzeichnung“ übersetzt) wäre nämlich 'de' oder 'en-US' oder 'es-419' oder 'sr-Latn'. Darin enthalten jeweils ein „language subtag“ („Sprachkürzel“): 'de', 'en', 'es', 'sr'.

Gunnar meinte übrigens die Attribute im <html>-Tag.

Ja, und ggfs. nicht nur dort.

Qapla'