Reviewing a translation means reading it against the source and deciding, segment by segment, whether it is right. In a bilingual file that is easier than in a finished document, because each sentence sits next to its source, and harder in one way: the file carries tags, statuses and IDs that a reviewer can break without noticing. This guide covers both the reading and the file.
Two kinds of reading
- Against the source. A bilingual check: is everything translated, and is it translated correctly? It needs someone who reads both languages, and it is the check a bilingual file is built for.
- The target on its own. A monolingual read for fluency, style and fitness for the reader, often by a subject expert or the client. It can be done in a spreadsheet or in the finished document, without the source.
A job can need either or both. Decide which one each reviewer is doing before they start, because they produce different kinds of change.
What to look for
A shared list of error types keeps a review from turning into a matter of taste. An openly published one is MQM, the Multidimensional Quality Metrics framework. Its MQM-Core typology is “the pre-defined subset of the full MQM Error Typology comprising the error types most widely used in the language sector”, with seven top-level dimensions:
| Dimension | What it covers |
|---|---|
| Terminology | A term that is not the required one, or not used consistently |
| Accuracy | Mistranslation, omission, addition: the meaning differs from the source |
| Linguistic conventions | Grammar, spelling, punctuation and other mechanics |
| Style | Text that is correct but breaks the style guide or reads badly |
| Locale conventions | Number, date, currency and other formats wrong for the locale |
| Audience appropriateness | A reference the intended reader will not understand |
| Design and markup | Formatting, layout and markup |
MQM’s own definition of accuracy errors is a useful test when you are unsure whether a change is a matter of style: errors “occurring when the target content does not accurately correspond to the propositional content of the source text because of distortion, omission, or addition to the message.”
Recording the category with each change does two things. It tells the translator what kind of mistake to stop making, and it lets you count errors by kind across a job instead of arguing about individual segments.
Let the checks do the mechanical part
Before reading a word, let the software find what software can. In xliff.ai, fifteen QA checks run when the file opens (on a file of more than 20,000 segments, start them from the QA panel): empty and untranslated targets; tags, placeholders and numbers; leading and trailing spaces, double spaces, no-break spaces and punctuation; capitalisation, length and repeated words; translations that are inconsistent across the file; and your glossary’s required and forbidden terms. Load the client’s glossary first, so the terminology checks have something to compare against.
Clear the findings that break the file first: empty targets, tag mismatches and placeholder mismatches. Read the rest as pointers, not verdicts. An inconsistency may be a deliberate choice, and a target identical to its source may be a product name. The QA report can be saved as Excel or CSV from the ▾ beside Export, for the record. Tag findings have their own guide: fixing tag errors.
Reviewing in the editor
- Filter to what needs reading. The filter bar shows segments by status (empty, draft, translated, reviewed, final, locked), by QA issue, by segments that have a note, by text in the source or the target, and with or without repetitions.
- Edit in place. Correct the target and press Ctrl+Enter to confirm it. The editor has no separate “reviewed” action: confirming writes the translated status, and a segment becomes Reviewed when a decision in a review workbook accepts it (see below).
- Read the file’s notes. XLIFF notes, Trados and memoQ comments and PO comments are shown beside each segment. They cannot be added to or edited, and xliff.ai writes no comments into the file, so feedback that has to travel goes in a review workbook or a separate report.
- Ask an AI reviewer, if you want one. With your own key, the AI panel can review segments with an MQM evaluation prompt. Each finding has an MQM category, a severity from Neutral to Critical, a comment and, where it has one, a suggested fix. Applying a suggestion sets the segment back to Draft for a person to confirm, and the findings travel to the review workbook’s AI columns. A review sends the segments and their translations to the provider you chose, with your key; the privacy page lists exactly what is sent.
Seeing exactly what changed
If you keep the translator’s file and the reviewed file, the difference between them is the review’s real output. Compare two XLIFF files shows it:
- Tracked changes in each segment, word by word.
- Similarity for each segment, from the character edit distance between the two targets, with an inline tag counting as one character; only an identical target is 100%. Segments fall into bands: 95–99%, 85–94%, 75–84%, 50–74%, under 50%, and translated from empty.
- Edit rate for the whole file: all the characters edited over all the characters measured.
- Recurring changes: the same edit, from one phrase to another, made in several places. A repeated correction is often a terminology or style point to send to the translator once, instead of fifty times.
It compares two files, or a whole batch paired by name, in any format the editor opens, and saves the result as a self-contained HTML report or an Excel workbook. Nothing is uploaded.
Sending it to someone with only Excel
When the reviewer is a client or a subject expert without a translation tool, send a review workbook instead of the XLIFF file. Choose Review workbook (.xlsx) from the ▾ beside Export. Each row has the segment’s ID, source, target and status, its first QA issue, the AI finding if there is one, and three columns for the reviewer: Suggested fix, Reviewer decision (Accept, Reject or Modify, from a dropdown) and Reviewer comment.
Tell them two things. Corrections go in Suggested fix, never over the Target column, because the Target column is not read back. And every row they change needs a decision.
When it comes back, choose Import review workbook from the same menu:
- A workbook made from a different document is refused as a whole.
- Rows are matched by ID, so sorting, filtering and deleting rows in Excel do no harm.
- Accept marks the segment Reviewed, with the fix if there is one. Modify with a fix writes the fix as Draft, for another look. Reject changes nothing.
- A fix that drops or adds a tag is refused and counted, and a locked segment is never changed.
- The Reviewer comment column is not read back. Keep the workbook if the comments matter.
The result says how many rows were accepted, modified, rejected and unmatched. XLIFF to Excel and back explains what Excel does to translation text on the way, and why changes belong in a column of their own.
A review that holds up
- Agree what kind of review it is, against the source or of the target alone, and which error categories count.
- Load the glossary, and clear the QA findings that break the file before reading.
- Read every segment against its source, and record a category with each change.
- Keep the translator’s version, compare it with the reviewed one, and send the report back as feedback.
- Apply a client’s review through the review workbook, not by retyping it.
- Export in the original format, and open it in the tool that will consume it when you can: xliff.ai’s exports are tested byte for byte, not yet inside Trados Studio or memoQ.