Rilevare automaticamente la lingua del chatbot: preferenze, fallback e scelta dell'utente

Un chatbot multilingue per siti web non dovrebbe inviare i visitatori verso la lingua sbagliata fin dalla prima risposta. Tuttavia, rilevare automaticamente la lingua del chatbot significa molto più che prendere il primo valore fornito dal browser. Le impostazioni del browser possono essere obsolete, un dispositivo può essere condiviso e una persona può preferire leggere contenuti tecnici in inglese, anche se il suo sistema operativo utilizza il tedesco.

Una soluzione solida gestisce quindi il rilevamento automatico solo come un segnale iniziale. La scelta esplicita dell'utente ha sempre la priorità, la disponibilità dell'interfaccia, della base di conoscenza e dei processi di escalation stabilisce i limiti, e un fallback visibile impedisce che una lingua apparentemente idonea porti a risposte incomplete o inventate.

Perché la lingua del browser è solo un indizio

I browser inviano spesso l'intestazione HTTP Accept-Language. Essa contiene intervalli linguistici e può esprimere un ordine tramite i cosiddetti valori di qualità, come de-AT,de;q=0.9,en;q=0.7. Lo standard RFC 9110 descrive espressamente queste preferenze come un aiuto per la selezione di una rappresentazione, non come un'affermazione certa sulla persona.

Nel browser, navigator.languages fornisce un elenco ordinato di tag linguistici BCP-47 preferiti. Secondo MDN , i browser possono tuttavia mostrare meno preferenze per motivi di privacy. Inoltre, in determinate circostanze un browser può integrare varianti più generali: da de-AT può diventare rilevante per il confronto anche de .

La conseguenza pratica per i chatbot è chiara: Accept-Language e navigator.languages sono ottimi candidati per il primo suggerimento. Tuttavia, non devono sostituire la posizione geografica o la nazionalità. Un indirizzo IP non rivela alcuna preferenza linguistica affidabile. Nemmeno il dominio o la lingua della pagina da soli sono sufficienti se un visitatore ha intenzione di passare a un'altra versione linguistica.

Una chiara catena di priorità previene le sorprese

La selezione deve essere deterministica. Si è dimostrato efficace un ordine che pondera chiaramente ogni fonte:

1. Scelta esplicita nella sessione corrente: se l'utente clicca su Francese, la risposta successiva del chatbot deve utilizzare il francese.
2. Preferenza salvata ancora valida: una scelta precedente può applicarsi nuovamente in una visita successiva, a condizione che la memorizzazione sia trasparente e tecnicamente consentita.
3. Lingua della pagina corrente: il chatbot non dovrebbe deviare senza motivo dalla versione linguistica aperta intenzionalmente.
4. Preferenze del browser: l'elenco viene confrontato con le impostazioni locali (locale) effettivamente supportate dal chatbot.
5. Impostazione predefinita documentata: se nulla corrisponde, si segue una lingua di base scelta consapevolmente anziché un risultato casuale.

Questa catena separa il rilevamento dalla decisione. Può essere registrata nei log e testata: source=user, source=stored, source=page, source=browser o source=default. Per le analisi di solito bastano la fonte e la locale selezionata. L'elenco completo delle lingue del browser non dovrebbe essere salvato inutilmente, poiché la RFC 9110 evidenzia i possibili rischi per la privacy e il fingerprinting derivanti da preferenze linguistiche dettagliate.

Normalizzare i tag BCP-47 senza perdere il significato

I tag linguistici non sono composti solo da due lettere. pt-BR e pt-PT condividono una lingua, ma possono differire nel tono, nella scelta dei vocaboli, nei formati e nei termini legali. Anche i sistemi di scrittura possono essere decisivi. Per questo motivo, l'applicazione dovrebbe normalizzare sintatticamente i tag in ingresso e successivamente verificarli rispetto a un elenco esplicito di locale supportate.

Dal tag specifico al fallback sicuro

Un confronto efficace tenta prima la variante esatta. Se de-AT non è disponibile, può seguire de . Dopodiché può subentrare una locale predefinita nota e verificata a livello redazionale. Tuttavia, il semplice taglio di tutti i subtag non è sempre sicuro. Per le lingue con più sistemi di scrittura o varianti molto diverse, il prodotto necessita di un'associazione definita consapevolmente.

Il fallback deve essere verificato separatamente per tre livelli: l'interfaccia di chat è tradotta? Esistono fonti di conoscenza adeguate? Un team di supporto umano può gestire questa lingua? Un pulsante localizzato non è ancora la prova che la base di conoscenza abbia la stessa copertura. Come le fonti vengono separate per lingua, versione e accesso è illustrato nell'articolo sui filtri di metadati RAG per chatbot IA.

Offrire l'automatismo, mantenere visibile la scelta dell'utente

La raccomandazione di internazionalizzazione del W3C unisce la negoziazione automatica della lingua con link facilmente reperibili a versioni linguistiche alternative. Se un utente cambia la lingua autonomamente, questa scelta deve prevalere sulla preferenza del browser e, se desiderato, rimanere valida per le pagine successive.

Per un chatbot questo significa: la lingua attiva deve trovarsi in modo visibile nell'intestazione della chat o in un menu ben accessibile. Il cambio non deve inviare inosservata una bozza in corso. Al contrario, il testo inserito rimane invariato, il bot spiega brevemente il cambio di lingua e prosegue la conversazione in modo controllato. Se i messaggi precedenti sono in un'altra lingua, il sistema dovrebbe preservarne il significato per il contesto, ma non tradurre la cronologia completa senza che sia richiesto.

Una buona formulazione potrebbe essere: «Il tedesco è stato ripreso da questa pagina. Cambia lingua.» In caso di fallback, l'avviso può essere più specifico: «Per il tedesco non sono disponibili informazioni verificate su questo argomento. Posso utilizzare la fonte in inglese o trasferire la richiesta al supporto.» In questo modo l'utente comprende il motivo del cambio di lingua o della profondità della risposta.

Separare lingua della pagina, lingua della chat e locale del contenuto

Tre valori vengono spesso erroneamente accorpati in un unico campo:

• Lingua della pagina: la lingua primaria del documento HTML;
• Lingua della chat: la lingua in cui appaiono l'interfaccia e le risposte;
• Locale del contenuto: la variante da cui il chatbot può recuperare informazioni verificate.

Questi valori possono coincidere, ma non devono necessariamente farlo. Un utente di lingua tedesca può porre una domanda in tedesco su una pagina di prodotto in inglese. Il bot può rispondere in tedesco e fare comunque riferimento in modo trasparente a una fonte originale in inglese. Tuttavia, non dovrebbe affermare di aver utilizzato una fonte in tedesco se è stata tradotta solo la risposta.

Per l'accessibilità, la lingua del documento e del contenuto deve essere contrassegnata correttamente. La tecnica W3C H57 descrive l'attributo langsull'elemento html, affinché tra l'altro gli screen reader possano elaborare la pronuncia e la sintassi in modo adeguato. Se una singola sezione cambia lingua, anche quell'area necessita di una marcatura opportuna. Ulteriori verifiche sono raccolte nella checklist WCAG per chatbot di siti web.

Cache e URL devono rispettare la decisione sulla lingua

Chi seleziona i contenuti lato server in base a Accept-Language deve considerare la strategia di caching. La RFC 9110 spiega che Vary: Accept-Language segnala alle cache che l'intestazione ha influenzato la rappresentazione. Se manca questa separazione, una cache può servire la variante tedesca a un visitatore di lingua inglese.

Per i contenuti pubblici e indicizzabili, gli URL stabili e specifici per lingua sono spesso più facili da verificare e condividere. Il rilevamento automatico può quindi indirizzare a un URL adeguato senza nascondere contenuti diversi sotto lo stesso indirizzo. Nella chat stessa, la locale dovrebbe far parte dello stato della sessione e di ogni richiesta lato server. Un cambio di lingua deve aggiornare contemporaneamente chiavi di cache, filtri di retrieval e generazione delle risposte.

Anche i valori formattati rientrano in questo contratto. Date, numeri, valute e fusi orari non derivano automaticamente in modo corretto dalla lingua del testo. La guida Localizzare le risposte del chatbot mostra come gestire questi dati separatamente e in modo coerente.

I fallback non devono mascherare le lacune di contenuto

L'errore più rischioso è un cambio silenzioso della base di conoscenza. Se non esiste un articolo in tedesco per la domanda in tedesco, il bot può utilizzare una fonte in inglese, a condizione che il prodotto consenta questo percorso. Deve però verificare la fonte, l'attualità e le autorizzazioni esattamente come nel caso di una corrispondenza diretta.

Una matrice di fallback sicura contiene almeno: locale richiesta, locale UI disponibile, locale contenuto disponibile, locale alternativa consentita, modalità di traduzione e destinazione dell'escalation. Il risultato non è sempre una risposta. Per argomenti sensibili o fortemente dipendenti dal contesto, «nessuna informazione verificata in questa lingua» è preferibile a una traduzione fluida ma priva di riscontri. L'articolo sui fallback in caso di lacune di conoscenza descrive come interagiscono incertezza ed escalation umana.

Casi di test per la logica linguistica

Un set di test ridotto e sistematico individua più errori rispetto a un singolo controllo del browser. Dovrebbe coprire almeno questi casi:

• de-AT viene offerto, ma è supportato solo de;
• la prima preferenza del browser non è disponibile, la seconda sì;
• la scelta dell'utente è in contrasto con la lingua della pagina e del browser;
• la preferenza salvata fa riferimento a una locale nel frattempo rimossa;
• l'interfaccia utente è presente, ma la base di conoscenza o l'escalation no;
• il cambio di lingua avviene a metà di una conversazione con testo non inviato;
• la cache fornisce effettivamente la nuova locale dopo il cambio;
• lo screen reader rileva correttamente la lingua della pagina e della sezione;
• le analisi tracciano la fonte della selezione e il fallback, ma non un elenco di preferenze inutilmente dettagliato.

Per ogni combinazione, i team dovrebbero stabilire la locale prevista, la fonte della decisione, l'avviso visibile e lo spazio di contenuto consentito. Inoltre, ogni lingua necessita di campionamenti tecnici. La completezza e la qualità delle risposte non possono essere dedotte unicamente dalla presenza di una riga di traduzione.

Checklist pratica di implementazione

1. Inventariare separatamente tutte le locale supportate per UI, contenuto ed escalation.
2. Documentare una catena di priorità univoca per scelta dell'utente, scelta salvata, pagina, browser e impostazione predefinita.
3. Definire il matching BCP-47 comprese le eccezioni regionali e di scrittura.
4. Progettare il cambio di lingua in modo visibile e senza perdita di testo inserito.
5. Limitare i fallback in base alla copertura delle fonti, all'attualità e alle autorizzazioni.
6. lang, URL specifici per lingua, tag canonical e comportamento della cache.
7. Salvare solo i dati analitici necessari e stabilire la durata di conservazione.
8. Testare desktop, dispositivi mobili, tastiera e screen reader con elenchi di preferenze realistici.

La decisione centrale di prodotto non è quindi: «Quale lingua parla questo visitatore?». È invece: «Quale lingua è stata richiesta, quali contenuti sono disponibili in modo affidabile e come spieghiamo una via alternativa necessaria?». Chi risponde separatamente a queste tre domande ottiene un chatbot che parte in modo utile e automatico, ma lascia il controllo all'utente.

Fonti

• RFC 9110: Accept-Language, Vary e privacy
• MDN: Navigator.languages
• W3C Internationalization: Guida per gli utenti alle pagine tradotte
• W3C WAI: Contrassegnare la lingua del documento con lang