Microsoft's 2026 Translator API puts an NMT-or-LLM choice in every request

I think the engine choice belongs in the API but not in feature code. Once each request carries a flag for neural translation or an LLM ^[1], any call site that sets it decides how a class of content is handled. Usually nobody reviews that decision.

The code changes are ordinary. A client that serializes a `to` parameter has to emit a `targets` array, and anything reading the response has to handle a changed structure ^[2][3]. Those details come from a KBV Research post on dev.to that summarizes Microsoft's guide. The post does not say whether or when v3.0 will be retired ^[2]. The evidence supports a migration with real code changes. It does not establish a deadline.

The post's test plan covers request serialization, language detection dependencies, error handling and downstream consumers of response data, all in nonproduction ^[10]. Old and new paths run against the same approved test set and get compared on edits and latency ^[10]. Those tests can pass while dashboards go quiet. The post also asks for a check of the response fields, error codes and billing identifiers that dashboards read ^[9].

Documents need separate fixtures. Microsoft's 2026 Document Translation overview describes format preservation alongside batch and single-file processing ^[11]. A string-level unit test will not catch a broken diagram label, according to the post. It suggests testing a real manual, a slide deck and an image-heavy PDF where the product uses those formats ^[11].

The routing design is the best engineering in the piece. The caller supplies a class from a fixed set. A router maps that class to an approved model, glossary and review path, and an evaluator scores results against a test set ^[4]. A job with no class fails into a draft state instead of moving toward publication ^[5]. Policy changes get reviewed and tested like a release, and every job records the policy version it ran under ^[6]. According to the post, that record is what makes a surprising result easier to reproduce ^[6].

The design has one soft spot. Fail-to-draft catches a missing class; it cannot catch a wrong one. A contract labelled as catalog copy takes the catalog route of neural translation, glossary checks and sampled review ^[7]. Input validation ^[5] rejects labels outside the fixed set. A valid label on the wrong asset gets through.

The route examples also need a condition before anyone copies them. The post calls them design examples, not guarantees of model accuracy ^[8]. Its editorial route sends LLM output through an evaluation against the neural baseline and then a local reviewer ^[7]. That route transfers to another team only if the team's own test set, for its own language pairs, shows the LLM output needing fewer reviewer edits than the baseline ^[10].

KBV Research points readers to its own Machine Translation Market report for context ^[15]; the engineering advice is the more useful half. Its proposed internal service accepts a content-class identifier, source and target language, asset reference, glossary version and an idempotency key. It returns a job status and a traceable artifact ^[12]. Each job logs model route, language pair, content class, glossary version, latency, cost and reviewer outcome ^[14].