Credit suggester when accepting his suggestions with alterations

[ta2-1]

Currently if you select a suggestion and make alterations then you, as the translator gets credit for the translation but suggester doesn't get anything (his suggestion is not accepted).
Let's add Accept with alterations submission type if a translator uses any suggestion for his translation and similarity between final translation and the initial suggestion is more than threshold (for instance 50%).

[ta2-1]

There was discussion with @iafan who should be set as the last owner of translation in this case: suggester or reviewer.

[iafan]

Let me provide reasoning here (it's definitely more convenient than side notes in the related Google doc).

I think we need to define what "credit" for the suggester is.

If by "credit" you mean the avatar image next to the translation, then this would be misleading. If translator "accepts a suggestion with alterations", it means that it is the translator who adds the final edits and reviews the string, and he's the "owner" now (he, not the original suggester, is held responsible for the final string quality, and everyone — original suggester, translator and project admins want to know what these edits were).

If by "credit" we mean proper score attribution and appearance in the "top contributors" list, then we can make the feature fully consistent and unambiguous (and also easier to implement).

This is what I propose:

1. Do not introduce any new submission type
2. Express the "accept with alteration" action with two submission types: (A) suggestion accepted, (B) translation edited. The suggester is properly credited for the action (A). The translator is properly credited for the final review/editing for the action (B).
3. From the UI standpoint, introduce the special explicit "Accept with alterations" button that would copy the translation into the editor. This will have the same effect as clicking on the suggestion text itself (this is what we already have in the UI).
4. Once the translator types in their translation, dynamically highlight the most similar suggestion in the list if it is above the certain threshold. Upon string submission, if there's such a highlighted suggestion, generate either both (A) and (B) events if there are any edits, or just (A) if there are no edits.

This is more consistent:

1. if the translator accepts the suggestion first (with no edits) and then returns back to the unit and provides edits, this will result in the same set of submission actions, the same scores, and the same unit edit history.
2. If a translator wants to cheat the system and provide the same (or similar) translation by just typing in the translation without explicitly accepting someone's suggestion, this will also result in the same set of submission actions/scores.

[iafan]

This is how this new button might look like:

It's hint can be something like "Edit suggestion before accepting"

[iafan]

Some more thoughts:

When the "best suggestion" is dynamically determined based on current translation value, we need to take TM results into consideration as well. For example, if there's a better match in TM (e.g. a 100% match, which is copied automatically into the editor), I think we shouldn't credit any suggestions.

---

We might also consider supporting "cheating" situations when a translator rejects someone's suggestion first, and then provides their own translation which is identical or very similar to the rejected one. This could be done by keeping rejected suggestions in the system and comparing against them.

[ta2-1]

I'd agree that it is important to add new button explicitly. But it can be confusing that
"click on suggestion area" == "click on the orange button" (not green nor red).

[ta2-1]

Initially I thought about two actions instead of one.
But having to say that a new submission type as "accept with alterations" looks more clear regarding motivation. Also it will allow us to avoid situations when "not very good" translation can be used as the final one. In such situations we can also consider "accept as fuzzy" submission type.

[iafan]

But it can be confusing that
"click on suggestion area" == "click on the orange button" (not green nor red).

Both will result in the same visual feedback (glow around the suggestion unit, since it will be a 100% match) to suggest these are the same. Obviously, people will likely use this explicit button to copy the suggestion and work with it, but such a visual clue will help them discover that clicking anywhere on the text has the same effect.

[iafan]

But having to say that a new submission type as "accept with alterations" looks more clear regarding motivation.

My point is that in this case the effect (state of the unit) will be different from the case when someone accepts the suggestion and then they (or someone else) alter the translation in two different steps, which is not good (not to mention that this will make score calculation and other parts of the UI more complex).

Also, if we have two independent records, the volunteer will see a "suggestion accepted" event, which shouldn't be worse than "suggestion accepted with alterations" in terms of motivation ("my work is recognized!").

[ta2-1]

Also it will allow us to avoid situations when "not very good" translation can be used as the final one.

I meant that if we do two different actions (accept and edit) it is important to perform them in one transaction.

In such situations we can also consider "accept as fuzzy" submission type.

It looks like overthinking.

[julen]

But it can be confusing that
"click on suggestion area" == "click on the orange button" (not green nor red).

Both will result in the same visual feedback (glow around the suggestion unit, since it will be a 100% match) to suggest these are the same. Obviously, people will likely use this explicit button to copy the suggestion and work with it, but such a visual clue will help them discover that clicking anywhere on the text has the same effect.

I agree with @ta2-1 that it can result confusing, especially because this very same feedback (glow around match) exists in scenarios where translators are not editing others' suggestions.

What about adding a minor text below the textarea which will display something like Editing 's suggestion (in a similar fashion we display NN time ago) when reviewers click the button and make an edit? If the edits result in a similarity value below a threshold, the message would go away, indicating that it's not an edit anymore, but a completely new translation.

[iafan]

What about adding a minor text below the textarea which will display something like Editing 's suggestion

Please note that the translator might not have to click on any suggestion, so what you suggest will not work consistently and confuse even more. Copying a suggestion into an editor is just a convenience function. Even if someone types in (or copy-pastes) their translation, we want to find the best suggestion (above the threshold) and credit suggester for it.

[dwaynebailey]

@iafan this model looks good. I think some sides are overcomplicating it for now (the auto select the best suggestion). I think the explicit button is good as some people have been confused by this and it isn't clear that clicking on the unit achieves the same thing.

The credit part concern is this:

• The primary concern is not score
• The primary concern is that if you do a minor correction e.g. fix a or minor spelling mistake. Then the last person who worked on this is credited and that is you. This remove all obvious credit from original translator.

That said the quick wins of:

• Adding an explicit button
• Two stage accept and adjust

Are fine with me as they address the numeric credit and make accept+alter much clearer and explicit.

[iafan]

I think some sides are overcomplicating it for now (the auto select the best suggestion)

This "auto select the best suggestion" thing is pretty easy to implement (we already have the similar code in place, I believe) and it in fact supersedes other attribution logic. In other words, it is enough to implement it alone to support multiple use cases ("copy the suggestion and submit it with no edits", "copy the suggestion and edit it before submission", or "type exact or similar translation and still credit the suggester").

[iafan]

The primary concern is that if you do a minor correction e.g. fix a or minor spelling mistake. Then the last person who worked on this is credited and that is you. This remove all obvious credit from original translator.

But in this case it's not the suggester who makes the final edit, and they might even disagree with that small edit. Translator may make a mistake by e.g. placing a comma in the wrong place, or picking a word that is worse than the original, or introduce a spelling mistake that wasn't there in the suggestion. I think that showing that the final translation comes from the original suggester can lead to all sorts of confusion. I'd prefer to be fully transparent on this and show this as two actions with proper score attribution, proper timeline and proper diffs that indicate the change done by a reviewer.

Keep in mind that in the case when the suggester fully translated a string and then translator just did a minor change, suggester will still — fairly — get more score points than the editor. So they will be recognized in "top contributor" reports and all sorts of leaderboards. The only thing they will not see is their avatar in the translation editor next to the unit. But as i said, this is actually good, because this will avoid confusion in case of post-edits the suggester has no control of.

[iafan]

I think I have found a solution to better indicate the authors of the unit (and also give a better indication that the unit has multiple edits, which is nice):

---

This is a pure rendering improvement that can piggyback on the timeline data (whether there are multiple authors and whether the last edit was minor or not (based on similarity threshold). This approach still implies that we correctly save "suggestion with alteration" as two timeline events as I described earlier.

[ta2-1]

This issue was addressed in #4659. I'm closing it now.