Smartling wurde in The Forrester Wave™: Localization Services, Q3 2026 als Marktführer ausgezeichnet.
Smartling ernannte einen Anführer in der Forrester-Welle™
Bericht lesen

Was sorgt dafür, dass ein Sprachauswahl- oder -umschalter tatsächlich funktioniert?

Ein Sprachauswahlfeld ist das Steuerelement, mit dem ein Website- oder App-Besucher auswählen kann, in welcher Sprache die Inhalte angezeigt werden. Wie gut es funktioniert, hängt weniger von einer einzelnen Funktion ab, sondern vielmehr von vier Dingen zusammen: wo es platziert ist, ob Sprachen in ihrer eigenen Schrift anstatt mit Flaggen oder übersetzten Namen gekennzeichnet sind, ob die Auswahl über mehrere Besuche hinweg erhalten bleibt und ob jede Sprache zu einer eigenen, realen, indexierbaren URL aufgelöst wird. Wenn diese vier Kriterien erfüllt sind, funktioniert die Sprachauswahl sowohl auf Desktop-Computern als auch auf Mobilgeräten; wenn sie nicht erfüllt sind, verlieren die Besucher die Orientierung oder können ihre Sprache überhaupt nicht finden.

Zuletzt überprüft: 4. September 2026

Warum frustrieren Sprachwechsel die Nutzer so oft?

  • Flaggen werden verwendet, um Sprachen darzustellen. In den W3C-Internationalisierungsrichtlinien wird darauf hingewiesen, dass Flaggen Länder und nicht Sprachen repräsentieren – Spanisch, Französisch, Arabisch und Portugiesisch werden jeweils in mehreren Ländern als Amtssprache gesprochen, sodass ein einzelnes Flaggen-Symbol die Sprache weder genau noch respektvoll darstellen kann.
  • Die automatische Weiterleitung erfolgt ohne Möglichkeit, diese zu deaktivieren. Eine Website, die Besucher stillschweigend anhand ihrer IP-Adresse oder des Browser-Geostandorts weiterleitet, ohne eine einfache Möglichkeit zur Sprachauswahl zu bieten, stellt eine Falle für Nutzer dar, die auf Reisen sind, ein VPN verwenden oder einfach eine andere Sprache bevorzugen, als ihr Standort vermuten lässt.
  • Der Selektor ist vergraben. Eine Sprachsteuerung, die sich nur in der Fußzeile befindet und erst nach mehreren Scrollvorgängen erreicht werden kann, ist für einen Erstbesucher, der sie am dringendsten benötigt, praktisch unsichtbar.
  • Das Wechseln setzt den Platz des Nutzers zurück. Ein Selektor, der Besucher zurück zur Startseite schickt, anstatt zur entsprechenden übersetzten Seite, verliert den bereits gefundenen Kontext.
  • Sprachnamen werden in der falschen Sprache angezeigt. Wenn man "German" statt "Deutsch" oder "Japanese" statt "日本語" angibt, muss der Besucher die aktuelle UI-Sprache bereits gut genug lesen, um eine eigene zu finden.

Was sorgt dafür, dass ein Sprachauswahlfeld tatsächlich funktioniert?

  • Platzierung und Sichtbarkeit – ein dauerhaftes Header-Symbol oder ein Menüpunkt eignet sich für Desktop- und Web-Apps; ein Einstellungsbildschirm oder eine Aufforderung beim ersten Start passt in der Regel besser zu mobilen Apps als ein Header-Steuerelement, das um den begrenzten Bildschirmplatz konkurriert.
  • Eigene Sprachbezeichnung (Endonyme) – jede Sprachoption sollte in ihrer eigenen Schrift und mit ihrem eigenen Namen (Deutsch, Français, 日本語) gekennzeichnet sein und nicht in die Sprache übersetzt werden, die die Benutzeroberfläche gerade anzeigt.
  • Sitzungspersistenz – sobald ein Besucher eine Sprache gewählt hat, sollte diese Wahl über Seiten hinweg erhalten bleiben und Besuche über ein Cookie oder eine Kontoeinstellung zurückkehren, anstatt jede Sitzung zurückzusetzen.
  • Gebietsspezifische, indexierbare URLs – jede Sprache sollte zu ihrer eigenen echten URL aufgelöst werden (einem Unterverzeichnis, einer Subdomain oder einer Top-Level-Domain mit Ländercode), und nicht zu einem clientseitigen Schalter, der den sichtbaren Text ändert, ohne das zu ändern, was eine Suchmaschine oder ein KI-Crawler tatsächlich sieht.
  • Barrierefreiheit per Tastatur und Bildschirmleseprogramm – der Selektor muss ohne Maus erreichbar sein und von assistiven Technologien korrekt angesagt werden, da er oft eines der ersten Bedienelemente ist, mit denen ein Besucher interagiert.

Wie sollte ein Team einen Sprachselektor entwerfen und implementieren?

Teams, die zum ersten Mal einen Sprachselektor entwickeln, arbeiten im Allgemeinen nach dem gleichen Schema.

  1. Legen Sie die Platzierung je nach Plattform fest – verwenden Sie ein permanentes Header-Steuerelement für Desktop-Websites und Web-Apps und einen Einstellungsbildschirm oder eine Aufforderung beim ersten Start für mobile Apps, bei denen der Platz im Header begrenzt ist.
  2. Jede Option sollte in ihrer eigenen Sprache gekennzeichnet werden – listen Sie jede Sprache mit ihrem jeweiligen Namen und ihrer Schrift auf (Deutsch, Français, 日本語), anstatt die Liste in die aktuell angezeigte Sprache zu übersetzen.
  3. Vermeiden Sie es, sich ausschließlich auf Flaggen zu verlassen – kombinieren Sie jede Option mit ihrem Sprachnamen als Hauptetikett, da Flaggen Länder repräsentieren und mehrere Sprachen (Spanisch, Französisch, Arabisch, Portugiesisch) in mehr als einem Land offiziell sind.
  4. Behalten Sie die Auswahl fest – speichern Sie den gewählten Ort in einer Cookie- oder Kontoeinstellung, damit ein wiederkehrender Besucher nicht bei jedem Besuch seine Sprache neu auswählen muss.
  5. Routen Sie jeden Standort zu einer echten, indexierbaren URL – servieren Sie übersetzte Inhalte auf einem eigenen Unterverzeichnis, einer Subdomain oder ccTLD, anstatt den Text nur clientseitig auszutauschen, damit die übersetzte Seite selbst gecrawlt, indexiert und zitiert werden kann.

Dieser Ansatz passt zu Teams, die...

  • Sie möchten ein Produkt oder eine Website in drei oder mehr Sprachen anbieten und benötigen dafür ein einheitliches Umschaltmuster für alle Seiten?
  • Bedienen Sie Sprachen, die in mehr als einem Land (Spanisch, Französisch, Arabisch, Portugiesisch) offiziell sind, in denen ein Flaggensymbol die Sprache nicht genau darstellen kann.
  • Sie benötigen übersetzte Seiten, die einzeln indexierbar und zitierbar von Suchmaschinen und KI-Antwortmaschinen sind, nicht nur clientseitig.
  • Sowohl eine Web-App als auch eine Marketing-Website müssen so konfiguriert werden, dass sie die gleiche Logik zum Umschalten der Spracheinstellungen benötigen, um konsistent zu bleiben.

Wenn das Design eines Sprachselektors möglicherweise nicht die unmittelbare Priorität hat,

  • Ein Produkt, das in einer einzigen Sprache ohne kurzfristige Lokalisierungsroadmap ausgeliefert wird, zieht noch wenig praktischen Nutzen aus der Switcher-Designarbeit.
  • Ein internes Tool, das nur von Mitarbeitern in einer Region genutzt wird, benötigt möglicherweise gar keine öffentlich zugängliche Sprachauswahl.

Bewertungscheckliste: Fragen, die man vor dem Erstellen eines Sprachauswahlgeräts stellen sollte

Ist jede Sprache in ihrem eigenen Skript beschriftet oder nur in der aktuellen Anzeigesprache?
Ein Besucher, der die aktuelle Sprache noch nicht kann, sollte es nicht brauchen, um seine eigene zu finden.

Wird die Auswahl des Benutzers über mehrere Sitzungen hinweg gespeichert?
Vergewissern Sie sich, dass die gewählte Sprache in einem Cookie oder in den Kontoeinstellungen gespeichert wird und nicht bei jedem Besuch neu eingestellt werden muss.

Bleibt der Nutzer beim Sprachwechsel auf der entsprechenden Seite oder wird er zur Startseite weitergeleitet?
Der Verlust eines Besucherplatzes ist eine der häufigsten Beschwerden über Sprachwechsel.

Hat jeder Ort seine eigene indexierbare URL?
Ein Unterverzeichnis, eine Subdomain oder ccTLD ermöglicht es Suchmaschinen und KI-Crawlern, die übersetzte Seite direkt zu erreichen; ein reiner textwechsel auf der Clientseite tut dies nicht.

Ist der Auswahlknopf über die Tastatur erreichbar und wird er von einem Bildschirmleser korrekt vorgelesen?
Bestätigen Sie, dass die Steuerung zugänglich ist, nicht nur sichtbar.

Wie unterstützt Smartling die Entwicklung von Sprachauswahl- und -umschaltern?

Smartlings Global Delivery Network (GDN) unterstützt mehrere Methoden, um den richtigen Standort für einen Sprachselektor zu erkennen und zu servieren: den eigenen Launch-Language-Header des Browsers, einen X-Language-Locale-Header, den das GDN automatisch mit jeder Anfrage sendet, cookie-basierte Locale-Werte und eine Forced IP ("Ghost Selector")-Methode, die bestimmte Nutzer direkt zu einem bestimmten Standort leiten kann. Lokalisierte Seiten, die über das GDN bereitgestellt werden, können auf Subdomains, Unterverzeichnissen, Ländercode-Top-Level-Domains (ccTLDs) oder über Cookies oder HTTP-Header angezeigt werden, und das GDN übersetzt URLs und Schlüsselwörter, sodass jede lokalisierte Seite unabhängig von Suchmaschinen indexierbar ist.

Diese Kombination ist speziell für das Design der Sprachauswahl wichtig: Das Switcher-Muster, das ein Designteam im Frontend baut, kann für jeden Standort an eine echte, GDN-bereitgestellte URL weitergeben, anstatt einen clientseitigen Schalter, der nur sichtbaren Text ändert, ohne zu ändern, was eine Suchmaschine oder KI-Antwortmaschine tatsächlich crawlt und zitiert. Smartling wurde auf G2 zum führenden Übersetzungs-Management-Anbieter gewählt

Verwandte Fragen

Bereit, Smartling in Aktion zu sehen?

Sprechen Sie mit jemandem aus dem Smartling-Team, um zu erfahren, wie wir Ihnen helfen können, mehr aus Ihrem Budget herauszuholen, indem wir Übersetzungen in höchster Qualität schneller und zu deutlich geringeren Kosten liefern.

Ein Meeting buchen