
Ein QR-Code, alle Sprachen: automatische Spracherkennung für internationale Kampagnen
Ein dynamischer QR-Code erkennt die Gerätesprache und leitet automatisch zur passenden Landingpage weiter. So funktioniert die Erkennung, welches Signal zählt und wie die DSGVO-konforme Rückfalloption aussieht.
ScanKit · Organization
· 17 Min. Lesezeit
Ein Händler, der dasselbe Produkt in Rotterdam, Berlin und Mailand verkauft, brauchte früher drei QR-Codes: einen pro Markt, einen pro Sprache, gedruckt in drei getrennten Verpackungsauflagen. Dieser Ansatz funktioniert noch immer, doch die meisten Agenturen lösen das Problem heute anders. Ein einziger dynamischer QR-Code kann inzwischen erkennen, auf welche Sprache das scannende Gerät eingestellt ist, und den Scan direkt an die passende Landingpage weiterleiten, ohne dass die Käuferin oder der Käufer jemals einen Sprachumschalter berühren muss.
Das ist wichtiger, als es auf den ersten Blick wirkt. Für Agenturen, die Verpackungs-, Messe-, Tourismus- oder Direktmarketingkampagnen in mehreren Ländern betreuen, nimmt ein sprachsensibler QR-Code eine ganze Kategorie der Druckplanung ab: kein Abstimmen mehr, welche Artikelnummer welchen Code bekommt, kein Nachdrucken mehr, wenn ein neuer Markt hinzukommt, und kein Rätselraten mehr, in welche Sprache ein Scan „auflösen" sollte. Der Code selbst bleibt gleich. Nur das Ziel ändert sich, und zwar automatisch, anhand eines Signals, das das Telefon ohnehin schon sendet.
Dieser Beitrag erklärt, wie diese Erkennung technisch tatsächlich funktioniert, welchem Signal Sie zuerst vertrauen sollten, wenn zwei sich widersprechen, wo sie an ihre Grenzen stößt (VPNs, gemeinsam genutzte Geräte, Reisende), und wie Sie eine Rückfalloption einbauen, damit niemand auf einer Seite hängen bleibt, die er nicht lesen kann.
Was ein „mehrsprachiger QR-Code" wirklich ist
Es gibt keinen QR-Code, der mehrere Sprachen in sich speichert. Ein QR-Code ist lediglich ein Container für eine einzige Nutzlast, fast immer eine einzelne URL. Was einen Code „mehrsprachig" wirken lässt, ist die Tatsache, dass die URL, auf die er verweist, ein dynamischer Redirect ist: Das ist derselbe Mechanismus, der auch dynamischen QR-Codes im Allgemeinen zugrunde liegt. Der Code selbst bleibt fest auf der Verpackung oder dem Flyer, doch das Ziel dahinter ist eine kleine Entscheidungsebene, die nach Sprache verzweigt, noch bevor überhaupt Inhalt ausgeliefert wird.
Diese Entscheidungsebene sieht sich die Anfrage an, die das Telefon sendet, wählt eine Sprache aus und leitet die Besucherin oder den Besucher an die passende Version der Seite weiter. Stimmt die Verzweigungslogik, sieht die Käuferin nie ein Sprachmenü. Stimmt sie nicht, landet die Besucherin auf einer Seite in einer Sprache, die sie nicht lesen kann, ganz gleich, wie gut der QR-Code selbst gestaltet ist.
Die drei Signale, und in welcher Reihenfolge Sie ihnen vertrauen sollten
Es gibt drei Wege herauszufinden, welche Sprache jemandem angezeigt werden sollte, und sie sind nicht gleich zuverlässig. Die Reihenfolge richtig zu treffen, ist der größte Teil der Aufgabe.
- Explizite Wahl, gewinnt immer. Hat eine Besucherin bereits eine Sprache gewählt, bei diesem Scan oder einem früheren, über einen Umschalter oder ein gespeichertes Cookie, überstimmt diese Wahl alles andere. Überschreiben Sie niemals stillschweigend eine Sprache, die jemand bewusst ausgewählt hat. Das klingt selbstverständlich, ist aber der mit Abstand häufigste Fehler bei Implementierungen der Spracherkennung: eine erneute Prüfung bei jedem Besuch, die jemanden, der beim letzten Mal bewusst Englisch gewählt hat, leise wieder umleitet.
- Gerätesprache, das stärkste automatische Signal. Jeder Browser sendet bei jeder Anfrage einen
Accept-Language-Header, und jedes Telefon stellt das Äquivalent JavaScript alsnavigator.languagezur Verfügung. Beide werden aus der Sprach- und Regionseinstellung des Geräts befüllt, unter Verwendung von Tags nach BCP 47, dem Standard, der einen ISO-639-Sprachcode mit einem optionalen ISO-3166-Regions- oder Schriftsystem-Subtag kombiniert, etwaen-GB,pt-BRoderzh-Hans. Ein Header sieht häufig so aus:fr-FR, fr;q=0.9, en;q=0.5, eine nach Präferenz geordnete Liste: Französisch (Frankreich) bevorzugt, allgemeines Französisch danach, Englisch als Rückfalloption, wobei dieq-Werte die relative Präferenz ausdrücken. In der Regel genügt es, den ersten Eintrag mit dem höchsten Gewicht zu lesen, um eine Sprache auszuwählen. - IP-Geolokalisierung, nur eine Rückfalloption. Wo sich das Telefon physisch befindet, abgeleitet aus seiner IP-Adresse, ist hilfreich, wenn die Gerätesprache fehlt, nicht verfügbar ist oder auf etwas eingestellt ist, das Sie nicht übersetzt haben. Sie ist kein Stellvertreter dafür, welche Sprache jemand spricht. Viele Menschen in den Niederlanden nutzen ihr Telefon auf Englisch; viele Touristinnen und Touristen in Rom tragen kein italienischsprachiges Gerät bei sich. Behandeln Sie IP-Geolokalisierung als letzten Ausweg, nicht als primäres Signal, und kombinieren Sie sie mit dem weiter unten beschriebenen manuellen Umschalter als Rückfallebene.
Warum die Gerätesprache dem Standort überlegen ist, und warum keines der beiden Signale perfekt ist
Die Gerätesprache spiegelt eine Entscheidung wider, die der Besitzer oder die Besitzerin des Telefons irgendwann tatsächlich getroffen hat, oder zumindest die Werkseinstellung, mit der Mobilfunkanbieter oder Hersteller es ausgeliefert haben. Der Standort spiegelt dagegen überhaupt nichts über die Person wider, sondern nur etwas über eine Netzwerkverbindung. Deshalb ist die Prioritätsreihenfolge entscheidend: zuerst das Sprachsignal, dann der Standort, dann eine sichtbare manuelle Option.
Keines der drei Signale ist jedoch wasserdicht. Telefone reisen mit ihren Besitzern, sodass eine französische Touristin, die einen Code in Amsterdam scannt, anhand der Gerätesprache weiterhin als Französisch erscheint, was korrekt ist. Dieselbe Touristin, verbunden über ein Hotel-VPN mit Route über Deutschland, könnte anhand der IP-Adresse jedoch als in Deutschland befindlich erscheinen, was nicht stimmt. Gemeinsam genutzte Geräte, etwa das Vorführtablet eines Ladens oder ein Bibliotheks-Terminal, tragen oft die Sprache der zuletzt nutzenden Person. Und ein nennenswerter Anteil der Smartphone-Besitzer weltweit ändert die Werkssprache seines Telefons schlicht nie, wobei Englisch die häufigste Standardeinstellung ist, was bedeutet, dass die Gerätesprache manchmal eher über die Werkseinstellungen eines Herstellers Auskunft gibt als über eine tatsächlich gesprochene Sprache.
Das macht den Ansatz nicht unzuverlässig, es macht eine sichtbare Rückfalloption unverzichtbar. Erkennung sollte sich wie eine Annehmlichkeit anfühlen, nicht wie eine Entscheidung, die unwiderruflich stellvertretend für jemand anderen getroffen wird.

- Explizite Wahl. Eine Sprache, die die Besucherin bereits gewählt hat, bei diesem Scan oder einem früheren, überstimmt jedes automatische Signal darunter.
- Gerätesprache. Der
Accept-Language-Header undnavigator.language, ausgelesen aus den Einstellungen des Telefons selbst, werden zuerst geprüft, wenn keine explizite Wahl vorliegt. - IP-Standort, nur als Rückfalloption. Wird nur verwendet, wenn die Gerätesprache fehlt oder nicht unterstützt wird, hier mit gestricheltem Rand dargestellt, weil es das schwächste Signal ist, keine Ebene, auf die man sich verlassen sollte.
- Manueller Umschalter, immer vorhanden. Eine sichtbare Möglichkeit, die automatische Vermutung zu übersteuern, erreichbar unabhängig davon, welches der drei Signale die Entscheidung getroffen hat.
Die Rückfalloption aufbauen: Besucherinnen und Besucher nie in der falschen Sprache gefangen halten
Die eine Regel, die eine gute mehrsprachige QR-Implementierung von einer frustrierenden unterscheidet: Bieten Sie immer einen Ausweg. Konkret bedeutet das:
- Erkennen Sie die Sprache automatisch und leiten Sie zur besten Übereinstimmung weiter, behalten Sie aber einen kleinen, sichtbaren Sprachumschalter auf der Landingpage selbst bei. Flaggen-Icons sind hier ein schwaches Muster, da eine Flagge ein Land repräsentiert, keine Sprache; verwenden Sie stattdessen den eigenen Namen der Sprache, etwa „Nederlands" oder „Deutsch".
- Gibt es für die erkannte Sprache keine übersetzte Seite, greifen Sie auf eine sinnvolle Standardsprache zurück, häufig Englisch oder die Sprache des Marktes, für den der Code ursprünglich gedruckt wurde, statt eine kaputte oder maschinell übersetzte Seite anzuzeigen.
- Merken Sie sich eine explizite Wahl für den Rest dieses Besuchs, und idealerweise auch bei wiederkehrenden Besuchen, mithilfe eines Cookies, damit dieselbe Person beim nächsten Scan nicht erneut gefragt oder umgeleitet wird.
- Protokollieren Sie, welchen Zweig ein Scan tatsächlich genommen hat. Das ist dieselbe Tagging-Disziplin, die im Leitfaden zu QR-Code-UTM-Parametern beschrieben wird, nur pro Sprache statt pro Kampagne angewendet, damit aus „40 % der Scans zu dieser Artikelnummer haben auf Deutsch aufgelöst" ein Wert wird, den Sie tatsächlich abrufen können, statt ihn schätzen zu müssen.
Wo sich das wirklich auszahlt: Verpackung, Messen und Direktmarketing
Produktverpackung ist der eindeutigste Fall. Ein einziges Kartondesign, das an Vertriebspartner in mehreren Ländern ausgeliefert wird, kann einen einzigen QR-Code tragen, der je nach Markt zur passenden Produktseite, den Sicherheitsinformationen oder der Gebrauchsanweisung auflöst. Das berührt direkt die Kennzeichnungsrealität, die bereits im GS1-Digital-Link-Verpackungsleitfaden behandelt wird: Die Produktsicherheitsvorschriften der EU verlangen Gebrauchsanweisungen und Sicherheitsinformationen in der Amtssprache des jeweiligen Mitgliedstaats, in dem ein Produkt tatsächlich verkauft wird, nicht automatisch in allen EU-Sprachen, und die Sunrise-2027-Initiative von GS1, bis zu der Kassensysteme im Einzelhandel einen 2D-Barcode neben dem klassischen 1D-Barcode lesen können sollen, bis zum 31. Dezember 2027, treibt die Verpackungsgestaltung zunehmend in Richtung eines einzigen, informationsreicheren QR-Codes statt separater Codes pro Markt. Ein sprachverzweigendes Ziel ist genau das, was es einem gedruckten Code erlaubt, die Kennzeichnungsanforderungen mehrerer Märkte über eine einzige Artikelnummer hinweg zu erfüllen.
Messen und internationale Veranstaltungen sind der zweite Fall: Ein einziger Banner- oder Badge-Code kann einen deutschen Teilnehmer auf eine deutsche Produktseite und eine Besucherin aus Spanien auf eine spanische schicken, ohne für jede Sprache einen eigenen Stand drucken zu müssen. Das ergänzt den Koordinationsansatz aus QR-Codes für Events und Messen, wo ein einziger Code bereits mehreren Zwecken dienen muss; Sprachverzweigung ist einfach eine weitere Ebene auf demselben dynamischen Ziel.
Internationales Direktmarketing und mehrsprachige touristische Beschilderung runden die gängigen Fälle ab: Ein Flyer, der in mehreren Ländern verteilt wird, oder Beschilderung in einem mehrsprachigen Touristenviertel profitiert genauso wie eine Verpackungsauflage davon, ein einziges gedrucktes Element statt mehrerer zu nutzen.
Sprachverzweigung versus Standortverzweigung: oft brauchen Sie beides, in der richtigen Reihenfolge
Es lohnt sich, genau zu unterscheiden, worin sich das von standortbasierten QR-Codes unterscheidet, denn die beiden werden häufig durcheinandergebracht. Geotargeting leitet einen Scan danach weiter, wo der Code gescannt wird, nützlich, um jemanden zur nächstgelegenen Filiale oder einem regionsspezifischen Angebot zu schicken. Sprachverzweigung leitet danach weiter, auf welche Sprache das Gerät eingestellt ist, nützlich, um Inhalte zu zeigen, die die Person tatsächlich lesen kann. Eine einzelne Kampagne braucht häufig beides, und die Reihenfolge ist entscheidend: Lösen Sie zuerst die Sprache auf, damit die Seite überhaupt lesbar ist, und nutzen Sie dann den Standort innerhalb dieser Sprache, um zu entscheiden, etwa welchen Filialbestand oder welche Preise Sie zeigen. Es andersherum zu tun, zuerst den Standort, riskiert, jemandem eine Seite in einer Sprache zu geben, die von einer Netzwerkverbindung diktiert wird, statt von einem Telefon, das die Person tatsächlich besitzt.
Einrichtung, ohne selbst einen Sprachumschalter anfassen zu müssen
Nichts davon erfordert, dass Besucherinnen und Besucher mit irgendetwas interagieren. Die Verzweigungslogik liegt vollständig im Ziel, nicht im QR-Code selbst, weshalb sie mit jedem bestehenden dynamischen QR-Code funktioniert: Das gedruckte Element ändert sich nie, nur die dahinterliegende Weiterleitungsregel. In der Praxis bedeutet das:
- Behalten Sie einen QR-Code pro Produkt, Banner oder Element bei, genau wie bei einer Kampagne ohne Sprachverzweigung, gemäß derselben Ein-Workspace-pro-Kunde-Struktur, die Agenturen bereits nutzen, um Kunden mit mehreren Märkten organisiert zu halten.
- Stellen Sie die Weiterleitungsregel so ein, dass zuerst die Gerätesprache geprüft wird, mit Rückfall auf eine Standardseite.
- Fügen Sie den sichtbaren manuellen Umschalter auf der Landingpage hinzu, als Sicherheitsnetz für die Fälle, in denen die Erkennung danebenliegt.
- Kennzeichnen Sie jeden Sprachzweig eindeutig im Analytics-Tracking, sodass ein Scan-Report die Aufteilung nach Sprache zeigt und nicht nur eine einzelne Gesamtzahl.
- Aktualisieren Sie die Standard-Rückfalloption oder fügen Sie jederzeit eine neue Sprache hinzu, da sich das Ziel ohne Neudruck bearbeiten lässt, derselbe Vorteil, der unter das Ziel eines QR-Codes ändern, ohne neu zu drucken beschrieben wird.
Häufig gestellte Fragen
Wie erkennt ein QR-Code, welche Sprache er anzeigen soll?
Er speichert keine mehreren Sprachen. Der Code verweist auf eine einzige dynamische URL, und eine Weiterleitungsregel hinter dieser URL liest das Sprachsignal des scannenden Geräts aus, den Accept-Language-Header oder navigator.language im Browser, und leitet die Besucherin oder den Besucher an die passende übersetzte Seite weiter. Der Standort, abgeleitet aus der IP-Adresse, wird nur als Rückfalloption genutzt, wenn kein Sprachsignal verfügbar ist.
Erkennt ein QR-Code die tatsächliche Muttersprache oder nur die Spracheinstellung des Telefons?
Nur die Spracheinstellung des Telefons, und beides ist nicht zwangsläufig dasselbe. Ein Gerät meldet, worauf es eingestellt ist, was entweder eine bewusst getroffene Einstellung widerspiegelt oder eine Werkseinstellung, die nie geändert wurde, nicht notwendigerweise die Sprache, die die Person am besten spricht. Deshalb ist ein sichtbarer manueller Umschalter wichtig: Automatische Erkennung ist eine starke erste Vermutung, keine Garantie.
Was ist der Accept-Language-Header, und woher stammt er?
Es handelt sich um einen HTTP-Anfrage-Header, definiert in der HTTP-Spezifikation (RFC 9110), den jeder Browser bei jeder Anfrage automatisch sendet. Er listet die Sprachen auf, die auf dem Gerät bevorzugt eingestellt sind, geordnet nach einem Qualitätswert, zum Beispiel fr-FR, fr;q=0.9, en;q=0.5, was bedeutet: Französisch (Frankreich) zuerst, allgemeines Französisch danach, Englisch zuletzt. Ein Server liest diese Liste aus und wählt die am höchsten eingestufte Sprache, für die eine Übersetzung vorliegt.
Sollte man die Browsersprache, die IP-Geolokalisierung oder beides nutzen?
Beides, aber nicht gleichrangig. Die Gerätesprache, aus dem Accept-Language-Header oder navigator.language, sollte zuerst geprüft werden, da sie eine tatsächliche Spracheinstellung widerspiegelt. IP-basierte Geolokalisierung sollte nur als Rückfalloption dienen, wenn die Gerätesprache fehlt oder nicht unterstützt wird, da der Standort nichts Verlässliches darüber aussagt, welche Sprache eine Besucherin lesen kann. Eine explizite Wahl, die eine Besucherin bereits getroffen hat, über einen Umschalter oder ein gespeichertes Cookie, sollte beides überstimmen.
Was ist ein BCP-47-Sprach-Tag?
BCP 47 ist der Standard, der die im Web verwendeten Sprach-Tags definiert, etwa en-GB, pt-BR oder zh-Hans. Er kombiniert einen Basis-Sprachcode aus der ISO-639-Familie mit einem optionalen Regions-Subtag aus ISO 3166 oder einem Schriftsystem-Subtag, sodass sich dieselbe Basissprache bei Bedarf nach Land oder Schriftsystem unterscheiden lässt, etwa britisches gegenüber amerikanischem Englisch oder brasilianisches gegenüber europäischem Portugiesisch.
Können VPNs oder Reisen eine sprachbasierte QR-Weiterleitung durcheinanderbringen?
Ja, auf unterschiedliche Weise. Ein VPN kann dazu führen, dass die IP-basierte Geolokalisierung ein Land meldet, in dem sich die Besucherin gar nicht befindet, was aber nur dann ein Problem ist, wenn der Standort als primäres Signal genutzt wird, und das sollte er nicht sein. Die Gerätesprache übersteht Reisen und VPN-Nutzung problemlos, da sie eine Einstellung des Telefons selbst ist, keine Netzwerkeigenschaft, und genau deshalb sollte ihr vor dem Standort vertraut werden.
Was passiert, wenn die Gerätesprache nicht in eine der übersetzten Sprachen fällt?
Die Weiterleitung sollte auf eine sinnvolle Standardseite zurückfallen, üblicherweise Englisch oder die Sprache des Marktes, für den der Code ursprünglich gedruckt wurde, statt eine kaputte oder automatisch übersetzte Seite anzuzeigen. Auch hier zeigt sich der Wert eines sichtbaren manuellen Sprachumschalters: Jemand kann eine Sprache wählen, die tatsächlich unterstützt wird, selbst wenn die Standardeinstellung des Geräts nicht dazugehörte.
Sollte die Weiterleitung die erkannte Sprache erzwingen oder nur vorschlagen?
Vorschlagen, indem automatisch weitergeleitet wird, aber immer eine sichtbare Möglichkeit bestehen bleibt, die Sprache zu ändern. Eine stille, unveränderliche Weiterleitung anhand einer automatischen Vermutung ist genau das Fehlverhalten, das es zu vermeiden gilt. Wählt eine Besucherin bewusst eine andere Sprache, sollte diese Wahl gespeichert und bei späteren Scans respektiert werden, statt bei jedem Mal erneut geraten zu werden.
Wie lässt sich nachverfolgen, in welche Sprache ein Scan aufgelöst hat?
Indem jeder Sprachzweig als eigenes, nachverfolgbares Ziel gekennzeichnet wird, dieselbe Disziplin, die bei QR-Code-UTM-Parametern beschrieben wird, nur pro Sprache statt pro Kanal oder Kampagne angewendet. Das macht aus „wir unterstützen fünf Sprachen" einen echten Report: in welche Sprachen Scans tatsächlich auflösen, und ob ein Markt, den Sie für überwiegend englischsprachig hielten, sich in Wirklichkeit auf zwei oder drei Sprachen aufteilt.
Kurz zusammengefasst
Ein mehrsprachiger QR-Code ist keine besondere Art von Code, sondern ein dynamisches Ziel, das anhand des Sprachsignals des scannenden Geräts verzweigt, bevor Inhalte ausgeliefert werden. Vertrauen Sie zuerst einer expliziten Wahl, an zweiter Stelle der Gerätesprache (Accept-Language und navigator.language, geregelt durch BCP 47), und dem IP-basierten Standort nur als allerletzter Rückfalloption, denn der Standort verrät, wo sich ein Telefon befindet, nicht, was sein Besitzer liest. Lassen Sie immer einen sichtbaren manuellen Umschalter bestehen, protokollieren Sie, welchen Zweig jeder Scan nimmt, und aktualisieren Sie die Rückfalloption oder fügen Sie eine neue Sprache hinzu, sobald die Kampagne es erfordert, da sich das Ziel ohne Neudruck bearbeiten lässt. Wenn Sie eine Verpackungs-, Messe- oder internationale Direktmarketingkampagne über mehr als einen Sprachmarkt hinweg betreiben, richten Sie das einmal hinter Ihrem bestehenden dynamischen QR-Code ein, statt für jede Sprache einen eigenen Code zu drucken.
Mehr lesen

· 20 Min. Lesezeit
Standortbasierte QR-Codes: So funktionieren Geo-Redirects wirklich (und daran scheitern sie)
IP-basierte Geolokalisierung ist auf Länderebene zuverlässig (über 99 %), aber auf Stadtebene wacklig (20-75 %). GPS-Geofencing ist präzise, braucht aber eine Standortfreigabe. Und wo genau die DSGVO-Grenze verläuft.
Weiterlesen
· 17 Min. Lesezeit
Warum Ihr QR-Code so lange zum Weiterleiten braucht (und wie Sie das beheben)
Warum QR-Code-Scans manchmal quälend lange laden: 301 vs. 302, In-App-Browser und wie Sie Ihre Weiterleitungskette in wenigen Minuten selbst prüfen und beschleunigen.
Weiterlesen