xliff file invalid segment id duplicate error

Fix XLIFF file invalid from duplicate segment ids

TL;DR

Two segments share the same id, so make every id unique. XLIFF processors key segments by id, and a duplicate makes the file invalid. Renumber or namespace the colliding ids, then validate the file before sending it anywhere.

The error

XLIFF validation error: duplicate segment id "seg-1042"
the TMS rejects the import

Fix it

Step 1: Find the duplicates

grep -o 'id="[^"]*"' file.xliff | sort | uniq -d | head -10

Expected: You see each duplicated id.

Step 2: See where they collide

grep -n 'id="seg-1042"' file.xliff | head -5

Expected: You see the two segments sharing the id.

Step 3: Make the ids unique

node -e "console.log('renumber the second occurrence, or prefix ids with the file or unit name they came from')"

Expected: Every id in the file is now unique.

Step 4: Validate the XLIFF

xmllint --noout file.xliff && node -e "console.log('well-formed, now re-import to the TMS')"

Expected: xmllint passes and the TMS accepts the import.

When to use this

• An XLIFF file is rejected for duplicate segment ids
• A merge produced colliding ids

When NOT to use this

• The ids are unique but the file is still invalid, check the schema
• The TMS rejects for another reason, read its error

Tool and version compatibility

• XLIFF 1.2 and 2.0, xmllint for validation
• Any TMS that validates on import

Variant phrasings

duplicates after merging two XLIFF files

Prefix each file's ids with a file tag before merging. Merging raw is what collides.

duplicate unit ids rather than segment ids

Same fix at the unit level. Units need unique ids too.

Why it happens

XLIFF uses id attributes as the primary key for segments and units. Merges, copy-paste, and generators that restart numbering all create collisions, and any validating parser rejects the file.

Edge cases

• IDs must also be valid XML ids in some tools, avoid spaces and leading digits
• Keep a mapping of old to new ids if translations reference them
• Validate after every programmatic edit, not just at the end

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_gJvAzA38O1YrHlbS0OPOrg