Identifiera chatbot-språk automatiskt: Inställningar, fallbacks och användarval

En flerspråkig chatbot på en webbplats bör inte skicka besökare till fel språk redan vid det första svaret. Men automatisk identifiering av chatbot-språk innebär mer än att bara ta det första värdet från webbläsaren. Webbläsarinställningar kan vara utdaterade, en enhet kan delas av flera och en person kan föredra att läsa tekniskt innehåll på engelska även om operativsystemet är inställt på tyska.

En robust lösning behandlar därför automatisk identifiering endast som en startsignal. Användarens explicita val har alltid företräde, tillgängligheten av gränssnitt, kunskapsbas och överlämningsprocess sätter gränserna, och en synlig fallback förhindrar att ett skenbart passande språk leder till ofullständiga eller påhittade svar.

Varför webbläsarspråket bara är en ledtråd

Webbläsare skickar ofta HTTP-headern Accept-Language. Den innehåller språkområden och kan uttrycka en ordning med hjälp av så kallade kvalitetsvärden, till exempel de-AT,de;q=0.9,en;q=0.7. Standarden RFC 9110 beskriver uttryckligen dessa inställningar som en hjälp vid val av presentation, inte som en säker uppgift om personen.

I webbläsaren ger navigator.languages en sorterad lista över föredragna BCP-47-språktaggar. Enligt MDN kan webbläsare dock lämna ut färre inställningar av integritetsskäl. Dessutom kan en webbläsare i vissa fall lägga till mer generella varianter: Från de-AT kan även de bli relevant för matchningen.

Den praktiska konsekvensen för chatbots är: Accept-Language och navigator.languages är bra kandidater för det första förslaget. De får dock varken ersätta plats eller medborgarskap. En IP-adress avslöjar inte ett tillförlitligt språkönskemål. Inte heller domänen eller enbart sidans språk räcker till om en besökare medvetet har växlat till en annan språkversion.

En tydlig prioriteringskedja förhindrar överraskningar

Valet bör vara deterministiskt. En ordning som väger varje källa tydligt har visat sig fungera bra:

1. Explicit val i den aktuella sessionen: Om användaren klickar på franska måste nästa chatbot-svar använda franska.
2. Sparat, fortfarande giltigt val: Ett tidigare val får gälla igen vid ett senare besök, förutsatt att lagringen är transparent och tekniskt tillåten.
3. Språk för den aktuella sidan: Chatboten bör inte utan anledning avvika från den språkversion som medvetet öppnats.
4. Webbläsarinställningar: Listan matchas mot de chatbot-locales som faktiskt stöds.
5. Dokumenterad standard: Om inget passar används ett medvetet valt grundspråk i stället för ett slumpmässigt resultat.

Denna kedja skiljer identifiering från beslut. Den kan loggas och testas: source=user, source=stored, source=page, source=browser eller source=default. För analys syften räcker oftast källan och den valda locale-koden. Webbläsarens fullständiga språklista bör inte sparas i onödan, eftersom RFC 9110 pekar på potentiella risker gällande spårning och integritet med detaljerade språkinställningar.

Normalisera BCP-47-taggar utan att förlora innebörd

Språktaggar består inte bara av två bokstäver. pt-BR och pt-PT delar ett språk, men kan skilja sig åt när det gäller tonläge, ordval, format och juridiska begrepp. Även skriftsystem kan vara avgörande. Applikationen bör därför normalisera inkommande taggar syntaktiskt och därefter kontrollera dem mot en explicit lista över stödda locales.

Från specifik tagg till säker fallback

En genomtänkt matchning försöker först med den exakta varianten. Om de-AT inte är tillgänglig kan de följa. Därefter kan en känd, redaktionellt granskad standard-locale användas. Att helt enkelt skära bort alla subtaggar är dock inte alltid säkert. För språk med flera skriftsystem eller kraftigt avvikande varianter behöver produkten en medvetet definierad mappning.

En fallback måste kontrolleras separat för tre nivåer: Är chatgränssnittet översatt? Finns det passande kunskapskällor? Kan ett mänskligt supportteam ta över på detta språk? En lokaliserad knapp är inget bevis för att kunskapsbasen har samma täckning. Hur källor separeras efter språk, version och åtkomst visas i artikeln om RAG-metadatafilter för AI-chatbots.

Erbjud automatik, håll användarvalet synligt

W3C:s internationaliseringsrekommendation kombinerar automatisk språkförmedling med lättfunna länkar till alternativa språkversioner. Om en användare själv byter språk ska detta val överstyra webbläsarinställningen och på begäran bevaras för följande sidor.

För en chatbot innebär detta: Det aktiva språket ska vara synligt i chatthuvudet eller i en lättillgänglig meny. Ett språkbyte får inte skicka iväg ett pågående utkast obemärkt. I stället ligger texten kvar, boten förklarar språkbytet kortfattat och fortsätter konversationen på ett kontrollerat sätt. Om tidigare meddelanden finns på ett annat språk bör systemet bevara deras innebörd i kontexten, men inte översätta hela historiken opåkallat.

En bra formulering kan till exempel vara: ”Svenska hämtades från den här sidan. Byt språk.” Vid en fallback kan meddelandet vara mer konkret: ”Det finns ingen granskad information på svenska om detta ämne. Jag kan använda den engelska källan eller koppla dig till supporten.” På så sätt förstår användaren varför språket eller svarsdjupet ändras.

Separera sidspråk, chattspråk och innehålls-locale

Tre värden slås ofta felaktigt ihop till ett enda fält:

• Sidspråk: det primära språket i HTML-dokumentet;
• Chattspråk: språket som gränssnittet och svaren visas på;
• Innehålls-locale: varianten från vilken chatboten får hämta verifierad information.

Dessa värden kan vara desamma, men behöver inte vara det. En svenskspråkig användare kan ställa en fråga på svenska på en engelsk produktsida. Boten får svara på svenska och ändå transparent hänvisa till en engelsk originalkälla. Den bör dock inte påstå att den använt en svensk källa om det bara är svaret som har översatts.

För tillgänglighetens skull måste dokument- och innehållsspråk vara korrekt angivna. W3C-tekniken H57 beskriver lang-attributet på html-elementet, så att bland annat skärmläsare kan hantera uttal och syntax på rätt sätt. Om ett enskilt avsnitt byter språk behöver även det området en lämplig märkning. Ytterligare kontroller finns samlade i WCAG-checklistan för webbplats-chatbots.

Cachning och URL:er måste respektera språkvalet

Den som väljer innehåll på serversidan utifrån Accept-Language måste ta hänsyn till cachningsstrategin. RFC 9110 förklarar att Vary: Accept-Language signalerar till cacher att headern har påverkat presentationen. Om denna separation saknas kan en cache leverera den tyska varianten till en engelskspråkig besökare.

För offentligt, indexerbart innehåll är stabila språkspecifika URL:er ofta lättare att granska och dela. Den automatiska identifieringen kan då leda till en passande URL utan att dölja olika innehåll under samma adress. I själva chatten bör locale-koden ingå i sessionsstatusen och i varje begäran till serversidan. Ett språkbyte måste uppdatera cache-nycklar, hämtningsfilter och svarsgenerering samtidigt.

Även formaterade värden ingår i detta avtal. Datum, tal, valuta och tidszon följer inte automatiskt på ett korrekt sätt från textens språk. Guiden Lokalisera chatbot-svar visar hur dessa data hanteras separat och konsekvent.

Fallbacks får inte dölja luckor i innehållet

Det mest riskfyllda felet är ett tyst byte av kunskapsbas. Om det inte finns någon svensk artikel för en svensk fråga kan boten använda en engelsk källa, förutsatt att produkten tillåter den vägen. Men den måste kontrollera källa, aktualitet och behörighet på exakt samma sätt som vid en direkt matchning.

En säker fallback-matris innehåller minst: begärd locale, tillgänglig UI-locale, tillgänglig innehålls-locale, tillåten ersättnings-locale, översättningsläge och överlämningsmål. Resultatet är inte alltid ett svar. I känsliga eller starkt kontextberoende frågor är ”ingen verifierad information på detta språk” bättre än en flytande men obekräftad översättning. Artikeln om fallbacks vid kunskapsluckor beskriver hur osäkerhet och överlämning samverkar.

Testfall för språklogik

Ett litet, systematiskt testset hittar fler fel än en enstaka webbläsarkontroll. Det bör täcka minst följande fall:

• de-AT erbjuds, men endast de;
• första webbläsarinställningen är inte tillgänglig, men den andra är det;
• användarvalet strider mot sidans och webbläsarens språk;
• sparat val hänvisar till en locale som har tagits bort;
• UI finns, men inte kunskapsbas eller överlämning;
• språkbyte sker mitt i en konversation med ej skickad text;
• cachen levererar verkligen den nya locale-koden efter byte;
• skärmläsaren identifierar sidans och avsnittets språk korrekt;
• analysverktyg fångar valkälla och fallback, men ingen onödigt detaljerad lista över inställningar.

För varje kombination bör teamet dokumentera förväntad locale, beslutsorsak, synligt meddelande och tillåtet innehållsområde. Dessutom behöver varje språk ämnesmässiga stickprov. Fullständighet och svarskvalitet kan inte avgöras enbart utifrån att en översättningsrad finns på plats.

Praktisk checklista för lansering

1. Inventera alla stödda UI-, innehålls- och överlämnings-locales separat.
2. Dokumentera en entydig prioriteringskedja för användarval, sparat val, sida, webbläsare och standard.
3. Definiera BCP-47-matchning inklusive regionala och skriftrelaterade undantag.
4. Utforma språkbyten synligt och utan att förlora inmatad text.
5. Begränsa fallbacks utifrån källtäckning, aktualitet och behörighet.
6. lang, språkspecifika URL:er, canonicals och cachebeteende.
7. Spara endast nödvändiga analysdata och fastställ lagringstid.
8. Testa stationära datorer, mobila enheter, tangentbord och skärmläsare med realistiska inställningslistor.

Det centrala produktbeslutet handlar därför inte om: ”Vilket språk har den här besökaren?” Det handlar om: ”Vilket språk önskades, vilket innehåll finns tillförlitligt tillgängligt för detta och hur förklarar vi en nödvändig reservväg?” Den som besvarar dessa tre frågor separat får en chatbot som startar automatiskt hjälpsamt, men lämnar kontrollen hos användaren.

Källor

• RFC 9110: Accept-Language, Vary och dataskydd
• MDN: Navigator.languages
• W3C Internationalization: Guiding users to translated pages
• W3C WAI: Ange dokumentets språk med lang