# How it works

> What happens to a WPML export between the moment you upload it and the moment you download it back - parsing, classification, translation, checking and rebuilding.

> Canonical HTML: https://aixlifftranslate.com/docs/how-it-works/
> Last updated: 2026-09-08

WPML exports your content as XLIFF: a standard XML file where each piece of text is a
**translation unit** with a source (your original) and an empty target (waiting for a
translation). We fill in the targets and hand the file back structurally unchanged, so WPML
accepts it on import.

The interesting part is everything that happens between those two moments.

## 1. Parse

The file is read as XML, not as text. That distinction matters: a WordPress page is full of
markup that *looks* like content - block comments, shortcodes, HTML attributes, structured
data - and a tool that treats the file as a string will happily translate a CSS class name or
a URL slug.

Parsing gives us the unit boundaries WPML defined, plus the source and target language from
the file's own header. We translate into the language the *file* asks for, not one you pick in
the interface, because WPML exports one file per target language.

## 2. Find the duplicates

Real websites repeat themselves. A call to action, a footer disclaimer, a product blurb reused
across twelve pages - an export routinely contains far fewer *distinct* strings than units.

Every unit is fingerprinted by its source text. Identical sources are grouped, one member of
each group is translated, and the result is applied to the rest. You pay for the work done,
not the units counted, which is where most of the saving on a typical export comes from.

## 3. Classify each unit

Not all text should be treated the same way, and some should not be translated at all. Each
unit is routed to one of four strategies.

- **Body content** - paragraphs, headings, descriptions. Translated in your brand voice, with
  room to breathe.
- **Metadata** - page titles, meta descriptions, alt text. Translated under SEO constraints:
  these have length limits and a job to do, so they are handled more tightly than prose.
- **Structured data** - JSON-LD blocks describing your business, products or FAQs. Parsed as
  JSON, with only the human-readable fields translated. Identifiers, enumerations, URLs, dates
  and type names are left exactly as they were, because changing them breaks how search
  engines read your page.
- **Not translatable** - URLs, email addresses, slugs, brand names, template placeholders such
  as `%%title%%`. Passed through untouched.

Large HTML blocks get one more step. They are split into meaningful segments - an FAQ item, a
section - translated segment by segment, then reassembled into the original document
structure. Translating a 4,000-word HTML blob in one shot is how you lose a closing tag.

## 4. Translate

Each unit goes to the model with instructions assembled for that unit: your brand voice, the
protected terms that apply to it, what kind of content it is, and where it sits on the page.

Two things are held out of the model's reach entirely. URLs inside links are swapped for
placeholders before the text is sent and restored afterwards, so a model cannot "improve" a
link target. Protected glossary terms are declared up front and enforced afterwards.

You choose a quality tier - **Medium** or **Pro** - rather than a specific model. Medium is
the sensible default for body content at volume. Pro costs more per page and earns it on copy
that carries weight. The tier is recorded against the job, so you can compare results.

## 5. Check the result

A translation that reads beautifully but drops a `<strong>` tag is a broken page. Before
anything is accepted it is checked against its source for:

- **Markup integrity** - the same tags, in the same shape. If the model invents a tag the
  source never had, that tag is removed rather than the whole translation being discarded.
- **Shortcodes and placeholders** - `[gallery]`, `%%sitename%%` and friends must survive
  intact and in the same quantity.
- **Protected terms** - your brand names must still be present, spelled the way you spell them.
- **Length** - a translation several times longer than its source is a hallucination, not a
  translation.
- **Unchanged output** - output identical to the input usually means a failure. Not always,
  though: a proper noun legitimately translates to itself, so short identities and
  model-confirmed ones are accepted rather than fought.

A failed check triggers one stricter retry. If that also fails, the unit is **flagged for your
review** rather than quietly shipped. Nothing is presented as translated unless it passed.

## 6. Rebuild

Translated units are written back into a copy of your original file. The XML structure,
attribute order and unit ids are preserved exactly, because WPML validates them on import.

Every download is rebuilt from the stored translations at the moment you request it. Edit a
translation in the review screen and your next download contains that edit - there is no
cached archive that can drift from what you see.

## What you get back

XLIFF files with the same names and structure you uploaded, each marked with a suffix so you
can tell them apart from your originals, zipped together. Import them into WPML exactly as you
would import work from any translation vendor.

## What we deliberately do not do

- **We do not touch your database.** Translation happens on files. Nothing is installed in
  WordPress and nothing changes on your site until *you* import.
- **We do not hold your translations hostage.** They are standard XLIFF files. Stop using us
  tomorrow and everything you already translated stays in your WordPress install.
- **We do not machine-translate blindly.** Any unit that could not be verified is flagged,
  because a translation you cannot trust is worse than one you know to check.
