How People Translate Quickly | XLIFF Structural Validation: Catch Broken Units, IDs and Inline Codes Before Bilingual Files Enter Production

People searching XLIFF validation, XLIFF validator, XLIFF 2.0 validation, bilingual file validation, XLIFF schema validation, trans-unit validation, XLIFF inline code errors, or how to check an XLIFF file before importing it into a CAT tool are trying to solve a structural problem that is different from translation quality. An XLIFF file can contain excellent source and target language and still fail because an ID is duplicated, XML is malformed, a required unit is missing, an inline code is broken, a namespace is wrong, or a receiving system interprets the bilingual structure differently.

Current XLIFF search language revolves around unit, segment, source, target, inline codes, IDs, schema validation, validation rules, states, and canResegment. The OASIS XLIFF specification itself defines structural processing requirements and validation mechanisms, while CAT/TMS import settings can preserve or reinterpret segmentation, notes, confirmation states, and metadata. The practical reader job is therefore clear: check that the bilingual interchange file is structurally valid and semantically sane before it becomes the handoff layer between tools.

This article has one dominant job: validate an XLIFF or related bilingual interchange file before import, handoff, reimport, or delivery so structural defects do not become translation loss, tag damage, missing segments, or failed round trips. It does not replace the existing round-trip-file-test workflow, which checks whether a final native file can be exported correctly. It also does not replace inline-tag QA, which checks the translator’s placement of tags inside a target segment. XLIFF structural validation sits one layer earlier: is the bilingual container itself internally coherent enough to trust?

Quick answer

A reliable XLIFF structural-validation workflow is:

1. identify the exact XLIFF version and producer;
2. preserve an untouched original before editing;
3. confirm the file is well-formed XML;
4. validate against the correct XLIFF schema or tool-specific rules where available;
5. check unique file, unit, trans-unit, and segment IDs;
6. inspect source-target pairing and required elements;
7. verify inline code pairs, references, and protected placeholders;
8. inspect language and locale metadata;
9. check segmentation and canResegment behavior;
10. verify state, confirmation, lock, note, and context metadata if the workflow depends on them;
11. import a copy into the receiving CAT/TMS and inspect counts and warnings;
12. export or round-trip a small sample before trusting the entire handoff.

The central rule is:

validate the bilingual container before asking translators to work inside it.

What XLIFF is doing in the workflow

XLIFF stands for XML Localization Interchange File Format.

Its purpose is to carry localizable content and related metadata between systems.

Conceptually, an XLIFF file can contain:

• files;
• units;
• segments;
• source text;
• target text;
• inline codes;
• notes;
• states;
• metadata.

A content management system can extract source text into XLIFF.

A TMS can translate it.

A build system can reinsert target text into the original format.

XLIFF is therefore a bridge.

A broken bridge can damage otherwise correct translation.

Structural validity versus linguistic validity

Consider:

<segment id="s1">
  <source>Save</source>
  <target>Enregistrer</target>
</segment>

The translation may be linguistically correct.

But structural problems could still exist elsewhere:

• duplicate id="s1";
• missing namespace;
• unclosed tag;
• invalid inline-code reference;
• wrong target language;
• unexpected state;
• missing unit wrapper.

Linguistic review cannot repair XML architecture reliably.

Use structural validation.

Step 1: identify the XLIFF version

Common forms include:

• XLIFF 1.2;
• XLIFF 2.0;
• later 2.x specifications;
• vendor-specific bilingual derivatives.

Do not validate a 1.2 file against a 2.0 schema.

The structures differ.

Even when file extensions look similar, the processing model may not.

Record:

• version;
• source system;
• receiving system.

Why producer and consumer matter

A standards-valid XLIFF file can still expose interoperability differences.

One tool may:

• preserve notes;
• ignore custom metadata;
• resegment units;
• map states differently.

Another may not.

Therefore validation has two layers:

Standards layer

Is the file valid XLIFF/XML?

Workflow layer

Will the receiving system interpret the file as intended?

You need both.

Step 2: preserve the original

Before:

• manual XML edits;
• repair scripts;
• search-and-replace;
• schema normalization;

save the untouched source file.

Use a clear name:

projectexportoriginal.xlf

Then work on a copy.

A structural repair can create a new defect.

Recovery should be easy.

Step 3: check XML well-formedness

Before XLIFF-specific validation, basic XML must be valid.

Common failures:

• unclosed element;
• mismatched closing tag;
• unescaped ampersand;
• invalid character;
• duplicate attribute;
• broken quotation mark.

Example:

<source>Research & Development</source>

The bare ampersand can break XML.

Correct XML representation may require:

<source>Research &amp; Development</source>

The exact source text rendered to the translator remains the same.

The container becomes valid.

Well-formedness is the first gate

If XML cannot be parsed, higher-level XLIFF checks are meaningless.

A useful validation sequence is:

XML parse → schema → XLIFF semantics → CAT import → round trip.

Do not debug step 4 before step 1.

Step 4: validate namespaces

XML namespaces tell software what vocabulary an element belongs to.

A typo in an XLIFF namespace can make a document look visually correct in a text editor but unreadable to standards-aware tools.

Do not “simplify” namespace declarations casually.

Vendor-specific extensions may also use their own namespaces.

Preserve them unless you know the consumer does not need them.

Step 5: validate the required hierarchy

For XLIFF 2.x, the structure normally includes elements such as:

• <xliff>;
• <file>;
• <unit>;
• <segment>;
• <source>;
• optional <target>.

The exact requirements belong to the version.

A unit should contain the required translatable structure.

If a transformation script accidentally moves <target> outside the segment, the file can fail.

XLIFF 1.2 uses different names

Many 1.2 workflows use:

• <trans-unit>;
• <source>;
• <target>.

Do not write generic repair scripts that assume one version.

A search for <trans-unit> tells you little about a 2.0 file that uses <unit> and <segment>.

Version awareness prevents false diagnostics.

Step 6: check IDs for uniqueness

Identifiers matter because tools use them to preserve identity.

Possible IDs include:

• file ID;
• unit ID;
• trans-unit ID;
• segment ID;
• inline-code IDs.

A duplicate unit ID can cause:

• collision;
• overwritten translation;
• wrong target mapping;
• failed import.

Uniqueness should be checked within the scope defined by the XLIFF version.

Worked example 1: duplicate unit ID

<unit id="u15">...</unit>
<unit id="u15">...</unit>

A receiving tool may:

• reject the file;
• keep first;
• keep last;
• behave unpredictably.

The safest workflow flags the duplicate before import.

IDs are not visible text

A translator may never see them.

That makes structural QA essential.

Hidden metadata can control visible output.

Step 7: check source-target pairing

A segment can have:

• source only;
• source plus target.

Depending on workflow, an empty target may be valid before translation.

But a target without an expected source is suspicious.

Check:

• source exists;
• target belongs to correct segment;
• target language matches project;
• no accidental cross-segment copy.

Step 8: count units and segments

Before handoff:

• source XLIFF units: 4,218;
• target/import units: 4,218.

After processing:

• exported units: 4,217.

One disappeared.

That difference deserves investigation.

Counts are a cheap structural check.

Also compare:

• segments;
• translated targets;
• empty targets.

Count changes can be legitimate

Resegmentation can change segment count.

Merged/split units can alter internal structure.

Do not insist on identical counts blindly.

Instead ask:

Is the change expected and explainable?

Unexplained count drift is the problem.

Step 9: inspect inline codes

Inline codes can represent:

• formatting;
• placeholders;
• links;
• fields;
• protected markup.

XLIFF versions provide structures for paired and standalone codes.

A broken inline-code relation can make:

• target export fail;
• formatting move;
• placeholder disappear.

Validate code identity and pairing before blaming the translator.

Worked example 2: missing closing code

Source conceptually contains:

Click <b>Save</b>.

XLIFF represents the bold span with paired codes.

Target accidentally contains the opening code but not the closing reference.

The target may look mostly readable in a raw editor.

The native export can fail.

Inline-code QA is critical.

Structural code integrity versus target placement

Two questions:

Does every required code exist and pair correctly?

Structural validation.

Is the code placed around the right translated words?

Linguistic/tag-placement review.

A file can pass the first and fail the second.

Keep the layers distinct.

Step 10: check code references

Some inline structures use IDs or references linking:

• start;
• end;
• original data;
• paired elements.

A repair script that renumbers one side only can break the connection.

If you normalize IDs, update all references consistently.

Avoid manual renumbering in large files.

Step 11: validate placeholders separately

A placeholder such as {name} may appear:

• as text;
• as protected inline code;
• as vendor-specific tag.

Understand how the producer encodes it.

Do not assume every brace token is ordinary text.

A structurally valid file can still have a missing runtime variable.

Run placeholder QA too.

Step 12: inspect language metadata

Check:

• source language;
• target language;
• locale codes.

A valid XLIFF tagged de-DE when the project expects de-AT may import but route to the wrong linguistic resource.

Strict locale workflows can reject or separate variants.

Language metadata is structural project meaning.

Step 13: inspect encoding declaration

XML often declares encoding.

Most modern workflows use UTF-8.

If the declaration and actual bytes disagree, non-ASCII text can corrupt.

Do not change encoding label without changing the actual encoding.

Validate real parse behavior.

Step 14: inspect XLIFF states

Bilingual files may carry workflow states such as:

• translated;
• reviewed;
• final;
• confirmed;
• locked.

Vendor mappings vary.

Before importing a reviewer-return file, understand whether its state metadata will:

• confirm segments;
• write to TM;
• lock content.

A structural field can change workflow behavior.

Worked example 3: confirmed-on-import side effect

A bilingual XLIFF is imported with segments marked confirmed.

The TMS is configured to save confirmed segments to a writable project TM.

Now imported content enters TM automatically.

If the XLIFF state was not trustworthy, bad targets become reusable.

Validation must include status semantics, not only XML syntax.

Step 15: inspect locks

Locked units may be intentionally protected.

Possible reasons:

• approved legal text;
• code;
• nontranslatable content;
• prior translation.

If an import unexpectedly locks thousands of segments, translators cannot edit them.

Check lock rules before project starts.

Step 16: inspect notes

Notes can carry:

• developer context;
• reviewer guidance;
• translator instructions.

XLIFF versions place notes differently.

A pipeline can lose notes while still preserving source and target.

If context matters, compare note counts and sample content.

Step 17: inspect context metadata

Context may control:

• TM 101% matching;
• UI interpretation;
• repeated-string disambiguation.

A conversion from one XLIFF flavor to another can strip this metadata.

The bilingual file still “works.”

Translation quality may fall because context disappeared.

Structural validation should include important metadata preservation.

Step 18: inspect translate behavior

Some units can be marked nontranslatable.

If that attribute flips:

• protected text becomes editable;
• intended target content disappears from translation queue.

Check nontranslatable counts.

Do not assume the translator intentionally skipped the strings.

Step 19: inspect segmentation metadata

An XLIFF file may already contain segment boundaries.

A receiving tool may:

• preserve them;
• resegment;
• refuse resegmentation.

This affects TM and IDs.

Know the canResegment or equivalent behavior.

canResegment is not cosmetic

If a unit says it cannot be resegmented, local segmentation rules may not change it.

A project manager expecting SRX to fix bad imported boundaries can be surprised.

The bilingual container may own the boundary.

Step 20: validate custom extensions

Real XLIFF files often contain vendor-specific metadata.

Do not delete unfamiliar elements merely because they are not core XLIFF.

They may carry:

• comments;
• match scores;
• original format data;
• workflow status.

First identify the namespace and producer.

Extension preservation matters in round trip

A CAT tool may ignore an extension but preserve it.

A cleanup script may remove it.

The file can still validate against a simplified schema but lose information needed by the original system.

“Clean” XML is not always a better handoff.

Step 21: use schema validation

Where schemas are available, validate:

• core XLIFF;
• relevant modules;
• vendor extension schema if supplied.

Schema validation catches structural mistakes faster than manual reading.

It does not prove:

• correct translation;
• correct business logic;
• correct target state.

Treat it as one gate.

Step 22: use semantic validation too

A file can be schema-valid but logically wrong.

Examples:

• target language wrong;
• duplicate business key stored in metadata;
• source-target swapped;
• every target copied from source;
• state says final while targets empty.

Add workflow-specific checks.

OASIS validation rules

XLIFF 2.x includes a validation module capable of expressing conditions such as:

• a value must be present;
• a value must not be present;
• a string must start or end with a value;
• occurrence counts;
• source-target relationships.

This shows an important principle:

XLIFF can carry validation intent, not only text.

Use it where the toolchain supports it.

Step 23: validate normalization expectations

Unicode text can look identical while using different code-point sequences.

Some XLIFF validation rules can consider normalization.

If your workflow compares strings exactly, normalization differences can matter.

Do not normalize bilingual files blindly; use a deliberate Unicode policy.

Step 24: inspect target-empty semantics

An empty <target> may mean:

• untranslated;
• intentionally blank;
• deleted translation;
• unsupported locale.

The project must know.

An empty target is not always corruption.

But hundreds of unexpected empty targets after tool conversion are a red flag.

Step 25: check source immutability

In many translation workflows, source text should not change inside the bilingual exchange file.

If external editing modifies <source>, mapping back to original content can fail.

Compare source hashes or counts if source integrity is important.

Worked example 4: accidental source edit

External reviewer opens XLIFF in a generic XML editor and “fixes” a typo in source.

The TMS imports the target, but source identity no longer matches the original job.

Possible result:

• segment rejected;
• new segment created;
• TM context changes.

Source corrections belong in the source system unless workflow explicitly allows bilingual source edits.

Step 26: check target locale completeness

One XLIFF may be monolingual target.

Another workflow may produce multilingual XLIFF.

Verify the file contains exactly the language structure expected by the receiving system.

Do not import a multilingual bilingual package into a tool assuming one target without testing.

Step 27: test unsupported extensions

If a receiving tool ignores:

• change tracking;
• metadata;
• validation module;

decide whether that information is essential.

Interoperability is about retained meaning, not just successful import.

Step 28: import into a sandbox project

Never make the first validation test inside the live production job.

Create a sandbox.

Import the XLIFF.

Check:

• warnings;
• segment count;
• languages;
• tags;
• notes;
• states;
• locks.

A successful parser response is necessary but not sufficient.

Step 29: export the sandbox file back

After import, export it again.

Compare:

• unit IDs;
• segment counts;
• inline codes;
• custom metadata;
• target text.

This is a bilingual round-trip check.

Then separately test the final native-file round trip if relevant.

Step 30: diff XML carefully

Text diff tools can show huge changes from:

• attribute ordering;
• whitespace;
• namespace prefixes.

Focus on meaningful differences.

Useful structural diff targets:

• IDs;
• source;
• target;
• states;
• codes;
• notes.

Do not panic over harmless serialization changes.

Step 31: automate basic XLIFF checks

For recurring pipelines, automate:

• XML parse;
• schema validation;
• unique IDs;
• source/target counts;
• locale values;
• empty target count;
• inline-code count.

This creates an early gate before human translation.

A useful CI pipeline

source extraction → XLIFF generation → structural validator → TMS import.

If validation fails, stop before translators receive the job.

Fix the producer.

This is cheaper than discovering corruption after 40 languages have started.

Step 32: log validation reports

A report can contain:

• file name;
• XLIFF version;
• unit count;
• segment count;
• duplicate IDs;
• malformed codes;
• warnings.

Attach it to the handoff.

Now the receiver knows the file was checked.

Step 33: distinguish errors from warnings

Error

• XML malformed;
• duplicate required ID;
• invalid code reference;
• missing required source.

Warning

• unusual empty target;
• unknown extension;
• unexpected state;
• count drift.

Not every anomaly should block the project.

Severity follows consequence.

Failure mode 1: only XML well-formedness checked

Result:

XLIFF-specific defects survive.

Repair:

schema and workflow validation.

Failure mode 2: file validates but language metadata wrong

Result:

wrong locale resources.

Repair:

locale check.

Failure mode 3: custom extensions stripped

Result:

context/status lost.

Repair:

preserve known producer metadata.

Failure mode 4: duplicate IDs ignored

Result:

mapping collision.

Repair:

uniqueness validation.

Failure mode 5: inline code exists but pairing wrong

Result:

export failure.

Repair:

code-reference check.

Failure mode 6: imported state auto-confirms targets

Result:

unreviewed content enters TM.

Repair:

state-policy validation.

Failure mode 7: receiver resegments unexpectedly

Result:

IDs and TM alignment change.

Repair:

check segmentation settings.

Failure mode 8: source text edited inside handoff

Result:

mapping breaks.

Repair:

source integrity policy.

Failure mode 9: successful import treated as proof

Result:

metadata loss goes unnoticed.

Repair:

sandbox export/diff.

Failure mode 10: one XLIFF repair script used across versions

Result:

structure corrupted.

Repair:

version-aware processing.

An XLIFF validation checklist

Before import:

• version known?
• original backed up?
• XML well-formed?
• correct namespace?
• schema valid?
• IDs unique?
• source elements present?
• target locale correct?
• inline codes balanced?
• custom extensions understood?
• states/locks expected?
• segmentation behavior understood?

After sandbox import:

• counts plausible?
• notes visible?
• tags intact?
• statuses expected?
• target text present?
• export succeeds?

A structural triage table

Finding	Likely owner
malformed XML	localization engineer/source system
duplicate unit ID	exporter/developer
bad target language	project setup
broken inline-code reference	exporter or bilingual editor
wrong segment state	workflow configuration
notes missing	converter/tool interoperability
unexpected resegmentation	import settings
target linguistic error	translator/reviewer

Routing the problem correctly saves time.

Search-intent transfer

People searching:

• “XLIFF validation”
• “XLIFF 2.0 validator”
• “bilingual file validation”
• “XLIFF schema validation”
• “trans-unit validation”
• “XLIFF inline code errors”

want one operational answer:

prove the bilingual interchange container is structurally coherent before translation or reimport.

That is the job this URL should own.

A 15-minute preflight

For a new XLIFF producer:

Minutes 1–3

Identify version and namespace.

Minutes 4–6

Parse and validate.

Minutes 7–9

Count units, segments, empty targets, and IDs.

Minutes 10–12

Inspect tags, states, notes, languages.

Minutes 13–15

Sandbox import one file.

This can prevent a multi-language handoff failure.

Transfer to other bilingual formats