Detección automática del idioma del chatbot: preferencias, fallbacks y selección de usuario

Un chatbot web multilingüe no debería responder a los visitantes en el idioma equivocado desde el primer mensaje. Sin embargo, detectar automáticamente el idioma del chatbot implica mucho más que limitarse a adoptar el primer valor del navegador. La configuración del navegador puede estar desactualizada, un dispositivo puede ser compartido y una persona puede preferir leer contenidos técnicos en inglés aunque su sistema operativo esté en español.

Por ello, una solución sólida trata la detección automática solo como una señal inicial. La elección explícita del usuario tiene prioridad, la disponibilidad de la interfaz, la base de conocimiento y el proceso de derivación marcan los límites, y un fallback visible evita que un idioma aparentemente adecuado lleve a respuestas incompletas o inventadas.

Por qué el idioma del navegador es solo una pista

Los navegadores suelen enviar el encabezado HTTP Accept-Language. Este contiene rangos de idioma y puede expresar un orden mediante valores de calidad, por ejemplo de-AT,de;q=0.9,en;q=0.7. El estándar RFC 9110 describe explícitamente estas preferencias como una ayuda para seleccionar la representación, no como una afirmación certera sobre la persona.

En el navegador, navigator.languages proporciona una lista ordenada de etiquetas de idioma BCP 47 preferidas. Según MDN , los navegadores pueden revelar menos preferencias por razones de privacidad. Además, en ocasiones el navegador añade variantes más generales: a partir de de-AT también puede resultar relevante de para la coincidencia.

La consecuencia práctica para los chatbots es clara: Accept-Language y navigator.languages son buenos candidatos para la sugerencia inicial. Sin embargo, no deben sustituir a la ubicación ni a la nacionalidad. Una dirección IP no revela una preferencia de idioma fiable. La variante del dominio o el idioma de la página tampoco bastan si un visitante ha cambiado deliberadamente a otra versión lingüística.

Una cadena de prioridades clara evita sorpresas

La selección debe ser determinista. Ha demostrado ser eficaz un orden que pondera de forma transparente cada fuente:

1. Elección explícita en la sesión actual: Si el usuario hace clic en francés, la siguiente respuesta del chatbot debe utilizar el francés.
2. Preferencia guardada y aún válida: Una elección anterior puede volver a aplicarse en una visita posterior, siempre que el almacenamiento sea transparente y técnicamente permitido.
3. Idioma de la página actual: El chatbot no debería desviarse sin motivo de la versión lingüística que el usuario ha abierto intencionadamente.
4. Preferencias del navegador: La lista se contrasta con los locales del chatbot realmente soportados.
5. Idioma predeterminado documentado: Si nada coincide, se recurre a un idioma base elegido conscientemente en lugar de un resultado aleatorio.

Esta cadena separa la detección de la decisión. Permite registrarse y probarse: source=user, source=stored, source=page, source=browser o source=default. Para las analíticas, suele bastar con la fuente y el locale elegido. No conviene guardar innecesariamente la lista completa de idiomas del navegador, ya que el RFC 9110 advierte sobre los posibles riesgos de privacidad y huella digital (fingerprinting) derivados de las preferencias detalladas de idioma.

Normalizar las etiquetas BCP 47 sin perder significado

Las etiquetas de idioma no constan solo de dos letras. pt-BR y pt-PT comparten un idioma, pero pueden diferir en tonalidad, vocabulario, formatos y términos legales. Los sistemas de escritura también pueden ser determinantes. Por ello, la aplicación debe normalizar sintácticamente las etiquetas entrantes y luego verificarlas contra una lista explícita de locales admitidos.

De la etiqueta específica al fallback seguro

Una coincidencia lógica intenta primero la variante exacta. Si de-AT no está disponible, puede seguir de . A continuación, puede aplicarse un locale estándar conocido y verificado editorialmente. Sin embargo, no siempre es seguro recortar simplemente todas las subetiquetas. En idiomas con múltiples escrituras o variantes muy distintas, el producto requiere una asignación definida conscientemente.

El fallback debe evaluarse por separado en tres niveles: ¿Está traducida la interfaz del chat? ¿Existen fuentes de conocimiento adecuadas? ¿Puede un equipo de soporte humano atender en ese idioma? Un botón localizado no garantiza que la base de conocimiento tenga la misma cobertura. Cómo separar las fuentes por idioma, versión y acceso se explica en el artículo sobre filtros de metadatos RAG para chatbots de IA.

Ofrecer automatización, mantener visible la elección del usuario

La recomendación de internacionalización del W3C combina la mediación automática de idioma con enlaces fácilmente accesibles a versiones alternativas. Si un usuario cambia el idioma por sí mismo, esa elección debe prevalecer sobre la preferencia del navegador y conservarse para las páginas siguientes si así se desea.

Para un chatbot, esto significa que el idioma activo debe situarse de forma visible en el encabezado del chat o en un menú de fácil acceso. El cambio no debe enviar de forma inadvertida un borrador en curso. En su lugar, el texto introducido se conserva, el bot explica brevemente el cambio de idioma y continúa la conversación de forma controlada. Si hay mensajes anteriores en otro idioma, el sistema debe preservar su significado para el contexto, pero no traducir todo el historial sin consultar.

Una formulación adecuada sería: «Se ha adoptado el español de esta página. Cambiar idioma.» En el caso de un fallback, la indicación puede ser más concreta: «No hay información verificada sobre este tema en español. Puedo utilizar la fuente en inglés o derivar la consulta al soporte.» Así, el usuario comprende por qué cambia el idioma o la profundidad de la respuesta.

Separar el idioma de la página, el idioma del chat y el locale del contenido

A menudo se agrupan erróneamente tres valores en un solo campo:

• Idioma de la página: el idioma principal del documento HTML;
• Idioma del chat: el idioma en el que aparecen la interfaz y las respuestas;
• Locale del contenido: la variante de la que el chatbot puede extraer información documentada.

Estos valores pueden coincidir, pero no tienen por qué hacerlo. Un usuario hispanohablante puede formular una pregunta en español en la página de un producto en inglés. El bot puede responder en español y, aun así, remitir de forma transparente a una fuente original en inglés. Sin embargo, no debe afirmar que ha utilizado una fuente en español si solo se ha traducido la respuesta.

Para la accesibilidad, el idioma del documento y del contenido debe estar correctamente etiquetado. La técnica W3C H57 describe el atributo langen el elemento htmlpara que los lectores de pantalla, entre otros, puedan procesar la pronunciación y la sintaxis adecuadamente. Si una sección individual cambia de idioma, esa zona también requiere la etiqueta correspondiente. La lista de comprobación WCAG para chatbots web.

reúne comprobaciones adicionales.

La caché y las URL deben respetar la decisión de idioma Accept-Language Quien seleccione contenidos en el servidor según Vary: Accept-Language debe tener en cuenta la estrategia de almacenamiento en caché. El RFC 9110 explica que señalar

a las cachés indica que el encabezado ha influido en la representación. Si falta esta separación, una caché podría entregar la versión en español a un visitante angloparlante. Para contenidos públicos e indexables, las URL estables específicas de cada idioma suelen ser más fáciles de probar y compartir. La detección automática puede redirigir a una URL adecuada sin ocultar contenidos diferentes bajo la misma dirección. En el propio chat, el locale debe formar parte del estado de la sesión y de cada solicitud en el servidor. Un cambio de idioma debe actualizar de forma conjunta las claves de caché, los filtros de recuperación y la generación de respuestas.

Los valores formateados también forman parte de este acuerdo. Las fechas, números, monedas y zonas horarias no se derivan automáticamente de forma correcta a partir del idioma del texto. La guía localizar respuestas de chatbots muestra cómo tratar estos datos de manera independiente y coherente.

Los fallbacks no deben ocultar vacíos de contenido

El error más riesgoso es un cambio silencioso de la base de conocimiento. Si no existe un artículo en español para una pregunta formulada en español, el bot puede utilizar una fuente en inglés si el producto habilita esa vía. Sin embargo, debe verificar la fuente, la actualización y las autorizaciones con el mismo rigor que en una coincidencia directa.

Una matriz de fallback segura incluye como mínimo: locale solicitado, locale de interfaz disponible, locale de contenido disponible, locale alternativo permitido, modo de traducción y destino de derivación. El resultado no siempre es una respuesta. En temas sensibles o con gran dependencia del contexto, es mejor indicar «no hay información verificada en este idioma» que ofrecer una traducción fluida pero no respaldada. El artículo sobre fallbacks ante vacíos de conocimiento describe cómo interactúan la incertidumbre y la derivación.

Casos de prueba para la lógica de idioma

Un conjunto de pruebas pequeño y sistemático detecta más errores que una verificación aislada del navegador. Debe cubrir como mínimo estos casos:

• de-AT se ofrece, pero solo se admite de;
• la primera preferencia del navegador no está disponible, pero la segunda sí;
• la elección del usuario entra en contradicción con el idioma de la página y del navegador;
• la preferencia guardada apunta a un locale que ha sido eliminado;
• la interfaz está disponible, pero no la base de conocimiento ni la derivación a soporte;
• el cambio de idioma ocurre a mitad de una conversación con texto sin enviar;
• la caché entrega realmente el nuevo locale tras el cambio;
• el lector de pantalla reconoce correctamente el idioma de la página y de la sección;
• las analíticas registran la fuente de selección y el fallback, pero no una lista de preferencias innecesariamente detallada.

Para cada combinación, los equipos deben documentar el locale esperado, la fuente de la decisión, el aviso visible y el espacio de contenido permitido. Además, cada idioma requiere muestras técnicas de prueba. La exhaustividad y la calidad de las respuestas no pueden deducirse únicamente de la presencia de una línea traducida.

Lista de comprobación práctica para la implementación

1. Inventariar por separado todos los locales soportados para la interfaz, el contenido y la derivación.
2. Documentar una cadena de prioridades clara para la elección del usuario, la elección guardada, la página, el navegador y el valor predeterminado.
3. Definir la coincidencia BCP 47 incluyendo excepciones regionales y de escritura.
4. Diseñar el cambio de idioma de forma visible y sin perder el texto introducido.
5. Limitar los fallbacks según la cobertura de las fuentes, la actualización y los permisos.
6. langVerificar las URL específicas por idioma, las canónicas y el comportamiento de la caché.
7. Guardar únicamente los datos analíticos necesarios y fijar su periodo de conservación.
8. Probar en escritorio, dispositivos móviles, teclado y lectores de pantalla con listas de preferencias reales.

Por lo tanto, la decisión central de producto no es: «¿Qué idioma habla este visitante?», sino: «¿Qué idioma se ha solicitado, qué contenidos están disponibles de forma fiable para ese idioma y cómo explicamos una ruta alternativa necesaria?». Quien responde a estas tres preguntas por separado obtiene un chatbot que comienza ofreciendo ayuda automáticamente, pero mantiene el control en manos del usuario.

Fuentes

• RFC 9110: Accept-Language, Vary y privacidad
• MDN: Navigator.languages
• Internacionalización W3C: Orientación de usuarios hacia páginas traducidas
• W3C WAI: Identificación del idioma del documento mediante lang