To better describe the situation.
If the German "klicken" with matching English "click" is defined in the TB, "clicking" will not match, although a 5/8 match value would.
Possibly allow different match values for source and target.

Thanks Anthony - I am wondering if you had a chance yet to look at our cloud-based terminology offering. The reason I am asking this is that we have added a new type of search there called "linguistic search" - which is the new default rather than fuzzy search as we have it in MultiTerm. I believe that you will not see such false positives anymore with the linguistic search, since it will consider derived forms in a much better, more 'linguistic' way, rather than the more 'brute force' fuzzy search. Might be worth a look potentially.

Thanks Anthony - I am wondering if you had a chance yet to look at our cloud-based terminology offering. The reason I am asking this is that we have added a new type of search there called "linguistic search" - which is the new default rather than fuzzy search as we have it in MultiTerm. I believe that you will not see such false positives anymore with the linguistic search, since it will consider derived forms in a much better, more 'linguistic' way, rather than the more 'brute force' fuzzy search. Might be worth a look potentially.

I tried some time ago, but failed to register on the cloud. I will try again. 

But if my suggestion to also apply a match value to the target would largely solve the problem with false positives for term derivatives. I cannot imagine that this is a large change to the logic: does the flagged term lies within the weighted value?

Hi Anthony - the challenge may be that we do a different kind of term recognition in the source segment as opposed to the target and this might play into it also, and then it would be a bigger change, but I might be wrong. In any event, when reinventing terminology in the cloud, we were keen to think about these things from day 1 and hence came up with the linguistic search.