Webstandards/Internationalisierung

Aus SELFHTML-Wiki
Wechseln zu: Navigation, Suche

Inhaltsverzeichnis

Bewusstsein

Im WWW gilt eine von zwei Tatsachen:

  • Eine Website in einer Sprache wird einem internationalen Publikum vorgesetzt.
  • Eine Website mit Inhalten in mehreren Sprachversionen wird einem internationalen Publikum vorgesetzt.

Internationalisierung von Webinhalten geht also alle an. Selbst wenn Sie sicher sind, dass alle Empfänger Ihrer Daten in Ihrer Sprache kommunizieren, sollten Sie Internationalisierung nicht missachten.

Wenn Ihre Website einsprachig ist, fallen die Bemühungen global betrachtet minimal aus. Lediglich bei Sprachwechseln von eingebetteten fremdsprachlichen Texten müssen Sie diese speziell markieren.

Wenn Ihre Website mehrsprachig ist, haben Sie nicht nur die Qual der Übersetzung, Sie müssen auch die client-seitige Anforderung bestimmter Sprachversionen richtig verwalten.

Dieses Dokument will Ihnen wichtige Punkte vor Augen führen, bevor Sie das Unternehmen mehrsprachige Website beginnen. Internationalisierung ist aber ein umfassendes Gebiet. Das W3C unterhält deshalb eine eigene Website, welche alle Aspekte der Internationalisierung berührt: http://www.w3.org/International/.

Warum Sprachdeklarationen sinnvoll sind

Jedes Textdokument ist in einer Hauptsprache geschrieben. Die Deklaration der Sprache im Dokument erlaubt es User-Agents oder assistierender Software wie Screenreadern, den Text angemessen zu präsentieren. Bei Suchdiensten stellt die Dokumentsprache ein mögliches Filterkriterium dar. Eine Deklaration der Hauptsprache umgeht eine ungünstige Heuristik seitens des Dienstes zur Erkennung der Sprache.

In einem Dokument können Sprachwechsel stattfinden. Jeder Sprachwechsel sollte von der behandelten Software ebenso korrekt erkannt werden. Sprachwechsel liegen nicht nur bei größeren Passagen wie fremdsprachlichen Zitaten oder übersetzten Abschnitten vor, sondern vor allem durch die in der Netzkultur sehr häufigen Fremdworte.

Screenreader stellen für einen Autor ein gutes Instrument dar, um die Effizienz von Sprachdeklarationen zu prüfen, denn ohne Hilfe können diese ein fremdsprachliches Element nicht verständlich wiedergeben. Übersetzungstools können mit einem Text besser umgehen, dessen Teile sprachlich korrekt ausgezeichnet wurden.

Das Sprachverständnis der Gäste

Internet-User können in aller Regel bei ihren User-Agents präferierte Sprachen vorkonfigurieren. Sie nutzen aber diese Möglichkeit nicht immer oder tun das manchmal mit falschen Prämissen. Wesentlich im WWW ist, wie gut jemand eine Sprache lesend verstehen kann. Das Vermögen, eine Sprache zu schreiben, sie zu sprechen oder sie hörend zu verstehen, kann davon sehr abweichen und für jede Fremdsprache wiederum anders ausfallen.
Wird eine Zusatzsoftware wie ein Screenreader verwendet, kommen zusätzliche Erschwernisse hinzu. Screenreader können nur zwischen einer beschränkten Zahl von Sprachen umstellen. Den besten Umgang mit Text kann man sich vergegenwärtigen, wenn man sich diesen vorlesen lässt, denn die Aussprache trägt wesentlich zum Verständnis bei.

Ihre Gäste kommen normalerweise nicht mit der Erwartung auf Sprachversionen auf Ihre Seite. Sie müssen bei Sprachversionen aktiv propagieren. Dafür haben sich Konventionen herausgebildet, wo Ihre Leser diese zuerst suchen: Visuell oben rechts, oder seltener im Fußbereich.

Wenn Gäste eine Sprachwahl aktiv getroffen haben, möchten sie gerne allen weiteren Inhalt in dieser Sprache, sofern verfügbar. Da dies nicht immer möglich ist, weil Übersetzungen manchmal nicht vorhanden sind, sollte ein Leser darüber informiert werden, dass die gewünschte Version nicht verfügbar ist, und es sollte ihm die aus seiner Sicht beste Alternative geboten werden.

Übersetzungen sollten adäquat sein. Sie machen Ihren Lesern keine Freude, wenn Sie missverständliches Deutsch ausliefern, wenn Ihr Leser das unmissverständliche Englisch als Fremdsprache sehr gut versteht.

Wenn Ihre Besucher schreiben dürfen, erlauben Sie ihnen, Sie in der Sprache ihrer eigenen Wahl anzuschreiben. Sie dürfen Ihre Gäste fragen, in welcher Sprache der Text im Formular verfasst ist.

Internationalisierung und Lokalisierung

Internationalisierung ist der Vorgang, Inhalte für einen internationalen Kontext aufzubereiten. Lokalisierung ist die konkrete Auswahl einer Version aus dem internationalisierten Angebot. Sie finden zuweilen die Kürzel i18n (i + 18 Buchstaben + n) für internationalisation und l10n (l + 10 Buchstaben + n) für localisation.

Desktop-Programme können in einer Sprache installiert werden. Es wird also ein Locale einmalig angewendet. Im WWW geschieht jedoch dieser Vorgang bei jedem Request auf eine internationalisierte Ressource. Deshalb bedingt die Verfolgung des gewünschten Locales durch den Gast einer Website eine permanente Beobachtung. Nicht die Internationalisierung an sich, sondern die Lokalisierung erfordert, dass der Server eine Logik anwendet. Eine User-Session ist das verbreitete Modell, um die Sprachwahl des Users zu verwalten.

Lokalisierung ist im WWW sehr beschränkt möglich und beschränkt sich eigentlich auf die Sprache allein. Es gibt keine Möglichkeit, Zeitzonen oder Maße zu lokalisieren. Das hat seinen Hauptgrund darin, dass Sprachen nichts mit Ländern zu tun haben, und somit alle landesspezifischen Lokalisierungen nicht in den verfügbaren Technologien implementiert sind.

Die in einem System von einem Locale abhängigen Parameter erstrecken sich über einen weiten Bereich. Nur sehr wenige davon lassen sich im WWW steuern.

  • Datum- und Zeitformat
  • Zeitzone/Sommerzeit
  • Numerische Werte (verschiedene Fließkomma, und Tausender-Trennzeichen)
  • Standardmaße
  • Währungsformat
  • Alphabetische Sortierung
  • Anführungsstriche für Zitate
  • ursprüngliche Leserichtung (Layout)
  • Verschiedene Konventionen zur Text-Hervorhebung

User-Agents negieren oft eine Beeinflussung dieser Parameter. Die Software, welche Daten erstellt und ausliefert, mag hingegen von einem Locale abhängig sein. Zum Beispiel operieren alle Server in einer bestimmten Zeitzone, oder geben Daten in einer bestimmten Form alphabetischer Sortierung aus.

Sie können einige Probleme lösen, indem Sie das lokale indizieren (z.B. die Zeitzone bei Zeitangaben explizit erwähnen), oder eine Technik anwenden, welche sprachabhängige Anzeige erlaubt (z.B. die Anführungszeichen sprachabhängig mittels CSS definieren statt sie fest im HTML zu schreiben).

Typographische Feinheiten im Text (welche Art Leerzeichen oder Bindestrich) sind ebenfalls tendenziell inkompatibel zur Internationalisierung, da die typographische Gestaltung wiederum stark vom Locale abhängig ist.

Praxis

Sprachen maschinenlesbar deklarieren

Damit Maschinen Sprachangaben verstehen können, braucht es einen einheitlichen Standard.

IANA verwaltet die Sprachkürzel in einer Liste, die regelmäßig aktualisiert wird. Diese auch als Language-Tags bezeichneten Kürzel bezeichnen in ihren einfachen Formen Sprachgruppen (z.B. de für Deutsch insgesamt) oder mit Ergänzung eine Unterklasse der Sprache (de-CH für Schweizerdeutsch). Manche Sprachen können in verschiedenen Schriften geschrieben sein (wie z.B. Bulgarisch in Lateinisch oder Kyrillisch). Auch hierfür gibt es wiederum spezielle Tags für die Schrift.

All diese Angaben sind relevant für die Sprachangaben, jedoch gilt es bei der Verwendung einiges zu beachten:

  • Ein deutscher Leser aus der Schweiz mag sich mit Deutsch insgesamt zufrieden geben. Sein Browser mag aber de-CH bevorzugen. Ob Sie nun mit einem als de oder als de-DE deklarierten Inhalt antworten, ist für das allgemeine Verständnis in diesem Fall unproblematisch. Dennoch erlaubt zum Beispiel CSS explizit verschiedene Anführungszeichen für verschiedene Sprachen und Sprachdialekte. Wenn Sie Texte nach deutscher Rechtschreibung ausliefern, können Sie auch dazu stehen in Bezug auf die Sprachdeklaration im Dokument.
  • Wenn Sie eine Sprachauswahl bereitstellen, sollten Sie ohne speziellen Grund nur allgemein Deutsch und nicht einen Dialekt anbieten.
  • Wenn Sie jedoch Sprachen in Schriften anbieten, für die es Alternativen gibt, erwähnen Sie diese Schrift im Sprachwahlmenu.


Wieviel Übersetzung darf es denn sein?

Jedes Textdokument ist in genau einer Hauptsprache geschrieben. Dies verbietet aber in keiner Weise sekundäre Sprachen im gleichen Dokument.

Auszeichnungssprachen können mehrsprachentauglich sein. Diese Fähigkeit erschöpft sich aber meist ab einem bestimmten Grad.

Wieviel Sprachwechsel ist möglich

Textformate wie HTML ermöglichen Sprachwechselmarkierungen im Dokument. Aber nicht alle Elemente erlauben den Sprachwechsel.

Beispiel ansehen …
<html lang="en">
<head>
  <title>English Text with German Translation</title>
</head>
<body>
  <h1>
    <span>Header in English</span>
    <span lang="de">Überschrift in Deutsch</span>
  </h1>
</body>
</html>
Das title-Element darf nur einmalig sein und keine anderen Elemente enthalten. Sprachwechsel sind deshalb nicht möglich.

Weil das html-Element ebenfalls einmalig ist und das lang-Attribut genau ein IANA-language-tag aufnehmen darf, gilt die gesamte HTML-Dokument-Hauptsprache als Englisch.

Deshalb wäre eine Angabe des Attributs im englischsprachigen Header redundant und kann weggelassen werden. Es ist jedoch kein Fehler, wenn Sie es dennoch notieren.

Wie viele Sprachwechsel sind sinnvoll

Wenn wir wie oben festgestellt einen Screenreader vor Ohren haben, so lässt sich am besten entscheiden, wieviel Sprachwechselmarkierungen sinnvoll sind.

Beispiel
<p>Die wichtigste Sprache im 
  <span lang="en">WorldWideWeb</span> 
  (<abbr>WWW</abbr>) 
ist zweifellos 
  <abbr>HTML</abbr> 
  (<span lang="en">hypertext markup language</span>).
</p>
Warum sind die Abkürzungen nicht mit Sprachattributen versehen? Weil ein Screenreader dem Deutsch-Hörer ein /ˈdʌbəljuː ˈdʌbəljuː ˈdʌbəljuː/ oder ein /ˈeɪtʃ ˈtiː ˈɛm ˈɛl/ vorlesen würde, was dieser unzweifelhaft schlechter verstehen würde.
<p>Das 
  <span lang="en">Intergovernmental Panel on Climate Change 
  (<abbr>IPCC</abbr>)
  </span> 
erhitzt dank seiner umstrittenen Datensammlung vor allem die Köpfe.</p>
Es ist pure Konvention, aber die Medien kolportieren eher eine /ˈaɪ ˈpiː ˈsiː ˈsiː/-Aussprache auch in deutschen Landen.

Die obigen Beispiele zeigen, dass es nicht einmal für Abkürzungen eine allgemeine Regel geben kann, in welcher Sprache man sie markiert. Übersetzungen und Auszeichnungen verlangen nach Einzelfallbehandlung.

Content-Negotiation

Das HTTP-Protokoll sieht vor, dass der Client im Feld Accept-Language eine Liste von präferierten und gewichteten Sprach-Tags senden kann. Darauf beruht die Möglichkeit, dass ein Server Inhalte in einer geeigneten Sprachversion ausliefern kann.

Content-Negotiation sollte ein Instrument bei Erstkontakt sein. Sie sollte aber bei weiteren Subrequests entfallen. Der Grund ist, dass eine Sprachwahl des Users auf der Seite mehr Gewicht haben sollte, als ein Default, der im User-Agent gesetzt ist. Dieser Default könnte in einigen Situationen auch unzutreffend sein (Bsp. Internet-Café, ein Browser im Hotel oder an der Uni).

In folgenden Fällen darf keine Content-Negotiation stattfinden:

  • Der User hat bereits eine manuelle Sprachwahl über ein Menu ausgeführt. Diese Wahl ist auf dem Server zu speichern oder muss in alle Links eingearbeitet sein, bis der User eine neue Wahl ausführt.
  • Es wurde ein Link getätigt, dessen URI bereits eine Sprachversion indiziert.

Content-Negotiation sollte aber dann temporär wieder ausgeführt werden, wenn zwar eine Sprachversion seitens des Users auf dem Server gespeichert ist, aber für einen konkreten Inhalt derselbe in dieser Sprache temporär nicht verfügbar ist. Auch mehrsprachige Websites sind oft nicht in allen ihren Komponenten konsequent mehrsprachig.

Bei Content-Negotiation über das Accept-Language Attribut sind einige technische Klippen zu beachten.

  • Ein Client könnte de-CH präferieren, der Server bietet aber nur die Versionen en und de an. Language-Subtags wie de-CH sollten so behandelt werden, als würde der Client das einfache Language-Tag übermitteln.
  • Ein Client könnte de-CH und de senden, der Server bietet aber nur die Versionen en und de an. Es ist das höher gewichtete Tag aus de-CH und de zu verwenden.
Beachten Sie: Content-Negotiation setzt voraus, dass die ausgelieferte sekundäre Sprachversion keinesfalls in einer minderen Qualität ist, als die originale Sprachversion der Site. Eine schlechte Übersetzung kann eventuell schlechter verstanden werden als ein gutes fremdsprachliches Original. Generell gilt, dass Menschen Fremdsprachen eher korrekt lesen können, als sie in dieser schreiben können.

Sprachauswahl-Menu

Warum Sprachen nichts mit Länderflaggen zu tun haben

Ein populärer Irrtum ist es, Sprachwahl durch Flaggen visuell darzustellen. Eine Sprache hat aber nichts mit Ländern und somit auch nichts mit Flaggen zu tun.

  • Die Schweiz hat 4, Südafrika 11, Indien gar 23 Amtssprachen.
  • Englisch ist die de-facto Amtssprache im Vereinigten Königreich und den USA, jedoch in beiden Staaten keine offiziell festgelegte Amtssprache.
  • Flaggen werden zuweilen obsolet und abgelöst durch andere Flaggen.
  • In welchem Land wird Latein oder Esperanto gesprochen?

Bei Inhalten in mehreren Sprachen ist die Auswahl über ein Menu essentiell wichtig. Es ist zu beachten, dass sich hierbei eine Konvention herausgebildet hat. Die meisten großen Websites platzieren die Sprachauswahl visuell oben links und logisch sehr früh, allenfalls mit vorangehenden Skiplinks. Es ist ebenso wichtig, dass eine Sprachwahl über die ganze Site konsistent am gleichen Ort gefunden wird.

In der Sprachauswahl wollen wir Menschen in der Sprache ansprechen, die sie selbst verstehen und deren Schreibweise sie erkennen.

Es geschieht öfters, dass Anwender am Mobiltelefon die Sprachauswahl umstellen, und dann ihr Gerät nicht mehr wiedererkennen. Für einen Deutsch Sprechenden ist ein wörtliches Deutsch in einem ansonsten kyrillischen Buchstabensalat ein Rettungsring, vorausgesetzt, er findet diese Spracheinstellung in jeder Situation.

Ein Menu könnte folgende Sprachversionen enthalten:

Beispiel: HTML Sprachwahl-Formular
<html lang="de">
...
<form action="" method="get">
  <p>
    <label for="language">Diese Seite 
       in einer anderen Sprache:</label>
    <select id="language">
      <option lang="en" value="en">English</option>
      <option lang="es" value="es">Español</option>
      <option lang="fr" value="fr">Français</option>
      <option lang="re" value="ru">Русский</option>
      <option lang="ar" value="ar">العربية</option>
    </select>
    <input type="submit" value="Ändern">
  </p>
</form>
...
</html>
Angezeigt werden die Sprachbegriffe in der jeweiligen Landessprache. Das Formular übermittelt jedoch die IANA-Language-Tags.

Dieses Beispiel beinhaltet jedoch einen beachtlichen Nachteil: Das select-Feld versteckt die für einen nach seiner Sprache Suchenden Option. Dies stellt die Frage, wie man ein dem Feld den Sinngehalt einer Sprachwahl vermitteln kann.

Nicht ohne Grund hat sich die Wikipedia für eine Linkliste entschieden.
<html lang="de">
...
<h4>Diese Seite in einer anderen Sprache</h4>
<ul>
  <li><a hreflang="en" lang="en" href="?lang=en">English</a></li>
  <li><a hreflang="fr" lang="fr" href="?lang=fr">Français</a></li>
  <li><a hreflang="es" lang="es" href="?lang=es">Español</a></li>
</ul>
...
</html>
Wenn Sie nur wenige Sprachversionen darstellen müssen, können Sie auch die Sprachkürzel als horizontale Linkliste darstellen.

Eine Liste der korrekten Schreibweisen von Sprachnamen finden Sie in der Liste der IANA-Sprachkürzel. Die von Mediawiki unterstützte Untermenge finden Sie unter Referenzen: Sprachkürzel

URIs bei mehrsprachigen Websites

Warum sich Toplevel-Domains nicht als Language-Tags eignen

Toplevel-Domains bezeichnen entweder landesspezifische Domains, und es trifft darauf zu, was über Flaggen und Sprachen gesagt wurde, oder sie bezeichnen nicht landesspezifische Kategorien.

Sie können in keiner Weise darauf vertrauen, dass ein Anwender aufgrund der TLD die ausgelieferte Sprache erraten kann.

Verwenden Sie aber landesspezifische TLDs, wenn Sie explizit nach Maßen, Währungen oder anderen syntaktischen landesspezifischen Kennzeichen Inhalte ausliefern.

  • In der Schweiz werden vier Sprachen gesprochen. Maße und orthographische Interpunktion bleiben aber durch alle vier Sprachen konstant.

Wenn Sie nur Inhalte in einer Sprache anbieten, braucht der URI nicht auf die Sprache zu verweisen. Das ändert sich jedoch, wenn Sie Inhalte in mehreren Sprachen anbieten.

Es bieten sich folgende Formen an:

Keine der Formen hat die Semantik einer Sprachversion. Es ist lediglich eine gute Konvention, Sprachversionen in URIs durch die IANA-Sprachkürzel anzugeben.

Wenn Sie die Sprache über ein HTML-Formular umschalten lassen, dann sollten Sie das Formular über die Methode GET versenden, damit die Sprache auch im URI repräsentiert wird. Sofern die serverseitige Software mit gemischten HTTP-Methoden GET und POST umgehen kann, können Sie bei Formularen, welche die Sprache nicht ändern, Sprachparameter auch im action-Attribut notieren und das Formular mittels POST übermitteln.

Wird auf der Website Content-Negotiation über das HTTP-Feld Accept-Languageangewendet, sollte ein URI, welcher eine Sprachversion indiziert, auf jeden Fall Content-Negotiation für diesen Request außer Kraft setzen, es sei denn, die Sprachversion kann nicht ausgeliefert werden und es muss ein Fallback-Mechanismus ausgeführt werden.

Zeichenkodierung

Im WWW herrscht die Beschränkung: Eine Zeichenkodierung pro HTTP-Request im Header Content-type. Da ein Dokument schlicht aus Bytes besteht, werden diese Bytes nur aufgrund der einen Kodierungsangabe interpretiert. Die Zeichenkodierung wird als Meta-Angabe zum Dokument verwaltet. Die Verwaltung ist jedoch dem Datenersteller überlassen. Die Angabe wird im HTTP im Header gesendet. Einige Dokumentformate erlauben es, die Meta-Angabe im Dokument nochmals zu spezifizieren (z.B. HTML, CSS).

Zeichencodierungen wie die ISO-8859-Familie decken nur jeweils maximal 256 Zeichen ab, einige davon sind aber bereits durch allgemein Sonderzeichen oder Steuerzeichen belegt. In einem Dokument können Sprachen mit diesen Familien ohne Zuhilfenahme von benannten oder nummerischen Zeichenreferenzen schlecht gemischt werden. Verwenden die Sprachen völlig unterschiedliche Schriftzeichen, ist es bereits ein Ding der Unmöglichkeit. Besser geeignet sind Multibyte-Kodierungen wie UTF-8 oder UTF-16, welche einen viel größeren Zeichenvorrat direkt kodieren können.

Unicode definiert den universellen Zeichensatz, welcher nahezu alle (menschlichen) Sprachen abdeckt. Viele (Programmier- und Auszeichnungs-)Sprachen haben Sondermechanismen, um dennoch höhere Unicode-Zeichen zu adressieren (Beispiel: HTML &#x2193; ↓) Probleme mit diesen Maskierungen: Bei Volltextsuche werden Stellen eventuell wegen der Maskierung nicht gefunden. Probleme der ISO-8859-Familie: Eine Software kann nicht zweifelsfrei erkennen, welcher Subtyp der Familie im Dokument gespeichert wurde.

Abhilfe: Verwendung einer Zeichenkodierung, welche Unicode möglichst vollständig abbilden kann: UTF-8 (ein bezüglich Byte-Order unmissverständlicher Zeichensatz), UTF-16 (bedarf einer Byte-Order-Mark).

Empfehlung:
  • verwenden Sie, sofern es keinen guten Grund gibt, ausschließlich UTF-8.
  • verzichten Sie auf benannte oder nummerische Zeichenreferenzen (außer für unsichtbare oder schwer unterscheidbare Zeichen).

Zeitangaben

  • Die Interpretation von Zeitformaten ist landesspezifisch. Da aber Länder in HTML nicht speziell semantisch bezeichnet werden können, müssen Sie ein unmissverständliches Format verwenden.
    • schlecht: 1.1.2001
    • gut: 1. Januar 2001
  • Auch bei Zeitangaben für den Leser: Geben Sie die Zeitzone explizit an!
    • Humor: Während wie vieler Stunden hat das Datum 2001-01-01 irgendwo auf der Welt Relevanz? Lösung: Während maximal 48 Stunden.
    • Genaue Zeitangaben sind ohne die Angabe einer Zeitzone unmöglich.

Für Maschinen und Menschen lesbare Angaben kombinieren:

Beispiel
<span class="date" title="2009-11-30T00:00:00 -00:00">30. Nov. 2001 GMT</span>
Im title-Attribut wird das Datum in maschinenlesbarer Form angegeben mit Zeit und Zeitzone. -00:00 bedeutet hierbei: Die Zeit ist auf GMT bezogen, aber die Zeitzone, aus welcher das originale Datum gewonnen wurde, ist unbekannt.

Microformate nehmen sich des Problems an, Daten für Mensch und Maschine semantisch aufzubereiten. Ein Beispiel zu Datums- und Zeitangaben finden Sie unter http://microformats.org/wiki/datetime-design-pattern.

Technologien

HTTP

Accept-Language

Das HTTP-Protokoll kennt das Feld Accept-Language, mit welchem der Client eine Liste gewichteter Sprachtags übermitteln kann.

Die Syntax des Accept-Language Feldes ist in RFC 2616 Abschnitt 14 dokumentiert.

Beispiel: Auszug aus dem HTTP-Request-Header
Accept-Language: de-ch,de;q=0.8,en;q=0.5,fr;q=0.3
Die Liste ist wie folgt zu interpretieren:
  • de-CH 100%
  • de 80%
  • en 50%
  • fr 30%
Accept-Language: da, en-gb;q=0.8, en;q=0.7
Die Liste ist wie folgt zu interpretieren:
  • da 100%
  • en-GB 80%
  • en 70%
Beachten Sie: Ein User-Agent übermittelt nicht notwendigerweise das richtige Sprachverständnis seines Anwenders. Nicht jeder Anwender ist sich im Umgang mit seinem Agent bewusst, dass er hier die Stärke seines lesenden Sprachverständnisses definieren sollte.

Hier finden Sie einen geeigneten Algorithmus in PHP zum Auslesen von Accept-Language.

Content-Language

Der Server-Response darf ein Feld Content-Language übermitteln, welches die Sprachen des intendierte Publikum angibt. Sinnvolle Anwendungen sind jedoch beschränkt.

Beispiel: Sie wollen einen Sprachkurs-Übungstext in Italienisch, der Hilfsübersetzungen in Deutsch und Französisch enthält, einem Deutsch oder Französisch sprechenden Publikum vorsetzen.

Beispiel: Auszug aus dem HTTP-Response-Header
Content-Language: de, fr
Der Wert des Feldes darf eine Komma-separierte Liste von IANA-Language-Tags sein.
Beachten Sie: Content-Language ist nicht geeignet, die Hauptsprache eines Dokuments zu bezeichnen.

Webserver Content-Negotiation

Webserver kennen Mechanismen der Content-Negotiation. Dies sei anhand von Apache besprochen.

Apache kennt das Prinzip von Typemaps. Dabei steht ein File verwaltend für eine Reihe von Alternativen Dokumenten bereit.

Beispiel
Die folgenden Seiten:
  • ressourcename.de
  • ressourcename.en
  • ressourcename.es

sollen durch eine einzelne Ressource

  • ressourcenname.var

Verwaltet werden.

dazu bedarf es zuerst mal eines generellen Eintrags in der httpd.config von Apache
AddHandler type-map .var
Dateien mit der Endung .var agieren jetzt als typemaps. Die Datei 'ressourcenname.var' hat nun folgenden möglichen Inhalt:
URI: ressourcenname

URI: ressourcenname.de.html Content-type: text/html Content-language: de

URI: ressourcenname.en.html Content-type: text/html Content-language: en

URI: ressourcenname.es.html Content-type: text/html

Content-language: es

Mehr Details zur Apache Content-Negotiation: http://httpd.apache.org/docs/2.0/content-negotiation.html


HTML

Zeichenkodierung

In HTML- und XHTML-Dokumenten können Sie eine Zeichenkodierung spezifizieren. Diese hat jedoch kein Gewicht, wenn die Zeichenkodierung bereits im HTTP-Header gesendet wurde. Hilfreich ist sie dennoch für Seiten, die aus dem lokalen Filesystem im Browser aufgerufen wurde.

Achten Sie darauf, dass die Zeichenkodierung sehr früh im HTML-Head aufgeführt wird.

Beispiel
<!DOCTYPE html> <html> <head> <meta http-equiv=Content-type" content="text/html; charset=UTF-8"> </head> ... </html>

Sprachbehandlung

HTML unterstützt nur die sprachlichen Aspekte der Internationalisierung, aber keine nationalen Konventionen und Richtwerte (Maße, Währung). Iana-Landeskennzeichen dienen lediglich der Spezifizierung einer Sprache. Beispiel de-CH. HTML-Semantik unterstützt heute weder Währungen, noch den Nummerntyp noch Maßtypen und vor allem auch nicht die Kennzeichnung einer länder­spezifischen Autorität.

Die Hauptsprache im Quelltext bezeichnen:

Beispiel
HTML 4.0HTML5
<html lang="de">
XHTML 1.0
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de" lang="de">
Empfehlung: Notieren Sie immer die Hauptsprache im Dokument.

In Kindknoten Sprachwechsel markieren:

Beispiel
HTML 4.0HTML5
<p lang="en">This is plain english.</p>
XHTML 1.0
<p xml:lang="en" lang="en">This is plain english.</p>
xml:lang wird interpretiert bei XHTML als application/xhtml+xml
lang wird interpretiert bei bei XHTML als text/html
Empfehlung: Notieren Sie immer die Elemente, deren Inhalt in einer anderen Sprache sind als das Parent-Element.

Die Zielgruppe nach Sprachen angeben:

Beispiel
Im HTTP-Response-Header
Content-language:de, fr, it
HTML 4.0HTML5
<meta http-equiv="content-language" content="de, fr, it">
XHTML 1.0
<meta http-equiv="content-language" content="de, fr, it" />

Die HTTP- bzw Meta-Angabe bezeichnet entgegen dem Feldnamen Content-Language nicht die Sprache des Inhalts, sondern die Sprache der bevorzugten Zielgruppe. Mehrere Sprachen können angegeben werden. Die Angabe sollte nur bei besonderen Gründen verwendet werden.

Siehe auch: http://www.w3.org/International/questions/qa-http-and-lang

Sprache der Ziele in Links definieren

Ob Leser einen Link navigieren, hängt wesentlich von der Sprache des Zieldokuments ab. Sie können in Links die Sprache der Zielressource unabhängig von der Sprache eines Linklabels angeben. Verwenden Sie dazu das hreflang Attribut.

Beispiel
HTML 4.0HTML5
<p lang="en">This text represents the primary language of the linking ressource<br>
It contains a link to another Ressource
<a href="http://example.org" lang="de" hreflang="de">Ressource in Deutsch</a>
</p>

Nutzen Sie diese Möglichkeit vor allem dann, wenn Sie Ressourcen in einer anderen Sprache als der aktuellen verlinken Der Inhalt des hreflang-Attributs lässt sich durch CSS sichtbar gestalten.

Welchen Geltungsbereich hat ein lang-Attribute?

Das lang Attribut eines Elementes:

  • wirkt auf den Inhalt des Elements
  • aber nicht auf die Attribute, die im gleichen Element deklariert sind.
Beispiel
<p
  lang="en" 
  title="Ich bin immer noch deutsch"
>This ist english</p>
Es wäre falsch, im title Attribut englischen Text zu schreiben.

CSS

Zeichenkodierung

Die @charset Regel erlaubt Ihnen zu Beginn des CSS-Files die Definition der Zeichenkodierung. Wenn Sie keine Regel aufführen, wird die HTTP-Angabe oder die Zeichenkodierung des einbindenden Dokuments angewendet.

Beispiel
@charset "UTF-8"; @media screen{ ... } @media print{ ... }
Die @charset Angabe sollte allen weiteren Angaben vorangehen.

Sie können in CSS jedoch jedes Unicode-Zeichen direkt adressieren durch die Form \nnnn. n stellt hierbei den HEX-Wert der Unicode-Zeichennummer dar.

Sprachbehandlung

Sprachabhängige Formatierung

Mehrere Möglichkeiten bestehen, sprachabhängig zu formatieren:

Die beste Methode verwendet den für Sprachverschachtelung optimierten Algorithmus über die :lang() Pseudo-Klasse

Beispiel
selector:lang(de) { param:value; }
selector:lang(en) { param:value; }

Die lang() Pseudo-Klasse wird auf alle Kind-Elemente angewendet, bis ein abweichendes lang-Attribut die Sprache für einen Ast im Dom ändert.

Eine weniger gute, aber auch für ältere Browser verständliche Methode mittels Attribut-Selektor ist limitiert, da Kind-Elemente nicht von der Regel betroffen werden.

Beispiel
selector[lang|="de"] { param:value; }
selector[lang|="en"] { param:value; }
Empfehlung: Verwenden Sie die :lang() Pseudo-Klasse.

Die Sprache von Linkzielen visuell darstellen

Browser stellen den Inhalt des hreflang-Attributs nicht dar. Mittels CSS lässt sich dies auf einfache Weise anzeigen.

Beispiel
a[hreflang]:after { content: "(" attr(hreflang) ")" }


Weiterführende Links

Umfassende Dokumentationen
http://www.w3.org/International/
Sprachkürzel
Referenzen IANA-Sprachkürzel
Internationalisierung für XHTML und HTML
http://www.w3.org/TR/2007/NOTE-i18n-html-tech-lang-20070412/
Zeitzonen
http://www.w3.org/TR/2005/NOTE-timezone-20051013/
HTTP Accept-Language auslesen
http://aktuell.de.selfhtml.org/artikel/php/httpsprache/index.htm
Content-Negotiation mit Apache Webserver
http://httpd.apache.org/docs/2.0/content-negotiation.html
http://httpd.apache.org/docs/2.0/mod/mod_negotiation.html
Meine Werkzeuge
Namensräume

Varianten
Aktionen
Übersicht
Schnell‑Index
Mitmachen
Werkzeuge
Spenden
SELFHTML