Handling a user who opens a ticket in another language stalls the whole flow: the agent selects the text, pastes it into an external translator, switches back to GLPI, replies - and repeats it on every new follow-up. The NexTool Translate module cuts out that back and forth by translating the description and the follow-ups right inside the ticket timeline, on demand, in the language of the agent's own session.
The problem
Anyone running a service desk that serves customers or branches in more than one language knows the scene: the ticket comes in English, French or Spanish, the agent selects the text, opens a translator tab, pastes it, reads it, goes back to GLPI and types the reply. On every follow-up from the requester, the cycle starts over. Besides being slow, the process pulls the text out of the ticket's context - the history is fragmented and the translation vanishes the moment the browser tab is closed.
The usual workaround, asking the requester to write in the support team's language, pushes the friction onto the customer and degrades the experience at the very first contact. For a team serving international accounts, language should not become an operational hurdle on every message.
How it works
Translate replicates, within the NexTool module architecture, the behavior of Teclib's translation plugin - with the difference of not locking you into a single service. It works inside the ticket timeline:
- Per-item translation, on demand: each timeline element (description, follow-up, task, validation or solution) gets its own translation button. Nothing is translated in bulk - the agent translates only what they need to read.
- Session language: the translation comes out in the interface language of whoever is logged in. A multilingual team handles the same ticket, each agent reading in their own language, with nothing to reconfigure.
- Three providers, your choice: DeepL, Google Cloud Translation or AI (an LLM from OpenAI, Google Gemini or Anthropic Claude). The choice is the provider - the target language is still the session's.
- Translation cache: the result is stored and reused. The same text is not translated - or billed - twice. The cache respects the content version: an edited follow-up is re-translated, an unchanged one is served from cache.
- Encrypted API keys: the provider key is stored encrypted (via GLPI's GLPIKey), not in plain text in the configuration.
- Per-entity scope and logs: you can restrict the module to certain entities (with inheritance to child entities) and track what was translated, by whom and with which provider, at an adjustable log level.
- Built-in connection test: before releasing it to the team, a button validates the configured key and provider.
DeepL, Google or AI: the choice that matters
All three providers translate monolingual text well. The difference shows up - and we learned this in day-to-day support - in tickets that are multilingual within a single document, which is the real case for anyone receiving leads and contact forms.
DeepL and Google Translate, on the REST API with automatic source detection, decide on a single language per document. In a lead ticket whose description is mostly English (the template labels: "Name:", "Company:", "Message:") with the customer's message in French, the provider detects English as the dominant language, sets the target to English and returns nearly identical text - the French passage stays untouched. We confirmed this with a real test ticket: the whole document was detected as EN (a no-op on the French), while the same French passage, in isolation, was detected as FR and translated correctly. The source-language column in the module's cache leaves no doubt.
# Ticket description from a lead (labels in EN + message in FR)
Name: ...customer...
Company: ...french company...
Message: Bonjour, je souhaite un devis... Merci.
# DeepL / Google (source=auto) - ONE language detected per document
detected_source_language = "EN" -> target en -> FR passage NOT translated (no-op)
# The same FR passage, isolated:
detected_source_language = "FR" -> translated correctly ("Hello... Thank you")
# AI provider (OpenAI / Gemini / Claude) - the whole document as context
-> translates any passage outside the target language, no single detection
The operator's takeaway: for international customers and multilingual content within a single document, the right provider is AI, which semantically translates any passage outside the target language using the whole document as context. DeepL and Google remain excellent - and cheaper - for tickets written entirely in one language. That is why the module leaves the provider choice up to you and does not force a single one.
| Provider | Best for | Multilingual document (labels + message) | Typical cost |
|---|---|---|---|
| DeepL | Quality in European languages, monolingual text | Detects 1 dominant language - the minority passage may go untranslated | Per character |
| Google Cloud Translation | Broad language coverage, high availability | Same single-detection limitation | Per character |
| AI (OpenAI / Gemini / Claude) | Context, human tone and multilingual content | Translates any passage outside the target language | Per token |
How to enable it
- In GLPI, open the NexTool plugin and go to the module catalog.
- Find Translate (Ticket Translator) and click to enable it.
- Open the module configuration, go to the Integrations tab, choose the provider (DeepL, Google or AI) and paste the matching API key - it is stored encrypted.
- On the Test tab, run the connection test to validate the key before releasing it to the team.
- Optionally, adjust the per-entity scope, the cache and log retention, and the log level. From then on, the translation button appears on the timeline items of tickets.
A daily cleanup routine (the module's cron) removes old logs and cache according to the configured retention, so the module does not pile up data indefinitely.
Who it is for
Translate makes sense for service desks serving customers, branches or suppliers in more than one language - and especially for those receiving leads and forms from international sites, where the same ticket mixes languages. It also helps distributed teams, where each agent prefers to read in their own language.
When it is not worth it: if the entire operation and all customers use a single language, the module adds nothing - and you avoid the cost of a translation API. If your data policy forbids sending ticket content to external services, evaluate the provider carefully, because translation by nature sends the text to the chosen provider; in that scenario, restrict the per-entity scope and treat the provider choice as a privacy decision.
Compatibility
- GLPI: 11.x, on top of the NexTool base plugin.
- Plan: free - Translate is distributed at no license cost through the NexTool module catalog.
- External requirement: an API key from the chosen provider (DeepL, Google Cloud Translation or the LLM from OpenAI/Gemini/Claude), billed by usage by the provider itself.
Next step
Translate is part of NexTool. If your team wastes time switching between GLPI and external translators on every message, talk to our team and we will help you pick the right provider for your scenario.
Este conteúdo foi produzido com auxílio de inteligência artificial e revisado pela equipe Nextool Solutions.
