Registrer chatbot-sprog automatisk: Præferencer, fallbacks og brugervalg

En flersproget website-chatbot bør ikke sende besøgende i den forkerte retning med det allerførste svar. Men at registrere chatbot-sprog automatisk indebærer mere end blot at overtage den første browserværdi. Browserindstillinger kan være forældede, en enhed kan deles af flere, og en bruger kan foretrække at læse teknisk indhold på engelsk, selvom styresystemet er indstillet til tysk.

En robust løsning behandler derfor kun automatisk registrering som et startsignal. Brugerens eksplicitte valg har førsteprioritet, tilgængeligheden af brugerflade, videnbase og overdragelsesproces sætter grænserne, og en synlig fallback forhindrer, at et tilsyneladende passende sprog fører til ufuldstændige eller opdigtede svar.

Hvorfor browsersproget kun er en indikation

Browsere sender hyppigt HTTP-headere som Accept-Language. Den indeholder sprogområder og kan angive en rækkefølge via såkaldte kvalitetsværdier, for eksempel de-AT,de;q=0.9,en;q=0.7. Standarden RFC 9110 beskriver udtrykkeligt disse præferencer som en hjælp til valg af visning, ikke som en sikker påstand om personen.

I browseren leverer navigator.languages en sorteret liste over foretrukne BCP-47-sprogtags. Ifølge MDN kan browsere af privatlivshensyn dog vælge at videregive færre præferencer. Derudover supplerer en browser under visse omstændigheder med mere generelle varianter: Fra de-AT kan også de blive relevant for matchet.

Den praktiske konsekvens for chatbots er: Accept-Language og navigator.languages er gode kandidater til det første forslag. Men de må hverken erstatte placering eller nationalitet. En IP-adresse afslører ikke et pålideligt sprogønske. Domænet eller sidesproget alene er heller ikke tilstrækkeligt, hvis en besøgende bevidst har skiftet til en anden sprogversion.

En klar prioriteringskæde forhindrer overraskelser

Udvælgelsen bør være deterministisk. Det har vist sig effektivt at bruge en rækkefølge, der vægter hver kilde entydigt:

1. Eksplicit valg i den aktuelle session: Klikker brugeren på fransk, skal det næste chatbot-svar være på fransk.
2. Gemt, stadig gyldig præference: Et tidligere valg må gerne gælde ved et senere besøg, forudsat at lagringen er gennemskuelig og teknisk tilladt.
3. Sprog på den aktuelle side: Chatbotten bør ikke uden grund afvige fra den sprogversion, som brugeren bevidst har åbnet.
4. Browserpræferencer: Listen sammenlignes med de chatbot-locales, der faktisk understøttes.
5. Dokumenteret standard: Hvis intet matcher, anvendes et bevidst valgt grundsprog i stedet for et tilfældigt resultat.

Denne kæde adskiller registrering fra beslutning. Den kan logges og testes: source=user, source=stored, source=page, source=browser eller source=default. Til analytics er kilden og det valgte locale som regel tilstrækkeligt. Browserens fuldstændige sprogliste bør ikke gemmes unødigt, da RFC 9110 fremhæver mulige risici for privatliv og fingerprinting ved detaljerede sprogpræferencer.

Normaliser BCP-47-tags uden at miste betydning

Sprogtags består ikke kun af to bogstaver. pt-BR og pt-PT deler samme sprog, men kan adskille sig i toneangivelse, ordvalg, formater og juridiske begreber. Skriftsystemer kan også være afgørende. Applikationen bør derfor normalisere indkommende tags syntaktisk og derefter kontrollere dem mod en eksplicit liste over understøttede locales.

Fra specifikt tag til sikker fallback

Et hensigtsmæssigt match forsøger først den præcise variant. Er de-AT ikke tilgængelig, kan de følge efter. Derefter kan et kendt, redaktionelt godkendt standard-locale træde i kraft. Blot at skære alle subtags fra er dog ikke altid sikkert. Ved sprog med flere skriftsystemer eller meget forskellige varianter kræver produktet en bevidst defineret kortlægning.

Fallback skal afprøves separat på tre niveauer: Er chat-brugerfladen oversat? Findes der passende videnkilder? Kan et menneskeligt supportteam overtage på dette sprog? En lokaliseret knap er endnu ikke et bevis på, at videnbasen har samme dækning. Hvordan kilder adskilles efter sprog, version og adgang, fremgår af artiklen om RAG-metadatafiltre til AI-chatbots.

Tilbyd automatik, men hold brugerens valg synligt

W3C's internationaliseringsanbefaling kombinerer automatisk sprogvisning med let tilgængelige links til alternative sprogversioner. Hvis en bruger selv skifter sprog, skal dette valg tilsidesætte browserpræferencen og efter ønske bevares på efterfølgende sider.

For en chatbot betyder det: Det aktive sprog skal placeres synligt i chat-headere eller i en let tilgængelig menu. Sprogskiftet må ikke uforvarende indsende en igangværende kladde. I stedet bevares indtastningen, botten forklarer sprogskiftet kort og fortsætter samtalen kontrolleret. Hvis tidligere beskeder findes på et andet sprog, bør systemet bevare deres betydning for konteksten, men ikke uopfordret oversætte hele historikken.

En god formulering kan for eksempel være: »Dansk er hentet fra denne side. Skift sprog.« Ved en fallback kan meddelelsen være mere konkret: »Der findes ingen bekræftede oplysninger om dette emne på dansk. Jeg kan bruge den engelske kilde eller stille dig om til support.« På den måde forstår brugeren, hvorfor sproget eller svardybden ændres.

Adskil sidesprog, chat-sprog og indholdslocale

Tre værdier samles ofte fejlagtigt i et enkelt felt:

• Sidesprog: det primære sprog i HTML-dokumentet;
• Chat-sprog: det sprog, som brugerflade og svar vises på;
• Indholdslocale: den variant, hvorfra chatbotten må hente dokumenteret information.

Disse værdier kan være ens, men behøver ikke at være det. En dansktalende bruger kan stille et dansk spørgsmål på en engelsk produktside. Botten må gerne svare på dansk og samtidig gennemskueligt henvise til en engelsk originalkilde. Den bør dog ikke hævde at have brugt en dansk kilde, hvis det kun er svaret, der er blevet oversat.

Af hensyn til tilgængelighed skal dokument- og indholdssprog være korrekt angivet. W3C-teknikken H57 beskriver lang-attributten på html-elementet, så blandt andet skærmlæsere kan håndtere udtale og syntaks korrekt. Hvis et enkelt afsnit skifter sprog, skal dette område også have en passende mærkning. Flere kontrolelementer er samlet i WCAG-tjeklisten for website-chatbots.

Cache og URL'er skal respektere sprogbeslutningen

Hvis indhold udvælges på serversiden ud fra Accept-Language , skal der tages højde for cache-strategien. RFC 9110 forklarer, at Vary: Accept-Language signalerer til caches, at headeren har påvirket visningen. Mangler denne adskillelse, kan en cache levere den tyske variant til en engelsktalende besøgende.

For offentligt, indekserbart indhold er stabile sprogspecifikke URL'er ofte lettere at teste og dele. Automatisk registrering kan derefter føre til en passende URL uden at skjule forskelligt indhold under den samme adresse. I selve chatten bør locale være en del af sessionstilstanden og enhver forespørgsel på serversiden. Et sprogskift skal opdatere cache-nøgler, retrieval-filtre og svargenerering på én gang.

Formaterede værdier hører også under denne aftale. Dato, tal, valuta og tidszone følger ikke automatisk korrekt med tekstsproget. Guiden Lokalisering af chatbot-svar viser, hvordan disse data håndteres separat og konsistent.

Fallbacks må ikke skjule manglende indhold

Den mest risikable fejl er et stille skift i videnbasen. Hvis der ikke findes en dansk artikel til et dansk spørgsmål, kan botten benytte en engelsk kilde, forudsat at produktet tillader denne vej. Men kilde, aktualitet og rettigheder skal kontrolleres nøjagtigt som ved et direkte match.

En sikker fallback-matrix indeholder mindst: efterspurgt locale, tilgængeligt UI-locale, tilgængeligt indholdslocale, tilladt reserve-locale, oversættelsestilstand og overdragelsesmål. Resultatet er ikke altid et svar. Ved følsomme eller stærkt kontekstafhængige emner er »ingen bekræftet information på dette sprog« bedre end en flydende, men udokumenteret oversættelse. Artiklen om fallbacks ved manglende viden beskriver, hvordan usikkerhed og overdragelse spiller sammen.

Testtilfælde for sproglogikken

Et lille, systematisk testsæt afdækker flere fejl end et enkelt browser-tjek. Det bør som minimum dække følgende tilfælde:

• de-AT tilbydes, men kun de;
• understøttes; den første browserpræference er ikke tilgængelig, men den anden er;
• brugerens valg strider imod side- og browsersprog;
• gemt præference henviser til et locale, der i mellemtiden er fjernet;
• UI er til stede, men videnbase eller overdragelse er ikke;
• sprogskift sker midt i en samtale med uafsendt tekst;
• cache leverer reelt det nye locale efter skiftet;
• skærmlæser registrerer side- og afsnitssprog korrekt;
• analyseværktøjer registrerer valgkilde og fallback, men ingen unødigt detaljeret præferenceliste.

For hver kombination bør teams fastholde forventet locale, beslutningskilde, synlig meddelelse og tilladt indholdsområde. Derudover skal hvert sprog gennemgå faglige stikprøver. Fuldstændighed og svarkvalitet kan ikke udledes alene af, at en oversættelseslinje eksisterer.

Praktisk tjekliste til implementering

1. Kortlæg alle understøttede UI-, indholds- og overdragelses-locales separat.
2. Dokumentér en entydig prioriteringskæde for brugervalg, gemt valg, side, browser og standard.
3. Definér BCP-47-matching inklusiv regionale og skriftbaserede undtagelser.
4. Gør sprogskift synligt og uden tab af indtastede data.
5. Begræns fallbacks til kildedækning, aktualitet og rettigheder.
6. lang, sprogspecifikke URL'er, canonicals og cache-adfærd.
7. Gem kun nødvendige analytics-data og fastlæg opbevaringsperiode.
8. Test desktop, mobil, tastatur og skærmlæser med realistiske præferencelister.

Den centrale produktbeslutning lyder derfor ikke: »Hvilket sprog har denne besøgende?« Den lyder i stedet: »Hvilket sprog er ønsket, hvilket indhold er pålideligt tilgængeligt på dette sprog, og hvordan forklarer vi en nødvendig reservevej?« Når disse tre spørgsmål besvares særskilt, får du en chatbot, der starter automatisk hjælpsomt, men lader kontrollen forblive hos brugeren.

Kilder

• RFC 9110: Accept-Language, Vary og databeskyttelse
• MDN: Navigator.languages
• W3C Internationalization: Guiding users to translated pages
• W3C WAI: Mærkning af dokumentets sprog med lang