BeLazy has long been able to export the XLIFF file of a document at any workflow step from any supported TMS, and import it back at the end of the step. This is what makes workflows with both human and automated steps possible: an external AI engine, a script or a person can process the file between the export and the import, and the TMS project continues as if the work had been done inside the TMS.


For LLM-based processing, the XLIFF alone is no longer enough. BeLazy is therefore introducing its own JSON-based format, which carries the full picture of a bilingual document in a single, compact file that you can send directly to an LLM, and import back the same way. This article explains why, what the format contains, and how it relates to the XLIFF you can already use.

  • Every TMS speaks its own XLIFF. XLIFF 1.2 is supported by practically every translation tool, but each tool extends it in its own way. SDLXLIFF, MQXLIFF, MXLIFF and TXML represent the same or similar information differently, and inline formatting tags are not harmonized between tools. If you build an AI step on raw XLIFF, you need to handle every flavor separately.
  • The important information is no longer in the file. Comments, segment locks, match rates and statuses have largely moved from the XLIFF into the TMS APIs, especially in cloud and developer-oriented TMSes. Some systems treat XLIFF as just another document format. An LLM step that only sees the XLIFF does not know which segments are locked, which ones came from a 100% match, or what the reviewer commented.
  • Verbosity costs money. LLMs are charged by tokens, and XML is expensive to read: long attribute names, angle brackets and internal metadata such as previews, segment history and internal IDs all consume tokens without helping the model. In our measurements, the JSON representation of the same information uses around 10% of the tokens of the original XLIFF. The exact saving depends on the content and on which information you send, and much of it comes from leaving out what the model does not need, not only from the shorter notation. Even if you only shorten the tag representation and send the source and target segments, the saving can still be 20-30%.

What the JSON format is

The JSON format is one file per bilingual document. It combines two sources:

  • the content of the XLIFF exported from the TMS, and
  • the information BeLazy fetches about the same document's segments through the TMS's public or private APIs.

The structure is the same regardless of which TMS the document comes from. The same prompt, script or application can therefore process documents from any supported TMS.

The file contains, per segment:

  • Source and target text, with inline formatting tags replaced by short placeholders. The model works with the position of the tags, not with the markup. The original tag definitions are kept aside so that BeLazy can restore them.
  • Segment status, such as not translated, translated or confirmed.
  • Locking, so that the model and your validation know which segments must not change.
  • Match information: the match rate, and where the match came from, for example translation memory or machine translation.
  • QA issues raised by the TMS, with their severity and position in the segment, so that an automated step can resolve them or mark false positives.
  • Comments: existing comments as readable context, and a place for a new comment, for example a question to the project manager.

The file also identifies the XLIFF flavor it was created from, and the exact file version it belongs to. This prevents changes from being applied to a different version of the document than the one that was exported.

Tip: Not every step needs every piece of information. For a pre-translation step, the source text, the locks and the match information are usually enough. For a review or QA step, the QA issues and comments matter too. Sending only what the step needs is the simplest way to reduce token cost further.


How the round trip works

  1. When a workflow step that you have set up for automated processing starts, BeLazy exports the XLIFF from the TMS and fetches the additional segment information through the TMS APIs (public or internal).
  2. BeLazy combines both into the JSON file and makes it available for download, together with the original XLIFF.
  3. An AI engine, script or application processes the JSON file, for example by translating, post-editing or resolving QA issues.
  4. The system uploads the changed JSON file. BeLazy writes the changes back into the XLIFF, imports the XLIFF into the TMS, and performs the API operations needed to update the information that does not live in the XLIFF, such as comments. 

The calls follow the same logic as the XLIFF-based AI Hub workflow. See Extending TMS capabilities via the AI Hub APIs for the webhooks and endpoints.


The XLIFF is still available

If an application prefers to keep working with XLIFF, it can. The XLIFF that BeLazy provides is the file exported from the TMS. It does not contain the additional information BeLazy fetched through the API. That information is only available in the JSON file. JSON is the preferred format for LLMs, whereas machine translation providers and other tools use the XLIFF export.


The specification

The format specification is maintained as an LLM skill (for example, a Claude skill). The skill explains the format to the LLM, including what the abbreviations mean and how the model should return its changes, and it is equally readable for developers. This keeps the format as openly documented as XLIFF. The format is meant to be interoperable: developers are free to use it in their own applications.

If you are sending the file to an LLM, include the skill in the request, or load it in your agent, so that the model knows how to read and return the format.

Availability

We are adding the API-based information gradually, TMS by TMS. Until a TMS is fully supported, its JSON file contains the XLIFF content and the information that is already available. Currently we support Phrase and memoQ JSONs.