Problem

AutoQA "Not-edited Fuzzy Match" does not work as it should

To reproduce

1st case

Pre-translate the attached txt file with the attached TM and a pre-translation match rate of 80%.

Segment 2 will be pre-translated with an 83% match.

It is logged as "not edited fuzzy match", what is correct.

If the user edits the match, the error in the autoQA stays.

2nd case

Import the attached txt file and assign an empty TM.

Translate segment 1 and save it to the TM.

Open segment 2 and take over the 83% fuzzy match and save it without editing it.

You will not get an "not an "not edited fuzzy match" error in the AutoQA.

Proposal how to fix this

Currently probably (not sure) the autoQA quality is only checked with a segment stemming from the pre-translation and simply it is checked, if a segment is pre-translated and has a match-rate below 100%.

This is correct, as long as the target stems from the import and is not edited.

For the 2 cases above we need an additional logic.

The proposal of Thomas and Marc is to use the already very flexible MatchRateType field of the segment to check if a match was changed after pre-translation / UI match take over or not.

Currently that field contains values like (; separated list):

pretranslated;termcollection;TermCollection - Term Collection for Translate5 Demo Text-en-de - en / de
pretranslated;termcollection;TermCollection - Term Collection for Translate5 Demo Text-en-de - en / de;auto-propagated 
edited;termcollection;TermCollection - Term Collection for Translate5 Demo Text-en-de - en / de

Example 1 is pretranslated from a termcollection named "TermCollection - Term Collection for Translate5 Demo Text-en-de - en / de".

Example 2 is the same, but with the addition that it was taken over by repetiton editor the pretranslation of Example 1.

Example 3 was a segment where no pretranslation was made, but the Match was taken over in the UI from the match panel.

In general the syntax of the field is very flexible, only the first part is really fixed, the so called prefix - one of the following values:

import (when MatchType info is coming from imported data, like some XLF dialects support it.
edited: when taking over a match in the UI
pretranslated: when using pre-translation

Second value is a type, normally mt, or tm but also several others too. As third parameter we store the LanguageResource name, but then additional types can be added, as the above Example 2 with auto-propagated.
The idea is now to extend the existing AutoQA check for matchrate < 100 and check for an additional flag "interactive". If this is existing, then the Match was modified, if not then not.

For unchanged pretranslated segments we already get:

pretranslated;termcollection;TermCollection - Term Collection for Translate5 Demo Text-en-de - en / de

When user modifies the segment we could add ";interactive" once to the end. Same for taking over in the UI;
When not editing a match in the UI it is currently looking like:
edited;termcollection;TermCollection - Term Collection for Translate5 Demo Text-en-de - en / de
So
pretranslated;termcollection;TermCollection - Term Collection for Translate5 Demo Text-en-de - en / de;interactive
edited;termcollection;TermCollection - Term Collection for Translate5 Demo Text-en-de - en / de;interactive
would comply with the rules, and could be identifyied by AutoQA then.

Only tricky will be how to find out if the user did change something or not.

So the back-end needs to check if it was a pre-translated segment / Match take over in UI with matchrate < 100 and interactive is set and then set the autoqa quality, when segment is saved