I am in the process of re-organizing my organization's glossary. In several sources, including SDL sources like the White Paper on Terminology Management, the concept-oriented approach to term management is promoted. From a logical point of view, this is very convincing and I would like to implement it.
In this approach, each concept has a a termbase entry, so "stain" (the discoloration) has an entry and "stain" (the penetrative dye) has one = two entries (more if the respective verbs are added).
When I organize my TB like this, I get warnings (or errors, whatever is defined in the settings) for each homonym. The white paper mentioned above uses "monitor" as an example (the screen and the activity of observing).
Since the concept-oriented approach is so much promoted by SDL, I am wondering if I am doing something wrong that following that recommendation seems to render a key feature of MultiTerm integration in Studio practically useless. Is there an option to only warn if no target term at all is used?
the concept-oriented approach is not only promoted by SDL - it has always been the foundation of terminology in theory and in real terminology work for decades.
Terminology work is knowledge-based and linguistically motivated, and thus structured accordingly in a termbase (unless you do software glossaries etc). Translation memory technology, however, works on pattern matching, and so does term recognition (and term verification), it knows nothing about linguistics and concept-orientation.
There is no perfect solution to combine the linguistic resources with pattern-matching oriented systems.And those pattern-matching approaches are about to become obsolete in times of deep-learning, content enrichment initiatives etc. With SDL Language Cloud Terminology, now some linguistic features have been introduced for term recognition (and more "linguistic AI" seems to be on the SDL product roadmap). So maybe we can expect solutions to your problem in some future Studio + LC Terminology combination.
Hi Christine Bruckner
Thank you for your thoughtful reply. I know that at the moment there is no silver bullet for this problem, but I wonder whether some rather simple changes could improve how MultiTerm works with concept-oriented glossaries. In the meantime I tried to outline it here, and I would be happy to get input from somebody who obviously has more experience in this than I do:
you are definitely right with your ideas. I have raised similar ideas and enhancements requests in the past about 15 years with Trados/SDL (also in direct discussions with SDL representatives, for example in the European Trados User Group, see https://community.sdl.com/customers-partners/user-groups/etug_public/).
Sadly enough, I must say that hardly any of them has been implemented. So in the last few years, I rather focussed my energy on MultiTerm/Studio term features that used to work and then no longer worked properly after upgrades (e.g. term verification failures in the first release of Studio 2017 due to some field changes, merge import issues with MultiTerm Server 2015, or just recently this one: Multiterm 2019 Desktop user can delete termbase on MT Server 2015).
I keep my fingers crossed that your ideas will be implemented in whatever is/will be SDL's terminology solution in conjunction with SDL Trados Studio ;-)