IMPORTANT MESSAGE: We are still experiencing some difficulties that will affect your ability work with the RWS AppStore. Our IT team is working to resolve this but for now you may not be able to download or upload apps through the RWS AppStore. We apologise for the inconvenience and will update the community when we have a resolution in place. In the meantime you can take advantage of the Private AppStore if you are using Trados Studio 2021 or 2022.

Term recognition problem: only the terms recognized in the first (default) termbase are shown in full

Hi, please help if you could solve this problem:

Working environment: Windows 10 + Office 365 + SDL Trados Studio 2015 (with multiple termbases).

Problem: Term Recognition window within Studio (Edit) only shows full term recognition results (source + translation) from the first (default) termbase,  while for the second/third termbase, the same terms are still recognized, but it shows only the source term (without translation).

Note: The problem remains after (1) reorganizing the termbases, and/or (2) using new termbases.

 

Picture below:

 

  • Hi Yejun,

    This issue occurs since SR2. The previous version has no such issues. I tested myself.

    One workaround is that ensure the language pairs of the termbases are "exactly the same"

    Ivan

  • Hi, Pengfei, thank you for your reply. It seems to be not working even with exactly the same language codes! And it's strange that nobody brought this up in SDL Community and Proz forum if this happens so common. So SDL Support please step in to solve this. Thanks a million!
  • Indeed. Please fix this issue. It works just fine in SR1. Why now in SR2?
  • Hi Yejun,

    You can try changing the target language for both termbases to Chinese, not Chinese Simplified, and see if this solves your problem.

    Chunyi
  • I'm also having the same problem with Studio 2015 SR3 and MultiTerm 2015 SR2 (12.2.1657.4).
    Terms from non-default termbase show only source term, not the translation.

    Target languages are set EXACTLY the same, so the workaround apparently does NOT work.
  • 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:

  • Hi Evzen,

    Got your project and can obviously repro in 2015 and also 2017. Will look at this with support/development as appropriate and come back to you.

    Thank you for sharing this project.
  • Hi Evzen,

    We raised an enhancement request, CRQ-4205, for this problem you have shown. It's a slightly unusual situation because you are using as a default termbase one that doesn't have the target language in the project. So the pair is EN-DE but you use the EN-CZ bilingual termbase as default. In a way this makes no sense since you can't add terms to that termbase anyway, but as we take termbases at All language Pairs level you don't have a lot of choice other than to change the default so we should at least show the correct results from the non-default termbase.

    So an easy workaround, and probably one reason we don't see this reported a lot is because it's a strange thing to do... use as default a non-matching termbase.

    Regards

    Paul
  • 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.