A machine translation is a strong first pass. For a lot of content it is the whole job. But some content needs more before it ships: source text that has been cleaned of typos first, a human translator in the loop, copy that reads like a native wrote it, a check that the meaning survived the round trip.
You could bolt those steps on yourself – call translate, run a grammar pass, route the result to a reviewer, wait for them, translate back to check for drift, reconcile the differences. The translating is the easy part. Orchestrating the waits, the ordering, and the failures between those steps is the hard part – and a reviewer who takes two days to respond is the hardest part of all.
The pipeline is those steps, already wired. Each stage is an optional wrapper around the core translate step, toggled on the localization engine (or overridden per request), and run inside the durable async job that already owns retries and failure isolation. You pick the stages; the platform runs them in order and records what happened. The job is the single belief this cluster leaves you with: wrap the translate step with exactly the stages you need.
Async API only
Pipeline stages apply only to jobs created through the Async Localization API. The synchronous /localize endpoint runs the core translate step and nothing else – any pipeline configuration on the engine is ignored. A human-review stage needs a workflow that can pause for two days; a single request/response call has nowhere to put that wait. The pipeline lives where the job is durable.
On this page
Why a pipeline#
Raw translation has no opinion about what kind of content it is translating. Legal text wants to stay literally faithful to the source. Marketing copy wants to read like a native wrote it, not like it was translated. User-generated source text wants the typos cleaned up first, before a single error in the source poisons every target locale. Regulated content wants a qualified human to sign off.
These are different jobs, and the pipeline lets one engine do any of them by composing stages instead of forcing one behavior. Enable none and you get plain translation. Enable a human-review stage and the job pauses for your team. Enable the rephrase stage and the output is rewritten to read native. Each stage page below names the content it is for – and, just as plainly, the content it is not for, so you do not enable a stage that works against your goal.
You configure the defaults once on the engine's Pipeline tab, or override them for a single submission with a pipelineConfig object on the request – omitted stages inherit the engine's setting. The mechanics of both layers live on Configure the pipeline.
Stages at a glance#
The pipeline wraps the core localization step. Any combination of stages can be enabled, in this fixed order. Disabled stages are skipped entirely. Each stage has its own page with the full behavior, the failure mode, and the call to enable it.
Pre-localization AI edit
Optional. An AI agent cleans the source payload – typos, grammar, spelling – before anything is translated, so a single source error does not propagate to every target locale. Non-critical. See Pre-localization AI edit.
Core localization
Always runs. Your engine applies its model config, glossary, brand voice, and instructions to produce the translation. This is the one stage you cannot turn off – everything else wraps it.
Post-localization human review
Optional. A human reviews the translation – your own team in the dashboard (Internal Review) or a professional translator from an external provider (External Review). The job pauses for their output on an event-driven wait, so a long review burns no compute while it waits. See Human review.
Post-localization AI review
Optional, and only runs after human review produces output. An AI agent reconciles the human's edits with your engine's glossary, brand voice, and instructions. This is not the same as AI Reviewers, which score quality without changing the text. See AI review.
Rephrase for natural copy
Optional. An AI agent rewrites the translation to read as native, idiomatic copy in the target locale, preserving meaning, placeholders, and tags. Non-critical. For marketing copy; skip it where literal accuracy matters. See Rephrase for natural copy.
Back-translation check
Optional. The output is translated back to the source, an AI compares it against the original, and drift is flagged minor, major, or critical – major and critical issues are auto-corrected. A classic human-QA technique, automated. See Back-translation check.
What a failed stage does to the job#
The obvious objection to a six-stage pipeline: every stage you add is another thing that can break – so does enabling them make the job more likely to fail? No. A failure in a non-critical stage does not fail the job. Pre-edit and rephrase are non-critical: if either fails, the last good output carries forward unchanged and the job continues. The job degrades to a warning state instead of breaking, and every enabled stage leaves a record you can read back to see exactly what ran.
That is the shape of the whole pipeline: wrap the translate step with exactly the stages you need, run them inside a job that already owns the failures, and read back a record for each stage. How a degraded job reports itself, and the per-stage inspection surface, are on Observe pipeline runs. The pages below are the stages themselves – start with the one that matches the content you are translating.
