Michael Bailey 

You are right, this is a job for MultiTerm

At term entry level, you should have a list of your terms, meaning law or ministry name
So your initial termbase definition would look like this:

Entry 1
          Term A
          Term B

But then you amend your termbase definition to also support a term status field with a pick list of: Approved | Forbidden
This status field is at term level so your structure would look like this:

Entry 1
          Term A
          Status: Approved
          Term B
          Status: Forbidden

Now in your project settings within Trados Studio, under Terminology Verification you then

• Enable: Check for terms which may have been set as forbidden
• Decide the severity: in my screen print error
• Select the verified value

This means that even if your project has been deemed complete or regardless if they have given you an updated source text, so long as your termbase reflects the known changes you can reliably run term verification.  Those instances were once approved terms were used but now changed status - you will have a reduced list to assess and manually amend to the approved term as you see fit.

I hope I understood your post correctly and that the point of supporting termbase fields / definition is clear.

Lyds

Dear Lydia, 

Thanks for the quick response - I know that workflow well from using it for deprecated terminology and also for inclusive language. I just wanted to check that I wasn't missing a neater way of doing it!

As a slightly cheeky follow-up, would you advise saving the abbreviation used for the name of a ministry or law as another term in the same entry or as separate entries?

e.g 

Entry 1

Polizeiliches Staatsschutzgesetz
Forbidden

PStSG
Forbidden

Staatsschutz- und Nachrichtendienst-Gesetz
Approved

SNG
Approved

or 

Entry 1

Polizeiliches Staatsschutzgesetz
Forbidden

Staatsschutz- und Nachrichtendienst-Gesetz
Approved

Entry 2

PStSG
Forbidden

SNG
Approved

Thanks in advance for any further information!

Best regards, Michael

Michael Bailey 

Very good question as I have seen very mature termbase's like in your first example, where for each entry level each term is further supported by a formality field that it supports values long form or abbreviated form.

The fields of term status and formality then offer extended QA possibilities. But the drawback is then very active terminology management to ensure the entries, terms and field values are correct. 

Your second option may reduce the need to have a formality field for each term, which makes term management easier in that sense. Another benefit is that filters typically work across term entries and not terms themselves. But then I would be tempted to support entry note either at entry level or term level (**)  so one could cross reference and have some correlation between the two term entries (full form and abbreviated form) 

So, what you would then have is:

Entry 1
Field: Abbreviated
Note: ** with cross reference to entry 2
          Term: A
                   Note: ** with cross reference to entry 2: term A
                   Status: Approved
          Term B:
                   Note: ** with cross reference to entry 2: term B
                   Status: Rejected 


Entry 2
Field: longform  
          Term: A
                   Status: Approved
          Term B:
                   Status: Rejected 

For the sake of direct clarity and to avoid cross referencing, it's my preference to have 

Entry 1
          Term: A
                   Status: Approved
                   Formality: Abbreviated
          Term B:
                   Status: Rejected
                   Formality: Full form 

Either way, the term verification will require the picklist fields to be defined regardless of if at entry or term level.
 

Sorry I know. Helpful not helpful. As with some TM discussions, it's hard to have a strong view if you should work with 1 TM or based on specialisation (customer | content etc) 

Lyds

Thanks for the detailed response - will see how I get on with the approach that avoids cross-referencing! Realise that this might seem a very specific use case, but am sure others might have similar usages! 

Thanks again! Michael