Just to say that I expressed the very same idea during a talk in Luxembourg in October, recommending it as the way forward. But I have no further ideas on its implementation (other than the slow way that you have outlined).

 Daniel Hug (DanielHug6562 Joost Buysschaert 

Hi, 
Unfortunately, I can't help you with AI Assistant, and passing the context of the document and termbase to the prompt can be difficult in general.
However, if you want to export the entire text and terms from the termbase in the document, and then import the AI translation, you can check out the TransAIde plugin. This plugin does just do that.

https://posteditacat.xyz/en/

https://www.youtube.com/watch?v=VbW-YH-yaw4&t=6s

https://appstore.rws.com/Plugin/414

Dariusz Adamczak (posteditacat.xyz)

Thank you Dariusz Adamczak ,

Your solution makes a lot of sense, but (cc:Daniel Brockmann ) I notice there are a lot of attempts at the moment to export content from Trados Studio in order to translate it within context using AI or MT systems, then re-import it into Trados. Michael Beijer's “Supervertaler” is another variation of the theme. I have been tinkering around with the XLIFF export function for the same purpose for almost a year now.

I think the message is clear: While there is a lot of utility in segmentation still, the time for context has arrived. This is a functionality that CAT systems should provide natively – and will, I am sure. The market will dictate it. The competitive advantage of being able to do so is overwhelming.

I am currently using Trados to translate with MT (more reliable than AI), export to XLIFF, hand the whole file over to an AI agent and re-import the translations. Then I work in Trados to do the QA steps or send projects off to co-workers. So while Trados is still the hub of my translation tech stack (file conversions/ file types!), the actual translation happens more and more outside of it. I wish it could move back in.

Daniel Hug 

I agree with you on many points.

Document-level context vs. segment-level context:
Once someone has tried using AI for translation with document-level context, they will never go back to segment translation. And the CAT industry must take this into account because the first solutions will reap the biggest rewards. However, this is not a trivial problem. Personally, I also would prefer to use Trados only for importing source files, as a QA tool, and for generating target documents. (https://posteditacat.xyz/beyond-segments-the-critical-role-of-context-in-modern-translation/).
I think there are many translators who work this way or at least copy text from AI to their CAT tools, because they don't know that there are already tools for this purpose. I only now just found out about Michael Beijer Supervertaler for example.

XLIFF process:
My attempts to translate large XLIFF files with AI have not been very successful. XLIFF files are simply too large to be processed efficiently by AI. We could process them segment by segment, but then we wouldn't be able to retain the context of entire documents. Do you have any ideas for this?
For projects with a lot of exact and fuzzy segments, I develop a compact JSON format containing only the necessary data (source, existing target, segment identification, and status), and it works surprisingly well when updating large projects.

Let me reveal the nature of my own experiments (with small files - medical guidelines - of about 300 words only).
STEP1 I upload my source text and a glossary to NotebookLM and ask for a translation that respects the glossary. This yields a text-based translation.
STEP2 I turn source and target into a tmx-file using LF Aligner.
STEP3 I start up a project in Studio using the tmx and run through the text, revising where needed.

My latest experiment shows a few worthwhile improvements with this method as compared with an earlier translation in Studio (so in segmentation mode) of the same text, with Chat GPT as an engine. Two examples of improvements:
(1) in the earlier translation the title was rendered in a shortened version, which would be okay in the body of the text but not as a title. The NotebookLM translation (text-based) didn't make this error.
(2) in the earlier translation a feminine French term was referred to with the masculine pronoun "il" in a subsequent sentence; the NotebookLM version correctly chose "elle".

Hi guys,

Supervertaler has been undergoing extremely rapid development (thanks to Claude Code). I am even starting to get .sdlppx/.sdlrpx support working reliably!

See: https://supervertaler.com/changelog

Indeed, Supervertaler will soon even be signed and notarized on macOS and I currently already have ready-to-run Windows EXE and macOS DMGs in the latest releases on GitHub!   

https://github.com/michaelbeijer/Supervertaler/releases/tag/v1.9.276

In the beginning, I spent most of my time exporting bilingual files from memoQ or Trados and then pre-translating them in Supervertaler with AI (while creating the prompt on chatgpt.com), but the CAT tool in Supervertaler has now gotten so good that I prefer to do the actual human translation (post-tweaking, whatever you call it these days) in Supervertaler as well. Claude Code basically allows me to implement new ideas in mere hours that would take a proper team weeks! 

For example, I always loved the novel terminology display system I first encountered in the RYS plugin for Trados (then called "RyS Termbase & Translation Assembler"; now called "RYSTUDIO Post-editing Package"), so I implemented a version of it in Supertranslator. The whole process was completed in a day!

See: community.rws.com/.../the-sad-sad-state-of-trados-studio-s-useless-terminology-tools

Michael

• - https://appstore.rws.com/Plugin/135 (RYSTUDIO Post-editing Package)
• - http://www.rycat.cn/
• - www.rycat.cn/.../trados-postediting.html

Dariusz Adamczak 

Dariusz Adamczak said:

XLIFF files are simply too large to be processed efficiently by AI

Not sure if I understand this. Do you send the full XLIFF file? Have you tried stripping the <internal-file> content first ? (it can be huge if the original file had images)?

Hi guys! Supervertaler now has an "Okapi sidecar" — a lightweight Java microservice that runs quietly in the background and handles monolingual file imports and exports using the industry-standard Okapi Framework file filters.

See: https://github.com/michaelbeijer/Supervertaler/releases/tag/v1.9.342 + - https://supervertaler.com/changelog (see: v1.9.342)

What is the Okapi Framework?

The Okapi Framework is the same open-source localisation toolkit used under the hood by various professional translation tools. It contains thoroughly battle-tested file filters for dozens of formats — DOCX, XLSX, PPTX, HTML, XML, IDML, and many more — with proper handling of inline formatting, segmentation, and round-trip fidelity.

What does "sidecar" mean?

Since Okapi is written in Java and Supervertaler is a Python/Qt application, they can't talk to each other directly. The sidecar is a small Java process that starts automatically in the background when needed. Supervertaler communicates with it over a local REST API — sending files to be extracted into translatable segments, and sending translations back to be merged into a properly formatted output file. You never have to interact with it; it just works behind the scenes.

What does this mean in practice?

The previous system used a fully Python-based DOCX importer, which worked reasonably well but struggled with more complex formatting. The Okapi-powered system produces exported files that are exact replicas of the original in terms of formatting and layout — bold, italic, colored text, heading styles, fonts, lists — everything comes through faithfully. It also brings proper SRX segmentation, better paragraph detection, and semantic inline formatting tags (like <b> for bold) that are visible while you translate.

The new system can already be tested in the latest Windows builds available via pip. I'm also working on a Windows EXE release and a Mac DMG.

Hi guys! Supervertaler now has an "Okapi sidecar" — a lightweight Java microservice that runs quietly in the background and handles monolingual file imports and exports using the industry-standard Okapi Framework file filters.

See: https://github.com/michaelbeijer/Supervertaler/releases/tag/v1.9.342 + - https://supervertaler.com/changelog (see: v1.9.342)

What is the Okapi Framework?

The Okapi Framework is the same open-source localisation toolkit used under the hood by various professional translation tools. It contains thoroughly battle-tested file filters for dozens of formats — DOCX, XLSX, PPTX, HTML, XML, IDML, and many more — with proper handling of inline formatting, segmentation, and round-trip fidelity.

What does "sidecar" mean?

Since Okapi is written in Java and Supervertaler is a Python/Qt application, they can't talk to each other directly. The sidecar is a small Java process that starts automatically in the background when needed. Supervertaler communicates with it over a local REST API — sending files to be extracted into translatable segments, and sending translations back to be merged into a properly formatted output file. You never have to interact with it; it just works behind the scenes.

What does this mean in practice?

The previous system used a fully Python-based DOCX importer, which worked reasonably well but struggled with more complex formatting. The Okapi-powered system produces exported files that are exact replicas of the original in terms of formatting and layout — bold, italic, colored text, heading styles, fonts, lists — everything comes through faithfully. It also brings proper SRX segmentation, better paragraph detection, and semantic inline formatting tags (like <b> for bold) that are visible while you translate.

The new system can already be tested in the latest Windows builds available via pip. I'm also working on a Windows EXE release and a Mac DMG.