Hi Evzen,

Can you share a project and termbases for me to look at?  I just quickly created this scenario and don't have any problem so I think we need to see what you have set up that I don't and then we can investigate more:

I will send the project privately in a moment.

This is what I get:

Well, you are "barking the wrong tree" ;-)... that "strange thing to do" is actually just a result of bad Studio design.

If termbases configuration would be consistent with TMs configuration - i.e. if it would

1. allow configuring language-specific termbases (which is impossible as you pointed out)
2. not force me to select default termbase (since termbases are 'read-only' in my scenarios and never updated by translator)

then I would not need to end up with that "strange thing to do"...

Or maybe I'm missing something and you will show me some smart way to solve this very typical real-project-life scenario:

• terminology is handled purely on client side
• client has absolutely no clue about localization and about "proper ways" to do misc. stuff
• therefore terminology is ALWAYS updated ONLY on client's side... NEVER by translators (because client believes he knows everything best and LSP is "just a bunch of cheapo translators, who's only task is light-speed translation for (almost) no money"
• so terminology comes from client in Excels, separately for each target language (optionally also in differently formatted Excels, since each language is handled by different person and a) these persons do not talk to each other, b) client doesn't care about unifying the Excel formats)
• terms list differs between languages (lang. A has 30 terms, lang B has 200 terms... some terms may or may not be common for more languages)
• these Excels may or may not come from client in regular intervals (e.g. weekly or bi-weekly)
• there is a separate "term list" and "do-not-translate terms list" Excel file for each language
• there is absolutely no time for some smart processing of the Excels (like merging them together or some other engineering voodoo) since new projects are coming VERY often from the client and with VERY tight deadlines
  (as mentioned, client has no clue about localization processes and tools, so believes either that translators have these Excels opened on a side and manually check the terminology in there... or something very similar)
• engineers handling the projects are VERY junior, basically know nothing about localization and are basically able to follow just simple "click this, then click this, copy this here and then click that" recipes, without actually understanding what they are doing :-\

So what's happening is that the Excels coming from client are simply converted to termbase using Glossary Converter (no-config quick drag-and-drop no brainer), so we end up with 2 termbases per language.

And now the point is that we need SIMPLE and fast(!) way to create Studio project and packages for translators which would have the termbases pre-configured for them, so that translators won't be required to touch any setting(!). This is important requirement since there is a very bad experience with translators and their knowledge of the tools they are using, i.e. we cannot rely on translators being able to set up everything correctly... and even if they would be able to, they simply won't do it... (we have been through this discussion recently in the other thread... BTW, to all translators reading this and feeling offended - then you simply do NOT fall into this category... as simple as that... unfortunately there are many others - probably much cheaper than you - that do...). So we really need to have everything pre-configured, so that translators will just open the package and start working ("just wash and go...").

So... to do this following the current crazy design, engineer would have to add termbase(s) for one language and create package for that language... then remove these termbases and add another one(s) for another language and create package... and so on, e.g. for 25 languages... Doh!
Not only would the engineer spend his life by clicking, but would most probably do some very bad mistake very soon...

It seems to me that these design flaws are caused by SDL focusing too much on the translator side (i.e. on how translators work, using Freelance version) and effectively ignoring the engineering/PM side (i.e. scenarios intended for the Professional version).
We have seen too much "bells and whistles" for translators recently (e.g. all this fragment matching buzz, etc.), but no progress at all in the terrible user experience or the design flaws like this one... Given the uncomparable price of the Professional vs. Freelance license, it's frustrating and not fair at all.

Well, you are "barking the wrong tree" ;-)... that "strange thing to do" is actually just a result of bad Studio design.

If termbases configuration would be consistent with TMs configuration - i.e. if it would

1. allow configuring language-specific termbases (which is impossible as you pointed out)
2. not force me to select default termbase (since termbases are 'read-only' in my scenarios and never updated by translator)

then I would not need to end up with that "strange thing to do"...

Or maybe I'm missing something and you will show me some smart way to solve this very typical real-project-life scenario:

• terminology is handled purely on client side
• client has absolutely no clue about localization and about "proper ways" to do misc. stuff
• therefore terminology is ALWAYS updated ONLY on client's side... NEVER by translators (because client believes he knows everything best and LSP is "just a bunch of cheapo translators, who's only task is light-speed translation for (almost) no money"
• so terminology comes from client in Excels, separately for each target language (optionally also in differently formatted Excels, since each language is handled by different person and a) these persons do not talk to each other, b) client doesn't care about unifying the Excel formats)
• terms list differs between languages (lang. A has 30 terms, lang B has 200 terms... some terms may or may not be common for more languages)
• these Excels may or may not come from client in regular intervals (e.g. weekly or bi-weekly)
• there is a separate "term list" and "do-not-translate terms list" Excel file for each language
• there is absolutely no time for some smart processing of the Excels (like merging them together or some other engineering voodoo) since new projects are coming VERY often from the client and with VERY tight deadlines
  (as mentioned, client has no clue about localization processes and tools, so believes either that translators have these Excels opened on a side and manually check the terminology in there... or something very similar)
• engineers handling the projects are VERY junior, basically know nothing about localization and are basically able to follow just simple "click this, then click this, copy this here and then click that" recipes, without actually understanding what they are doing :-\

So what's happening is that the Excels coming from client are simply converted to termbase using Glossary Converter (no-config quick drag-and-drop no brainer), so we end up with 2 termbases per language.

And now the point is that we need SIMPLE and fast(!) way to create Studio project and packages for translators which would have the termbases pre-configured for them, so that translators won't be required to touch any setting(!). This is important requirement since there is a very bad experience with translators and their knowledge of the tools they are using, i.e. we cannot rely on translators being able to set up everything correctly... and even if they would be able to, they simply won't do it... (we have been through this discussion recently in the other thread... BTW, to all translators reading this and feeling offended - then you simply do NOT fall into this category... as simple as that... unfortunately there are many others - probably much cheaper than you - that do...). So we really need to have everything pre-configured, so that translators will just open the package and start working ("just wash and go...").

So... to do this following the current crazy design, engineer would have to add termbase(s) for one language and create package for that language... then remove these termbases and add another one(s) for another language and create package... and so on, e.g. for 25 languages... Doh!
Not only would the engineer spend his life by clicking, but would most probably do some very bad mistake very soon...

It seems to me that these design flaws are caused by SDL focusing too much on the translator side (i.e. on how translators work, using Freelance version) and effectively ignoring the engineering/PM side (i.e. scenarios intended for the Professional version).
We have seen too much "bells and whistles" for translators recently (e.g. all this fragment matching buzz, etc.), but no progress at all in the terrible user experience or the design flaws like this one... Given the uncomparable price of the Professional vs. Freelance license, it's frustrating and not fair at all.

Hi Paul, forum members,

I encountered the same bug on Trados 2021 SR2 still persisting.

Only translations from the default TB are shown, and only terms (w/o translations) from the recognized terms found in other (not default) TB's.

All the language pairs (project's, TB's) are identical.

Are there any workaround for this by now?

Seems it's a rather widespread problem for Trados users:

https://community.rws.com/product-groups/trados-portfolio/trados-studio/f/multiterm/14111/term-recognition-only-shows-results-of-first-termbase

https://community.rws.com/product-groups/trados-portfolio/trados-studio/f/multiterm/20185/term-recognition-only-shows-target-term-results-for-the-default-termbase-when-multiple-termbases-are-added-to-a-project

https://community.rws.com/product-groups/trados-portfolio/trados-studio/f/studio/8236/any-way-to-search-multiple-multiterm-termbases-while-having-only-hits-from-a-single-termbase-shown-in-term-recognition-pane