Build solutions that translate text by using Azure Translator in Foundry Tools or LLM-powered translation flows

Translator is no longer only a neural machine translation API. The 2026-06-06 text translation version adds the ability to select specified large language models and adaptive custom translation, which means the choice is not simply "Translator or an LLM" any more. What still decides most questions is a smaller detail: asynchronous document translation requires Blob storage and synchronous does not.

Why This Matters

The sync/async split has an infrastructure consequence. Batch document translation "requires an Azure Blob storage account with containers for your source and translated documents"; single-file synchronous translation "doesn't require an Azure Blob storage account".

Customization has two very different shapes. Custom Translator trains a model. Adaptive custom translation builds "a custom bilingual index in minutes" from 5–10,000 segment pairs to adapt an LLM.

Format preservation is a Translator property. Document translation preserves "the structure and format of the original documents" — something a raw model call does not do.

Prerequisites

• That neural machine translation and generative models are different mechanisms.
• What a glossary or terminology list does in translation.
• Container deployment for data residency.
• The idea of adapting a model with examples rather than retraining.

Learning Objectives

By the end of this lesson you will be able to:

1. Choose between synchronous and asynchronous document translation.
2. Distinguish Custom Translator from adaptive custom translation.
3. Apply dynamic dictionary and prevent translation controls.
4. Decide between Translator and an LLM-powered flow.
5. Meet residency requirements with the Translator container.

Building Blocks

Translator features.

Development options. REST API, the Text translation SDK, the Document Translation SDK, the Foundry portal, and the Translator container. Foundry provides "a no-code interface" for "text and synchronous document translation operations".

Terminology controls on v3. A dynamic dictionary for supplying a translation inline, and prevent translation for marking spans that must be left untouched.

Deep Dive

The document translation split

This is the most reliably tested detail in the objective, and both halves matter.

Asynchronous — batch translation. It translates "batch and complex files while preserving the structure and format of the original documents", and "the batch translation process requires an Azure Blob storage account with containers for your source and translated documents". So the architecture includes storage, container configuration, and access — real infrastructure, appropriate when volume justifies it.

Synchronous — single file translation. It translates "a single document file alone or with a glossary file", also preserving structure and format, and "doesn't require an Azure Blob storage account. The final response contains the translated document and is returned directly to the calling client."

Two design consequences follow.

A user-facing "translate this document" button is synchronous. No storage account, no polling, the file comes back in the response.

A nightly job over thousands of documents is asynchronous. The storage requirement is a feature there, not overhead — the source and translated containers are where the work naturally lives.

And note that the glossary is called out on the synchronous path, translating a file "alone or with a glossary file" — terminology control without any storage infrastructure.

Customization: train a model or adapt an LLM

The two paths solve the same problem with different economics.

Custom Translator builds "customized models to translate domain- and industry-specific language, terminology, and style", and supports creating "a dictionary (phrase or sentence) for custom translations". It runs through the Custom Translator portal. This is the established path: you are producing a trained artefact tuned to your corpus, which suits a large, stable body of domain language.

Adaptive custom translation is the newer and more distinctive option, and its numbers are examinable. You "upload 5–10,000 prealigned source–target segment pairs (≤500 chars per pair)", and "the service builds a custom bilingual index in minutes to adapt supported LLMs… via Azure Translator APIs".

Three properties make it attractive. The volume needed is modest — five thousand pairs is a realistic translation memory export, not a research corpus. It is ready in minutes rather than after a training cycle. And it adapts an LLM, so you inherit generative fluency while constraining terminology to your examples.

The discriminator: a large stable domain corpus and a desire for a trained model → Custom Translator. An existing translation memory and a need to be running quickly → adaptive custom translation.

Translator against an LLM flow

The framing has shifted, because 2026-06-06 offers "the option to select specified large language models (LLM)" from within Translator. So "use an LLM" no longer implies leaving the translation service.

Translator remains the answer when the work is translation: many language pairs, high volume, predictable cost, format-preserving document translation, terminology enforced by glossary or dictionary, and a container for residency. These are properties a general model call does not provide — a raw model does not preserve .docx structure, and reproducing that is substantial work.

An LLM-powered flow earns its place when translation is entangled with other reasoning: translate and summarise, translate and adapt register for an audience, translate and extract fields, or translate content whose meaning depends on surrounding context the API does not see. The saving is one pass instead of two.

Adaptive custom translation sits between them, giving LLM output constrained by your own segment pairs, inside the Translator API surface.

The rule that generalises: if the requirement is translation, use the translation service; if translation is one step inside a larger transformation, a generative flow is legitimate — and check whether Translator's own LLM selection already covers it.

Terminology control

Three mechanisms, on different surfaces.

Dynamic dictionary on text translation v3 supplies a specific translation inline for a term, without training anything — the right tool when a handful of terms must render a particular way.

Prevent translations marks spans to leave untouched: product names, code identifiers, trademarks. The failure it prevents is a brand name being helpfully translated into the target language.

Glossary files attach to synchronous document translation — a file translated "alone or with a glossary file" — giving document-scale terminology control with no storage infrastructure.

Beyond these, Custom Translator dictionaries (phrase or sentence) and adaptive custom translation's segment pairs encode terminology at model or index level rather than per request.

The escalation is: a few terms → dynamic dictionary or prevent translation. A document's worth → a glossary. A domain's worth → Custom Translator or adaptive custom translation.

Worked Examples

Example 1 — a translate button. A portal lets users translate a single uploaded contract on demand, preserving its formatting, with company terminology respected.

Synchronous document translation — a single file "alone or with a glossary file", preserving "the structure and format", which "doesn't require an Azure Blob storage account" and returns the document "directly to the calling client". The asynchronous path would add a storage account for no benefit at one file per request.

Example 2 — a nightly batch. Twelve thousand documents must be translated overnight into four languages with formatting intact.

Asynchronous document translation — "batch and complex files while preserving the structure and format" — which "requires an Azure Blob storage account with containers for your source and translated documents". Here the storage requirement matches the workload's natural shape.

Example 3 — an existing translation memory. A team has roughly 8,000 approved bilingual segment pairs and wants domain-accurate output running this week.

Adaptive custom translation: it takes 5–10,000 prealigned source–target segment pairs (≤500 chars per pair) and "builds a custom bilingual index in minutes to adapt supported LLMs". Custom Translator trains a model and suits a large stable corpus, but adaptive translation matches both the data on hand and the timescale.

Visual Explanations

The document translation decision:

Escalating terminology control:

Common Mistakes

Assuming both document paths need Blob storage. Synchronous does not.

Using the batch path for a single on-demand file.

Expecting a model call to preserve document formatting.

Confusing Custom Translator with adaptive custom translation. Trained model against a bilingual index.

Forgetting adaptive custom translation's limits. 5–10,000 pairs, ≤500 characters each.

Translating product names. Use prevent translations.

Assuming an LLM flow is required for LLM quality. 2026-06-06 allows selecting LLMs inside Translator.

Overlooking the Translator container under a residency requirement.

Practice Exercises

1. State the storage requirement for each document translation path.
2. Distinguish Custom Translator from adaptive custom translation, with the numbers.
3. Which terminology mechanism fits a few terms, a document, and a domain?
4. When is an LLM-powered flow legitimate rather than Translator?
5. What did text translation 2026-06-06 add?

Summary & Concept Map

Translator now spans classic neural machine translation and LLM-backed translation in one service: text translation 2026-06-06 adds LLM selection, adaptive custom translation, and expanded parameters, while v3 carries dynamic dictionary and prevent translations. The decision most often tested is document translation's split — asynchronous batch requires an Azure Blob storage account with source and translated containers, while synchronous single-file does not and returns the document directly, optionally with a glossary. Both preserve structure and format, which is the property a raw model call cannot supply. Customization runs two ways: Custom Translator trains a model with phrase or sentence dictionaries, and adaptive custom translation turns 5–10,000 segment pairs of ≤500 characters into a bilingual index in minutes to adapt an LLM. Reserve a generative flow for cases where translation is one step inside a larger transformation, and reach for the Translator container when data cannot leave.

Sources and freshness

Written against current Microsoft Learn documentation for the AI-103 skills measured (16 April 2026), reviewed 2026-08-20. Microsoft Learn controls every changing product contract — availability, preview status, quotas, limits, regional support, naming, and retirement dates all move independently of this lesson. Where a scenario turns on a specific number or a GA/preview boundary, confirm it against the product's own page before relying on it.