Internationalisierung

Aus SELFHTML-Wiki
(Weitergeleitet von Content Negotiation)
Wechseln zu: Navigation, Suche

Unter Internationalisierung versteht man ein Design eines Produkts, einer Anwendung oder eines Dokuments, das eine leichte Lokalisierung für Zielgruppen, die in Kultur, Region oder Sprache variieren, ermöglicht. Lokalisierung ist die konkrete Auswahl einer Version aus dem internationalisierten Angebot.


Sie finden zuweilen die Kürzel i18n (i + 18 Buchstaben + n) für internationalization und L10n (L + 10 Buchstaben + n) für localization. (Wegen der schlechten Unterscheidbarkeit von großem I und kleinem l verwendet man besser kleines i und großes L.)

Lokalisation

Sprachangaben

„Ein Benutzer wird doch beim Lesen merken, in welcher Sprache mein Text ist.“ – Eigentlich schon, aber Suchmaschinen und Screenreader profitieren von einer Sprachangabe.

  • Bei Suchdiensten stellt die Dokumentsprache ein mögliches Filterkriterium dar.
  • Assistierende Software wie Screenreader können so den Text mit der richtigen Aussprache wiedergeben.
  • Übersetzungstools können mit einem Text besser umgehen, dessen Teile sprachlich korrekt ausgezeichnet wurden.
Sprachangabe 
<html lang="de">

Eine Sprachangabe legen Sie über das Universal-Attribut lang fest. Als Wert wird ein Sprachkürzel der IANA verwendet. 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 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 Sprachwahlmenü.

Sprachwechsel

In einem Dokument können Sprachwechsel stattfinden. 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.

Sprachwechsel 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.

Grenzfälle ansehen …
<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ː/(anhören) oder ein /ˈeɪtʃ ˈtiː ˈɛm ˈɛl/ (anhören) vorlesen würde, was dieser unzweifelhaft schlechter verstehen würde.

Beispiel 
<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 (anhören) 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.

Sprachangaben bei Links

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 Sprachangabe des Linktexts angeben. Verwenden Sie dazu das hreflang-Attribut.

Sprachangaben bei Links ansehen …
<p lang="en">
  This text represents the primary language of the linking ressource<br>
  It contains a link to another Ressource
  <a href="https://example.org" lang="en" hreflang="de">Ressource in German</a>
</p>

Der Absatz in englischer Sprache erhält eine entsprechende Sprachangabe.
Der Linktext ist zwar auch in Englisch, was über das lang-Attribut ausgezeichnet wird, die Sprache der Ressource ist aber Deutsch, was mit dem hreflang-Attribut ausgezeichnet wird.

Mit CSS lässt sich der Attributwert auf einfache Weise anzeigen:

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

Bei jedem Link, der ein hreflang-Attribut besitzt, wird der Wert über ein after-Pseudoelement ausgegeben.

Nutzen Sie diese Möglichkeit vor allem dann, wenn Sie Ressourcen in einer anderen Sprache als der aktuellen verlinken.

Zeichencodierung

Früher benötigten deutschsprachige Webseiten eine spezielle Zeichencodierung, da es im ASCII-Code keine Umlaute gab. Verwendet wurden hauptsächlich ISO 8859-2 oder Windows-1250. Heute wird nur noch Unicode verwendet.

Die Festlegung der Zeichencodierung kann entweder über den HTTP-Header oder eine meta-Angabe im head des HTML-Dokuments festgelegt werden.

Beispiel
<!DOCTYPE html> <html lang="de"> <head> <meta charset="UTF-8"> </head> ... </html>
Empfehlung:
  • Verwenden Sie, sofern es keinen guten Grund gibt, ausschließlich UTF-8.
  • Verzichten Sie auf maskierte Zeichen (außer für unsichtbare oder schwer unterscheidbare Zeichen).

Zeitangaben

Die Interpretation von Zeitformaten ist landesspezifisch. Trotzdem ist es zu empfehlen, ein maschinenlesbares Format zu verwenden.[1]

"Für Maschinen und Menschen lesbare Angaben kombinieren" ansehen …
<h1>neuer Termin</h1> <p>Das nächste SelfHTML-Treffen wird auf den <time datetime="2014-12-19 10:00">19. Dezember</time> verschoben. Beginn ist um 10:00 Uhr.</p> <p>Das Organisationsteam trifft sich bereits am <time datetime="2014-12-18 20:00"> <strong>18. Dezember</strong> um 20 Uhr</time>.</p> <p>Entsprechende Einladungen werden <time datetime="2014-12-04">2 Wochen vorher</time> versendet.</p>

Die Zeitangaben werden mit dem time-Element ausgezeichnet. Neben der „menschlichen“, oft unpräzisen Zeitangabe enthält das datetime-Attribut eine maschinenlesbare Angabe.


Alternativ könnten Sie Zeitangaben des Date-Objects mit lokaler Formatierung ausgeben:

mehrsprachige Webseiten

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

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.

Sprachauswahl-Menu

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:

HTML Sprachwahl-Formular 
<html lang="de">
...
<form action="" method="get">
  <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>
  <button>Ändern</button>
</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.

Sprachangaben bei Links 
<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.

URIs bei mehrsprachigen Websites

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-Language angewendet, 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.

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.


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.

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%
Beispiel
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 Auswerten 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.

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:

Beispiel
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

Quellen

  1. ↑ Microformats: Datetime Design Pattern
  2. ↑ t3n: Internationale Website: So gelingt die perfekte Sprachumschaltung

Weblinks

Umfassende Dokumentationen:

Sprachkürzel
IANA-Sprachkürzel
HTTP Accept-Language auslesen
Content-Negotiation mit Apache Webserver
https://httpd.apache.org/docs/2.0/content-negotiation.html
https://httpd.apache.org/docs/2.0/mod/mod_negotiation.html
Abgerufen von „http://wiki.selfhtml.org/index.php?title=Internationalisierung&oldid=99643#Content-Negotiation“