Hello Paul,

Has there been any progress on this issue?

Still present in 2021 and I do have a client who would really appreciate this working as it should...

Thx,

Ed

Hi, I wanted to check in on this issue too. The alleged workaround with regex is simply non-practical for large termbases. Moreover, a termbase should work as expected: checking target and source to mark terms as forbidden. PLEASE, correct this current (and useless) behaviour...   

Regards,

Almudena

I also encountered this issue. The option to flag forbidden terms via terminology verification ends up being useless this way. You could instead use y simple wordlist.

The term verification should only give an alert when a forbidden term was identified in the target segment where a source term for the same entry was identified in the source segment.

What's more is that if you have a field for forbidden terms in your termbase but its datatype is not set to picklist but to plain text, you still can tick the option for checking for forbidden terms. But you cannot set any criteria. You even get a blinking warning symbol saying there is no picklist. If you then perform a QA Check with terminology verification, forbidden terms are flagged nonetheless. I do not undestand this behaviour at all.

I also encountered this issue. The option to flag forbidden terms via terminology verification ends up being useless this way. You could instead use y simple wordlist.

The term verification should only give an alert when a forbidden term was identified in the target segment where a source term for the same entry was identified in the source segment.

What's more is that if you have a field for forbidden terms in your termbase but its datatype is not set to picklist but to plain text, you still can tick the option for checking for forbidden terms. But you cannot set any criteria. You even get a blinking warning symbol saying there is no picklist. If you then perform a QA Check with terminology verification, forbidden terms are flagged nonetheless. I do not undestand this behaviour at all.

Luciano, Almudena Ballester

Luciano said:

The term verification should only give an alert when a forbidden term was identified in the target segment where a source term for the same entry was identified in the source segment.

I fully agree with you this is a weakness. Even if there is a way to automate the generation of regular expressions from some TB export - this should work out of the box.

There are suggestions to implement this, but they need more upvotes:

• https://community.rws.com/ideas/trados-portfolio-ideas/i/trados-studio/when-checking-for-non-usage-of-target-terms-accept-if-one-target-term-is-used
• This idea corresponds exactly to the issue you struggle with: https://community.rws.com/ideas/trados-portfolio-ideas/i/trados-studio/studio-behaviour-with-forbidden-terms
• And since we are at it, this is also a very useful feature request regarding how forbidden terms are handled: https://community.rws.com/ideas/trados-portfolio-ideas/i/trados-studio/exclude-forbidden-terms-from-automation-autosuggestfuzzy-repair-etc

I hope you can have a look at these and upvote them.

Daniel

PS:

Luciano said:

What's more is that if you have a field for forbidden terms in your termbase but its datatype is not set to picklist but to plain text

I think this is a wrongly set up TB. Setting up a TB is tricky, but as a general rule, fields like "status" or whatever should be picklists. Only comments, notes etc. should be plain text. Plain text should only be used where a closed datatype is impossible to use.

Daniel, thank you for sharing those idea links. I have voted them up.

With respect to our TB setup, yes, I know such fields should be picklists. However, I need a reason to change the field datatype to a picklist. I thought being able to flag forbidden terms would be that reason. But now that I know it does not work, I don't see a reason to change it. The only way we can profit from those fields while translating in Trados Studio is by highlighting the field value in red in the term recognition window.

What I don't understand is that even though the field datatype is plain text and I am not able to select any values to search for as forbidden terms, I get an error warning while translating and when verifying terminology within the QA check I also get errors for using forbidden terms. So, how does Studio determine what a forbidden term is for me, if I could not specify anything.

Luciano

Could you post a screenshot of such an error message?

It's the general error message for wrong terminology usage:

And that termbase does not have any picklist fields? I can't reproduce that.

I just tested with a completely new termbase and at first could not reproduce it either. But then I figured out what was happening.

During my tests I created different termbases with almost the same definition: the only thing changing was the datatype of the forbidden term field. When I used the termbase with the picklist in my test project and defined the according picklist value to be checked for during the terminology verification, everything went by as expected: when the forbidden term was used, it was flagged with an error message.

Now, after testing that, if I changed the termbase in that test project to a tembase without the picklist but with a text value instead, somehow Studio seems to remember settings from the other termbase with the picklist. So it still flaggs the forbidden term. This was regardless of the termbases' names. Probably it has to do with the termbase definition.

Luciano

Thanks for soling the riddle! Hm, since the problem only seems to occur after a series of very unusual steps I'd not be too worried about it. It might be a bug, but one that you are unlikely to run into when using Trados Studio in a normal way (i.e. not testing this functionality, just using it).

Another user started a thread with about the same topic here: https://community.rws.com/product-groups/trados-portfolio/trados-studio/f/studio/40562/quality-check-terminology-forbidden-picklist-fields-any-way-to-have-this-trigger-depending-on-source-terms

I am waiting for an answer from Daniel Brockmann concerning this, whether there is hope on the horizon or not. If not I might try to find a workaround. If I do I will post it.

Daniel