What this XLIFF validator checks
The bounded parser recognizes XLIFF 1.2 and the 2.0, 2.1, and 2.2 core document families. It checks root version and namespace agreement, required file and translation-container structure, scoped identifiers, basic locale-tag shape, source and target presence, completion states, phase references, inline identities, original-data references, subflow unit references, external skeleton declarations, protected text placeholders, preserved whitespace, and conflicting translations for repeated source text.
Inline codes and placeholders
Formatting markers and application placeholders are part of the round trip, not decorative text. The audit compares XLIFF inline identities between each source and target and separately compares common brace, template, shell-style, and printf-style tokens. A mismatch points to the exact segment but is not automatically repaired because the correct code order and linguistic placement depend on the extractor and target application.
Comparing translation exports
The optional comparison keys each segment by its file, unit, and segment identity. Added and removed segments remain distinct from source-text, target-text, or state/metadata changes. This avoids treating a workflow-state update as a translation rewrite while still making release drift reviewable.
Conformance and linguistic boundary
This is a structural and release-QA preflight, not complete XLIFF conformance or translation approval. It does not apply every official XSD, Schematron rule, module or extension constraint; fully validate BCP 47; evaluate grammar, meaning, terminology, typography, or plural logic; prove skeleton or original-file availability; simulate a CAT-tool round trip; rewrite translations; or certify a release. Validate important deliveries with the applicable official artifacts and the exact producer and consumer applications.
Frequently asked questions
Does the tool upload translations?
No. Parsing, comparison, filtering, and report generation happen locally. Declared external links are never opened by the auditor.
Why can a missing target be a warning rather than an error?
XLIFF can legitimately carry source-only content before translation. A missing target is therefore review evidence; an empty target marked final or reviewed is a stronger structural workflow conflict.
Does matching inline-code count prove the target is safe?
No. This audit compares identities and references as well as counts, but only the extractor, CAT workflow, target application, and human review can prove correct placement and round-trip behavior.
Authoritative references
OASIS publishes the XLIFF 1.2 specification, the XLIFF 2.1 specification, and the newer XLIFF 2.2 Core specification. Use their validation artifacts when full version-specific schema and constraint validation is required.
Validate JSONL / NDJSON · Preflight EPUB packages · Browse localization tools