SDLXLIFF files

What the vendor namespace adds

The namespace is http://sdl.com/FileTypes/SdlXliff/1.0, conventionally bound to the prefix sdl. Strip every element and attribute in it and what remains is an ordinary, always-segmented XLIFF 1.2 file with <seg-source> and <mrk mtype="seg"> markers. What the namespace adds sits mostly outside the translatable content.

<xliff xmlns:sdl="http://sdl.com/FileTypes/SdlXliff/1.0"
       xmlns="urn:oasis:names:tc:xliff:document:1.2" version="1.2" sdl:version="1.0">
  <sdl:doc-info project-id="4d0a9e2f-…" document-id="1a2b3c4d-…"
                source-language="en-US" target-language="de-DE">
    <sdl:cmt-defs>…</sdl:cmt-defs>
  </sdl:doc-info>
  <file original="Getting-Started.docx" datatype="x-sdlfilterframework2"
        source-language="en-US" target-language="de-DE">
    <header>
      <sdl:ref-files>…</sdl:ref-files>
      <sdl:filetype-info>…</sdl:filetype-info>
      <sdl:tag-defs>
        <sdl:tag id="1">
          <sdl:bpt name="b"><![CDATA[<b>]]></sdl:bpt>
          <sdl:ept name="b"><![CDATA[</b>]]></sdl:ept>
        </sdl:tag>
      </sdl:tag-defs>
    </header>

• sdl:doc-info — project and document identifiers, and the comment definitions for the whole file.
• sdl:ref-files — the source documents the bilingual was made from, with the identifiers the preview feature needs.
• sdl:filetype-info — which file type filter produced the content, which is what lets the editor generate the target document again.
• sdl:tag-defs — the real markup behind every formatting tag, stored as CDATA. This is where a tag chip's <b> or <img src="save.png"/> actually lives.
• sdl:seg-defs — one row per segment, inside each trans-unit. The interesting one.

Confirmation levels are not in the state attribute

This is the single most important fact about the format, and the one that most third-party editors get wrong. The XLIFF 1.2 state attribute on <target> is usually absent, and when it is present it is not authoritative. The confirmation level lives in the conf attribute of an <sdl:seg> row, whose id matches the mid of the segment marker in the target.

<trans-unit id="a1f4c9e0-3b7d-4f21-8c5a-9e0d6b2f7143" translate="yes">
  <source>Back up your files automatically.</source>
  <seg-source><mrk mtype="seg" mid="1">Back up your files automatically.</mrk></seg-source>
  <target><mrk mtype="seg" mid="1">Sichern Sie Ihre Dateien automatisch.</mrk></target>
  <sdl:seg-defs>
    <sdl:seg id="1" conf="Translated" origin="tm" percent="100" struct-match="true"/>
  </sdl:seg-defs>
</trans-unit>

Six values are defined, and they map one to one onto the editor's status column.

A seventh case has no value at all: an <sdl:seg id="1"/> with no conf is a segment nobody has touched, which shows as not translated. That is normal and must stay that way — writing conf="Draft" onto every untouched segment would turn a clean file into one that looks half-worked, and would wreck the analysis the project manager runs against it.

Match rates and origin

The rest of the <sdl:seg> row records where the translation came from. percent is the match rate the segment was populated with — 74 for a fuzzy hit, 100 for an exact one. origin names the source: tm for translation memory, mt for machine translation (with origin-system naming the engine), interactive for text a human typed. struct-match="true" marks a hit whose surrounding structure also matched, which is what turns a 100% into a context match in the analysis. text-match records the finer classification of the text hit.

Those attributes are money. A file that comes back with its match rates flattened cannot be invoiced against the analysis it was quoted from, and re-analysing it does not bring them back, because the match a segment was populated with is history rather than a property of the current text. xliff.ai writes one attribute, conf, into the segments whose status you changed, by editing that open tag in place. Everything else on the row survives byte for byte.

Comments

Comments are stored in two places at once. The bodies sit in <sdl:cmt-defs> near the top of the document, each in a <sdl:cmt-def> with a GUID. The segment that carries the comment references that GUID from a marker inside its target.

<sdl:cmt-def id="8c5b3d71-2e94-4b06-9f1a-6d3c0a7e5b42">
  <Comments xmlns="http://sdl.com/FileTypes/SdlXliff/1.0">
    <Comment severity="High" user="Anja Vogt" date="2026-03-11T14:22:07" version="1.0"
      >Client insists on "Eingabetaste", not "Enter-Taste".</Comment>
  </Comments>
</sdl:cmt-def>

<!-- referenced from the target of the segment it belongs to -->
<mrk mtype="x-sdl-comment" sdl:cid="8c5b3d71-2e94-4b06-9f1a-6d3c0a7e5b42">Enter-Taste</mrk>

Note what the marker does: it wraps the exact words the comment is attached to. A comment is anchored to a text range, not to a segment, which is why editing around one is delicate and why a serializer that normalizes the target destroys the anchor even when it keeps the text. Comment bodies may be plain text or CDATA, and carry severity, user and date. xliff.ai reads them and shows them beside the segment; it never rewrites <sdl:cmt-defs>.

Locked segments

A lock is locked="true" on the <sdl:seg> row, independent of conf — a segment can be signed off and locked, or empty and locked. Project managers lock repeated content, do-not-translate blocks and anything already approved elsewhere. A separate mechanism, translate="no" on the trans-unit, marks content the file type filter itself declared untranslatable. xliff.ai honours both: locked rows are visible, searchable and read-only, and an export cannot change them because there is nothing to splice.

Why most browser editors corrupt these files

The usual approach is to parse the XML into a document tree, apply the edits and serialize the tree back out. On a plain XLIFF file the damage is cosmetic. On an SDLXLIFF file it is not:

• CDATA in sdl:tag-defs collapses into escaped text, so the tag definitions no longer round-trip.
• Namespace prefixes are renumbered. A file that said sdl: comes back saying ns0:, and elements the serializer did not recognize are dropped outright.
• <sdl:seg-defs> is rewritten, so percent, origin, struct-match and text-match are lost or reordered.
• Comment markers inside targets are normalized away, taking the anchors with them. The bodies remain in the header, referenced by nothing.
• Attribute order, self-closing form, entity style and indentation all change, so the diff is the whole file and nobody can review what actually happened.

The result opens with an error, or worse, opens cleanly with the reviewer's comments and the match rates quietly gone.

What "only the segments you touched change" means

xliff.ai never builds a document tree to write from. It keeps the original bytes, records byte offsets while tokenizing, and on export splices replacement ranges into those bytes in descending order. For an SDLXLIFF file that means an edit produces at most two changed ranges per segment: the content of that segment's <mrk mtype="seg"> inside the target, and the <sdl:seg> open tag if you changed the status. Nothing else in the file is written at all — sdl:cmt-defs, sdl:ref-files, sdl:filetype-info, sdl:tag-defs and the file header are never spliced.

You can check this yourself. Open a file, change nothing, export it, and compare the two with any binary diff tool: identical, byte-order mark and CRLF line endings included. Then change one segment and diff again — the only differences are the ones you made. That is a test in this project's suite, run against real files.

These files get large, because every tag definition, comment and match record travels with the text. Parsing and export run in a worker thread and the grid is virtualized, so a file with hundreds of thousands of segments still scrolls.

Related formats

Everything on the XLIFF 1.2 page applies here too, since SDLXLIFF is a 1.2 dialect. MQXLIFF is the equivalent dialect from memoQ, which solves the same problems in a different namespace.

Straight to the point: open an SDLXLIFF file online.