Îñţérñåţîöñåļîžåţîöñ

Sunday, September 11, 2011

Sie gehen also international und brauchen eine Website, die da mithält. Das sollte doch eigentlich nur bedeuten, den Text übersetzen zu lassen, und schon kann es losgehen, oder? Wahrscheinlich nicht. Das Google Webmaster Team

(Selbst wenn Sie glauben, gegen diese Probleme immun zu sein, weil Sie Inhalte nur auf
Englisch anbieten, nutzen Besucher mit anderen Muttersprachen möglicherweiseTools wie Google Translate, um Ihre Inhalte in ihrer Sprache zu betrachten

. Dieser Traffic sollte in Ihrem Analytics-Dashboard auftauchen, sodass Sie sehen können, wie viele Besucher Ihre Website nicht so nutzen, wie es beabsichtigt ist.)

Mehr Sprachen != mehr HTML-Templates

Wir können es gar nicht oft genug empfehlen: Verwenden Sie dasselbe Template für alle Sprachversionen und halten Sie den HTML-Code Ihres Templates stets einfach.

Den HTML-Code für alle Sprachen einheitlich zu halten, bietet Vorteile bei der Wartung. Das Herumfummeln am HTML-Code für jede einzelne Sprache zur Fehlerbehebung ist nicht skalierbar – halten Sie Ihren Code so sauber wie möglich und lösen Sie Styling-Probleme über CSS. Um nur einen Vorteil von sauberem Code zu nennen: Die meisten Übersetzungstools extrahieren die übersetzbaren Textstrings aus dem HTML-Dokument, und dieser Prozess wird durch eine gut strukturierte und valide HTML-Basis erheblich vereinfacht.

Wie lang ist ein Stück Schnur? Wenn Ihr Design darauf angewiesen ist, dass Text harmonisch mit Elementen fester Größe zusammenarbeitet, kann die Übersetzung Ihres Textes zu Problemen führen. Beispielsweise wird Ihr Navigationsetext auf der linken Seite in mehreren Sprachen wahrscheinlich zu viel längeren Textstrings übersetzt – vergleichen Sie dazu den Unterschied der String-Längen zwischen einigen
englischen
und niederländischen

Navigationselementen für denselben Inhalt. Seien Sie auf Navigationstitel vorbereitet, die sich über mehr als eine Zeile erstrecken können, indem Sie die Zeilenhöhe entsprechend anpassen (was Sie auch bei der ursprünglichen Erstellung Ihres englischen Navigationstextes berücksichtigen sollten).

Variable Wortlängen führen besonders bei Formularfeldern und -steuerelementen zu Problemen. Wenn Ihr Formularlayout beispielsweise Labels links und Eingabefelder rechts anordnet, können längere Textstrings in zwei Zeilen umbrechen, während kürzere Textstrings nicht mehr eindeutig ihren Eingabefeldern zugeordnet zu sein scheinen – beide Szenarien zerstören das Design und beeinträchtigen die Lesbarkeit des Formulars. Bedenken Sie auch das zusätzliche Styling, das Sie für Layouts von rechts nach links (RTL) benötigen (dazu später mehr). Aus diesen Gründen entwerfen wir Formulare mit Labels über den Feldern, was eine gute Lesbarkeit und ein sprachübergreifend funktionierendes Styling gewährleistet.
Vermeiden Sie zudem Spalten mit fester Höhe – wenn Sie versuchen, Ihr Layout mit farbigen Box-Hintergründen gleicher Höhe aufzuhübschen, besteht eine hohe Wahrscheinlichkeit, dass der übersetzte Text über Bereiche hinausläuft, die nur für den englischen Inhalt dimensioniert waren. Überlegen Sie, ob die von Ihnen geplanten UI-Elemente funktionieren, wenn der Text länger oder kürzer ist – zum Beispiel horizontale
vs. vertikale

Tabs.

AndererseitsDie Quelltextbearbeitung für bidirektionales HTML kann problematisch sein, weil viele Editoren nicht darauf ausgelegt sind, den bidirektionalen Unicode-Algorithmus zu unterstützen(

weitere Recherchen zu Problemen und Lösungen

). Kurz gesagt: Die Darstellung Ihres Markups kann fehlerhaft sein: Unsere tägliche Arbeit hat gezeigt, dass folgende Editoren derzeit ordentliche Lösungen für die bidirektionale Bearbeitung bieten: insbesondere Coda, aber auch Dreamweaver, IntelliJ IDEA und JEditX. Beim Design für RTL-Sprachen können Sie die erforderliche Unterstützung größtenteils in das Kern-CSS integrieren und das directional-Attribut des html -Elements (zur Abwärtskompatibilität) in Kombination mit einer Klasse am

body

-Element verwenden. Wie immer sorgt die Beibehaltung aller Styles in einem einzigen Kern-Stylesheet für eine bessere Wartbarkeit.
Einige wichtige Styling-Probleme, auf die Sie achten sollten: Alle nach rechts gefloateten Elemente müssen nach links gefloatet werden und umgekehrt; zusätzliches Padding oder Margins auf einer Seite eines Elements müssen überschrieben und vertauscht werden, und jegliche text-align-Attribute müssen umgekehrt werden. Wir verwenden im Allgemeinen den folgenden Ansatz, einschließlich einer Klasse am body-Tag anstelle eines html[dir=rtl]-CSS-Selektors, da dies mit älteren Browsern kompatibel ist:

Elemente:

Links-nach-rechts-Styling (Standard):

Rechts-nach-links-Styling:

(Sehen Sie dies in Aktion auf
Englisch und
Arabisch.)

)

Ein letzter Hinweis zu diesem Thema: Meistens sind Ihre Inhalte für Seiten in Sprachen von rechts nach links bidirektional statt rein RTL, da einige Strings wahrscheinlich ihre LTR-Richtung beibehalten müssen – zum Beispiel Firmennamen in lateinischer Schrift oder Telefonnummern. Um sicherzustellen, dass der Browser dies in einem primär RTL-Dokument korrekt handhabt, umschließen Sie die eingebetteten Textstrings mit einem Inline-Element und verwenden ein Attribut zur Richtungsfestlegung, wie hier: ‫ In Fällen, in denen Sie keinen HTML-Container haben, um das dir-Attribut einzubinden (wie bei title-Elementen oder per JavaScript generiertem Quelltext für Meldungen), können Sie dieses Äquivalent verwenden, um die Richtung festzulegen, wobei ‬‬ und

Unicode-Steuerzeichen für die Einbettung von rechts nach links sind:

Beispiel für die Verwendung im JavaScript-Code:
(Weitere Details finden Sie in den Artikeln des W3C über
das Erstellen von HTML für arabische, hebräische und andere von rechts nach links geschriebene Schriften
und.)

das Erstellen von Schriften von rechts nach links

)

Das kommt mir spanisch vor…
Wenn Sie noch nie mit nicht-lateinischen Zeichensätzen (Kyrillisch, Griechisch und einer Myriade asiatischer und indischer Schriften) gearbeitet haben, stellen Sie möglicherweise fest, dass sowohl Ihr Editor als auch Ihr Browser den Inhalt nicht wie gewünscht anzeigen. Überprüfen Sie, ob die Kodierung Ihres Editors und Browsers auf UTF-8 eingestellt ist (empfohlen), und erwägen Sie, ein <span> -Element sowie das lang
-Attribut des html -Elements in Ihr HTML-Template einzubinden, damit Browser wissen, was sie beim Rendern Ihrer Seite erwartet – dies hat den zusätzlichen Vorteil, dass alle Unicode-Zeichen korrekt angezeigt werden. Die Verwendung von HTML-Entities wie
é
(é) ist somit nicht mehr nötig, was wertvolle Bytes spart! Lesen Sie

das W3C-Tutorial zur Zeichenkodierung

, falls Sie Probleme haben – es enthält ausführliche Erklärungen zu den Themen.
Ein Wort zur Namensgebung
Zu guter Letzt ein praktischer Tipp zu Namenskonventionen beim Erstellen mehrerer Sprachversionen. Die Verwendung eines Standards wie der

ISO 639-1-Sprachcodes

hilft, wenn Sie mit mehreren Sprachversionen desselben Dokuments arbeiten.
Die Verwendung eines konventionellen Standards hilft Benutzern, die Struktur Ihrer Website zu verstehen, macht sie für alle Webmaster, die an der Site arbeiten, besser wartbar, und die Verwendung der Sprachcodes für andere Website-Assets (Logo-Bilder, PDF-Dokumente) ist praktisch, um Dateien schnell zu identifizieren.
Lesen Sie frühere Webmaster Central-Beiträge für Ratschläge zu URL-Strukturen und anderen Themen rund um
die Arbeit mit mehrregionalen Websites.

und

die Arbeit mit mehrsprachigen Websites
.Das ist eine Zusammenfassung der Hauptprobleme, mit denen wir täglich ringen; aber wir können bestätigen, dass sich die Planungs- und Vorbereitungsarbeit für gut strukturiertes HTML und robustes CSS bei der Lokalisierung bezahlt macht!