QA & entities

The platform checks translations on two levels:

Language checks run on every segment — when machine translation produces it, and again every time you save an edit. They compare your target text against the source: tags, placeholders, numbers, terminology, spelling and more.
Structural document checks run on the rebuilt file, comparing the translated document against the original to make sure nothing structural — tables, images, frames, lists, fields, pages — was lost or displaced on the way to delivery.

This page covers both, plus entity handling: how named entities such as product codes and brand names are recognised, protected through machine translation, and verified in your translation.

Language checks on every segment

Around 20 automated checks run on each saved segment. Findings are recorded per row with a severity, and stay attached to the row until they are fixed or dismissed.

Severity	Meaning
Critical	Positive evidence of a serious defect (for example an empty target or a lost placeholder)
Error	Positive evidence of a defect
Warning	A possible defect the checks cannot rule out
Info	An anomaly the checks verified is fine — kept visible, never blocking

The checks err on the side of caution: an occasional false positive is accepted so that real errors are not missed. That is what Dismiss is for.

What the checks look for:

Check	Flags
Empty target	Source has text, target is empty
Source copy	Target is identical to the source (graded: untranslated prose is an error; codes and part numbers are info)
Untranslated fragments	Source-language words left inside an otherwise translated target
Extra text	Machine translation added commentary or explanation instead of just translating
Under-translation	Target suspiciously short for the source — likely truncation
Placeholders	`{name}`, `%s`-style and similar placeholders missing from the target
Tags	Inline HTML/XML tags missing or mismatched
Message syntax	Broken plural/select message structures (unbalanced braces)
Number drift	Source numbers missing from the target — aware of locale conventions, so `1,000.5` and `1 000,5` count as the same number, and numbers legitimately spelled out as words are not flagged
Whitespace	Leading/trailing or doubled spaces the source does not have
Repeated word	Accidental doubled words (`the the`) — intentional reduplication carried over from the source is not flagged
Punctuation	Missing terminal punctuation (added in the target language’s form) and unpaired brackets or quotes
Capitalization	First-letter case changes and lost ALL-CAPS tokens
Terminology	Missing mandated glossary terms and uses of forbidden terms (see glossaries)
Inconsistent translation	The same source translated differently elsewhere in the file
Spelling	Dictionary-based spellcheck in about 14 languages, including Finnish; glossary vocabulary and the project dictionary never flag
Grammar	Grammar checking for Finnish, where enabled on the project
Entity survival	A protected entity (code, name, URL, …) missing from the target

A project manager can switch individual checks off per project from the project settings (“QA checks”), so the exact set can vary by project.

Live hints while you type

The simplest checks (empty target, target identical to source, missing placeholders and tags, broken message syntax) also run instantly on your unsaved draft. They show as an outlined, provisional indicator on the row. When the segment saves, the full check pass replaces the provisional result with the authoritative one.

Where issues appear

Row indicator — rows with unresolved findings show a warning triangle next to the state dot, colored by the worst severity, with a count when there is more than one issue. The tooltip lists the findings; clicking the triangle opens the row issues panel.
Toolbar QA strip — while the target has unresolved issues, the toolbar shows severity counts. Clicking the strip jumps to the current or next row with issues and opens its panel; the ‹ › buttons step between issue rows; the report button opens the full QA report.
Row filter — the QA issues option in the State menu shows only rows with unresolved findings.

The row issues panel

The row issues panel is a floating window (drag it by its title bar, resize it by the corner) that lists one row’s findings and lets you act on them. The grid stays visible behind it, because the panel is built for a fix-them-all sweep: the footer arrows step to the previous/next row that has issues, and the grid scrolls along.

Click an issue to highlight the exact affected text in the row (hover to preview). Where the problem text cannot be located, the whole cell is washed instead; if the offending piece only exists in the source — a dropped number, a missing entity — the source side is highlighted.

Each issue line offers:

Fix — shown when the check computed a safe correction: trimming stray whitespace, collapsing a doubled word, adding the missing terminal punctuation mark, re-formatting a number into the target language’s convention, or replacing a forbidden term with the mandated one (matching the word form where supported). The fix is applied through a normal save, so the checks re-run and the issue clears itself.
Dismiss — marks the finding as reviewed. Dismissals are sticky: the same finding will not come back on later saves of this row (per term or per word for terminology and spelling findings). Fixing text is deliberately not sticky — a re-check verifies the fix instead of trusting it.
Add to dictionary — on spelling findings, teaches the word to the project dictionary so it stops being flagged anywhere in the project, for everyone. Use this for brand names and domain vocabulary; use Dismiss for one-off cases.

Issues never block saving. Fix the text however you like — every save re-checks the row, clears findings that no longer apply, and records any new ones your edit introduced.

The QA report

The report button in the QA strip opens the full QA report for the target: every row with unresolved issues, in document order, with the same Fix and Dismiss actions and a severity rollup at the top. Click a row header to close the report and jump to that row. The Include resolved toggle adds dismissed and superseded findings, dimmed, so you can audit what was already handled.

Rows may also carry a small colored number — the machine-translation quality estimate — and the report can sort by it. That comes from the MT quality lane; see Machine translation & quality, which also covers the AI repair suggestions that can appear in the row issues panel on some projects.

QA gates

Findings escalate gradually along the delivery path:

Advisory warns — confirming a row, marking it ready, or locking it for delivery over unresolved errors asks for confirmation first (this includes bulk actions and keyboard shortcuts).
Stage gate — a workflow stage can be configured to warn or to block advancement while unresolved findings at or above the configured severity remain. A blocked advance shows the reason; a project manager can force past it, and the override is recorded in the stage history.
Export gate — projects can additionally be set to refuse file downloads and exports while unresolved errors remain.

Only translation-quality findings count toward gates and warnings — internal engine diagnostics never block your work.

Entities

Segments often contain pieces that must survive translation byte-for-byte: product codes, company and person names, URLs, email addresses, phone numbers, IBANs, acronyms. The platform recognises these entities in the source when a file is ingested.

What that does for you:

Protection through MT. Recognised names, codes and similar entities are shielded from the MT engine and restored verbatim in its output — so a brand that is also a dictionary word (“Jaguar”) is never translated as the animal, and a product code is never re-cased or mangled. Dates, money and measures are deliberately not frozen: those must be localised, and the number checks audit them instead. Place names are also left translatable (“Suomessa” should become “in Finland”).
A survival check. If a protected entity is missing from the target — including after your own edits — the entity-survival check flags the row, and the row issues panel highlights the entity in the source so you can see what to restore. Word-form variations of an entity count as present.

Seeing entities in the editor

The Entities toggle in the toolbar (the label icon) highlights recognised entities in the source column, colored by type, with the type name on hover. It is off by default; turn it on when you want to see what is being protected in a segment or to double-check the recognition on your material. Files processed before entity recognition was enabled simply show no highlights.

Structural document checks

Independent of the per-segment language checks, the platform verifies the rebuilt document — the translated file it will deliver — against the original. These checks are document-level rather than row-level: they compare structure, not wording, across 33 issue types, including:

lost tables, table cells, images, frames, lists and paragraphs,
dropped line breaks, fields and broken cross-references,
list numbering flattened or switched between numbered and bulleted,
paragraph indentation drift and frames that moved or resized,
content that landed on a different page, or a changed page count,
sheet, cell and formula checks for spreadsheets; slide, notes, chart and text-fit checks for presentations.

They run automatically when a document is rebuilt, and findings carry the same severities as the language checks. As a translator you rarely interact with this lane directly — it is the safety net that makes sure the delivered file still is the document you translated. To see how your translation affects the real layout while you work, use the preview.

Editor basics — confirming rows and stage advance
TMs, termbases & glossaries — terminology enforcement
Machine translation & quality — quality estimates and MT review