• State Suggested Answer
  • +2 person also asked this people also asked this
  • Replies 16 replies
  • Answers 5 answers
  • Subscribers 196 subscribers
  • Views 8949 views
  • Users 0 members are here
Options
Related

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

Yejun Huang

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:

 
Rate translation
×
Suggest better translation
×
Moderator UI
×
  • Get AI Suggestion
Parents Reply Children
  • 0 in reply to Paul
    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
  • 0 in reply to 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.
  • 0 in reply to Evzen Polenka
    Hi Evzen,

    I don't disagree with you about the design... I guess one way to resolve this is use one termbase which might be acceptable given the emphasis you place on making things easy for the translator and the skills of the localization engineer. The Glossary Converter would make light work of all your excels into one multilingual termbase and then you wouldn't have this problem.

    Generally there is no need to lecture me, I get it. But really, given you can't even add terms to the termbase the way round you have this is it really such a bad workaround to change the default? You have to work with what you have. If you want something else don't waste your energy in here, post it into the ideas site and rally some support.

    Regards

    Paul
  • 0 in reply to Paul
    Surely creating multilingual termbase is one of the theoretical options. But - as explained in the Glosary Converter help - there may be problems in real life with merging on the source terms if they have different meanings in the separate Excel files. And since the client is extremely sensitive to ANY issues primarily caused on the LSP side - and mixing up or even losing terms is possible in such case - it's quite risky :-\.
    So it would be definitely preferable if Studio supported such real-life scenarios... i.e. I simply take this opportunity to express publicly the need in a hope that it gets noticed by responsible people (either you or some other SDL person) and treated internally appropriately.
    I don't think it belongs to ideas as it's simply not an "improvement idea", but rather a bugreport ;-).

    Anyway... regarding "changing the default", what exactly do you mean? How exactly should I "change the default", so that each of the 25 packages has the default correctly pre-configured? It means again millions of clicks and creating packages one-by-one :-(. Is that what you mean?
  • 0 in reply to Evzen Polenka
    I already gave you the enhancement number for this Evzen. On the default, you can't as this will obviously change for each translator. So they would have to do it.

    I guess there is nothing to help you that doesn't involve you doing some work. Hopefully we'll be able to do something sooner rather than later. I would still recommend you post it in ideas as our product management team might get the idea it's a fringe case if you're the only one complaining.
  • 0 in reply to Paul

    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
    emoji