How it works

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.