By Toolverly Editorial. Research and local analysis checked on October 19, 2026.
Choose a machine translation API by the shape of the work: byte-bounded arrays for DeepL, code-point-bounded requests for Google Advanced, a target-multiplied budget for Azure, single-text calls for Amazon Translate, or context-aware groups for Lara. Our executed packing analysis of 120 independent records found that a universal “50 strings per request” adapter would misrepresent several of these contracts. Request count is not a quality or cost ranking.
This comparison addresses software teams translating product records into three languages, rather than the approval and translation-management workflows in our localization-platform comparison. The resulting strings still need content review before entering a headless CMS.
Five different units behind one translation job
| Service | Decision boundary | What to verify |
|---|---|---|
| DeepL API | 50 texts plus 128 KiB body ceiling | Measure serialized bytes and leave headroom |
| Google Cloud Translation | Advanced: 30000 code points | Basic and batch have different contracts |
| Azure Translator | 50000 characters across targets | Three targets consume the budget three times |
| Amazon Translate | TranslateText: one text, 10000 bytes | Array packing does not apply to this operation |
| Lara Translate | Arrays require context-linked strings | 128 elements is not an unrelated-batch guarantee |
DeepL API
DeepL’s large-volume guide documents up to 50 texts per request and a 128 KiB request-body ceiling. Our fixture’s 3000-byte records reach our deliberately smaller 120 KiB body budget at 40 records. The 50-item ceiling alone is insufficient. Context and other request fields must share the byte budget.
Usage documentation counts text-translation billing in source Unicode code points. Bytes used for transport and characters used for billing are therefore different quantities. The API plan destination currently redirects into a broader plan page; consumer translator allowances should not be substituted for an API quote. Verify the selected API subscription, commitment and usage charges. We do not publish an inferred monthly amount.
Google Cloud Translation
Google’s quota guide sets a 30000-code-point maximum for a Cloud Translation Advanced request and recommends smaller requests, around 5000 characters. A hard limit is an admission boundary, not an optimal operating size. Our maximum-size model packs 30 of the 1000-code-point records per call to one target, or four requests per target.
Google pricing distinguishes methods and models: standard NMT input-character metering differs from LLM input/output metering. Specify Advanced versus Basic, the model and all target languages in a procurement estimate. Our 12-call count covers one particular synchronous Advanced packing strategy; it says nothing about latency, parallel quotas or asynchronous batch economics.
Azure Translator
Azure’s service-limit table applies the 50000-character translate-request limit across target languages and separately caps the input array at 1000 elements. With three targets, each 1000-character record consumes 3000 of the request’s character budget. Sixteen records fit; seventeen do not. That produces seven 16-record groups and one 8-record group in our fixture.
This can mean fewer HTTP requests than three separate single-target batches without reducing the translated character workload. Azure pricing depends on the selected tier and service operation. Do not equate a larger request ceiling with a free allowance, a higher throughput entitlement or lower translation costs.
Amazon Translate
Amazon’s synchronous quota guide gives a 10000-byte text-input limit. TranslateText accepts one Text string and one target language. Our choice to preserve one unrelated record per call therefore yields 360 calls: 120 records times three targets. Concatenating descriptions into one string changes the response-reassembly problem and is outside this model.
Amazon’s pricing page meters the chosen translation operation; real-time text, document translation and batch workflows must be scoped separately. For an AWS-integrated application this API may fit the surrounding operational model even with more requests. No measured speed or total-cost disadvantage follows from our count.
Lara Translate
We initially researched ModernMT, then found its announced migration to Lara. The migration page says existing ModernMT API keys continue until December 31, 2026. A new selection should evaluate the current Lara contract instead of treating that legacy API as an unchanged long-term purchase.
Lara’s text API documentation allows up to 128 list elements but explicitly reserves string/TextBlock arrays for context-linked content. Our unrelated catalog records do not meet that semantic assumption. A conservative adapter would submit them independently; 128 is not permission to combine arbitrary records. Lara API pricing separates API usage from consumer usage and model-specific costs; rate limits introduce a separate characters-per-second constraint. Confirm model, account entitlement and current commercial terms. We did not estimate an accepted maximum payload or test the service.
Executed packing result and reproducible input
Each of 120 synthetic records contains the two-character string商品 repeated 500 times: 1000 Unicode code points and 3000 UTF-8 bytes. These are size fixtures standing for independent records, not meaningful text for a translation-quality test. Targets are German, French and Italian.
Our chosen DeepL 120 KiB body budget produced 40/40/40 records per target, or 9 calls overall. Google Advanced’s maximum-based packing produced 30/30/30/30 per target, or 12 calls. Azure’s target-weighted groups were 16/16/16/16/16/16/16/8, or 8 three-target requests. Amazon’s one-record adapter and Lara’s conservative unrelated-record adapter each imply 360 calls. The latter is an adapter choice, not a measured Lara requirement for every integration.
import json
text = "商品" * 500
assert len(text) == 1000
assert len(text.encode("utf-8")) == 3000
for n in (40, 41):
body = json.dumps({"text": [text]*n,
"source_lang":"ZH", "target_lang":"DE"},
ensure_ascii=False, separators=(",", ":"))
print(n, len(body.encode("utf-8")))
print(50000 // (len(text)*3)) # 16The important procurement question is whether the API preserves the application’s record boundaries and context assumptions. Repeated filler, larger payloads and fewer requests cannot establish linguistic quality. A production adapter should keep stable record IDs outside translated text, verify response cardinality, honor quotas and back off on rate errors.
Methodology and limitations
We executed greedy array packing and actual JSON byte serialization with Python 3.14.6 on macOS 26.6.2, retaining inputs and outputs. The DeepL 120 KiB budget is our operational headroom choice below 128 KiB; additional options may require more. We did not call translation APIs, assess language accuracy, measure latency, consume quotas or compare paid invoices. Batch/file translation, HTML handling, glossaries and specialized LLM models are outside the calculation. Actual acceptance, throughput and plan-specific limits need an authorized pilot. AI assistance was used for research, local analysis code and writing; source claims and executed outputs were reviewed before publication.
Photo by Johan Mouchet on Unsplash. Read about our publication or send a correction.