Automatická detekce jazyka chatbota: Preferenci, záložní řešení a volba uživatele

Vícejazyčný chatbot na webu by neměl návštěvníky poslat do špatného jazyka hned při první odpovědi. Nicméně automatická detekce jazyka chatbota znamená více než jen převzetí první hodnoty z prohlížeče. Nastavení prohlížeče mohou být zastaralá, zařízení může být sdílené a člověk může dát přednost čtení odborného obsahu v angličtině, i když jeho operační systém používá němčinu.

Robustní řešení proto přistupuje k automatické detekci pouze jako k výchozímu signálu. Výslovná volba uživatele má přednost, dostupnost rozhraní, báze znalostí a procesu předání lidské podpoře stanovuje limity a viditelné záložní řešení (fallback) zabraňuje tomu, aby zdánlivě odpovídající jazyk vedl k neúplným nebo vymysleným odpovědím.

Proč je jazyk prohlížeče pouze vodítkem

Prohlížeče často odesílají HTTP hlavičku Accept-Language. Ta obsahuje jazykové oblasti a může vyjádřit pořadí pomocí takzvaných hodnot kvality, například de-AT,de;q=0.9,en;q=0.7. Standard RFC 9110 výslovně popisuje tyto preference jako pomůcku pro výběr prezentace obsahu, nikoli jako spolehlivou informaci o samotné osobě.

V prohlížeči poskytuje navigator.languages seřazený seznam preferovaných BCP-47 jazykových tagů. Podle MDN však mohou prohlížeče z důvodů ochrany soukromí odhalovat méně preferencí. Prohlížeč navíc může doplnit obecnější varianty: z de-AT se tak pro porovnání může stát relevantním i de .

Důsledek pro chatboty je praktický: Accept-Language a navigator.languages jsou dobrými kandidáty pro prvotní návrh. Nesmí však nahrazovat polohu ani státní příslušnost. IP adresa neprozrazuje spolehlivé jazykové přání. Ani samotná doména nebo jazyk stránky nestačí, pokud návštěvník vědomě přešel na jinou jazykovou verzi.

Jasný řetězec priorit předchází překvapením

Výběr by měl být deterministický. Osvědčilo se pořadí, které jasně váží každý zdroj:

1. Výslovná volba v aktuální relaci: Pokud uživatel klikne na francouzštinu, musí následující odpověď chatbota použít francouzštinu.
2. Uložená, dosud platná preference: Předchozí volba může platit i při pozdější návštěvě, pokud je ukládání transparentní a technicky přípustné.
3. Jazyk aktuální stránky: Chatbot by se neměl bezdůvodně odchylovat od vědomě otevřené jazykové verze.
4. Preference prohlížeče: Seznam se porovnává se skutečně podporovanými lokalizacemi chatbota.
5. Dokumentovaný standard: Pokud nic neodpovídá, následuje vědomě zvolený základní jazyk namísto náhodného výsledku.

Tento řetězec odděluje detekci od rozhodnutí. Lze jej protokolovat a testovat: source=user, source=stored, source=page, source=browser nebo source=default. Pro analytiku obvykle stačí zdroj a zvolená lokalizace (locale). Úplný seznam jazyků prohlížeče by se neměl zbytečně ukládat, protože RFC 9110 poukazuje na možná rizika pro soukromí a fingerprinting u detailních jazykových preferencí.

Normalizace BCP-47 tagů bez ztráty významu

Jazykové tagy se neskládají pouze ze dvou písmen. pt-BR a pt-PT sdílejí jazyk, ale mohou se lišit v tonalitě, výběru slov, formátech a právních pojmech. Rozhodující mohou být i písemné systémy. Aplikace by proto měla příchozí tagy syntakticky normalizovat a následně je ověřit vůči explicitnímu seznamu podporovaných lokalizací.

Od specifického tagu k bezpečnému fallbacku

Smysluplné párování se nejprve pokusí o přesnou variantu. Pokud de-AT není k dispozici, může následovat de . Poté může nastoupit známá, redakčně overená standardní lokalizace. Pouhé odříznutí všech podtagů (subtags) však není vždy bezpečné. U jazyků s více písmy nebo výrazně odlišnými variantami potřebuje produkt vědomě definované mapování.

Fallback musí být kontrolován odděleně pro tři úrovně: Je rozhraní chatu přeloženo? Existují odpovídající zdroje znalostí? Může tuto řeč převzít lidský tým podpory? Lokalizované tlačítko ještě není důkazem toho, že báze znalostí má stejné pokrytí. Jak se zdroje oddělují podle jazyka, verze a přístupu, ukazuje článek o metadatových filtrech RAG pro AI chatboty.

Nabídnout automatiku, zachovat viditelnou volbu uživatele

Doporučení W3C pro internacionalizaci spojuje automatické zprostředkování jazyka se snadno vyhledatelnými odkazy na alternativní jazykové verze. Pokud uživatel sám změní jazyk, měla by tato volba přebít preference prohlížeče a na přání zůstat zachována pro následující stránky.

Pro chatbota to znamená: aktivní jazyk patří viditelně do hlavičky chatu nebo do dobře dostupného menu. Změna nesmí bez povšimnutí odeslat rozepsanou zprávu. Místo toho zůstane vstup zachován, bot změnu jazyka stručně vysvětlí a kontrolovaně pokračuje v konverzaci. Pokud jsou předchozí zprávy v jiném jazyce, měl by systém zachovat jejich význam pro kontext, ale nepřekládat celou historii bez vyzvání.

Dobrá formulace zní například: „Čeština byla převzata z této stránky. Změnit jazyk.“ V případě záložního řešení může být upozornění konkrétnější: „Pro češtinu nejsou k tomuto tématu k dispozici žádné ověřené informace. Mohu použít anglický zdroj nebo dotaz předat podpoře.“ Uživatel tak pochopí, proč se mění jazyk nebo hloubka odpovědi.

Oddělení jazyka stránky, jazyka chatu a lokalizace obsahu

Tři hodnoty bývají často mylně sloučeny do jednoho pole:

• Jazyk stránky: primární jazyk HTML dokumentu;
• Jazyk chatu: jazyk, ve kterém se zobrazuje rozhraní a odpovědi;
• Lokalizace obsahu: varianta, ze které smí chatbot čerpat podložené informace.

Tyto hodnoty mohou být stejné, ale nemusí. Česky mluvící uživatel může na anglické produktové stránce položit dotaz v češtině. Bot může odpovědět česky a přesto transparentně odkázat na anglický originální zdroj. Neměl by však tvrdit, že použil český zdroj, pokud byla odpověď pouze přeložena.

Pro přístupnost musí být jazyk dokumentu a obsahu správně označen. Technika W3C H57 popisuje atribut langu prvku html, aby mimo jiné čtečky obrazovky mohly správně zpracovat výslovnost a syntaxi. Pokud se v jednotlivém úseku změní jazyk, vyžaduje i tato oblast odpovídající označení. Další kontroly sdružuje kontrolní seznam WCAG pro webové chatboty.

Cache a URL musí respektovat rozhodnutí o jazyce

Kdo vybírá obsah na straně serveru podle Accept-Language , musí vzít v úvahu strategii ukládání do mezipaměti (cache). RFC 9110 vysvětluje, že Vary: Accept-Language signalizuje mezipamětem, že hlavička ovlivnila zobrazení. Chybí-li toto oddělení, může mezipaměť doručit českou variantu anglicky mluvícímu návštěvníkovi.

Pro veřejný, indexovatelný obsah se stabilní jazykově specifické URL často snáze kontrolují a sdílejí. Automatická detekce pak může navést na odpovídající URL, aniž by skrývala různý obsah pod stejnou adresou. V samotném chatu by měla být lokalizace součástí stavu relace a každého požadavku na server. Změna jazyka musí společně aktualizovat klíče mezipaměti, vyhledávací styly (retrieval) a generování odpovědí.

Do této dohody patří i formátované hodnoty. Datum, číslo, měna a časové pásmo nevyplývají automaticky správně z jazyka textu. Průvodce Lokalizace odpovědí chatbota ukazuje, jak s těmito daty zacházet samostatně a konzistentně.

Záložní řešení nesmí zastírat mezery v obsahu

Nejrizikovější chybou je tichá změna báze znalostí. Pokud k českému dotazu neexistuje český článek, může bot použít anglický zdroj, pokud produkt tuto cestu umožňuje. Musí však zkontrolovat zdroj, aktuálnost a oprávnění stejně jako při přímé shodě.

Bezpečná matice záložních řešení obsahuje minimálně: požadovanou lokalizaci, dostupnou lokalizaci rozhraní, dostupnou lokalizaci obsahu, povolenou záložní lokalizaci, režim překladu a cíl předání. Výsledkem není vždy odpověď. U citlivých nebo silně kontextových témat je „žádná ověřená informace v tomto jazyce“ lepší než plynulý, ale nepodložený překlad. Článek o záložních řešeních při mezerách ve znalostech popisuje, jak spolupracují nejistota a předání na člověka.

Testovací případy pro jazykovou logiku

Malá, systematická sada testů odhalí více chyb než jediná kontrola prohlížeče. Měla by pokrývat minimálně tyto případy:

• de-AT je nabízeno, podporováno je pouze de;
• první preference prohlížeče není k dispozici, druhá ano;
• volba uživatele protiřečí jazyku stránky a prohlížeče;
• uložená preference odkazuje na lokalizaci, která byla mezitím odstraněna;
• rozhraní je k dispozici, ale báze znalostí nebo předání nikoli;
• změna jazyka proběhne uprostřed konverzace s neodeslaným textem;
• mezipaměť po změně skutečně doručí novou lokalizaci;
• čtečka obrazovky správně rozpozná jazyk stránky a sekce;
• analytika zaznamenává zdroj výběru a fallback, ale žádný zbytečně detailní seznam preferencí.

Pro každou kombinaci by týmy měly zaznamenat očekávanou lokalizaci, zdroj rozhodnutí, viditelné upozornění a povolený prostor obsahu. Každý jazyk navíc vyžaduje odborné vzorkování. Úplnost a kvalitu odpovědí nelze vyvodit pouze z přítomnosti přeloženého řádku.

Praktický kontrolní seznam pro zavedení

1. Inventarizujte odděleně všechny podporované lokalizace rozhraní, obsahu a předání.
2. Zdokumentujte jednoznačný řetězec priorit pro volbu uživatele, uloženou volbu, stránku, prohlížeč a standard.
3. Definujte BCP-47 párování včetně regionálních výjimek a výjimek týkajících se písma.
4. Navrhněte změnu jazyka viditelně a bez ztráty zadaného textu.
5. Omezte záložní řešení podle pokrytí zdrojů, aktuálnosti a oprávnění.
6. langZkontrolujte , jazykově specifické URL, kanonické tagy a chování mezipaměti.
7. Ukládejte pouze nezbytná analytická data a stanovte dobu jejich uchovávání.
8. Otestujte desktop, mobilní zařízení, klávesnici a čtečku obrazovky s realistickými seznamy preferencí.

Klíčové produktové rozhodnutí tedy nezní: „Jaký jazyk má tento návštěvník?“ Zní: „Jaký jazyk byl požadován, jaký obsah je pro něj spolehlivě k dispozici a jak vysvětlíme nutnou záložní cestu?“ Kdo na tyto tři otázky odpoví odděleně, získá chatbota, který začne automaticky užitečně, ale kontrolu ponechá uživateli.

Zdroje

• RFC 9110: Accept-Language, Vary a ochrana soukromí
• MDN: Navigator.languages
• W3C Internationalization: Směrování uživatelů na přeložené stránky
• W3C WAI: Označení jazyka dokumentu pomocí lang