Guides / 13 of 14

How to fix tag errors in a translated XLIFF file

What missing, extra, reordered and unpaired tags mean, where they come from, why a file with one can fail on import, and how to find and fix each one without touching the markup.

A tag error is a difference between the inline tags of a segment’s source and those of its target. It is one way a translated file ends up rejected on import, or turned back into a document with a broken link, a missing image or bold text that never ends. The good news is that tag errors are mechanical: each kind has a cause you can find and a fix you can check.

What the file expects

Inline tags stand for formatting and code in the original document: a bold run, a link, a line break, a variable. The inline tags guide describes every element. What matters here is the rule they follow. The XLIFF 1.2 specification puts the translation in “a <target> element that has the same inline codes available to it as does the <source> element”. Each code’s id is the link back to the document. Of <g>, the specification says: “The required id attribute is used to reference the replaced code in the skeleton file”, the template the translated document is rebuilt from. A target whose ids do not match its source’s can leave that rebuild with codes it cannot place, or places it has no code for.

XLIFF 2.0 writes the rules down as editing hints on each code. A code may be deleted, copied and moved unless the file says otherwise, but where it does: “Modifiers MUST NOT delete inline codes that have their attribute canDelete set to no”, and “Modifiers MUST NOT replicate inline codes that have their attribute canCopy set to no”. Its example of an undeletable code is a %s placeholder, because removing it “would result in an error when running the application”.

In practice, treat the source’s tags as a list the target has to reproduce: the same tags, each once, with pairs intact, in an order that makes sense in the target language.

The four errors, and the fix for each

A missing tag. A tag in the source has no copy in the target. The formatting it stood for is lost, or a link, a line break or a variable vanishes from the result. The fix is to put it back where it belongs in the target sentence; for a pair, put both halves around the words that should carry the formatting.

An extra tag. The target has a tag the source does not have, or the same tag twice. It can arrive with pasted text: a target copied from another segment, or a memory match from a sentence with different formatting. XLIFF 2.0 does allow new and copied codes where the file permits them, so an extra tag is not always wrong, but unless you know the receiving tool expects it, delete it.

Tags in a different order. The target has exactly the source’s tags, in a different sequence. Sometimes that is right, because the target language puts the bold word or the link somewhere else in the sentence. Sometimes it means a pair has been crossed or the formatting moved onto the wrong words. Check each one, and keep the new order only when every tag sits around the words it belongs to. In XLIFF 2.0, a file can also forbid moving some codes, with the canReorder hint.

An unpaired tag. One half of a pair is there and the other is not: an opening tag with no closing tag, or the reverse. The rebuilt document can carry the formatting on past where it should stop, or fail to build at all. Restore the missing half, or delete the stray one, so that the pair goes or stays together.

There is a fifth problem no check can see: the right tags around the wrong words. Every tag is present, in a sensible order, but the bold covers the wrong phrase or the link the wrong text. Only reading the target finds it, and a preview in the receiving tool shows it best.

Where they come from

  • Editing the XML by hand. Deleting one character of a tag, or one half of a pair, in a text editor. Opening and editing an XLIFF file explains what breaks and why.
  • Machine translation. An engine trained on sentences can drop, invent or move tags. Machine-translating an XLIFF file covers how to protect them.
  • Memory matches. A match whose words are right but whose source had different formatting brings the wrong tags, or none.
  • Text pasted from elsewhere. A sentence pasted from Word, a PDF or a spreadsheet arrives as plain text: the formatting tags are not in it, and markup typed as text is not a tag.
  • Placeholders that are not tags. In some formats a {0} or %s is plain text, not a tag, so a tag check cannot see it go missing. The placeholder guide lists the syntaxes and how a placeholder check finds them.

Fixing them in xliff.ai

Open the file in the editor. The QA checks run when it opens, and Tag mismatch is one of them, reported as an error. Each finding names the tags involved and says which kind it is: missing tags, extra tags, or a different order. The QA panel groups the findings and jumps to each segment, and the filter bar can show only the segments with a tag mismatch.

The check compares tags by their exact original markup, not by the label on the chip, so two tags that both display as g but carry different ids are different tags. Each half of a pair is compared on its own, which is why an unpaired tag shows up as a missing or an extra one. Order is only reported once nothing is missing or extra.

Then, by kind:

  • Missing: put the caret where the tag belongs and press Ctrl+Alt+Insert, which inserts the next tag the target is missing. For a pair, both halves go in together, around the selected words if you selected some.
  • Extra: press Backspace or Delete next to it. Next to one half of a pair, both halves are removed together; a selection that would remove only one half is refused, and the cell says so. A tag the file marks as undeletable (canDelete="no" in XLIFF 2.0) is never removed.
  • Wrong order or wrong words: delete the pair, select the words it belongs around, and insert it again with Ctrl+Alt+Insert.
  • Too far gone: Ctrl+Insert copies the source into the target, with every tag in place, as Draft; translate around the tags from there. Alt+Delete clears the target.

The editor also refuses to make most of these errors for you. An AI result that loses a tag, invents one, repeats one or closes one before opening it is not written. A memory match whose tags do not fit the segment is offered as “Insert without tags”, so you know to add them. Find and Replace never replaces text across a tag. Filling repetitions skips any repetition whose tags differ. And a reviewer’s fix from a review workbook is refused unless it carries exactly the segment’s own tags.

When the file will not open at all

A tag error inside a segment is one thing; a file that is no longer valid XML is another. It happens when a file has been edited by hand: half a tag deleted, a closing tag left behind, or a raw & or < typed into a target. The XML specification is strict about the last one: “The ampersand character (&) and the left angle bracket (<) MUST NOT appear in their literal form, except when used as markup delimiters, or within a comment, a processing instruction, or a CDATA section.”

No editor can show the tags of a file it cannot parse. xliff.ai says it could not read the file, with the parser’s reason. Find the broken spot with an XML validator or a text editor that checks XML, or go back to the last copy that opened, which is why the original is worth keeping.

Before you deliver

  1. QA shows no tag mismatches, and no placeholder mismatches either.
  2. Every reordered tag has been looked at and sits around the right words.
  3. Heavily formatted segments have been read for tags around the wrong words.
  4. The export has been opened in the tool that will consume it, when you have it: xliff.ai’s exports are tested byte for byte, not yet inside Trados Studio or memoQ.