Trados termbase woes (finally being fixed?)

Termbases not working reliably in Trados Studio is a long-standing issue. The underlying technology – MultiTerm communicating with Studio via inter-process calls, on top of the old Microsoft JET/Access database engine – has been fragile for years, and it shows up as:

  • term recognition that randomly stops working mid-session
  • termbases that won’t accept new entries (“MultiTerm is unable to add the entry”)
  • general instability over long sessions, requiring termbase reorganisation or even project recreation

The community forum history is extensive (see below), and it’s hard not to see this as a persistent “tax” on translators’ time. As one long-suffering user put it: “This has been my experience when working with Trados for the past 10 years or so – term recognition simply stopping working, terms not being shown, completely unreliable F8 check.”

The root cause

The fundamental problem was architectural. Studio didn’t handle terminology directly – it delegated everything to MultiTerm running in the background. That behind-the-scenes communication channel was brittle, and once it broke during a session, term recognition would silently fail. The underlying JET/Access database engine only made things worse, adding its own layer of instability.

The promised fix: Studio 2024 SR1

In mid-2025, Daniel Brockmann (Principal Product Manager for Trados Studio) acknowledged the problem publicly on the RWS Community, responding directly to complaints about termbase reliability:

“You are right that this has been a challenge for us for many years (no beating around the bush here). The potentially interesting news is that for the upcoming Studio 2024 SR1 release, we have done some very deep changes in our code to bring all of the terminology logic into the Studio code base itself (most of it was living in the MultiTerm code base, and communication behind the scenes between Studio and MultiTerm could become fragile). As one example, this has helped us address term recognition problems where it might not work reliably anymore after a certain time of working. This should hopefully be a thing of the past now.”

Studio 2024 SR1 was released in the second half of 2025 and the official release notes describe the change as a “MultiTerm decoupling” – Studio now functions independently from MultiTerm for terminology handling. The SR1 blog post adds that terminology management has been “modernized, with all processing now happening entirely within Studio”, and that “term recognition and search now pull results from all loaded termbases more reliably”.

Has it actually worked?

The architectural change is real and substantial – they genuinely ripped out the old MultiTerm interop layer and brought terminology into Studio’s own codebase. On the developer side, the legacy Sdl.MultiTerm.TMO.Interop.dll has been removed entirely from the Studio installation folder.

But has it fixed the day-to-day experience? The jury is still out. As recently as October 2025, users who had upgraded to SR1 were still reporting that term recognition only worked for very short terms, with the problem persisting across different projects and file types. And the developer forums show that the decoupling introduced new bugs for third-party terminology providers.

Brockmann himself was honest about this, noting that they were “still stabilising this area after making these very extensive changes”. So the right foundations may now be in place – but I’ll believe it when I see reliable term recognition in my own daily work. The translators who depend on Trados deserve better than “hopefully a thing of the past”.

This is actually one of the reasons I built Supervertaler for Trados – a Studio plugin that sidesteps MultiTerm entirely and uses its own SQLite-powered terminology system for lookups directly in the editor. It also includes an AI chat assistant and a batch translator. If you’re tired of fighting with term recognition, it might be worth a look.

Comments