I would like to start a broader discussion about the current state of local terminology management in Trados Studio 2026.

To be clear, I am not opposed to the new TTB format itself. I understand that replacing the legacy SDLTB format may be necessary to provide a more modern foundation for terminology in Studio.

My problem is that RWS has made the new format mandatory before delivering a terminology-management workflow capable of replacing the previous one.

The current situation, as I understand and have experienced it, is as follows:

• Existing SDLTB termbases can be converted to the new TTB format.
• Trados Studio 2026 no longer supports SDLTB termbases.
• MultiTerm Desktop 2026 does not support the new TTB format.
• The new Termbases view in Studio provides certain administrative functions, such as creating termbases, configuring settings, and importing or exporting data.
• However, it does not provide a proper environment for browsing, editing, and maintaining terminology entries.
• Routine entry work therefore has to be performed in the small Termbase Viewer within the Editor, which means opening a translation project simply to manage terminology.
• TTB export appears to be limited to exporting the complete termbase. There is no equivalent of the filtered export workflows available in MultiTerm.

That last point has a major practical impact on our terminology processes.

We regularly need to export selected subsets of a termbase, for example:

• newly created terminology;
• entries awaiting review or approval;
• approved entries;
• terminology from a particular subject area;
• entries selected for exchange with a particular group or system.

A full XML export is useful for backup and interchange, but it is not a replacement for filtered, workflow-oriented exports.

In theory, I suppose I could export the complete TTB database as XML, create a new SDLTB termbase in MultiTerm using the appropriate termbase definition, import the XML, and then perform the filtered export from there.

But are users seriously expected to reconstruct and maintain an SDLTB version of their terminology whenever they need functionality that was already available before upgrading?

This also creates obvious risks:

• duplicate termbases;
• uncertainty about which database is authoritative;
• synchronization problems;
• unnecessary conversion and import work;
• possible loss or alteration of data during repeated round trips.

Incremental development is understandable, but this is not a feature that can safely be replaced in tiny, disconnected steps when the old workflow is removed at the same time.

A responsible transition could have taken several forms:

1. Studio 2026 could have continued supporting both SDLTB and TTB until the new workflow was complete.
2. MultiTerm 2026 could have supported TTB during the transition.
3. TTB could have remained optional until the essential terminology-management functions were available in Studio.
4. A reliable bidirectional conversion workflow between TTB and SDLTB could have been provided.

Instead, Studio cannot use the format supported by MultiTerm, while MultiTerm cannot use the format required by Studio. At the same time, Studio does not yet provide the terminology-management capabilities that MultiTerm previously supplied.

From the perspective of someone who actively manages terminology rather than only looking up terms while translating, the storage and recognition layer may be ready, but the terminology-management workflow is not.

I therefore have two questions for RWS:

1. What is the intended workflow in Trados Studio 2026 for professional terminology management, particularly entry maintenance, filtering, review, approval, and selective export?
2. Why was SDLTB support removed before either Studio or MultiTerm could provide a complete working environment for the new TTB format?

I would also be interested to hear how other terminology managers are handling this transition. Are you maintaining parallel SDLTB and TTB termbases, rebuilding SDLTB databases from XML exports, remaining on Studio 2024, or using another workaround?