Tool · quality checks
Run QA checks on an XLIFF file
Fifteen checks run over the file you drop below: empty target, untranslated, tag mismatch, number mismatch, placeholder mismatch, leading and trailing whitespace, double space, missing no-break space, punctuation mismatch, capitalization, length, repeated word, inconsistency, glossary and forbidden term. They run in a worker on your machine, so a 300,000-segment file is a matter of waiting, not of uploading.
Locked segments are skipped, because an issue you are not allowed to fix is not an issue you need to read.
The file opens in the editor and the checks run by themselves. QA in the top bar opens the issues panel; the ▾ beside Export writes the QA report as .xlsx or .csv.
When you need this
Before delivery, on a file you did not translate. A vendor sends one back and you have twenty minutes to decide whether to accept it; a translator worked in a tool whose QA profile you cannot see; a file went through machine translation and post-editing. What you are hunting is not style but structure: a dropped placeholder that crashes the app, a tag order that reverses a link, a number that lost a digit.
Those are the errors a proofreader misses and a mechanical check never does.
Steps
- Open the file. Drop the XLIFF, SDLXLIFF, MQXLIFF, PO, SRT, WebVTT, XLSX or CSV file on the zone above. Parsing and every check run in a worker in this browser tab.
- Load a glossary, if you have one. Open the Glossary panel and load a TBX, CSV or XLSX termbase. The glossary and forbidden-term checks have nothing to compare against until you do.
- Run the checks. Fifteen checks run over every unlocked segment as soon as the file opens. Choose QA in the top bar to see the results, grouped by check. On a very large file, start them with Run QA checks in that panel.
- Set the severities. Each check can be an error, a warning, an info or off, and the setting is remembered in this browser for the next file you open.
- Work the list. Click an issue to jump to its segment and fix it there. Ignore this issue clears a one-off false positive; ignore all of this type in this file clears a check that does not apply.
- Re-run and export the report. Run the checks again so the document-wide results refresh, then choose the ▾ beside Export, then QA report (.xlsx) or QA report (.csv) for the record.
What to check afterwards
Three groups have to be empty before the file leaves your hands: empty target, tag
mismatch and placeholder mismatch. Those break the file rather than the language, and
a downstream tool will either refuse it or produce broken output. The placeholder
recognizer covers {name}, {0}, %s, %1$s, {{x}}, #x# and <0>, so a missing one is a real bug
in a real build.
When the file goes back into a translation management system, the upload is where a tag error is refused. XLIFF from a translation management system lists what each one checks on the way back in.
The rest are read, not cleared. Number mismatch compares canonical values, so
1,000.50 and 1.000,50 match and only an absent number is reported. Untranslated needs at least one letter
in the source and masks placeholders first, so a version string or a bare token is not
flagged for staying put.
The gotcha
Editing a segment re-checks that segment, not the document. The inconsistency check asks a question about the whole file — the same source translated two ways, or one target used for two sources — and re-running it on every edit of a large file is not affordable, so it refreshes only on a full run. Fix twenty segments and the inconsistency group is still showing you the file as it was twenty edits ago. Re-run before you deliver and before you export the report.