Quality estimation

Machine translation is never delivered unexamined. Alongside the concrete checks described in QA & entities, every machine-translated segment is scored by the quality-estimation model — a reference-free estimate of translation quality that needs no human translation to compare against. The score drives three things: visibility, review flags, and repair suggestions.

Seeing the scores

In the editor, each scored segment shows a small quality chip. You can filter the segment list to low-scoring rows, and the QA report can be sorted by quality estimate so the weakest machine output is reviewed first.

Low scores are flagged for review

A segment scoring below the project’s threshold gets a LOW_QE finding — the same kind of finding the other quality checks produce, shown in the same places, with the same lifecycle:

Editing the segment clears it. Fixing the translation and saving re-checks the row; the flag does not linger on corrected work.
Dismissing it is sticky. If you review a flagged segment and decide the translation is fine, dismissing the finding keeps it from coming back.
Re-running MT re-evaluates. A fresh machine translation gets a fresh score and is judged anew.

By default a LOW_QE finding is a warning: visible everywhere, blocking nothing. A project manager can raise its severity to error, in which case low-scoring segments block quality gates and export until they are fixed or explicitly dismissed — the difference between monitoring MT quality and enforcing it.

Pre-confirming high scores

The same score can work in the other direction. With auto-approve enabled (it is off by default), segments scoring above a high threshold are confirmed automatically — useful in high-volume workflows where confirming obviously good machine output row by row is the bottleneck.

Safeguards apply:

A configurable share of qualifying segments (10% by default) is deliberately left unconfirmed as a human spot-check sample.
Only untouched machine output qualifies — never a segment someone has edited, confirmed, or locked, and never a segment with any unresolved finding.
Auto-confirmation is reversible, like any manual confirmation.

The quality policy

The threshold for flagging, the finding severity, and the auto-approve settings form the project’s quality policy, edited by the project manager in the project’s settings. Policy controls are available on plans that include quality-estimation routing.

AI repair suggestions

Flagged segments can be sent to the repair lane. In the segment’s issues panel, Suggest fixes generates candidate corrections using everything known about the row: the open findings, matches from your attached TMs, glossary constraints (including forbidden terms), and the neighboring segments for context.

Every candidate is then vetted before you see it:

Safety check. Each candidate is run through the automatic quality checks against your current translation. A candidate that would introduce a new defect is shown as rejected and cannot be applied.
Re-scoring. Candidates are scored by the quality-estimation model and ranked, each showing how much it would improve on the current translation.

Applying a suggestion is a one-click, ordinary edit: it saves through the normal editing path, the segment is re-checked, and cleared findings go away — exactly as if you had typed the fix yourself. You can also reject suggestions you disagree with.

All scoring and repair generation runs on the platform’s own infrastructure; segment content is not sent to third-party services for quality estimation.

QA & entities — the concrete checks that run on every saved translation.
MT engines and routing — what reaches machine translation in the first place.