6.2.2. Translation: Azure Translator and LLM-Powered Flows
💡 First Principle: Translation has two viable paths that mirror the whole domain's LLM-first-versus-dedicated-service tension. Azure Translator (in Foundry Tools) is the dedicated, high-volume, broad-language-coverage service; an LLM-powered translation flow handles nuance, domain tone, and combined tasks (translate and summarize) in one prompt. Choose by the same signals as elsewhere: volume and breadth favor Translator; flexibility and combined reasoning favor the LLM.
Azure Translator provides fast, low-cost translation across a very large set of languages and is the right answer for high-volume, straightforward translation at scale. An LLM-powered translation flow shines when the task needs domain tone, context-sensitive phrasing, or a combined operation — translating and summarizing a document, or translating while preserving a compliance register — in a single structured-output prompt. Speech translation combines recognition with either path. The decision signal is familiar: very high volume and broad language coverage at lowest cost point to the dedicated Translator service; nuance, domain customization, or a combined task point to LLM-powered translation.
⚠️ Exam Trap: A requirement for very high-volume, low-cost translation across many languages favors the dedicated Translator service — routing every message through a flagship LLM is costlier at scale. Conversely, "translate and adapt the tone for a legal audience" is an LLM-flow task. Match the signal (raw volume vs. nuanced combined task) to the path.
Reflection Question: A telecom must translate a billion SMS messages per month at minimal cost; a law firm must translate contracts while preserving formal legal register. Why do these point to different translation paths?
