XLIFF Editor: Translate, Review and Round-Trip XLIFF Files

XLIFF is a bilingual exchange format: it separates the translatable text into segments and carries formatting and placeholders as inline elements, so translation happens without editing the file's structure.

XLIFF localization is the loop of exporting that file from the system that owns the content, translating and reviewing the segments, and re-importing the result by unit ID.

L&D teams get XLIFF out of their authoring tool — Rise 360, Storyline, Easygenerator — and that is exactly what this workflow takes.

• The course exports as XLIFF.
• Segments translate with your glossary and translation memory applied.
• Locked units stay locked.
• The XLIFF 1.2 export goes back into the authoring tool by unit ID.

The alternative is retyping course text into a translator and rebuilding the course by hand. Smartcat's Learning Content Agent and Software Localization Agent handle the same content inside one project.

The file is parsed into its translation units and shown source-beside-target.

• Inline codes are protected and reinserted by the Tag Aligner.
• translate="no" units are locked.
• Translation memory pre-fills segments the account has seen before, and glossaries enforce terminology.

Export is XLIFF 1.2 with the same unit IDs and structure, ready for re-import into the originating system.

One direction only. Import accepts 1.2 and 2.0; export produces XLIFF 1.2 — so a 2.0 file effectively comes back as 1.2, and there is no 1.2 to 2.0 conversion.

If your receiving system requires 2.0, convert after export with an external tool, or keep that file out of this workflow.

XLIFF 2.0 introduces a more modular architecture with a streamlined core and specialized extensions for advanced functionality.

Compared with 1.2 it offers better handling of inline elements, richer metadata support, and stronger validation.

For one-off edits outside a translation workflow, Smartcat's own documentation recommends the desktop editors Poedit (2.2 or later) and Virtaal.

The workflow on this page — translation memory, glossary, review stages, locked-segment handling, round-trip at volume — is what teams use when XLIFF is a recurring pipeline rather than a single file.

No — translate="no" units cannot be overwritten.

• Targets that arrive already filled in — choose the import option "Lock segments for imported translations and confirm them to the last stage". Those segments are then locked on import and confirmed to the final workflow stage.
• Files edited outside Smartcat — on re-import you decide explicitly whether to update all segments or skip segments changed in Smartcat.

Vendor-supplied partial files are the case this is built for.

Smartcat is SOC 2 Type II compliant. Your XLIFF files are encrypted in transit and at rest, workspaces are isolated, and access is role-based.

Re-import the exported XLIFF into the system that generated it — the round trip is ID-matched.

If you need the final document itself, such as a DOCX or a course package, that merge happens in the originating tool rather than in the editor.

Smartcat's general ceiling for project files is 6 GB, and the docs advise splitting anything over 1 GB for speed; no XLIFF-specific segment-count limit is documented.

On file count there is no cap — batch uploads of hundreds of files into one project are supported, so a full course export goes in as one job.

Neither limit varies by plan: tiers differ on integrations and Marketplace billing, not on uploads. The constraint is per-file size, not file count.

Inline elements represent formatting, placeholders and other non-translatable content inside a segment. They are protected during translation, and the Tag Aligner reinserts them in the target automatically.

Two limits worth knowing: tagless editing is unavailable for Chinese, Japanese and Korean, and tags are forced visible on any segment where a quality check flags an alignment problem.

Not covered here? Book a demo — a 1:1 with a localization engineer, no commitment.

Usually — and there are two things worth checking before production work depends on it.

• The version — export is XLIFF 1.2, the flavor most tools ingest without complaint, so a system that emitted 2.0 may only want 2.0 back.
• Tolerance for extras — the exported file is spec-compliant with a few Smartcat-specific tag attributes added, and a strict importer can object to those.

Unit IDs and structure are preserved either way, which is what ID-matched re-import actually depends on.

For any system not on the documented list, run one small file through the full loop first — sound practice with any XLIFF tool, including ours.