Detectarea automată a limbii chatbotului: preferințe, fallback-uri și alegerea utilizatorului

Un chatbot multilingv pentru site-uri web nu ar trebui să trimită vizitatorii într-o limbă greșită încă de la primul răspuns. Totuși, detectarea automată a limbii chatbotului înseamnă mai mult decât preluarea primei valori furnizate de browser. Setările browserului pot fi învechite, un dispozitiv poate fi utilizat la comun, iar o persoană poate prefera să citească conținut tehnic în engleză, deși sistemul său de operare folosește romana.

O soluție robustă tratează prin urmare detectarea automată doar ca un semnal de pornire. Alegerea explicită a utilizatorului are prioritate, disponibilitatea interfeței, a bazei de cunoștințe și a procesului de transfer stabilește limitele, iar un fallback vizibil previne situația în care o limbă aparent potrivită duce la răspunsuri incomplete sau inventate.

De ce limba browserului este doar un indiciu

Browserele trimit frecvent antetul HTTP Accept-Language. Acesta conține intervale lingvistice și poate exprima o ordine prin așa-numitele valori de calitate, cum ar fi de-AT,de;q=0.9,en;q=0.7. Standardul RFC 9110 descrie aceste preferințe în mod expres ca pe un ajutor pentru selectarea unei reprezentări, nu ca pe o afirmatie certă despre persoană.

În browser, navigator.languages furnizează o listă ordonată de taguri lingvistice BCP 47 preferate. Conform MDN , din motive de confidențialitate, browserele pot totuși dezvălui mai puține preferințe. În plus, un browser poate adăuga variante mai generale: din de-AT poate deveni relevantă suplimentar, pentru potrivire, de .

Consecința practică pentru chatboturi este simplă: Accept-Language și navigator.languages sunt candidați buni pentru prima sugestie. Totuși, aceștia nu trebuie să înlocuiască locația sau cetățenia. O adresă IP nu dezvăluie o preferință lingvistică de încredere. De asemenea, domeniul sau limba paginii singure nu sunt suficiente dacă un vizitator a comutat intenționat la o altă versiune lingvistică.

O lanț clar de prioritate previne surprizele

Selecția ar trebui să fie deterministă. S-a dovedit eficientă o ordine care ponderează clar fiecare sursă:

1. Alegerea explicită în sesiunea curentă: Dacă utilizatorul dă clic pe franceză, următorul răspuns al chatbotului trebuie să folosească franceza.
2. Preferință salvată, încă valabilă: O alegere anterioară poate fi aplicată din nou la o vizită ulterioară, cu condiția ca stocarea să fie transparentă și permisă din punct de vedere tehnic.
3. Limba paginii curente: Chatbotul nu ar trebui să se abată fără motiv de la versiunea lingvistică deschisă intenționat.
4. Preferințele browserului: Lista este comparată cu localizările (locales) suportate efectiv de chatbot.
5. Standard documentat: Dacă nimic nu se potrivește, se folosește o limbă de bază aleasă deliberat, în locul unui rezultat aleatoriu.

Acest lanț separă detectarea de decizie. Poate fi înregistrat și testat: source=user, source=stored, source=page, source=browser sau source=default. Pentru analiza datelor, sursa și localizarea aleasă sunt de obicei suficiente. Lista completă de limbi a browserului nu ar trebui stocată inutil, deoarece RFC 9110 atrage atenția asupra posibilelor riscuri de confidențialitate și amprentare (fingerprinting) asociate preferințelor lingvistice detaliate.

Normalizarea tagurilor BCP 47 fără a pierde din sens

Tagurile de limbă nu constau doar din două litere. pt-BR și pt-PT împărtășesc o limbă, dar pot diferi în ceea ce privește tonalitatea, alegerea cuvintelor, formatele și termenii juridici. De asemenea, sistemele de scriere pot fi decisive. Prin urmare, aplicația ar trebui să normalizeze sintactic tagurile primite și apoi să le verifice în raport cu o listă explicită de localizări suportate.

De la tagul specific la un fallback sigur

O potrivire utilă încearcă mai întâi varianta exactă. Dacă de-AT nu este disponibil, poate urma de . După aceea, se poate aplica o localizare standard cunoscută și verificată editorial. Totuși, simpla eliminare a tuturor sub-tagurilor nu este întotdeauna sigură. În cazul limbilor cu mai multe sisteme de scriere sau variante foarte diferite, produsul are nevoie de o mapare definită intenționat.

Fallback-ul trebuie verificat separat pe trei niveluri: Este interfața de chat tradusă? Există surse de cunoștințe potrivite? Poate o echipă de suport uman să preia această limbă? Un buton localizat nu reprezintă încă o dovadă că baza de cunoștințe are aceeași acoperire. Modul în care sursele sunt separate în funcție de limbă, versiune și acces este explicat în articolul despre filtre de metadate RAG pentru chatboturi AI.

Afișarea opțiunilor automate, menținând vizibilă alegerea utilizatorului

Recomandarea W3C privind internaționalizarea combină negocierea automată a limbii cu linkuri ușor de găsit către versiuni lingvistice alternative. Dacă un utilizator schimbă singur limba, această alegere trebuie să aibă prioritate față de preferința browserului și, la dorință, să fie păstrată pentru paginile următoare.

Pentru un chatbot, acest lucru înseamnă: limba activă trebuie să fie vizibilă în antetul chatului sau într-un meniu ușor accesibil. Schimbarea nu trebuie să trimită neobservată o ciornă în curs de redactare. În schimb, textul introdus se păstrează, botul explică pe scurt schimbarea limbii și continuă conversația în mod controlat. Dacă mesajele anterioare sunt într-o altă limbă, sistemul ar trebui să le păstreze sensul pentru context, dar să nu traducă neîntrebat întregul istoric.

O formulare bună este, de exemplu: „Româna a fost preluată din această pagină. Schimbă limba.” În cazul unui fallback, notificarea poate fi mai specifică: „Nu există informații verificate în română pe acest subiect. Pot folosi sursa în engleză sau te pot transfera la suport.” Astfel, utilizatorul înțelege de ce se schimbă limba sau detaliul răspunsului.

Separarea limbii paginii, a limbii chatului și a localizării conținutului

Trei valori sunt adesea comasate eronat într-un singur câmp:

• Limba paginii: limba primară a documentului HTML;
• Limba chatului: limba în care apar interfața și răspunsurile;
• Localizarea conținutului: varianta din care chatbotul are voie să preia informații dovedite.

Aceste valori pot fi identice, dar nu este obligatoriu. Un utilizator vorbitor de română poate pune o întrebare în română pe o pagină de produs în limba engleză. Botul poate răspunde în română și totuși să facă trimitere transparentă la o sursă originală în engleză. Nu ar trebui însă să afirme că a folosit o sursă în română dacă doar răspunsul a fost tradus.

Pentru accesibilitate, limba documentului și a conținutului trebuie să fie marcată corect. Tehnica W3C H57 descrie atributul langpe elementul html, astfel încât, printre altele, cititoarele de ecran (screen readers) să proceseze corespunzător pronunția și sintaxa. Dacă o secțiune individuală își schimbă limba, și acel domeniu are nevoie de o marcare adecvată. Verificări suplimentare sunt grupate în lista de verificare WCAG pentru chatboturi de pe site-uri web.

Memoria cache și URL-urile trebuie să respecte decizia privind limba

Dacă selectați conținutul pe partea de server în funcție de Accept-Language , trebuie să luați în considerare strategia de memorie cache (caching). RFC 9110 explică faptul că Vary: Accept-Language semnalează sistemelor de cache că antetul a influențat afișarea. În lipsa acestei separări, o memorie cache poate livra varianta în română unui vizitator vorbitor de engleză.

Pentru conținutul public, indexabil, URL-urile stabile specifice fiecărei limbi sunt adesea mai ușor de verificat și de distribuit. Detectarea automată poate redirecționa către un URL potrivit, fără a ascunde conținuturi diferite sub aceeași adresă. În chat, localizarea ar trebui să facă parte din starea sesiunii și din fiecare solicitare pe partea de server. O schimbare de limbă trebuie să actualizeze simultan cheile de cache, filtrele de preluare a datelor și generarea răspunsului.

De asemenea, valorile formatate fac parte din această înțelegere. Data, numărul, moneda și fusul orar nu rezultă automat corect din limba textului. Ghidul Localizarea răspunsurilor chatbotului arată cum pot fi tratate aceste date în mod separat și consecvent.

Fallback-urile nu trebuie să mascheze lipsurile de conținut

Cea mai riscantă greșeală este o schimbare silențioasă a bazei de cunoștințe. Dacă nu există un articol în română pentru o întrebare în română, botul poate folosi o sursă în engleză, cu condiția ca produsul să permită acest lucru. Totuși, el trebuie să verifice sursa, actualitatea și autorizarea exact ca în cazul unei potriviri directe.

O matrice de fallback sigură conține cel puțin: localizarea solicitată, localizarea UI disponibilă, localizarea conținutului disponibilă, localizarea de rezervă permisă, modul de traducere și destinația de transfer (handoff). Rezultatul nu este întotdeauna un răspuns. În cazul subiectelor sensibile sau puternic dependente de context, „nicio informație verificată în această limbă” este mai bine decât o traducere fluentă, dar neconfirmată. Articolul despre fallback-uri în cazul lipsei de cunoștințe descrie modul în care incertitudinea și preluarea interacționează.

Cazuri de testare pentru logica lingvistică

Un set de teste restrâns și sistematic descoperă mai multe erori decât o singură verificare a browserului. Acesta ar trebui să acopere cel puțin următoarele cazuri:

• de-AT este oferită, dar este suportată doar de;
• prima preferință a browserului nu este disponibilă, dar a doua este;
• alegerea utilizatorului contrazice limba paginii și pe cea a browserului;
• preferința salvată face trimitere la o localizare eliminată între timp;
• interfața este disponibilă, dar baza de cunoștințe sau transferul nu sunt;
• schimbarea limbii are loc în mijlocul unei conversații cu text netrimis;
• memoria cache furnizează într-adevăr noua localizare după schimbare;
• cititorul de ecran detectează corect limba paginii și pe cea a secțiunii;
• analizele înregistrează sursa selecției și fallback-ul, dar nu o listă de preferințe inutil de detaliată.

Pentru fiecare combinație, echipele ar trebui să stabilească localizarea așteptată, sursa deciziei, notificarea vizibilă și spațiul de conținut permis. În plus, fiecare limbă are nevoie de verificări punctuale de specialitate. Completiudinea și calitatea răspunsului nu pot fi deduse doar din prezența unei linii de traducere.

Listă practică de verificare pentru implementare

1. Inventarierea separată a tuturor localizărilor suportate pentru UI, conținut și transfer.
2. Documentarea unui lanț clar de prioritate pentru alegerea utilizatorului, alegerea salvată, pagină, browser și valoarea implicită.
3. Definirea potrivirii BCP 47, inclusiv excepțiile regionale și cele legate de scriere.
4. Conceperea schimbării limbii în mod vizibil și fără pierderea textului introdus.
5. Limitarea fallback-urilor la acoperirea surselor, actualitate și autorizare.
6. langVerificarea antetului, a URL-urilor specifice fiecărei limbi, a legăturilor canonice (canonicals) și a comportamentului de cache.
7. Stocarea doar a datelor de analiză necesare și stabilirea duratei de păstrare.
8. Testarea pe desktop, mobil, tastatură și cititoare de ecran cu liste de preferințe realiste.

Prin urmare, decizia centrală de produs nu este: „Ce limbă are acest vizitator?” Ci: „Ce limbă s-a dorit, ce conținuturi sunt disponibile în mod de încredere pentru aceasta și cum explicăm o cale alternativă necesară?” Cine răspunde separat la aceste trei întrebări obține un chatbot care începe automat într-un mod util, dar lasă controlul la utilizator.

Surse

• RFC 9110: Accept-Language, Vary și confidențialitatea datelor
• MDN: Navigator.languages
• W3C Internationalization: Guiding users to translated pages
• W3C WAI: Marcarea limbii documentului cu lang