Chatbot-taal automatisch herkennen: voorkeuren, fallbacks en gebruikerskeuze

Een meertalige website-chatbot moet bezoekers niet meteen met het eerste antwoord naar de verkeerde taal sturen. Maar chatbot-taal automatisch herkennen betekent meer dan simpelweg de eerste browserwaarde overnemen. Browserinstellingen kunnen verouderd zijn, een apparaat kan worden gedeeld en iemand kan technische inhoud liever in het Engels lezen, ook al gebruikt het besturingssysteem Nederlands.

Een robuuste oplossing ziet automatische detectie daarom alleen als een startsein. De expliciete keuze van de gebruiker heeft voorrang, de beschikbaarheid van de interface, kennisbank en het overdrachtsproces stelt de grenzen, en een zichtbare fallback voorkomt dat een schijnbaar passende taal tot onvolledige of verzonnen antwoorden leidt.

Waarom de browsersaanduiding slechts een indicatie is

Browsers sturen vaak de HTTP-header Accept-Languagemee. Deze bevat taalbereiken en kan via zogeheten kwaliteitswaarden een volgorde aangeven, zoals de-AT,de;q=0.9,en;q=0.7. De standaard RFC 9110 beschrijft deze voorkeuren uitdrukkelijk als hulpmiddel voor het selecteren van een weergave, niet als een harde conclusie over de persoon.

In de browser levert navigator.languages een geordende lijst van gewenste BCP-47-taaltags op. Volgens MDN kunnen browsers om privacyredenen echter minder voorkeuren prijsgeven. Bovendien vult een browser eventueel algemenere varianten aan: uit de-AT kan voor de vergelijking ook de relevant worden.

De praktische consequentie voor chatbots: Accept-Language en navigator.languages zijn goede kandidaten voor de eerste suggestie. Ze mogen echter nooit locatie of nationaliteit vervangen. Een IP-adres verraadt immers geen betrouwbare taalwens. Ook de domeinnaam of de paginataal alleen is onvoldoende als een bezoeker bewust naar een andere taalversie is overgestapt.

Een duidelijke prioriteitenketen voorkomt verrassingen

De selectie moet deterministisch zijn. In de praktijk werkt een volgorde het beste waarin elke bron een helder gewicht krijgt:

1. Expliciete keuze in de huidige sessie: Klikt de gebruiker op Frans, dan moet het volgende antwoord van de chatbot in het Frans zijn.
2. Opgeslagen, nog geldige voorkeur: Een eerdere keuze mag bij een volgend bezoek weer gelden, mits het opslaan transparent en technisch toegestaan is.
3. Taal van de huidige pagina: De chatbot moet niet zonder reden afwijken van de bewust geopende taalversie.
4. Browservoorkeuren: De lijst wordt vergeleken met de daadwerkelijk ondersteunde chatbot-locales.
5. Gedocumenteerde standaard: Als niets past, volgt een bewust gekozen basistaal in plaats van een willekeurig resultaat.

Deze keten scheidt detectie van besluitvorming. Het proces laat zich zo goed vastleggen en testen: source=user, source=stored, source=page, source=browser of source=default. Voor analytics is de bron en de gekozen locale meestal voldoende. De volledige taallijst van de browser hoeft niet onnodig te worden opgeslagen, aangezien RFC 9110 wijst op mogelijke risico's rond privacy en fingerprinting bij gedetailleerde taalvoorkeuren.

BCP-47-tags normaliseren zonder betekenisverlies

Taaltags bestaan uit meer dan twee letters. pt-BR en pt-PT delen weliswaar een taal, maar kunnen verschillen in tonaliteit, woordkeuze, opmaak en juridische begrippen. Ook het schrift kan doorslaggevend zijn. Daarom moet de applicatie binnenkomende tags syntactisch normaliseren en vervolgens vergelijken met een expliciete lijst van ondersteunde locales.

Van specifieke tag naar een veilige fallback

Een slimme matching probeert eerst de exacte variant. Is de-AT niet beschikbaar, dan kan de volgen. Daarna mag een bekende, redactioneel gecontroleerde standaardlocale worden gebruikt. Maar het simpelweg afknippen van alle subtags is niet altijd veilig. Bij talen met meerdere schriften of sterk afwijkende varianten heeft het product een bewust gedefinieerde toewijzing nodig.

De fallback moet voor drie niveaus afzonderlijk worden gecontroleerd: Is de chat-interface vertaald? Zijn er passende kennisbronnen? Kan een menselijk supportteam deze taal afhandelen? Een gelokaliseerde knop bewijst namelijk nog niet dat de kennisbank dezelfde dekking heeft. Hoe bronnen op basis van taal, versie en toegang worden gescheiden, lees je in het artikel over RAG-metagegevensfilters voor AI-chatbots.

Automatisering bieden, gebruikerskeuze zichtbaar houden

De internationaliseringsaanbeveling van het W3C combineert automatische taaloverdracht met makkelijk vindbare links naar alternatieve taalversies. Als een gebruiker zelf van taal wisselt, moet deze keuze de browservoorkeur overschrijven en desgewenst voor vervolgpagina's bewaard blijven.

Voor een chatbot betekent dit: de actieve taal hoort zichtbaar in de header van de chat of in een goed bereikbaar menu te staan. Een taalwissel mag een conceptbericht niet ongemerkt verzenden. In plaats daarvan blijft de invoer behouden, legt de bot de taalwissel kort uit en wordt het gesprek gecontroleerd voortgezet. Als eerdere berichten in een andere taal zijn geschreven, moet het systeem de betekenis ervan voor de context bewaren, maar niet ongevraagd de hele geschiedenis vertalen.

Een goede formulering is bijvoorbeeld: "Nederlands is overgenomen van deze pagina. Taal wijzigen." Bij een fallback kan de melding concreter zijn: "Voor het Nederlands is over dit onderwerp geen gecontroleerde informatie beschikbaar. Ik kan de Engelse bron gebruiken of u doorverbinden met support." Zo begrijpt de gebruiker waarom de taal of de diepgang van het antwoord verandert.

Paginataal, chattaal en inhoudslocale scheiden

Drie waarden worden vaak onterecht samengevoegd tot één enkel veld:

• Paginataal: de primaire taal van het HTML-document;
• Chattaal: de taal waarin de interface en antwoorden verschijnen;
• Inhoudslocale: de variant waaruit de chatbot onderbouwde informatie mag ophalen.

Deze waarden kunnen identiek zijn, maar dat hoeft niet. Een Nederlandstalige gebruiker kan op een Engelse productpagina een Nederlandse vraag stellen. De bot mag in het Nederlands antwoorden en toch transparant verwijzen naar de Engelse originele bron. Hij moet echter niet beweren een Nederlandse bron te hebben gebruikt als alleen het antwoord is vertaald.

Met het oog op toegankelijkheid moeten de document- en inhoudstaal correct zijn gemarkeerd. De W3C-techniek H57 beschrijft het lang-attribuut op het html-element, zodat onder meer schermlezers de uitspraak en syntaxis correct verwerken. Als een enkel tekstgedeelte van taal verandert, heeft ook die sectie een passende markering nodig. Aanvullende controles vind je in de WCAG-checklist voor website-chatbots.

Caching en URL's moeten de taalkeuze respecteren

Als je inhoud aan de serverzijde selecteert op basis van Accept-Language , moet je rekening houden met de cachingstrategie. RFC 9110 legt uit dat Vary: Accept-Language aan caches signaleert dat de header de weergave heeft beïnvloed. Ontbreekt deze scheiding, dan kan een cache de Nederlandse variant tonen aan een Engelstalige bezoeker.

Voor openbare, indexeerbare inhoud zijn stabiele taalspecifieke URL's vaak gemakkelijker te testen en te delen. De automatische detectie kan dan naar een passende URL leiden zonder verschillende inhoud onder hetzelfde adres te verbergen. In de chat zelf moet de locale onderdeel zijn van de sessiestatus en van elke serveraanvraag. Een taalwissel moet cache-sleutels, retrieval-filters en antwoordgeneratie tegelijk bijwerken.

Ook geformatteerde waarden horen bij deze afspraak. Datum, getal, valuta en tijdzone volgen niet automatisch correct uit de teksttaal. De handleiding Chatbot-antwoorden lokaliseren laat zien hoe deze gegevens afzonderlijk en consistent worden behandeld.

Fallbacks mogen geen hiaten in de inhoud verbergen

De meest risicovolle fout is een stille wissel van de kennisbank. Als er bij een Nederlandse vraag geen Nederlands artikel bestaat, kan de bot een Engelse bron gebruiken mits het product dit toestaat. Hij moet de bron, de actualiteit en de autorisatie echter net zo strikt controleren als bij een directe match.

Een veilige fallback-matrix bevat ten minste: opgevraagde locale, beschikbare UI-locale, beschikbare inhoudslocale, toegestane vervangende locale, vertaalmodus en het overdrachtsdoel. Het resultaat is niet altijd een antwoord. Bij gevoelige of sterk contextafhankelijke onderwerpen is "geen gecontroleerde informatie in deze taal" beter dan een vloeiende maar ononderbouwde vertaling. Het artikel over fallbacks bij gebrek aan kennis beschrijft hoe onzekerheid en escalatie samenwerken.

Testcases voor de taallogica

Een kleine, systematische testset vindt meer fouten dan een enkele browsercheck. Deze moet ten minste de volgende situaties dekken:

• de-AT wordt aangeboden, maar alleen de;
• is ondersteund; de eerste browservoorkeur is niet beschikbaar, de tweede wel;
• de keuze van de gebruiker is strijdig met de pagina- en browsertaal;
• de opgeslagen voorkeur verwijst naar een inmiddels verwijderde locale;
• de UI is aanwezig, maar de kennisbank of overdracht optie niet;
• er vindt een taalwissel plaats midden in een gesprek met niet-verzonden tekst;
• de cache levert na de wissel daadwerkelijk de nieuwe locale;
• de schermlezer herkent de pagina- en sectietaal correct;
• analytics registreert de selectiebron en de fallback, maar geen onnodig gedetailleerde voorkeurslijst.

Voor elke combinatie moeten teams de verwachte locale, de bron van de beslissing, de zichtbare melding en de toegestane inhoudsruimte vastleggen. Aanvullend heeft elke taal inhoudelijke steekproeven nodig. Volledigheid en antwoordkwaliteit kunnen niet louter worden afgeleid uit het aanwezig zijn van een vertaalregel.

Praktische checklist voor de uitrol

1. Inventariseer alle ondersteunde UI-, inhouds- en overdrachtslocales afzonderlijk.
2. Documenteer een eenduidige prioriteitenketen voor de gebruikerskeuze, opgeslagen keuze, pagina, browser en standaard.
3. Definieer BCP-47-matching inclusief regionale en op schrift gebaseerde uitzonderingen.
4. Ontwerp taalwissels zo dat ze zichtbaar zijn en zonder verlies van invoer verlopen.
5. Beperk fallbacks op basis van brondekking, actualiteit en rechten.
6. langControleer taalspecifieke URL's, canonicals en het cachegedrag.
7. Sla alleen noodzakelijke analytics-gegevens op en stel een bewaartermijn vast.
8. Test op desktop, mobiel, toetsenbord en schermlezer met realistische voorkeurslijsten.

De centrale productbeslissing luidt dus niet: "Welke taal spreekt deze bezoeker?" Maar: "Welke taal is gewenst, welke inhoud is daarvoor betrouwbaar beschikbaar en hoe leggen we een noodzakelijke uitwijkroute uit?" Wie deze drie vragen los van elkaar beantwoordt, krijgt een chatbot die automatisch nuttig start, maar de controle bij de gebruiker laat.

Bronvermelding

• RFC 9110: Accept-Language, Vary en privacy
• MDN: Navigator.languages
• W3C Internationalization: Guiding users to translated pages
• W3C WAI: Taal van het document aanduiden met lang