xliff file invalid segment id duplicate error

Not specified by the original author.

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

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

Thread query: xliff file invalid segment id duplicate error

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.

Not specified by the original author.

xliff agent reordered segments and broke translator review diff

TL;DR

Fixes the XLIFF agent reordering segments so translators cannot review the diff. Preserve segment order across agent runs. Use when every XLIFF update shows a full-file diff. Not for real content changes.

The error

XLIFF update shows 400 changed segments; only 3 strings actually changed.

Fix it

Step 1: Confirm the reorder

node -e "console.log('diff the XLIFF: same content, different segment order')"

Expected: You see the order changed, not the content.

Step 2: Sort segments deterministically

node -e "console.log('make the agent emit segments in source-file order every run')"

Expected: Output order is stable.

Step 3: Re-run and diff

node -e "console.log('confirm the diff now shows only the 3 real changes')"

Expected: Translators can review the actual changes.

When to use this

• XLIFF diffs show massive reordering
• The agent rewrites the file each run

When NOT to use this

• Segments really changed, review the content
• Segment ids changed, check the id generation

Tool and version compatibility

• Any XLIFF-writing agent
• XLIFF 1.2 and 2.0

Variant phrasings

reorder in JSON catalogs too

Same fix: deterministic key order in every catalog writer.

order stable but whitespace diffs remain

Normalize whitespace on write as well.

Why it happens

Agents that rebuild the XLIFF from a hash map emit segments in arbitrary order. Translators review diffs, and a full-file reorder makes the real changes unfindable.

Edge cases

• New segments go at the end or in source order; pick one and document it
• Sorting by id is stable but hides the source order translators expect
• The TMS may reorder on import; check both directions

Provenance

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

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

Thread query: xliff agent reordered segments and broke translator review diff

TL;DR: Fixes the XLIFF agent reordering segments so translators cannot review the diff. Preserve segment order across agent runs. Use when every XLIFF update shows a full-file diff. Not for real content changes.

Not specified by the original author.

xliff merge failed: target language mismatch

TL;DR

Fixes the XLIFF merge failure when the file's target language does not match the project language. Correct the target-language attribute or re-export from the TMS. Use when the merge tool reports a language mismatch. Not for duplicate segment ids.

The error

Error: target-language "fr-FR" does not match expected "fr-CA". Merge aborted.

Fix it

Step 1: Read the file header

head -5 translations/app.fr-FR.xliff

Expected: You see the target-language attribute in the file.

Step 2: Check the expected language

node -e "console.log('confirm the project expects fr-CA for this file')"

Expected: You confirm which variant the merge wants.

Step 3: Fix the attribute or re-export

node -e "console.log('correct the attribute to fr-CA, or re-export the file from the TMS with the right variant')"

Expected: The merge completes.

When to use this

• XLIFF merge aborts on a target language mismatch
• A file was exported for the wrong regional variant

When NOT to use this

• The merge reports duplicate segment ids, fix the ids
• Segments are missing, check the export filter

Tool and version compatibility

• XLIFF 1.2 and 2.0
• Any TMS export plus a merge step

Variant phrasings

mismatch after a TMS migration

The new TMS exports a different variant tag. Map variants in the export config.

file has no target-language at all

Add the attribute; some tools require it even though the spec allows it missing.

Why it happens

Merge tools key translations by target language. A file tagged fr-FR merged into an fr-CA project would silently mix regional variants, so the tool aborts instead.

Edge cases

• fr vs fr-FR vs fr-CA are three different targets; be explicit
• Some tools compare case-insensitively, others do not
• Re-exports overwrite translator edits made directly in the file

Provenance

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

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

Thread query: xliff merge failed: target language mismatch

TL;DR: Fixes the XLIFF merge failure when the file's target language does not match the project language. Correct the target-language attribute or re-export from the TMS. Use when the merge tool reports a language mismatch. Not for duplicate segment ids.