Chatbot-nyelv automatikus felismerése: preferenciák, tartalék opciók és felhasználói választás

Egy többnyelvű weboldal-chatbotnak nem szabadna a látogatókat már az első válasszal a rossz nyelvre irányítania. Azonban a chatbot nyelvifelismerése automatikusan többet jelent az első böngészőérték átvételénél. A böngészőbeállítások elavultak lehetnek, az eszközt többen is használhatják, és előfordulhat, hogy valaki a műszaki tartalmakat szívesebben olvassa angolul, még akkor is, ha az operációs rendszere magyar.

Ezért egy robusztus megoldás az automatikus felismerést csak kiindulópontként kezeli. A felhasználó kifejezett választása élvez elsőbbséget, a felület, a tudásbázis és az átadási folyamat elérhetősége szab határokat, egy látható tartalék opció (fallback) pedig megakadályozza, hogy egy látszólag illeszkedő nyelv hiányos vagy kitalált válaszokhoz vezessen.

Miért csak támpont a böngésző nyelve?

A böngészők gyakran küldenek HTTP-fejlécet: Accept-Language. Ez nyelvi tartományokat tartalmaz, és úgynevezett minőségi értékeken keresztül sorrendet fejezhet ki, mint például de-AT,de;q=0.9,en;q=0.7. A szabvány RFC 9110 ezeket a preferenciákat kifejezetten a megjelenítés kiválasztásához nyújtott segítségként írja le, nem pedig a személyről szóló biztos kijelentésként.

A böngészőben a navigator.languages a preferált BCP-47 nyelvi tagek rendezett listáját adja meg. Az MDN szerint azonban a böngészők adatvédelmi okokból kevesebb preferenciát fedhetnek fel. Ezenkívül a böngésző adott esetben általánosabb változatokkal is kiegészítheti azokat: a de-AT esetében az összevetéshez a de is relevánssá válhat.

A chatbotok szempontjából ez a gyakorlatban a következőt jelenti: Accept-Language és navigator.languages jó jelöltek az első javaslathoz. Nem helyettesíthetik azonban sem a tartózkodási helyet, sem az állampolgárságot. Az IP-cím nem árul el megbízható nyelvi igényt. Maga a domain vagy az oldal nyelve sem elegendő, ha a látogató tudatosan váltott egy másik nyelvi változatra.

Egy egyértelmű prioritási lánc megelőzi a meglepetéseket

A kiválasztásnak determinisztikusnak kell lennie. Bevált az a sorrend, amely minden forrást egyértelműen súlyoz:

1. Kifejezett választás az aktuális munkamenetben: Ha a felhasználó a francia nyelvre kattint, a következő chatbot-válasznak franciául kell megjelennie.
2. Elmentett, még érvényes preferencia: Egy korábbi választás egy későbbi látogatás során újra érvényes lehet, feltéve, hogy a tárolás átlátható és technikailag megengedett.
3. Az aktuális oldal nyelve: A chatbotnak nem szabad nyomós ok nélkül eltérnie a tudatosan megnyitott nyelvi változattól.
4. Böngészőpreferenciák: A listát összevetjük a chatbot által ténylegesen támogatott területi beállításokkal (locale).
5. Dokumentált alapértelmezés: Ha semmi sem illeszkedik, egy véletlenszerű eredmény helyett egy tudatosan kiválasztott alapnyelv következik.

Ez a lánc elválasztja a felismerést a döntéstől. Naplózható és tesztelhető: source=user, source=stored, source=page, source=browser vagy source=default. Az analitikához általában elegendő a forrás és a kiválasztott locale. A böngésző teljes nyelvi listáját nem érdemes feleslegesen tárolni, mivel az RFC 9110 rámutat a részletes nyelvi preferenciák adatvédelmi és digitális ujjlenyomat-képzési (fingerprinting) kockázataira.

BCP-47 tagek normalizálása a jelentés elvesztése nélkül

A nyelvi tagek nem csak két betűből állnak. pt-BR és pt-PT osztoznak egy nyelven, de eltérhetnek a hangvétel, a szóhasználat, a formátumok és a jogi kifejezések tekintetében. Az írásrendszerek is döntőek lehetnek. Ezért az alkalmazásnak szintaktikailag normalizálnia kell a beérkező tageket, majd ellenőriznie kell azokat a támogatott területi beállítások kifejezett listájával szemben.

A konkrét tagtől a biztonságos tartalék opcióig (fallback)

Az értelmes illesztés először a pontos változattal próbálkozik. Ha a de-AT nem érhető el, a de következhet. Ezt követően egy ismert, szerkesztőségileg ellenőrzött alapértelmezett locale léphet életbe. Az összes subtag egyszerű levágása azonban nem mindig biztonságos. Több írásrendszerrel vagy erősen eltérő változatokkal rendelkező nyelvek esetén a terméknek tudatosan meghatározott hozzárendelésre van szüksége.

A tartalék opciót három szinten külön kell ellenőrizni: Le van fordítva a chat felülete? Léteznek megfelelő tudásforrások? Át tudja venni az emberi támogatási csapat ezt a nyelvet? Egy lokalizált gomb még nem bizonyítja, hogy a tudásbázis ugyanolyan lefedettséggel rendelkezik. A források nyelv, verzió és hozzáférés szerinti elkülönítését az alábbi cikk mutatja be: RAG metaadat-szűrők AI chatbotokhoz.

Automatizmus felajánlása, a felhasználói választás láthatóvá tétele

A W3C nemzetköziesítési ajánlása az automatikus nyelvközvetítést az alternatív nyelvi változatokra mutató, könnyen megtalálható hivatkozásokkal ötvözi. Ha a felhasználó maga vált nyelvet, ennek a választásnak felül kell írnia a böngésző preferenciáját, és kérésre meg kell maradnia a következő oldalakon is.

Egy chatbot esetében ez azt jelenti: az aktív nyelvnek láthatóan jelen kell lennie a chat fejléces részében vagy egy könnyen elérhető menüben. A váltás nem küldhet el észrevétlenül egy folyamatban lévő piszkozatot. Ehelyett a beviteli mező tartalma megmarad, a bot röviden elmagyarázza a nyelvváltást, és ellenőrzött módon folytatja a beszélgetést. Ha a korábbi üzenetek más nyelven születtek, a rendszernek meg kell őriznie azok jelentését a kontextus szempontjából, de nem szabad kérés nélkül lefordítania a teljes előzményt.

Egy jó megfogalmazás például így hangzik: „A magyar nyelvet erről az oldalról vettük át. Nyelv módosítása.” Tartalék opció esetén az értesítés konkrétabb lehet: „A magyar nyelvhez nem áll rendelkezésre ellenőrzött információ ebben a témában. Használhatom az angol forrást, vagy átirányíthatom az ügyfélszolgálathoz.” Így a felhasználó megérti, miért változik a nyelv vagy a válasz mélysége.

Oldalnyelv, chat-nyelv és tartalom-locale elkülönítése

Három értéket gyakran tévesen egyetlen mezőben vonnak össze:

• Oldalnyelv: a HTML-dokumentum elsődleges nyelve;
• Chat-nyelv: az a nyelv, amelyen a felület és a válaszok megjelennek;
• Tartalom-locale: az a változat, amelyből a chatbot igazolt információkat kérhet le.

Ezek az értékek lehetnek azonosak, de nem feltétlenül kell azoknak lenniük. Egy magyar ajkú felhasználó egy angol nyelvű termékoldalon tehet fel magyar kérdést. A bot válaszolhat magyarul, és mégis átláthatóan hivatkozhat egy angol eredeti forrásra. Nem szabad azonban azt állítania, hogy magyar forrást használt, ha csak a válasz lett lefordítva.

A akadálymentesség érdekében a dokumentum és a tartalom nyelvét helyesen kell megjelölni. A W3C technika, H57 a langattribútumot írja le a htmlelemen, hogy többek között a képernyőolvasók megfelelően tudják feldolgozni a kiejtést és a szintaxist. Ha egy egyedi szakasz nyelvet vált, annak a területnek is megfelelő jelölésre van szüksége. További ellenőrzéseket gyűjt össze a WCAG ellenőrzőlista weboldal-chatbotokhoz.

A gyorsítótárnak (cache) és az URL-eknek tiszteletben kell tartaniuk a nyelvi döntést

Aki szerveroldalon a Accept-Language alapján választ ki tartalmat, annak figyelembe kell vennie a gyorsítótárazási stratégiát. Az RFC 9110 elmagyarázza, hogy a Vary: Accept-Language jelzi a gyorsítótáraknak, hogy a fejléc befolyásolta a megjelenítést. Ha hiányzik ez az elkülönítés, a cache a magyar változatot egy angol nyelvű látogatónak is kiszolgálhatja.

A nyilvános, indexelhető tartalmak esetében a stabil, nyelvspecifikus URL-eket gyakran könnyebb ellenőrizni és megosztani. Az automatikus felismerés ekkor egy megfelelő URL-re vezethet anélkül, hogy eltérő tartalmakat rejtene el ugyanazon a címen. Magában a chatben a locale-nak a munkamenet-állapot és minden szerveroldali kérés részét kell képeznie. A nyelvváltásnak egyszerre kell frissítenie a gyorsítótár-kulcsokat, a lekérdezési szűrőket és a válaszgenerálást.

A formázott értékek is ehhez a megállapodáshoz tartoznak. A dátum, a szám, a pénznem és az időzóna nem következik automatikusan helyesen a szöveg nyelvéből. A Chatbot-válaszok lokalizálása című útmutató megmutatja, hogyan kezelhetők ezek az adatok külön és konzisztensen.

A tartalék opciók nem leplezhetik el a tartalomhiányosságokat

A legkockázatosabb hiba a tudásbázis csendes megváltoztatása. Ha a magyar nyelvű kérdéshez nem létezik magyar cikk, a bot használhat angol forrást, feltéve, hogy a termék engedélyezi ezt az utat. Ugyanakkor a forrást, a frissességet és a jogosultságot pontosan úgy kell ellenőriznie, mint a közvetlen egyezés esetén.

Egy biztonságos tartalék mátrix (fallback matrix) legalább a következőket tartalmazza: kért locale, elérhető UI locale, elérhető tartalom-locale, megengedett pót-locale, fordítási mód és ügyfélszolgálati átadási cél. Az eredmény nem mindig egy válasz. Érzékeny vagy erősen kontextusfüggő témák esetén a „nincs ellenőrzött információ ezen a nyelven” jobb, mint egy folyékony, de igazolatlan fordítás. A Tartalék opciók tudásbeli hiányosságok esetén című cikk leírja, hogyan hat együtt a bizonytalanság és az átadás.

Tesztesetek a nyelvi logikához

Egy kicsi, szisztematikus tesztkészlet több hibát tár fel, mint egyetlen böngészőellenőrzés. Legalább a következő eseteket kell lefednie:

• de-AT van felajánlva, de csak a de;
• az első böngészőpreferencia nem érhető el, de a második igen;
• a felhasználó választása ellentmond az oldal és a böngésző nyelvének;
• az elmentett preferencia egy időközben eltávolított locale-ra mutat;
• a UI rendelkezésre áll, de a tudásbázis vagy az átadás nem;
• a nyelvváltás egy beszélgetés közepén, elküldetlen szöveggel történik;
• a gyorsítótár a váltás után valóban az új locale-t adja vissza;
• a képernyőolvasó helyesen ismeri fel az oldal és a szakasz nyelvét;
• az analitika rögzíti a kiválasztási forrást és a tartalék opciót, de feleslegesen részletes preferencialistát nem.

Minden kombinációhoz rögzíteni kell az elvárt locale-t, a döntés forrását, a látható értesítést és a megengedett tartalomtartományt. Ezenkívül minden nyelvhez szakmai szúrópróbákra van szükség. A teljesség és a válaszminőség nem vezethető le pusztán egy fordítási sor meglétéből.

Gyakorlati bevezetési ellenőrzőlista

1. Az összes támogatott UI-, tartalom- és átadási locale külön leltárba vétele.
2. Egyértelmű prioritási lánc dokumentálása a felhasználói választás, a mentett választás, az oldal, a böngésző és az alapértelmezés számára.
3. BCP-47 illesztés meghatározása, beleértve a regionális és írásmódbeli kivételeket is.
4. A nyelvváltás megtervezése látható módon és adatvesztés nélkül.
5. A tartalék opciók korlátozása a forrás lefedettségére, frissességére és jogosultságára.
6. lang, a nyelvspecifikus URL-ek, a kanonikus címek (canonical) és a gyorsítótár viselkedésének ellenőrzése.
7. Csak a szükséges analitikai adatok tárolása és a megőrzési idő meghatározása.
8. Asztali gép, mobileszköz, billentyűzet és képernyőolvasó tesztelése reális preferencialistákkal.

A központi termékdöntés így nem az: „Milyen nyelven beszél ez a látogató?” Hanem az: „Milyen nyelvet kértek, mely tartalmak állnak rendelkezésre ehhez megbízhatóan, és hogyan magyarázzuk el a szükséges pótutat?” Aki ezt a három kérdést külön válaszolja meg, olyan chatbotot kap, amely automatikusan hasznosan indul, de a vezérlést a felhasználónál hagyja.

Források

• RFC 9110: Accept-Language, Vary és adatvédelem
• MDN: Navigator.languages
• W3C Internationalization: Guiding users to translated pages
• W3C WAI: A dokumentum nyelvének megjelölése a lang attribútummal