Internationale Rollout-Strategien für internationale Webauftritte
Kommentare

Systemtexte
Neben den textlichen Inhalten kann es auch Systemtexte im Frontend geben, die in die verschiedenen Auftritte geklont beziehungsweise übersetzt werden müssen. Beispiele für Systemtexte sind

Systemtexte

Neben den textlichen Inhalten kann es auch Systemtexte im Frontend geben, die in die verschiedenen Auftritte geklont beziehungsweise übersetzt werden müssen. Beispiele für Systemtexte sind die Feldbezeichner für die Such- und Loginmasken. Für sie gibt es häufig ein eigenes Übersetzungsmodul [1] und sie sollten beim Klonen eines Auftritts mit der Master-Version verknüpft sein.

Sobald eine Übersetzung stattfindet, wird diese Verknüpfung automatisch aufgelöst. Somit ändern sich bei einer Änderung der Systemtexte in der Master-Version alle Systemtexte auf den verknüpften Auftritten, die nicht übersetzt wurden, automatisch.

Ausgabe im Frontend

Zum Umgang mit mehrsprachigen Auftritten im Backend und bei der Pflege der Inhalte haben wir bereits mehrere Strategien kennengelernt. Natürlich gibt es, aber auch im Frontent Konzepte, die bei mehrsprachigen Seiten bedacht werden müssen. Zunächst gilt es eine klare und einfache Domainstrategie festzulegen.

Meist wird die Master-Version dabei mit der .com-Domain und die Sprachauftritte mit der entsprechenden Top-Level-Domain, zum Beispiel .de für Deutschland, verknüpft. Die Alternative, die Sprache als erste „Ordnerebene“ in Form von .com/de oder Ähnlichem zu realisieren, hat verschiedene Nachteile: Neben einer geringeren Suchmaschinenrelevanz durch die tiefere Schachtelung der Ordnerstruktur ist dabei vor allem der Nachteil zu nennen, dass es ohne spezielle Apache-Plug-ins (mod_proxy [2]) nicht möglich ist, die Länderversionen in verschiedene Systeminstallationen aufzuteilen.

Schwieriger als normale Top-Level-Domains ist der Umgang mit unterschiedlichen Sprachen in einem Land, zum Beispiel in der Schweiz. Die Empfehlung zur Lösung dieses Problems ist die Verwendung von Subdomains wie fr.mydomain.ch. Wichtiger ist jedoch die Möglichkeit zur Auswahl oder zum Wechsel der gewünschten Domain. Neben der direkten Eingabe der Domain oder anderen automatischen Verfahren, wie die Ermittlung von Sprache und Region über Browser und GeoIP -System [1], sollte für diese Auswahl eine möglichst einfache und transparente Regions- und Länderauswahl angeboten werden.

Jede Version der Seite sollte darüber hinaus über den Ländernamen in der Zielsprache verlinkt werden. Für die Schweiz wären das die folgenden Links: Suisse (FR), Schweiz (DE), Svizzera (IT).

Nutzer über Ländergrenzen hinweg

Für zentral gepflegte Inhalte bieten die genannten Strategien alle Möglichkeiten, um Texte zu pflegen und in die Länder auszurollen. Sobald jedoch Inhalte durch Nutzer erzeugt und auf der Seite veröffentlicht werden, reichen diese Mechaniken nicht aus. Das Kernproblem sind dabei die von den Nutzern erzeugten Inhalte wie Kommentare, Artikel, Videos und andere Beiträge.

Zunächst muss dabei die Trennung von Interface- und Content-Sprache berücksichtigt werden, bei der das Interface getrennt vom Content auf die Muttersprache des Nutzers eingestellt werden kann. So kann der Nutzer trotz eventuell gemischtsprachlicher Inhalte die Seite weiterhin sicher bedienen.

Ausführliches dazu auch unter [1]. Neben der Trennung der Interface- und Content-Sprache sind der Aufbau und das inhaltliche Ziel der Community ebenfalls von entscheidender Bedeutung für die gewählte Organisationsform der Inhalte.

Weitere Themen der folgenden Seiten:


  • Nutzer über Ländergrenzen hinweg
  • Welche Communityform?
  • Ein Beispiel mit RedSpark
  • Fazit
  • Autorenkasten
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -