Eén QR-code, meerdere talen: zo detecteer je automatisch de taal van de scanner

Een winkelketen die hetzelfde product verkoopt in Rotterdam, Berlijn en Milaan had vroeger drie QR-codes nodig: één per markt, één per taal, gedrukt op drie aparte verpakkingsruns. Dat werkt nog steeds, maar het is niet meer hoe de meeste bureaus dit probleem oplossen. Eén dynamische QR-code kan tegenwoordig detecteren in welke taal het scannende device staat ingesteld en de scan direct doorsturen naar de bijpassende landingspagina, zonder dat de shopper ooit een taalschakelaar aanraakt.

Dit is belangrijker dan het lijkt. Voor bureaus die verpakkings-, beurs-, toerisme- of directmailcampagnes in meerdere landen draaien, schrapt een taalbewuste QR-code een hele categorie printplanning: geen gepuzzel meer over welk SKU welke code krijgt, geen herdruk meer zodra er een nieuwe markt bijkomt, en geen giswerk meer over welke taal een scan "hoort" op te leveren. De code blijft hetzelfde. Alleen de bestemming verandert, en dat gebeurt automatisch, op basis van een signaal dat de telefoon toch al verstuurt.

Deze post legt uit hoe die detectie onder de motorkap werkt, welk signaal je moet vertrouwen als twee elkaar tegenspreken, waar het misgaat (VPN's, gedeelde devices, reizigers), en hoe je een fallback inbouwt zodat niemand vastloopt op een pagina die hij niet kan lezen.

Wat een "meertalige QR-code" eigenlijk is

Er bestaat geen QR-code die meerdere talen in zich opslaat. Een QR-code is gewoon een container voor één payload, vrijwel altijd een enkele URL. Wat een code "meertalig" laat aanvoelen, is dat de URL waarnaar hij verwijst een dynamische redirect is: hetzelfde mechanisme zit achter dynamische QR-codes in het algemeen. De code blijft vaststaan op de verpakking of de flyer, maar de bestemming erachter is een kleine beslislaag die op taal vertakt voordat er ooit content wordt geserveerd.

Die beslislaag kijkt naar het verzoek dat de telefoon stuurt, kiest een taal en stuurt de bezoeker door naar de bijpassende versie van de pagina. Krijg je die vertakkingslogica goed voor elkaar, dan ziet de shopper nooit een taalmenu. Gaat het mis, dan landt de bezoeker op een pagina in een taal die hij niet leest, hoe goed de QR-code zelf ook is ontworpen.

De drie signalen, en de volgorde waarin je ze vertrouwt

Er zijn drie manieren om te bepalen welke taal je iemand moet tonen, en ze zijn niet even betrouwbaar. De volgorde goed krijgen is het grootste deel van het werk.

• Expliciete keuze wint altijd. Heeft een bezoeker al een taal gekozen, op deze scan of een vorige, via een schakelaar of een opgeslagen cookie, dan overstijgt die keuze alles. Overschrijf nooit stilzwijgend een taal die iemand bewust heeft gekozen. Dit klinkt vanzelfsprekend, maar het is de meest voorkomende fout in taaldetectie-implementaties: een verse check bij elk bezoek die zonder waarschuwing iemand omleidt die eerder bewust voor Engels koos.
• Devicetaal is het sterkste automatische signaal. Elke browser stuurt bij elk verzoek een Accept-Language-header mee, en elke telefoon geeft het equivalent door aan JavaScript als navigator.language. Beide worden gevuld op basis van de eigen taal- en regio-instelling van het device, met tags volgens BCP 47, de standaard die een ISO 639-taalcode combineert met een optionele ISO 3166-regio- of scriptsubtag, zoals en-GB, pt-BR of zh-Hans. Een header ziet er vaak zo uit: fr-FR, fr;q=0.9, en;q=0.5: een gerangschikte lijst, Frans (Frankrijk) als voorkeur, algemeen Frans daarna, Engels als fallback, met de q-waarden die de relatieve voorkeur uitdrukken. Meestal volstaat het om de eerste, hoogst gewaardeerde entry te lezen om een taal te kiezen.
• IP-geolocatie is alleen een fallback. Waar de telefoon zich fysiek bevindt, afgeleid uit het IP-adres, is nuttig wanneer de devicetaal ontbreekt, niet beschikbaar is, of ingesteld staat op iets wat je niet hebt vertaald. Het is geen indicatie van welke taal iemand spreekt. Genoeg mensen in Nederland zetten hun telefoon op Engels; genoeg toeristen in Rome lopen niet rond met een Italiaanstalig device. Behandel IP-geolocatie als laatste redmiddel, niet als primair signaal, en combineer het met de fallback-schakelaar hieronder.

Waarom devicetaal wint van locatie, en waarom geen van beide perfect is

Devicetaal weerspiegelt een keuze die de eigenaar van de telefoon op enig moment daadwerkelijk heeft gemaakt, of de standaardinstelling waarmee de provider of fabrikant het toestel heeft afgeleverd. Locatie zegt helemaal niets over de persoon, alleen iets over een netwerkverbinding. Daarom is die prioriteitsvolgorde belangrijk: eerst het taalsignaal, dan de locatie, dan een zichtbare handmatige optie.

Toch is geen van de drie signalen waterdicht. Telefoons reizen mee met hun eigenaar, dus een Franse toerist die in Amsterdam een code scant, presenteert zich via de devicetaal nog steeds als Frans, en dat klopt, maar diezelfde toerist die via een hotel-VPN over Duitsland verbindt, kan via IP als Duits ogen, en dat klopt niet. Gedeelde devices, een demotablet in een winkel, een kiosk in de bibliotheek, staan vaak in de taal die de vorige gebruiker heeft achtergelaten. En een flink deel van de smartphonebezitters wereldwijd verandert de fabrieksinstelling van hun telefoon nooit, waarbij Engels de meest voorkomende standaard is, wat betekent dat devicetaal soms iets zegt over de standaardinstelling van een fabrikant en niets over een gesproken taal.

Niets van dit alles maakt de aanpak onbetrouwbaar, het maakt een zichtbare fallback juist onmisbaar. Detectie moet aanvoelen als gemak, niet als een beslissing die onherroepelijk namens iemand anders wordt genomen.

1. Expliciete keuze. Een taal die de bezoeker al heeft gekozen, op deze scan of een vorige, overstijgt elk automatisch signaal daaronder.
2. Devicetaal. De Accept-Language-header en navigator.language, uitgelezen uit de eigen instellingen van de telefoon, als eerste gecontroleerd wanneer er geen expliciete keuze is.
3. IP-locatie, alleen fallback. Alleen gebruikt wanneer devicetaal ontbreekt of niet wordt ondersteund, hier weergegeven met een onderbroken rand omdat het het zwakste signaal is, geen laag om op te leunen.
4. Handmatige schakelaar, altijd aanwezig. Een zichtbare manier om de automatische gok te overstemmen, bereikbaar ongeacht welk van de drie signalen de beslissing nam.

De fallback bouwen: laat een bezoeker nooit vastzitten in de verkeerde taal

De ene regel die een goede meertalige QR-implementatie scheidt van een frustrerende: bied altijd een uitweg. Concreet betekent dat:

• Detecteer een taal automatisch en redirect naar de beste match, maar houd een kleine, zichtbare taalschakelaar op de landingspagina zelf. Vlagicoontjes zijn hier een zwak patroon, want een vlag staat voor een land, niet voor een taal; gebruik in plaats daarvan de naam van de taal zelf, zoals "Nederlands" of "Deutsch".
• Heeft de gedetecteerde taal geen vertaalde pagina, val dan terug op een logische standaard, vaak Engels, of de taal van de markt waarvoor de code is gedrukt, in plaats van een kapotte of machinaal vertaalde pagina te tonen.
• Onthoud een expliciete keuze voor de rest van dat bezoek, en idealiter ook bij een volgend bezoek, via een cookie, zodat dezelfde persoon niet opnieuw wordt gevraagd of omgeleid bij de volgende scan.
• Log naar welke tak een scan daadwerkelijk ging. Dit is dezelfde taggingdiscipline als beschreven in de gids over UTM-parameters voor QR-codes, maar dan toegepast per taal in plaats van per campagne, zodat een rapport als "40% van de scans op dit SKU ging naar Duits" iets is dat je daadwerkelijk kunt opvragen, niet iets waar je naar moet gissen.

Waar dit zich terugbetaalt: verpakking, beurzen en direct mail

Productverpakking is het duidelijkste voorbeeld. Eén kartonontwerp, verzonden naar distributeurs in meerdere landen, kan één QR-code dragen die per markt naar de juiste productpagina, veiligheidsinformatie of gebruiksaanwijzing verwijst. Dit raakt direct aan de labelingsrealiteit uit de gids over GS1 Digital Link op verpakkingen: de productveiligheidsregels van de EU eisen instructies en veiligheidsinformatie in de officiële taal van de lidstaat waar een product daadwerkelijk wordt verkocht, niet automatisch in alle EU-talen, en het Sunrise 2027-initiatief van GS1, het moment waarop kassasystemen in de retail geacht worden een 2D-barcode te kunnen lezen naast de bestaande 1D-barcode, uiterlijk 31 december 2027, duwt verpakkingen steeds meer richting één rijkere QR-code in plaats van aparte codes per markt. Een taalvertakkende bestemming is precies wat één gedrukte code de labelingseisen van meerdere markten laat afdekken vanaf één SKU.

Beurzen en internationale evenementen zijn het tweede voorbeeld: één banner- of badgecode kan een Duitse bezoeker naar een Duitse productpagina sturen en een bezoeker uit Spanje naar een Spaanse, zonder aparte stands per taal te printen. Dit sluit aan op de coördinatie-aanpak uit QR-codes voor evenementen en beurzen, waar één code al meerdere doelen moet dienen; taalvertakking is daar gewoon nog een laag bovenop dezelfde dynamische bestemming.

Internationale direct mail en toeristische bewegwijzering maken de rij compleet: een folder verspreid over meerdere landen, of bewegwijzering in een meertalige toeristenbuurt, profiteert op dezelfde manier als een verpakkingsrun, van één gedrukt exemplaar in plaats van meerdere.

Taalvertakking versus locatievertakking: je hebt vaak beide nodig, in de juiste volgorde

Het is de moeite waard om precies te zijn over hoe dit verschilt van geotargeted QR-codes, want de twee worden vaak door elkaar gehaald. Geotargeting routeert een scan op basis van waar de code wordt gescand, handig om iemand naar de dichtstbijzijnde winkel of een regiospecifieke aanbieding te sturen. Taalvertakking routeert op basis van welke taal het device heeft ingesteld, handig om content te tonen die iemand daadwerkelijk kan lezen. Eén campagne heeft vaak beide nodig, en de volgorde is belangrijk: los eerst de taal op, zodat de pagina überhaupt leesbaar is, en gebruik daarna locatie binnen die taal om te bepalen, bijvoorbeeld, welke winkelvoorraad of prijs je toont. Doe je het andersom, eerst locatie, dan riskeer je iemand een pagina te geven in een taal die wordt bepaald door een netwerkverbinding in plaats van door de telefoon die hij echt bezit.

Instellen zonder zelf ook maar één taalschakelaar aan te raken

Niets hiervan vereist dat bezoekers ergens mee interacteren. De vertakkingslogica zit volledig in de bestemming, niet in de QR-code, en dat is precies waarom het werkt met elke bestaande dynamische QR-code: het gedrukte exemplaar verandert nooit, alleen de routeringsregel erachter. In de praktijk betekent dat:

1. Houd één QR-code per product, banner of exemplaar aan, precies zoals je zou doen bij een niet-taalgebonden campagne, volgens dezelfde structuur van één werkruimte per klant die bureaus al gebruiken om klanten met meerdere markten overzichtelijk te houden.
2. Stel de redirectregel zo in dat eerst de devicetaal wordt gecontroleerd, met een terugval naar een standaardpagina.
3. Voeg de zichtbare handmatige schakelaar toe op de landingspagina, als vangnet voor de gevallen waarin de detectie misgaat.
4. Tag elke taaltak apart in je analytics, zodat een scanrapport de verdeling per taal laat zien, niet alleen één totaalcijfer.
5. Werk de standaard-fallback bij of voeg op elk moment een nieuwe taal toe, want de bestemming is aanpasbaar zonder herdruk, hetzelfde voordeel als beschreven in de bestemming van een QR-code wijzigen zonder herdruk.

Veelgestelde vragen

Hoe weet een QR-code welke taal hij bij een scan moet tonen?

Hij slaat geen meerdere talen op. De code verwijst naar één dynamische URL, en een redirectregel achter die URL leest het taalsignaal van het scannende device, de Accept-Language-header, of navigator.language in de browser, en stuurt de bezoeker door naar de bijpassende vertaalde pagina. Locatie, afgeleid uit het IP-adres, wordt alleen als fallback gebruikt wanneer er geen taalsignaal beschikbaar is.

Detecteert een QR-code de echte moedertaal van de scanner, of alleen de instellingen van de telefoon?

Alleen de instellingen van de telefoon, en dat is niet altijd hetzelfde. Een device geeft door welke taal er is ingesteld, wat een keuze weerspiegelt die iemand ooit heeft gemaakt, of een fabrieksinstelling die nooit is aangepast, niet per se de taal die iemand het best spreekt. Daarom is een zichtbare handmatige schakelaar zo belangrijk: automatische detectie is een sterke eerste gok, geen garantie.

Wat is de Accept-Language-header en waar komt die vandaan?

Het is een HTTP-requestheader, gedefinieerd door de HTTP-specificatie (RFC 9110), die elke browser automatisch bij elk verzoek meestuurt. Hij bevat een lijst van talen waarop het device is ingesteld, gerangschikt op een kwaliteitswaarde, bijvoorbeeld fr-FR, fr;q=0.9, en;q=0.5, wat betekent Frans (Frankrijk) eerst, algemeen Frans daarna, Engels als laatste. Een server leest deze lijst en kiest de hoogst gerangschikte taal waarvoor hij een vertaling heeft.

Kun je beter browsertaal, IP-geolocatie of allebei gebruiken?

Allebei, maar niet in gelijke mate. Devicetaal, uit de Accept-Language-header of navigator.language, moet je als eerste checken, omdat die een werkelijke taalinstelling weerspiegelt. IP-gebaseerde geolocatie gebruik je alleen als fallback wanneer de devicetaal ontbreekt of niet wordt ondersteund, omdat locatie niets betrouwbaars zegt over welke taal een bezoeker leest. Een expliciete keuze die een bezoeker al heeft gemaakt, via een schakelaar of een opgeslagen cookie, moet boven beide gaan.

Wat is een BCP 47-taaltag?

BCP 47 is de standaard die de taaltags definieert die op het hele web worden gebruikt, zoals en-GB, pt-BR of zh-Hans. Hij combineert een basistaalcode uit de ISO 639-familie met een optionele regiosubtag uit ISO 3166, of een scriptsubtag, zodat dezelfde basistaal kan worden onderscheiden naar land of schrijfsysteem waar dat relevant is, bijvoorbeeld Brits versus Amerikaans Engels, of Braziliaans versus Europees Portugees.

Kunnen VPN's of reizen een taalgebaseerde QR-redirect verstoren?

Ja, op verschillende manieren. Een VPN kan ervoor zorgen dat IP-gebaseerde geolocatie een land aangeeft waar de bezoeker helemaal niet is, en dat is alleen een probleem als locatie als primair signaal wordt gebruikt, wat het niet zou moeten zijn. Devicetaal overleeft reizen en VPN-gebruik prima, omdat het een instelling op de telefoon zelf is, geen netwerkeigenschap, en precies daarom moet je het boven locatie vertrouwen.

Wat gebeurt er als iemands devicetaal een taal is die je niet hebt vertaald?

De redirect moet terugvallen op een logische standaardpagina, meestal Engels, of de taal van de markt waarvoor de code oorspronkelijk is gedrukt, in plaats van een kapotte of automatisch vertaalde pagina te tonen. Ook hier bewijst een zichtbare handmatige taalschakelaar zijn waarde: iemand kan alsnog een taal kiezen die je wel ondersteunt, zelfs als de standaardinstelling van zijn device er niet een van was.

Moet de redirect de gedetecteerde taal afdwingen, of alleen suggereren?

Suggereren, door automatisch door te sturen maar altijd een zichtbare manier te bieden om dat te wijzigen. Een stille, onwijzigbare redirect op basis van een automatische gok is precies het faalscenario dat je wilt vermijden. Kiest een bezoeker bewust voor een andere taal, dan moet die keuze worden onthouden en gerespecteerd bij latere scans, niet elke keer opnieuw worden gegokt.

Hoe volg je naar welke taal een scan is doorgestuurd?

Door elke taaltak te taggen als eigen trackbare bestemming, dezelfde discipline die wordt gebruikt voor UTM-parameters bij QR-codes, maar dan toegepast per taal in plaats van per kanaal of campagne. Dat maakt van "we ondersteunen vijf talen" een echt rapport: naar welke talen scans daadwerkelijk gaan, en of een markt waarvan je aannam dat die vooral Engelstalig was, in werkelijkheid over twee of drie talen verdeeld is.

De korte versie

Een meertalige QR-code is geen apart type code, het is een dynamische bestemming die vertakt op het taalsignaal van het scannende device voordat er content wordt geserveerd. Vertrouw eerst een expliciete keuze, dan devicetaal (Accept-Language en navigator.language, gestuurd door BCP 47), en gebruik IP-gebaseerde locatie alleen als laatste redmiddel, want locatie vertelt je waar een telefoon is, niet wat de eigenaar leest. Laat altijd een zichtbare handmatige schakelaar staan, log naar welke tak elke scan gaat, en werk de fallback bij of voeg een nieuwe taal toe zodra de campagne dat vraagt, want de bestemming is aanpasbaar zonder herdruk. Draai je een verpakkings-, beurs- of internationale directmailcampagne over meer dan één taalmarkt, zet dit dan één keer op achter je bestaande dynamische QR-code in plaats van per taal een aparte code te drukken.