Trados Studio
Trados Enterprise
Trados Team
Trados GroupShare
Trados Business Manager
Passolo
MultiTerm
RWS AppStore
Connectors
Beta Groups
Managed Translation
MultiTrans
TMS
WorldServer
Language Weaver
Language Weaver Connectors
Language Weaver Edge
Tridion Docs
Tridion Sites
LiveContent S1000D
XPP
Language Developers
Tridion Docs Developers
Community Help
RWS User Experience
Internal Trados Ideas Community
Mercury
RWS Community Internal Group
RWS Training & Certification
Style Guides
RWS Campus
RWS Enterprise Technology Partners
Trados Approved Trainers
ETUG (European Trados User Group) Public Information
Nordic Tridion Docs User Group
Tridion West Coast User Group
Trados Studio Ideas
Trados GroupShare Ideas
Trados Team Ideas
Trados Team Terminology Ideas
Trados Enterprise Ideas
Trados Business Manager Ideas
MultiTerm Ideas
Passolo Ideas
RWS Appstore Ideas
Tridion Docs Ideas
Tridion Sites Ideas
Language Weaver Ideas
Language Weaver Edge Ideas
Managed Translation - Enterprise Ideas
TMS Ideas
WorldServer Ideas
LiveContent S1000D Ideas
Contenta S1000D
XPP Ideas
Events & Webinars
To RWS Support
Detecting language please wait for.......
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 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
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:
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.