Microsoft Translations Pivot Language

Azure Translator does not publish a fixed direct-versus-pivot routing matrix or an English-to-European-language quality matrix; routing is selected automatically, so the supported approach is to benchmark each required direction with representative data.

Direct translation versus English pivoting

Translator can use:

• A bilingual model for a particular pair.
• A multilingual model covering related languages.
• A route through a third language, potentially English.

The service selects what it considers the optimal path for each translation request. Microsoft illustrates this with Swahili → English → Hindi, but does not identify which European pairs currently follow that pattern.^1^

Consequently:

• There is no published list confirming whether Slovenian → Italian is direct or Slovenian → English → Italian.
• The supported-language table indicates whether a language is available for cloud translation, containers, Custom Translator, and related features; it is not a pair-routing matrix.^2^
• The documented public interface does not expose the internal route chosen for a translation.
• Routing should not be assumed to remain fixed, because it is selected according to model quality rather than exposed as part of the API contract.

If routing visibility is a contractual or architectural requirement, raise an Azure support request asking whether Microsoft can provide guidance for the specific language pairs. Public documentation is insufficient to construct that matrix reliably.

Translation-quality matrix

Microsoft does not publish absolute quality scores for its standard translation systems. Translation quality depends on the language pair, domain, style, register, and test set; there is no established universal test set. Microsoft recommends evaluating a representative test set for the intended scenario and states that human evaluation provides the most significant and reliable scores.^1^

Build the requested 46-direction matrix—English to and from 23 languages—as follows:

1. Create a separate test set for each direction.
   Use production-like sentences and professionally prepared reference translations. Keep test material separate from any customization training data.
2. Preserve domain and content type.
   Do not combine, for example, product manuals, support conversations, and marketing text into one undifferentiated score.
3. Run all translations within the same evaluation window.
   Record the API version, date, source and target language codes, and whether standard or custom translation was used.
4. Calculate at least two automatic metrics.
   • BLEU for overlap with human references.
   • COMET or another contextual metric to account better for valid paraphrases.
5. Perform blinded human review on a representative sample.
   Score accuracy and fluency separately, and record critical terminology errors. Use human review as the primary criterion for high-impact content.
6. Report confidence and sample size.
   A useful matrix cell would contain:

   	Direction	BLEU	COMET	Human accuracy	Human fluency	Critical error rate	Samples
   	en → sl	…	…	…	…	…	…
   	sl → en	…	…	…	…	…	…

BLEU ranges from 0 to 100 and measures similarity to a reference translation, but it should not be treated as a universal percentage of correctness. Custom Translator exposes both a custom-model BLEU score and a baseline BLEU score so that models can be compared on the same test set.^3^

Use the current language-support table to validate the exact language codes and applicable capabilities before generating the matrix. Note particularly that pt defaults to pt-br; choose the required Portuguese variant explicitly where relevant.^2^

References

1. Azure Translator in Foundry Tools Transparency Note
2. Azure Translator in Foundry Tools language support
3. Test your Custom Translator