Sonntag, 11. September 2011
Ihr seid offen für alles, was die Welt euch bietet, und eure Website soll dem in nichts nachstehen? Einfach die Texte übersetzen und schon kann es losgehen, oder? Eigentlich eher nicht. Das Google Webmaster-Team arbeitet oft an Websites, die für über 40 Sprachen lokalisiert werden. Deshalb zeigen wir euch hier, welche Aspekte wir bei der Einführung unserer Seiten in andere Sprachen und Länder berücksichtigen.
Vielleicht denkt ihr, dass ihr davon nicht betroffen seid, weil ihr nur deutsche oder nur englische Inhalte anbietet. Trotzdem ist es möglich, dass Besucher, die nicht eure Website--Sprache beherrschen, Tools wie Google Übersetzer benutzen, um sich eure Inhalte in ihrer Sprache anzeigen zu lassen. Diese Zugriffe sollten in eurer Analytics-Übersicht angezeigt werden, sodass ihr einen Eindruck davon bekommt, wie viele Besucher eure Website nicht so sehen, wie ihr eigentlich möchtet.
Mehr Sprachen != mehr HTML-Vorlagen
Wir empfehlen immer wieder: Setzt für alle Sprachversionen die gleiche Vorlage ein und versucht immer, möglichst einfaches HTML für eure Vorlage zu verwenden.
Für alle Sprachen den gleichen HTML-Code zu verwenden hat seine Vorteile bei der Wartung der Website. Es ist mühsam, am HTML-Code für jede Sprache einzeln herumzubasteln, wenn Bugs repariert werden müssen. Haltet deshalb euren Code möglichst sauber und verwendet CSS für die Stilvorlagen. Hier einer der vielen Vorteile eines sauberen Codes: Die meisten Übersetzungstools extrahieren beim Parsen die übersetzbaren Content-Strings des HTML-Dokuments. Das funktioniert am besten mit einem gut strukturierten und gültigen HTML-Code.
Wie lang ist ein String?
Wenn euer Design auf Textelementen basiert, die in der Größe nicht variabel sind, kann eine Übersetzung fatale Auswirkungen haben. Beispielsweise werden die Textstrings eurer linken Navigationsleiste, wenn ihr englische Strings habt, nach der Übersetzung in einigen Sprachen länger. Schaut euch unten die unterschiedliche Länge der Strings im Englischen und Niederländischen bei gleichem Inhalt an. Die Anpassung der Zeilenhöhe ist eine gute Methode, um mit Navigationstiteln umzugehen, die sich über zwei Zeilen erstrecken. Das könnt ihr bereits bei der Erstellung der englischen Navigationsleiste mit einplanen.
Unterschiedliche Wortlängen verursachen besonders bei Formularbezeichnungen und Steuerelementen Probleme. Wenn beispielsweise in eurem Formular die Feldbezeichnungen links und die Felder unabhängig davon rechts angezeigt werden, können sich längere Textstrings über zwei Zeilen erstrecken, während bei kürzeren Textstrings der Bezug zwischen Titel und Eingabefeld verloren geht.. In beiden Fällen leiden das Design und die Lesbarkeit des Formulars erheblich. Denkt auch an die zusätzliche Stilvorlage für Layouts mit einer Leserichtung von rechts nach links. Dazu erfahrt ihr später mehr. Aus diesen Gründen gestalten wir Formulare so, dass sich die Bezeichnungen über den Eingabefeldern befinden. Das wirkt sich positiv auf Lesbarkeit und Design aus und erleichtert die Übersetzung in mehrere Sprachen.
Vermeidet außerdem Tabellen mit fester Höhe. Wenn ihr versucht, euer Layout mit einem Rasterformat mit gleich hohen Feldern sauber und aufgeräumt aussehen zu lassen, wird der Text nach der Übersetzung höchstwahrscheinlich über Felder hinausragen, die lediglich für eure englischen Inhalte groß genug waren. Überlegt, ob die UI-Elemente eures Designs auch für längere oder kürzere Texte geeignet sind, beispielsweise bei horizontalen oder vertikalen Tabs.
Der Quellcode
Die Bearbeitung des Quellcodes kann bei bidirektionalem HTML Probleme verursachen, weil viele Editoren den bidirektionalen Unicode-Algorithmus nicht unterstützen (weitere Informationen zu Problemen und Lösungen). Bei der Anzeige eurer Auszeichnung kann also einiges durcheinandergeraten:
<p> ابةتث <img src="foo.jpg" alt=" جحخد" /> < ذرزسش! </p>
Aus unserer Erfahrung bieten derzeit folgende Editoren gute Lösungen für eine bidirektionale Bearbeitung an: Besonders empfehlenswert sind Coda und Dreamweaver, IntelliJ IDEA und JEditX.
Wenn ihr euer Design für Rechts-nach-links-Sprachen entwerft, könnt ihr fast alle Elemente zur Unterstützung von Rechts-nach-links-Sprachen in die Haupt-CSS-Datei einbauen und für die Abwärtskompatibilität das direktionale Attribut des html
-Elements zusammen mit einem class-Attribut im body
-Element verwenden. Wie immer ist es für die Websitewartung besser, alle Stilvorlagen in einer Haupt-CSS-Datei abzulegen.
Auf Folgendes solltet ihr beim Design immer achten: Alle mit „float“ nach rechts ausgerichteten Elemente müssen nach links ausgerichtet werden und umgekehrt; zusätzliche Abstände („padding“) oder Randbreiten auf einer Seite eines Elements müssen entfernt und getauscht werden; sämtliche text-align-Attribute müssen angepasst werden.
Unten seht ihr, wie wir normalerweise damit umgehen. Außerdem verwenden wir statt des CSS-Selektors html[dir=rtl]
das class-Attribut im body-Tag, da es mit älteren Browsern kompatibel ist:
Elemente:
<body class="rtl"> <h1> <a href="https://www.blogger.com/"> <img alt="Google" src="https://www.google.com/images/logos/google_logo.png" /> </a> Heading </h1>
Links-nach-rechts-Stil (Standard):
h1 { height: 55px; line-height: 2.05; margin: 0 0 25px; overflow: hidden; } h1 img { float: left; margin: 0 43px 0 0; position: relative; }
Rechts-nach-links-Stil:
body.rtl { direction: rtl; } body.rtl h1 img { float: right; margin: 0 0 0 43px; }
Schaut euch die Umsetzung für Englisch und Arabisch an.
Noch eine letzte Bemerkung zu diesem Thema: Meistens werden eure Seiteninhalte für Rechts-nach-links-Sprachen bidirektional sein und nicht nur aus Rechts-nach-links-Elementen bestehen, da in einigen Strings die Links-nach-rechts-Richtung erhalten bleiben muss. Das gilt beispielsweise für Namen von Unternehmen in lateinischer Schrift oder Telefonnummern. Damit der Browser ein überwiegend von rechts nach links ausgerichtetes Dokument richtig verarbeitet, könnt ihr die eingebetteten Textstrings in einem Inline-Element einschließen und mit einem Attribut die Leserichtung festlegen. Das sieht dann so aus:
<h2>עוד ב- <span dir="ltr">Google</span></h2>
Bei title-Elementen oder mit JavaScript erzeugtem Quellcode für „message prompt“-Befehle, also in Fällen, in denen ihr keinen HTML-Container zur Verankerung des dir-Attributs habt, könnt ihr das unten stehende Pendant verwenden, um die Leserichtung anzugeben. Dabei sind ‫ und ‬ Unicode-Steuerelemente zur Einbettung der Rechts-nach-Links-Leserichtung:
<title>‫הפוך את Google לדף הבית שלך‬</title>
Beispiel für JavaScript-Codierung:
var ffError = '\u202B' +'כדי להגדיר את Google כדף הבית שלך ב\x2DFirefox, לחץ על הקישור \x22הפוך את Google לדף הבית שלי\x22, וגרור אותו אל סמל ה\x22בית\x22 בדפדפן שלך.'+ '\u202C';
Weitere Informationen findet ihr in den Artikeln des W3C zur Erstellung von HTML für Arabisch, Hebräisch und andere Rechts-nach-links-Sprachen sowie zur Handhabung von Rechts-nach-links-Sprachen.
Ich versteh nur Chinesisch …
Wenn ihr vorher noch nie mit nicht lateinischen Zeichensätzen gearbeitet habt, dazu zählen Kyrillisch, Griechisch und unzählige asiatische und indische Sprachen, kann es vorkommen, dass Editor und Browser eure Inhalte nicht so anzeigen, wie ihr es euch vorgestellt habt.
Überprüft, ob die Codierung für euren Editor und Browser auf UTF-8 eingestellt ist (empfohlen). Außerdem solltet ihr ein <span>
-Attribut und das lang
-Attribut des html
-Elements in euer HTML-Dokument einbauen, damit eure Seite von Browsern korrekt ausgegeben wird. Das hat den Vorteil, dass alle Unicode-Zeichen korrekt dargestellt werden. Somit ist die Verwendung von HTML-Einheiten wie é
(é) überflüssig und ihr spart wertvolle Bytes. Wenn ihr Probleme habt, hilft euch der Artikel des W3C zu Zeichencodierungen weiter. Dort findet ihr detaillierte Informationen zum Thema.
Noch eine Sache zur Benennung
Zu guter Letzt noch ein praktischer Tipp zu Namenskonventionen bei der Erstellung mehrerer Sprachversionen. Standardcodierungen wie ISO 639-1 eignen sich für Benennungen, wenn ihr am Anfang mit mehreren Sprachversionen eines Dokuments arbeitet.
Wenn ihr verbreitete Standards verwendet, verstehen Nutzer die Struktur eurer Website besser. Außerdem fällt Webmastern, die an der Entwicklung der Website mitwirken, die Wartung leichter. Die Sprachcodierung ist auch für andere Elemente auf der Website wie Logos und PDF-Dokumente praktisch, um Dateien schneller identifizieren zu können.
In Google Search Central findet ihr in früheren Beiträgen Tipps zu URL-Strukturen und anderen Problemstellungen beim Umgang mit Websites für mehrere Regionen und beim Arbeiten mit mehrsprachigen Websites.
Dieser Beitrag stellt eine Zusammenfassung der Herausforderungen dar, denen wir täglich gegenüberstehen. Wir können euch aber versichern, dass sich die vorausschauende Planung und Arbeit an gut strukturierten HTML- und robusten CSS-Dateien bei der Lokalisierung auszahlen!