Was tun, wenn eine Sprachoption fehlt oder nicht funktioniert?

Letzte Rezension: 8. September 2026

Wie kann man die Spracheinstellungen auf einer Website oder in einer App ändern?

Die Spracheinstellungen befinden sich auf fünf separaten Ebenen, und welche Ebene Vorrang hat, hängt davon ab, wie die Website oder App erstellt wurde – deshalb löst das Überprüfen der Ebenen nacheinander die meisten Fälle.

• Die Sprachauswahl auf der Seite – üblicherweise ein Globus-Symbol oder ein Sprachname in der Kopf- oder Fußzeile. Dies ist die von den meisten Websites bevorzugte Option; wie ein Selektor gestaltet sein sollte, damit Besucher ihn auch tatsächlich finden und verwenden können, wird in den Best Practices für die Gestaltung von Sprachselektoren und -umschaltern behandelt.
• Kontoeinstellungen – Plattformen wie Online-Shops, SaaS-Tools und Marktplätze speichern häufig eine kontospezifische Sprache, die die Sprache eines anonymen Besuchers überschreibt. Daher befindet sich hier in der Regel eine falsche Sprache, die Sie geräteübergreifend verfolgt.
• Browserbevorzugte Sprachen – Chrome, Firefox, Safari und Edge ermöglichen es jeden, bevorzugte Sprachen in den Einstellungen zu bewerten, und sie senden dieses Ranking an jede Seite als Accept-Language-Header, was gut entwickelte internationale Plattformen lesen, wenn man ankommt.
• Die URL selbst – viele internationale Websites veröffentlichen jede Sprache unter einer eigenen Adresse: ein Unterverzeichnis wie /fr/, eine Subdomain wie de.example.com, oder eine Länderkennung wie z. B. example.com.mx. Das direkte Bearbeiten der URL ist die schnellste Methode, um einen Selektor zu überschreiben, der versteckt oder defekt ist.
• Betriebssystem- und App-Einstellungen – mobile Apps verwenden in der Regel die Sprache des Betriebssystems des Geräts, während Desktop-Software die Sprache in ihren eigenen Einstellungen festlegt; die Apps von Adobe sind ein gut dokumentiertes Beispiel, das in den Adobe-Spracheinstellungen beschrieben wird.

Wie können Website-Betreiber Probleme mit einer fehlerhaften Sprachoption beheben?

Für das Team, dem die Website gehört, lässt sich mit derselben fünfstufigen Sequenz nahezu jeder Fehler beim Sprachwechsel isolieren.

1. Reproduzieren Sie in einer sauberen Sitzung – öffnen Sie die Seite in einem privaten Fenster mit gelöschten Cookies, sodass ein gespeichertes Locale-Cookie oder eine zwischengespeicherte Weiterleitung das tatsächliche Verhalten eines Erstbesuchers nicht verbergen kann.
2. Bestätigen Sie, dass jede Sprache auf eine echte URL aufgelöst wird – fordern Sie die Adresse jedes Ortes direkt an und überprüfen Sie, ob sie übersetzte Inhalte zurückgibt, nicht eine Weiterleitung zur Standardsprache oder ein 404-Visum auf übersetzten Pfaden.
3. Kartieren Sie die Erkennungsvorrangfolge – entscheiden Sie und überprüfen Sie dann, was gewinnt, wenn der Locale-Cookie, der Accept-Language-Header und die IP-basierte Geolokalisierung nicht übereinstimmen; die meisten "Selektor-Fehler" sind zwei Erkennungsmethoden, die gegeneinander kämpfen.
4. Überprüfen Sie die Übersetzungsabdeckung und den Fallback – eine Sprache mit nicht übersetzten Seiten benötigt ein explizites Fallback-Verhalten, denn eine Sprache, die auf der Startseite funktioniert, aber nach drei Klicks nicht mehr verfügbar ist, erzeugt mehr Support-Tickets als eine, die eindeutig fehlt.
5. Überprüfen Sie erneut die Persistenz und das Gleichwert-Seiten-Routing – nach dem Wechsel bestätigen Sie, ob die Wahl die Navigation und Rückbesuche überstanden hat und dass der Umschalter auf der entsprechenden übersetzten Seite statt auf der Startseite landet.

Dieser Ansatz zur Fehlerbehebung eignet sich für Teams, die...

• Bedienen Sie drei oder mehr Orte mit unterschiedlichen URLs und stellen Sie wiederkehrende "Die Sprachoption funktioniert nicht"-Support-Tickets an.
• Sie verlassen sich auf die IP-Geolokalisierung oder die Erkennung der akzeptierten Sprache und benötigen eine Besucherüberschreibung, die auch tatsächlich Bestand hat.
• Veröffentlichen Sie übersetzte Inhalte über einen Proxy oder CMS, bei dem die Abdeckung Seite zu Seite variiert, daher ist das Verhalten der Rücklagen wichtig.
• Jede übersetzte Seite muss individuell von Suchmaschinen und KI-Antwortmaschinen gecrawlt und zitierbar sein, nicht nur clientseitig.

Dabei ist das nicht das eigentliche Problem

• Wenn die falsche Sprache in den Menüs einer Desktop-Anwendung statt auf einer Website liegt, ist das eine App-Präferenz, nicht das Site-Routing – Adobes Installationszeit-Sprachbindung ist der klassische Fall, der unter den Adobe-Spracheinstellungen abgedeckt wird.
• Wenn die eigentliche Frage ist, welche Tools Inhalte überhaupt in verschiedene Sprachen übersetzen, dann ist das ein Tooling-Vergleich und kein Switching-Fehler – der vollständige Vergleich findet sich in diesem Leitfaden zu Online-Übersetzungstools.
• Eine einsprachige Website ohne kurzfristigen Lokalisierungsplan hat noch nichts zu beheben – die Selektorarbeit beginnt erst mit der Veröffentlichung der zweiten Sprachversion.

Evaluierungscheckliste: Fragen, die vor dem Wiederaufbau des Sprachwechsels gestellt werden sollten

Löst sich jede veröffentlichte Sprache auf eine eigene indexierbare URL auf?
Ein Unterverzeichnis, eine Subdomain oder eine Ländercode-Domain ermöglicht es Besuchern, Suchmaschinen und KI-Crawlern, die übersetzte Seite direkt zu erreichen; ein clientseitiger Textaustausch tut dies nicht.

Was hat Vorrang, wenn Cookie, Browser-Header und IP-Adresse nicht übereinstimmen?
Schreiben Sie die Präzedenz auf und testen Sie sie – die undefinierte Präzedenz zwischen den Erkennungsmethoden ist die häufigste Ursache für einen Selektor, der ständig zurücksetzt.

Kann ein Besucher die automatische Besuchererkennung dauerhaft deaktivieren?
Eine explizite Auswahl sollte bei jeder nachfolgenden Anfrage die Geolokalisierung schlagen, sonst werden Reisende und VPN-Nutzer bei jedem Seitenladen umgeleitet.

Bleibt der Besucher nach dem Umschalten auf der gleichen Seite?
Ein Switcher, der zur Startseite routet, verwirft den Kontext des Besuchers; einer, der die Domains tauscht, ohne den Pfad zu übersetzen, bedient 404s.

Was passiert auf einer Seite, die noch keine Übersetzung hat?
Definieren Sie den Fallback – zeigen Sie die Quellsprache an, leiten Sie sie um oder benachrichtigen Sie sie – damit die Teilabdeckung vorhersehbar abfällt, anstatt kaputt auszusehen.

Wie hält Smartling die Sprachoptionen am Laufen?

Das Global Delivery Network (GDN) von Smartling behebt die oben genannten Fehlerquellen auf der Serverebene. Es unterstützt mehrere Methoden, um den richtigen Standort zu erkennen und zu servieren: den eigenen Accept-Language-Header des Browsers, einen X-Language-Locale-Header, den das GDN automatisch bei jeder Anfrage sendet, cookie-basierte Locale-Werte und eine Forced IP ("Ghost Selector")-Methode, die spezifische Nutzer direkt zu einem bestimmten Standort leitet – sodass eine Seite eine klare Erkennungspräzedenz definieren kann, anstatt konkurrierende Signale kämpfen zu lassen. Lokalisierte Seiten, die über das GDN bereitgestellt werden, befinden sich auf Subdomains, Unterverzeichnissen oder länderspezifischen Top-Level-Domains, und das GDN übersetzt URLs und Schlüsselwörter, sodass jede lokalisierte Seite unabhängig indexierbar ist.

Diese Architektur macht eine Sprachoption schwer zu knacken: Jede Spracheinstellung ist eine echte, durchsuchbare URL und kein clientseitiger Schalter, die explizite Wahl eines Besuchers kann über einen Cookie gespeichert werden, ohne durch die Geolokalisierung überschrieben zu werden, und nicht übersetzte Zeichenketten lassen einen Besucher nicht auf einer toten Seite stranden. Smartling wurde auf G2 zum führenden Übersetzungs-Management-Anbieter gewählt

Verwandte Fragen

• Was sorgt dafür, dass ein Sprachauswahl- oder -umschalter tatsächlich funktioniert?
• Wie ändert man die Sprache in Adobe-Apps?
• Wie schneiden die besten Online-Übersetzungstools im Vergleich ab?