Skip to content

XLIFF Translation Preflight

Preflight supported XLIFF structure, translation targets, duplicate IDs and inline placeholders. Download a local diagnostic report.

XLIFF Translation Preflight

Locate missing translation targets, duplicate unit IDs and differing inline placeholder markers in XLIFF files.

Maximum file size: 25 MB per file. You can also drag files here.

Supported scope and limitations

Supports basic XLIFF 1.2 and 2.0/2.1/2.2 structures. This is not XSD validation or a complete check of inline-code pairing, modules or translation quality. Empty targets are warnings because untranslated units may be intentional.

Examples contain invented demonstration data. Replace it before using any export.

Privacy: files are processed in your browser and are never uploaded.

The XLIFF validator helps translators and developers spot a supported set of structural problems before reimporting a translation file. Open an XLF, XLIFF or XML document to inspect unit identifiers, source and target text, and differences between supported inline placeholder types and IDs. Empty targets are warnings because unfinished translations may be intentional. The XLIFF validator checks basic declared XLIFF 1.2 and 2.x structures locally; it does not judge translation quality or claim complete schema and inline-code compliance.

How to use the XLIFF validator

  1. Choose a .xlf, .xliff or .xml file, or paste the complete XML document.
  2. Select Process files. Try an example loads a small English-to-Spanish translation unit.
  3. Read the unit preview and the reported missing-source, empty-target, duplicate-ID or placeholder findings.
  4. Download xliff-report.json and correct the authoring translation file before checking again.

The report does not replace your XLIFF with a modified file. Keep the translation-tool export and apply corrections through a workflow that preserves its required metadata and inline-code structure.

Supported versions and unit structure

The checker accepts declared version 1.2 and the implemented basic 2.0, 2.1 and 2.2 structures. In 1.2 it inspects trans-unit elements; in the supported 2.x structure it inspects units and their segments. A non-XLIFF root or unsupported declared version is rejected rather than interpreted as a generic translation table.

Unit IDs must exist and remain unique within their file scope, including units located in different groups of that file. Source elements are expected in inspected segments. A missing or whitespace-only target creates a warning, not an automatic fabricated translation. The preview exposes source/target text for review; it does not establish whether the selected target language is linguistically correct.

Worked example: a greeting and a missing placeholder

The built-in sample contains a unit whose source is Hello and target is Hola. It demonstrates the supported text preview, not a claim that the XLIFF validator translated the greeting.

<trans-unit id="terms">
  <source>Read <x id="1"/> terms</source>
  <target>Lea las condiciones</target>
</trans-unit>

Inside a supported 1.2 document, this second illustration has an inline x marker in the source but not the target. The checker reports an inline-placeholder difference. Restore the correct code through the translation editor; inserting visible text that resembles a marker is not the same as preserving the required XML element.

XLIFF validator example result preview
Illustrative result from this XLIFF validator using a fictional test file.

What placeholder checking does, and does not, prove

The implemented comparison collects inline element types and supported identifier values, then compares those collections between source and target. It can reveal a missing or changed marker even when the visible words look complete. Such problems can cause a reimport to lose formatting or dynamic content.

This is not a complete model of paired-code nesting, every module, every inline-code relationship or every application-specific placeholder syntax. A clean result does not prove balanced pairs, correct ordering or correct handling of plain-text formatting variables. Inspect the target in the original translation tool and run its own QA checks when those richer rules matter.

Duplicate IDs and intentionally unfinished targets

A repeated unit ID inside one file can make a receiving system unsure which string is being updated. Fix identifiers in the source project rather than arbitrarily renumbering translated units: the application may rely on those IDs to map translations back to messages. The same ID in a different file scope is handled separately by this basic check.

An empty target may be a genuine omission or an intentional untranslated unit. Decide using project requirements and workflow status. The checker reports it as a warning so that it does not silently classify all unfinished work as XML corruption. It does not fill empty targets by copying the source or invoking a translation service.

Pair local checks with the receiving workflow

The OASIS XLIFF specification documents a broader interchange model than this preflight. Complete XSD validation, modules and application-specific import requirements may need separate tooling. Test a representative import in the actual receiving application before a large multilingual update.

If the translated file belongs to a course package, the SCORM package preflight checks a different layer: manifest and resource links. For subtitle dialogue exported from a separate workflow, the SRT to TXT converter creates a plain transcript rather than XLIFF. Related tasks do not share the same structural guarantees.

Troubleshooting XML errors and protecting source text

Malformed XML, unescaped ampersands and incomplete pasted documents can stop parsing before unit checks run. Obtain a fresh export and correct the original editor source rather than removing unfamiliar tags until the document becomes readable. If the file has no supported units, confirm its actual format and declared version.

The translation text stays in the browser during inspection. The JSON report still contains source and target strings, which may be confidential product copy. Review it before sharing, preserve the original translation file, and clear the page on a shared device. Use the XLIFF validator as a focused consistency check, followed by linguistic review and the receiving tool’s own import validation.

Common XLIFF validator errors and how to fix them

When the XLIFF validator cannot use a file, it stops with one clear message instead of producing a half-finished download. These are the problems people run into most often, with the fix for each:

  • Supported XLIFF versions are 1.2 and 2.0–2.2. The version attribute is missing or names another version.
  • Missing or duplicate unit ID. Two units share an ID, so a translation tool may overwrite one with the other.
  • Inline placeholder IDs/types differ from source. A target dropped or changed a placeholder such as a variable or tag pair.
  • Missing or empty translation target. Reported as a warning, because unfinished targets can be intentional.

Privacy: the XLIFF validator runs in your browser

XLIFF validator processing happens with JavaScript in a background worker on this page. Your file is not uploaded to a FileFix server, and the results you download are created in your browser’s memory. Configuration and network captures can expose tokens, hosts and internal paths, so local checking avoids another copy on someone else’s server. When you finish on a shared computer, clear the selection or close the tab.

For the underlying format rules, see the OASIS XLIFF 1.2. The XLIFF validator follows the subset described on this page rather than every optional feature in those documents.

Sources

The XLIFF validator follows these specifications and format guides:

Questions about this tool

Does the XLIFF validator assess translation quality?

No. It inspects supported structural and placeholder consistency issues. Meaning, grammar, tone and terminology need linguistic review.

Why are empty targets warnings?

An unfinished or intentionally untranslated unit can be valid for a workflow. The checker flags it without inventing a translation.

Are duplicate IDs checked across the entire document?

IDs are checked within each file scope, including different groups in that file. Separate file scopes are handled independently.

Does a matching placeholder report prove every inline-code rule is valid?

No. The comparison covers supported element types and IDs, not complete pairing, nesting, module or application-specific placeholder semantics.

Will the checker rewrite my XLIFF file?

No. It shows findings and downloads a JSON report. Corrections must be made in the source translation workflow.

Review the supported formats and limitations before using an output file. File processing happens in your browser.