Automatyczne wykrywanie języka chatbotu: preferencje, fallbacki i wybór użytkownika

Wielojęzyczny chatbot witryny nie powinien wysyłać odwiedzających w niewłaściwym języku już przy pierwszej odpowiedzi. Jednak automatyczne wykrywanie języka chatbotu oznacza coś więcej niż przejęcie pierwszej wartości z przeglądarki. Ustawienia przeglądarki mogą być nieaktualne, urządzenie może być udostępniane, a człowiek może woleć czytać treści techniczne po angielsku, mimo że jego system operacyjny używa języka niemieckiego.

Solidne rozwiązanie traktuje zatem automatyczne wykrywanie wyłącznie jako sygnał startowy. Wyraźny wybór użytkownika ma priorytet, dostępność interfejsu, bazy wiedzy i procesu przekazania wyznacza granice, a widoczny fallback zapobiega sytuacji, w której pozornie pasujący język prowadzi do niepełnych lub zmyślonych odpowiedzi.

Dlaczego język przeglądarki to tylko wskazówka

Przeglądarki często wysyłają nagłówek HTTP Accept-Language. Zawiera on zakresy językowe i może wyrażać kolejność za pomocą tak zwanych wartości jakości, na przykład de-AT,de;q=0.9,en;q=0.7. Standard RFC 9110 wyraźnie opisuje te preferencje jako pomoc w wyborze prezentacji, a nie jako pewną informację o danej osobie.

W przeglądarce navigator.languages dostarcza uporządkowaną listę preferowanych tagów językowych BCP 47. Według MDN przeglądarki mogą jednak ze względów prywatności ujawniać mniej preferencji. Ponadto przeglądarka może w pewnych okolicznościach uzupełniać bardziej ogólne warianty: Z de-AT dla dopasowania może dodatkowo stać się istotny de .

Konsekwencja dla chatbotów jest praktyczna: Accept-Language i navigator.languages są dobrymi kandydatami do pierwszej propozycji. Nie mogą one jednak zastąpić lokalizacji ani narodowości. Adres IP nie zdradza wiarygodnego życzenia językowego. Sama domena lub język strony również nie wystarczą, jeśli odwiedzający świadomie przełączył się na inną wersję językową.

Jasny łańcuch priorytetów zapobiega niespodziankom

Wybór powinien być deterministyczny. Sprawdziła się kolejność, która jasno waży każde źródło:

1. Wyraźny wybór w bieżącej sesji: Jeśli użytkownik kliknie język francuski, następna odpowiedź chatbotu musi używać języka francuskiego.
2. Zapisana, wciąż ważna preferencja: Wcześniejszy wybór może obowiązywać ponownie podczas późniejszej wizyty, o ile przechowywanie jest przejrzyste i dopuszczalne technicznie.
3. Język bieżącej strony: Chatbot nie powinien bez powodu odbiegać od świadomie otwartej wersji językowej.
4. Preferencje przeglądarki: Lista jest porównywana z rzeczywiście obsługiwanymi ustawieniami regionalnymi (locales) chatbotu.
5. Udokumentowany standard: Jeśli nic nie pasuje, następuje celowo wybrany język podstawowy zamiast losowego wyniku.

Ten łańcuch oddziela wykrywanie od decyzji. Można go rejestrować i testować: source=user, source=stored, source=page, source=browser lub source=default. W przypadku analityki zazwyczaj wystarcza źródło i wybrana lokalizacja. Pełna lista języków przeglądarki nie powinna być niepotrzebnie przechowywana, ponieważ RFC 9110 zwraca uwagę na potencjalne ryzyka związane z prywatnością i fingerprintingiem w szczegółowych preferencjach językowych.

Normalizuj tagi BCP 47 bez utraty znaczenia

Tagi językowe nie składają się tylko z dwóch liter. pt-BR i pt-PT dzielą jeden język, ale mogą różnić się tonacją, dobiorem słów, formatami i pojęciami prawnymi. Decydujące mogą być również systemy pisma. Dlatego aplikacja powinna syntaktycznie znormalizować przychodzące tagi, a następnie sprawdzić je z jawną listą obsługiwanych lokalizacji.

Od specyficznego tagu do bezpiecznego fallbacku

Sensowne dopasowanie najpierw próbuje dokładnego wariantu. Jeśli de-AT jest niedostępny, może nastąpić de . Następnie może zadziałać znana, sprawdzona redakcyjnie domyślna lokalizacja. Jednak zwykłe odcięcie wszystkich podtagów nie zawsze jest bezpieczne. W przypadku języków z wieloma systemami pisma lub znacznie różniącymi się wariantami produkt potrzebuje celowo zdefiniowanego przypisania.

Fallback musi być sprawdzony osobno dla trzech poziomów: Czy interfejs czatu jest przetłumaczony? Czy istnieją odpowiednie źródła wiedzy? Czy ludzki zespół wsparcia może przejąć ten język? Zlokalizowany przycisk nie jest jeszcze dowodem na to, że baza wiedzy ma takie samo pokrycie. O tym, jak rozdzielać źródła według języka, wersji i dostępu, dowiesz się z artykułu o filtrach metadanych RAG dla chatbotów AI.

Oferuj automatyzację, zachowaj widoczność wyboru użytkownika

Rekomendacja umiędzynarodowienia W3C łączy automatyczne pośrednictwo językowe z łatwo dostępnymi linkami do alternatywnych wersji językowych. Jeśli użytkownik sam zmieni język, ten wybór powinien unieważnić preferencje przeglądarki i na życzenie pozostać zachowany dla kolejnych stron.

Dla chatbotu oznacza to: aktywny język powinien być widoczny w nagłówku czatu lub w łatwo dostępnym menu. Zmiana nie może niezauważalnie wysłać bieżącego szkicu. Zamiast tego wpisany tekst pozostaje zachowany, bot krótko wyjaśnia zmianę języka i kontynuuje rozmowę w kontrolowany sposób. Jeśli wcześniejsze wiadomości istnieją w innym języku, system powinien zachować ich znaczenie dla kontekstu, ale nie tłumaczyć nieproszony całego przebiegu rozmowy.

Dobre sformułowanie brzmi na przykład: „Język polski został przejęty z tej strony. Zmień język.” W przypadku fallbacku informacja może być bardziej konkretna: „W języku polskim brak sprawdzonych informacji na ten temat. Mogę użyć źródła angielskiego lub przekazać sprawę do wsparcia.” W ten sposób użytkownik rozumie, dlaczego zmienia się język lub głębokość odpowiedzi.

Rozdziel język strony, język czatu i lokalizację treści

Trzy wartości są często błędnie łączone w jedno pole:

• Język strony: główny język dokumentu HTML;
• Język czatu: język, w którym pojawia się interfejs i odpowiedzi;
• Lokalizacja treści: wariant, z którego chatbot może pobierać potwierdzone informacje.

Te wartości mogą być takie same, ale nie muszą. Polski użytkownik może zadać pytanie po polsku na angielskiej stronie produktu. Bot może odpowiedzieć po polsku i nadal przejrzyście odwoływać się do angielskiego źródła oryginalnego. Nie powinien jednak twierdzić, że użył polskiego źródła, jeśli przetłumaczono tylko odpowiedź.

Z punktu widzenia dostępności język dokumentu i treści musi być prawidłowo oznaczony. Technika W3C H57 opisuje atrybut langna elemencie html, aby między innymi czytniki ekranu mogły odpowiednio przetwarzać wymowę i składnię. Jeśli pojedyncza sekcja zmienia język, również ten obszar wymaga odpowiedniego oznaczenia. Dalsze weryfikacje gromadzi lista kontrolna WCAG dla chatbotów witryn.

Pamięć podręczna i adresy URL muszą respektować decyzję językową

Kto wybiera treści po stronie serwera według Accept-Language , musi uwzględnić strategię pamięci podręcznej. RFC 9110 wyjaśnia, że Vary: Accept-Language sygnalizuje pamięciom podręcznym, że nagłówek wpłynął na prezentację. Jeśli brakuje tego podziału, pamięć podręczna może dostarczyć polską wersję użytkownikowi anglojęzycznemu.

Dla publicznych, indeksowalnych treści stabilne adresy URL specyficzne dla języka są często łatwiejsze do weryfikacji i udostępniania. Automatyczne wykrywanie może wtedy prowadzić do odpowiedniego adresu URL bez ukrywania różnych treści pod tym samym adresem. W samym czacie lokalizacja powinna być częścią stanu sesji i każdego żądania po stronie serwera. Zmiana języka musi wspólnie aktualizować klucze pamięci podręcznej, filtry wyszukiwania (retrieval) i generowanie odpowiedzi.

Sformatowane wartości również należą do tej umowy. Data, liczba, waluta i strefa czasowa nie wynikają automatycznie prawidłowo z języka tekstu. Przewodnik lokalizowanie odpowiedzi chatbotu pokazuje, jak traktować te dane osobno i spójnie.

Fallbacki nie mogą maskować luk w treści

Najbardziej ryzykownym błędem jest cicha zmiana bazy wiedzy. Jeśli do polskiego pytania nie istnieje polski artykuł, bot może użyć źródła angielskiego, o ile produkt dopuszcza taką ścieżkę. Musi jednak sprawdzić źródło, aktualność i uprawnienia dokładnie tak samo, jak przy bezpośrednim dopasowaniu.

Bezpieczna macierz fallbacków zawiera co najmniej: żądaną lokalizację, dostępną lokalizację UI, dostępną lokalizację treści, dopuszczalną lokalizację zastępczą, tryb tłumaczenia i cel przekazania (handoff). Wynikiem nie zawsze jest odpowiedź. W przypadku tematów wrażliwych lub silnie zależnych od kontekstu brak sprawdzonych informacji w tym języku jest lepszy niż płynne, ale niepotwierdzone tłumaczenie. Artykuł o fallbackach przy braku wiedzy opisuje, jak współgrają ze sobą niepewność i przekazanie rozmowy.

Przypadki testowe dla logiki językowej

Niewielki, systematyczny zestaw testowy znajduje więcej błędów niż pojedyncze sprawdzenie przeglądarki. Powinien obejmować co najmniej następujące przypadki:

• de-AT jest oferowany, obsługiwany jest tylko de;
• pierwsza preferencja przeglądarki jest niedostępna, druga tak;
• wybór użytkownika jest sprzeczny z językiem strony i przeglądarki;
• zapisana preferencja wskazuje na usuniętą w międzyczasie lokalizację;
• UI istnieje, ale baza wiedzy lub handoff nie;
• zmiana języka następuje w środku rozmowy z niewysłanym tekstem;
• pamięć podręczna po zmianie naprawdę dostarcza nową lokalizację;
• czytnik ekranu prawidłowo rozpoznaje język strony i sekcji;
• analityka rejestruje źródło wyboru i fallback, ale bez niepotrzebnie szczegółowej listy preferencji.

Dla każdej kombinacji zespoły powinny określić oczekiwaną lokalizację, źródło decyzji, widoczną informację i dozwolony obszar treści. Dodatkowo każdy język wymaga merytorycznych próbkowych testów. Kompletności i jakości odpowiedzi nie da się wywnioskować z samego istnienia wiersza tłumaczenia.

Praktyczna lista kontrolna wdrożenia

1. Zrób osobny inwentarz wszystkich obsługiwanych lokalizacji UI, treści i handoffu.
2. Zudokumentuj jednoznaczny łańcuch priorytetów dla wyboru użytkownika, zapisanego wyboru, strony, przeglądarki i domyślnego języka.
3. Zdefiniuj dopasowanie BCP 47 wraz z wyjątkami regionalnymi i dotyczącymi pisma.
4. Zaprojektuj zmianę języka w sposób widoczny i bez utraty wpisanego tekstu.
5. Ogranicz fallbacki do pokrycia źródeł, aktualności i uprawnień.
6. lang, sprawdź adresy URL specyficzne dla języka, adresy kanoniczne i zachowanie pamięci podręcznej.
7. Zapisuj tylko niezbędne dane analityczne i ustal okres ich przechowywania.
8. Przetestuj komputer, urządzenie mobilne, klawiaturę i czytnik ekranu z realistycznymi listami preferencji.

Kluczowa decyzja produktowa nie brzmi zatem: „Jakim językiem posługuje się ten odwiedzający?” Brzmi ona: „Jaki język był pożądany, jakie treści są w nim niezawodnie dostępne i jak wyjaśniamy konieczną ścieżkę zastępczą?” Kto odpowie na te trzy pytania osobno, otrzyma chatbot, który automatycznie zaczyna pomocnie, ale pozostawia kontrolę użytkownikowi.

Źródła

• RFC 9110: Accept-Language, Vary i ochrona danych
• MDN: Navigator.languages
• W3C Internationalization: Guiding users to translated pages
• W3C WAI: Oznaczanie języka dokumentu za pomocą lang