Idea Delivered Partially

Setting to delivered partially for cloud project flows but aware this is not available with file or server-based projects (not without third party solutions from the Trados ecosystem).

Only include target language-specific entries from a termbase when creating project packages

For some clients we work with large file-based termbases and a lot of target languages on a regular basis. When creating project packages, Trados Studio includes the entire termbase with all target languages
instead of creating smaller termbases that each exclusively contain the relevant language pairs, with the major downside being that unpacking and opening the project in Studio takes a lot of time.
This especially holds true for SDLPPX packages downloaded from Trados Enterprise and processed in Trados Studio, given that those packages include the XML+XDT instead of the SDLTB file,
thus adding extra time for Trados Studio for the conversion.

I think it would be quite handy to add an option to only include the target language-specific entries from a termbase in the package creation options.

Julian Hamm

  • This is already working as such in the cloud - when downloading a cloud project package with terms, those termbases will be bilingual only.

  • in reply to Paul

    Selecting the language would already be good, your addition would be even better. However, fuzzy matches would then also be important. So if ‘Kanne’ is used, that ‘Kannenwechsler, Kannenübergabe, Kannenfüllung’ would also be included.

    But if Trados or a plugin could fulfil the first requirement, that would be a good start. The workarounds are workarounds and it's not easy to find the time to do it again and again, as the termbases are added new terms to with almost every project.

  • in reply to Burim Bektesi

    I’d like to see a solution that went even further and created a termbase that only contained the terms that would be found in that project for each language in the project.  Perfectly possible to do via the APIs for any developer with time on their hands.

    The workaround proposed here is probably best carried out with the Glossary Converter as you could go straight to SDLTB without having to convert to an interim format.  In fact potentially you could do all of this and create the project using powershell since the Glossary Converter can be run via a command line. That could be a very neat solution.

  • in reply to Muhammad Khateeb

    Publishing MultiTerm offers several ways to select the desired fields and data ranges, including existing MultiTerm filters, proprietary filters, and a clickable tree structure. Publishing MultiTerm then stores your selection as an export definition so you can repeat the process later either manually or through the Windows Task Scheduler. The selected data are written to a simple XML format. The software then executes either an XSLT or XSLFO script in order to transform the data to XML or PDF. XSLT and XSLFO are standardized languages for use with XML. As a result, you can either ask us to create the desired target formats or create your own custom formats in-house. By combining flexible data selection with freely definable transformations, virtually any desired target format is possible.

    Features
    Export
    • Select the fields to be exported by simply clicking on them in a tree structure
    • Existing filters from MultiTerm can be used
    • The user can define additional filters in Publishing MultiTerm
    • Alphabetical sorting according to the "first" term of an entry or according to a term that has a certain field value (e.g., usage = standard)
    • Export definitions are saved for automated export via a command line or the Windows Task Scheduler
    • Connects to local and server-supported termbases via LAN or Anywhere connections

  • This is something I wanted to post since ages. Thank you. You are absolutely right. Event better would be to let us choose which languages to include in the package.