Daniel Brockmann  already mentioned that this is working in the cloud and I can remember the customer for which I logged the case. But I also agree with Bernhard Hoell  who found out that the feature doesn't work as expected. I would also have expected a Studio package to contain only bilingual termbases. However, if the project contains more or all target languages, the feature no longer helps the user. We had also observed loading times of approx. 45 minutes and these are probably unavoidable with termbases with a large number of languages. This makes the work very time-consuming, especially if the package does not contain that many words for translation.

Thanks Achim Herrmann   - that particular change is not live yet. From what I know, it should go live in the next few week(s). I will also repeat that it's not good practice to work with terminology in offline workflows like this, as it creates unnecessary burden for the CAT tool downstream to do terminology imports for every package in every language, even if they are bilingual. It's better to see how online access to termbases can be given to the vendors and overall supply chain. But hopefully we'll soon see this enhancement anyway, where termbases will be bilingual for each offline package rather than multilingual like now. Thanks, Daniel

Hi Luis Lopes 
Thanks for sharing this information! I don't quite know if the new feature really solves the problem that is being discussed in this thread. After downloading some sdlppx packages (e.g. English>German) from Trados Enterprise and importing them into Trados Studio, I found that the packages still included the entire termbase with ALL languages rather than only listing the terms for the selected language combination.
What I actually envisioned the new feature to enable is to only include the English>German termbase entries for an English>German sdlppx package - plus, potentially in a future release, how Paul recently put it: "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."

Also, I find the feature description to be quite vague: "When choosing to include termbases when downloading a package, we now only include termbases that contain language pairs corresponding to the selected tasks". It reads as if only termbases were included that match the language combination of the task without actually removing the languages that are not needed for the individual package.

Thanks in advance for your feedback!

Hi Luis Lopes , I agree with Julian Hamm on this.

I did raise a support ticket on this issue because providing a large termbase resulted in taking 45 minutes plus for importing a Studio package on the Translation PJMs side because of redundant 38 languages being part of the Termbase export. If the languages are still part of the export, this does not seem to solve the particular issue I raised.

Hi Luis Lopes,

Do you happen to have an update on this? This is still an issue.

Thanks in advance for your feedback.

KR,
Julian

Hi Daniel Brockmann ,

I know that Luis mentioned that the feature is available with the 25.03.1 release, but we can confirm that it does not work as intended.
Linguists keep complaining about packages taking ages to import and Studio crashing because of these large files when working in the editor.
We tried to create bilingual termbases from the multilingual one using export filters and then reimporting using the xml and same xdt, but MultiTerm can't handle it (nor does the Glossary Converter).
Is there really no other option than to use a MultiTerm server?
I would appreciate your feedback. Maybe there is a smart workaround that I've missed.

Thanks in advance!
KR,
Julian

Hi Julian,

We are aware of this still being a problem in many cases. The fundamental issue here is ways of working: with online projects, this does not happen as a) no offline packages need to be created and b) linguists can connect to the project including its resources and everyone benefits from each other's work right away. Offline packages were designed to be a workaround where working online might not be possible. Having said that, it's of course important to have efficient ways of working with packages also, including terminology. But it does not really make sense to keep exporting neither full nor relevant only terrminology into the packages every single time - it's bad both for the platform due to the load and bad for the linguists importing the package as import needs to happen behind the scenes and this can take long with bigger termbases. But those termbases should not be in the packages in the first place really. So we are thinking to move to a model where optionally the offline packages will contain links to the online termbases, rather than physically copying the termbases into the packages all the time. Would that be a solution to your problem as well? You would still work offline (online is better ) but the terminology would point to the online repository with no need to have the overhead. Would that be a potential solution? Thanks, Daniel

Hi Julian,

We are aware of this still being a problem in many cases. The fundamental issue here is ways of working: with online projects, this does not happen as a) no offline packages need to be created and b) linguists can connect to the project including its resources and everyone benefits from each other's work right away. Offline packages were designed to be a workaround where working online might not be possible. Having said that, it's of course important to have efficient ways of working with packages also, including terminology. But it does not really make sense to keep exporting neither full nor relevant only terrminology into the packages every single time - it's bad both for the platform due to the load and bad for the linguists importing the package as import needs to happen behind the scenes and this can take long with bigger termbases. But those termbases should not be in the packages in the first place really. So we are thinking to move to a model where optionally the offline packages will contain links to the online termbases, rather than physically copying the termbases into the packages all the time. Would that be a solution to your problem as well? You would still work offline (online is better ) but the terminology would point to the online repository with no need to have the overhead. Would that be a potential solution? Thanks, Daniel

Hi Daniel,

Many thanks for your reply! Yes, I agree, working online would be the smarter way to go, but we are still bound to working offline for various reasons (one of which being that there is no direct end-to-end connection between two different instances of Trados Enterprise (customer <> LSP)). So the online termbase you mention above will be available without any specific user access/permissions? I am asking because Bernhard Hoell rightfully mentioned that this would require a generic key that can be used by anybody in order to avoid having to create specific user accounts.
If yes, then online termbases would be exactly the thing we are looking for 

I appreciate your input on the subject matter.

Best regards,
Julian