Yulia Kovalskaya 

1. Exactness of phrase match
   • Is the entire term ("comprehensive maintenance") present as-is?
   • If yes => 100% match
   • If only components are found, Studio will attempt a fuzzy term match
2. Proximity of tokens
   • If the term is made up of multiple words, Trados checks how far apart those words are in the segment.
   • Closer = higher match score
   • Separated by multiple words or punctuation = lower score
3. Additional modifiers or interference
   • Words like “digitized” and “complex” interrupt the expected phrase, reducing confidence in the match.
4. Order of tokens
   1. If the words are out of order, it further weakens the score.

So, if I then look at some examples:

I changed the distance between "comprehensive" and "maintenance" in each one resulting in 78%, 87% and 72% matches, all based on the same single termbase entry "comprehensive maintenance".

Yulia Kovalskaya said:

First, I thought that Multiterm recognized only "comprehensive" and returned a fuzzy match from the database (even this would be a 50-60% match, definetely not 70%, in my opinion).

If it was a translation memory I'd agree... but it's not :-)

Studio attempts to infer the intent and provide useful term suggestions even if the exact match isn’t there.  In your use case (technical documentation/rail), this behaviour might be quite useful.  But equally it could be misleading if translators assume that “comprehensive” or “maintenance” are individually present in the termbase (when they're not).  So one difference I do see between 2024 and 2022 is that the match value seems to be there by default in 2024 (it wasn't in 2022 - although I didn't investigate this to see if my earlier or current default settings are at play).  Either way the match score helps flag that partial matches are being made, based on token recognition and order.

Hope that helps?

As always, thank you for answering, Paul!

As for the match value, it appears in 2024 version. My colleagues with Trados 2021/2022 do not have it and there is no such option in the Hitlist settings.

But this is not the issue. Technically, I do not know how the match calculation is performed, but let me assure you that Multiterm has never "recognized" terms separated by word/words before.

A recent example: my colleague asked me about a very common system used on the train (Juridical recording unit / Unidad de Registro Jurídico), she needed the exact, "official" term in Russian. Since I work on the TDB on a daily basis, I knew it HAD to be there, so I wondered why it did not appear in the Multiterm window.

In effect, it was not there, because the engineer used the wording "unidad jurídica", and I had only the first three options saved: 

Therefore, Multiterm had "unidad de registro jurídico", but when it came across "unidad jurídica", it was not recognized as a fuzzy match (null result). As you can see, I added this term "variation" to the database.

This is why the example I came across yesterday kind of struck me. Because it would save me recording so many "similar" wordings in the database (I really have plenty of them):

And in Russian, for example, the adjective can come before or after the noun (without any change in meaning), so I have to save both. If not, the term won´t be recognized.

So I think, some kind of update-improvement has been performed on the Multiterm search engine. But, then, I am just the final user :).

And if it works as you have explained above, then it is really great, since this may save us many manual fuzzy searches.

Best regards!

Yulia Kovalskaya 

Yulia Kovalskaya said:

Technically, I do not know how the match calculation is performed, but let me assure you that Multiterm has never "recognized" terms separated by word/words before.

Really... 

Paul, you are always so helpful!!! Then, it´s great news! The more terms are recognized by Multiterm, the better!

And I have double-checked. The colleague with the JRU example has Trados 2021 (we are working with 3 Trados versions: 21,22 and 24), so maybe it was slightly different in that version.

Anyway, the more we are shifting towards TA revision instead of translating from zero, the more useful Multiterm becomes. At least, this is how I see it...

Thank you very much once again!!!!

Yulia Kovalskaya 

The JRU example didn't get found because of the order, proximity and presence of the tokens.  In your termbase you have "Unidad de Registro Jurídico", but if your sentence only contains the wording "unidad jurídica" then only two out of four tokens from the full term are there.  So the phrase is farther in meaning and structure from the full term entry.  This is the same in 2024.

If I do something like this where all four tokens are found I get a 64% match:

But still only the one term:

So possibly useful, but you'll only be accurate by entering the terms you actually want control over.

As I do this I can see why it was worth adding the fuzzy values because now users will have a better understanding of what this is actually telling them, and it's essentially a tool they can use where appropriate to help with the right term that is actually needed.  But not mistake this for a 100% match that they have to be using!

Dear Paul!

What you mean is that if the word "registro" had been present in that sentence and if the match % had been lowered to 60%, then I would have probably gotten a fuzzy match, right? Ok, interesting.

However, I do not go below 70%, sometimes even set it to 80%. And I if want to search incomplete matches, then I go to the Fuzzy search in the Termbase window. 

Well, actually there are so many ways of searching The Multiterm TDB, most important is to have a good content

Best wishes and have a good week, Paul (though I cannot promise i won´t reappear soon with some other doubt-question of mine:).

As always, thank you very very much!

Me again, Paul:)

Something does not work. Look at this example:

We have "Passenger information system" in the TDB:

So, as far as I can understand: two of the three words (tokens) are present in the source segment, the match % is lowered to 60%, however, it is not detected by the search engine. For whatever reason. Nevertheless, "passenger" and "information" are recognized separately. 

I also selected "passenger information" in the source segment and used CTRL+ALT+F1 to perform the same search via Multiterm Widget: 

Then I have another question: how do these two options affect the search results: 

I played with them, but saw no difference...

Thanks in advance!

Yulia Kovalskaya 

ok - so you're not using 2024, so here's my 2024:

You can see I get a 75% match.

Then checking in 2022 I also get the same recognised terms:

I can't use 2021 on my laptop now so if that's what you're using you're on your own ;-)

Yulia Kovalskaya said:

Then I have another question: how do these two options affect the search results: 

I played with them, but saw no difference...

Most likely you are affect by whatever is causing you not to get a result in the first place!

But you can always use the help...

https://docs.rws.com/en-US/trados-studio-2024-1145319/terminology-recognition-settings-345706

Somehow the same version works differently:

Thank you for the link with the settings explanation!!!! Will study it!

Paul said:

Most likely you are affect by whatever is causing you not to get a result in the first place!

I am thinking about all the mergings I perform on the entries...maybe they are causing the "recognition" troubles. 

I will read the article, probably it has the answers:)

Thank you, Paul!!!

Yulia Kovalskaya 

Maybe a reorganisation would help?