Atender a un usuario que abre el ticket en otro idioma bloquea el flujo: el técnico selecciona el texto, lo pega en un traductor externo, vuelve a GLPI, responde - y lo repite en cada nuevo seguimiento. El módulo Translate de NexTool elimina ese ir y venir traduciendo la descripción y los seguimientos dentro de la propia línea de tiempo del ticket, bajo demanda, en el idioma de la sesión de quien atiende.
El problema
Quien gestiona un service desk que atiende a clientes o filiales en más de un idioma conoce la escena: el ticket llega en inglés, francés o español, el técnico selecciona el texto, abre una pestaña de traductor, lo pega, lo lee, vuelve a GLPI y escribe la respuesta. En cada seguimiento del solicitante, el ciclo vuelve a empezar. Además de lento, el proceso saca el texto del contexto del ticket - el historial queda fragmentado y la traducción desaparece en cuanto se cierra la pestaña del navegador.
La salida habitual, pedir que el propio solicitante escriba en el idioma del soporte, traslada la fricción al cliente y degrada la experiencia justo en el primer contacto. Para un equipo que atiende cuentas internacionales, el idioma no debería convertirse en un obstáculo operativo en cada mensaje.
Cómo funciona
Translate replica, dentro de la arquitectura de módulos NexTool, el comportamiento del plugin de traducción de Teclib - con la diferencia de no atarte a un único servicio. Actúa dentro de la línea de tiempo del ticket:
- Traducción por elemento, bajo demanda: cada elemento de la línea de tiempo (descripción, seguimiento, tarea, validación o solución) tiene su propio botón de traducción. Nada se traduce en masa - el técnico traduce solo lo que necesita leer.
- Idioma de la sesión: la traducción sale en el idioma de la interfaz de quien ha iniciado sesión. Un equipo multiidioma atiende el mismo ticket, cada técnico leyendo en su idioma, sin reconfigurar nada.
- Tres proveedores, tú eliges: DeepL, Google Cloud Translation o IA (un LLM de OpenAI, Google Gemini o Anthropic Claude). La elección es del proveedor - el idioma de destino sigue siendo el de la sesión.
- Caché de traducciones: el resultado se guarda y se reutiliza. El mismo texto no se traduce - ni se cobra - dos veces. La caché respeta la versión del contenido: un seguimiento editado se vuelve a traducir, uno sin cambios se sirve desde la caché.
- Claves de API cifradas: la clave del proveedor se guarda cifrada (mediante GLPIKey de GLPI), no en texto plano en la configuración.
- Alcance por entidad y registros: puedes restringir el módulo a ciertas entidades (con herencia a las entidades hijas) y hacer seguimiento de qué se tradujo, por quién y con qué proveedor, con un nivel de registro ajustable.
- Prueba de conexión integrada: antes de liberarlo al equipo, un botón valida la clave y el proveedor configurados.
DeepL, Google o IA: la elección que importa
Los tres proveedores traducen bien el texto monolingüe. La diferencia aparece - y lo descubrimos en la operación diaria - en tickets multilingües dentro de un mismo documento, que son el caso real de quien recibe leads y formularios de contacto.
DeepL y Google Translate, en la API REST con detección automática de origen, deciden un único idioma por documento. En un ticket de lead cuya descripción es mayoritariamente española (las etiquetas de la plantilla: "Nombre:", "Empresa:", "Mensaje:") con el mensaje del cliente en francés, el proveedor detecta el español como idioma dominante, fija el destino en español y devuelve un texto casi idéntico - el fragmento en francés queda intacto. Lo confirmamos con un ticket de prueba real: el documento entero se detectaba como ES (sin efecto sobre el francés), mientras que el mismo fragmento francés, aislado, se detectaba como FR y se traducía correctamente. La columna de idioma de origen en la caché del módulo no deja lugar a dudas.
# Descripción de un ticket de lead (etiquetas en ES + mensaje en FR)
Nombre: ...cliente...
Empresa: ...empresa francesa...
Mensaje: Bonjour, je souhaite un devis... Merci.
# DeepL / Google (source=auto) - UN idioma detectado por documento
detected_source_language = "ES" -> destino es -> fragmento FR NO traducido (no-op)
# El mismo fragmento FR, aislado:
detected_source_language = "FR" -> traducido correctamente ("Hola... Gracias")
# Proveedor IA (OpenAI / Gemini / Claude) - todo el documento como contexto
-> traduce cualquier fragmento fuera del idioma de destino, sin detección única
La conclusión de quien opera: para clientes internacionales y contenido multilingüe dentro de un mismo documento, el proveedor adecuado es la IA, que traduce semánticamente cualquier fragmento fuera del idioma de destino usando todo el documento como contexto. DeepL y Google siguen siendo excelentes - y más baratos - para tickets escritos íntegramente en un solo idioma. Por eso el módulo deja la elección del proveedor en tus manos y no impone uno solo.
| Proveedor | Mejor para | Documento multilingüe (etiquetas + mensaje) | Coste típico |
|---|---|---|---|
| DeepL | Calidad en idiomas europeos, texto monolingüe | Detecta 1 idioma dominante - el fragmento minoritario puede quedar sin traducir | Por carácter |
| Google Cloud Translation | Amplia cobertura de idiomas, alta disponibilidad | Misma limitación de detección única | Por carácter |
| IA (OpenAI / Gemini / Claude) | Contexto, tono humano y contenido multilingüe | Traduce cualquier fragmento fuera del idioma de destino | Por token |
Cómo activarlo
- En GLPI, abre el plugin NexTool y ve al catálogo de módulos.
- Localiza Translate (Traductor de Tickets) y haz clic para activarlo.
- Abre la configuración del módulo, ve a la pestaña Integraciones, elige el proveedor (DeepL, Google o IA) y pega la clave de API correspondiente - se guarda cifrada.
- En la pestaña Prueba, ejecuta la prueba de conexión para validar la clave antes de liberarla al equipo.
- Si quieres, ajusta el alcance por entidad, la retención de la caché y de los registros, y el nivel de registro. A partir de ahí, el botón de traducción aparece en los elementos de la línea de tiempo de los tickets.
Una rutina de limpieza diaria (el cron del módulo) elimina los registros y la caché antiguos según la retención configurada, para que el módulo no acumule datos indefinidamente.
Para quién está indicado
Translate tiene sentido para service desks que atienden a clientes, filiales o proveedores en más de un idioma - y especialmente para quienes reciben leads y formularios de sitios internacionales, donde el mismo ticket mezcla idiomas. También ayuda a equipos distribuidos, donde cada técnico prefiere leer en su propio idioma.
Cuándo no merece la pena: si toda la operación y todos los clientes usan un único idioma, el módulo no aporta - y evitas el coste de una API de traducción. Si la política de datos prohíbe enviar el contenido de los tickets a servicios externos, evalúa el proveedor con cuidado, porque la traducción, por naturaleza, envía el texto al proveedor elegido; en ese caso, restringe el alcance por entidad y trata la elección del proveedor como una decisión de privacidad.
Compatibilidad
- GLPI: 11.x, sobre el plugin base NexTool.
- Plan: gratuito - Translate se distribuye sin coste de licencia a través del catálogo de módulos NexTool.
- Requisito externo: una clave de API del proveedor elegido (DeepL, Google Cloud Translation o el LLM de OpenAI/Gemini/Claude), cobrada por uso por el propio proveedor.
Siguiente paso
Translate forma parte de NexTool. Si tu equipo pierde tiempo alternando entre GLPI y traductores externos en cada mensaje, habla con el equipo y te ayudamos a elegir el proveedor adecuado para tu escenario.
Este conteúdo foi produzido com auxílio de inteligência artificial e revisado pela equipe Nextool Solutions.
