Title: Inline per-article translation (“See translation”) in the ticket view
- What is your original issue/pain point you want to solve?
We run a web shop helpdesk based in Croatia that also serves German- and English-speaking customers (we have a separate German shop). Incoming emails arrive in a mix of Croatian, German and English, and no single agent reads all three comfortably.
Today, when an agent opens a ticket whose incoming message is in a language they don’t speak, they copy the message text out into an external translator (Google Translate / DeepL) in another browser tab, read it there, then switch back to reply. That is slow, breaks their flow, mangles the HTML/formatting of the original, and — the part that bothers me most as an admin — it sends customer message content to a third-party service that we have no control over and haven’t vetted, entirely outside Zammad.
- One or two concrete situations where this hurts most:
- A German customer of our .de shop writes in asking about a product. The Croatian agent has to understand the request precisely (product names, quantities, an order number) before quoting. Right now that means copy-pasting the body into an external tab every time.
- A short back-and-forth where just one incoming message is in a foreign language. The agent only needs the gist of that single message — not a summary of the whole ticket. There’s no quick way to get it.
- Why is it not solvable with the Zammad standard?
I looked into using what’s already there, and neither fits:
- AI ticket summary is per-ticket and rewrites the whole conversation. It doesn’t give a faithful translation of one specific incoming message, and it always processes the entire ticket.
- AI writing-assistant text tools only work inside the reply editor (the contenteditable field). They can’t act on the read-only rendered article body, so there is no way to translate an individual incoming message while just reading a ticket. The stock “Translate to English” text tool also has a fixed target language and lives in the compose box, not per-article in the ticket view.
- Language detection already exists (detected_language via CLD) but is only shown as metadata — nothing acts on it.
So the capability’s building blocks are present, but there’s no per-article, view-mode translation.
- What is your expectation / what do you want to achieve?
Facebook-/Gmail-style inline translation: a small “See translation” link under each incoming customer article whose detected language differs from the agent’s own language. Clicking it translates only that one message into the agent’s preferred locale, shown inline beneath the original (original left untouched), with “See original” to collapse it back.
Key points I’d want in a proper implementation:
- Uses Zammad’s already-configured AI provider — no new vendor or dependency, and customer content stays within the AI integration the admin already chose (not a random external tab).
- Only the single article is sent, server-side sanitized, cached per article + locale, run in a background job, permission-gated, and off by default.
I’ve actually built a working prototype of exactly this against the new desktop UI and have been running it on our own instance. Sharing it in case it’s useful or worth pursuing upstream — happy to take direction on the approach:
Code / diff: Comparing develop...feature/article-inline-translation-develop · CroDevil75/zammad · GitHub
Your Zammad environment:
- Average concurrent agent count: ~3
- Average tickets a day: ~15
- What roles/people are involved: agents handling inbound customer email across a multilingual web shop (Croatian primary, plus German and English customers); admins configure the AI provider
Anything else useful: The implementation reuses existing Zammad conventions (the AI::StoredResult cache and the async summarize job pattern), keeps the original message unchanged, protects code/URLs/inline images from being altered during translation, and treats the message strictly as untrusted content (prompt-injection safe).