What do you like best about Google Cloud Translation API?
The reason this API sits in our stack is simple: it translates anything we throw at it, in any of the languages our audience actually reads, and it does it in the time it takes an HTTP request to come back. Everything else about it is detail. Useful detail, but detail.
Coverage is the first thing that matters in practice. We publish content in Italian and English and localize pieces into Spanish, French, German, and Portuguese, and the API has never once been the constraint. It supports well over a hundred languages, and language detection means I can pipe in user-generated text without knowing or caring what language it arrived in. Detection has been accurate enough that I stopped double-checking it months into using the service. For a newsletter workflow where community submissions arrive in whatever language the sender prefers, that removes an entire manual sorting step.
The v3 Advanced edition is where the features I lean on daily live. Three of them carry most of the weight for us:
- Glossaries. We maintain a custom dictionary of product names, brand terms, and a handful of Italian marketing expressions that generic machine translation mangles. Once the glossary is attached to a request, those terms come out the same way every time, across every target language. Before glossaries, a product name would get "helpfully" translated in one paragraph and left alone in the next, and someone had to catch it by eye.
- Document translation. Feeding it a DOCX or a PDF and getting back a translated file with the layout intact is the feature that surprised me most. Media kits and one-pagers keep their structure, tables stay tables, and the formatting work that used to eat an afternoon per document is gone.
- Batch translation. When we localized a backlog of a few hundred articles, the batch endpoint let me submit the whole job asynchronously against files in a Cloud Storage bucket and collect the results later, instead of hammering the synchronous endpoint in a loop and babysitting rate limits.
Translation quality with the standard NMT model is strong for the language pairs we use, and the Translation LLM option raised the ceiling further for marketing copy. NMT output for Italian to English is clean and rarely needs more than a light editorial pass. Where the LLM model earns its keep is tone: idiomatic phrasing in landing page copy comes out reading like something a person wrote rather than a literal rendering. I route content by type now, NMT for functional text like UI strings and support macros, the LLM model for anything a customer will actually read as prose. Having both behind the same API means that routing is one parameter, not a second vendor.
Adaptive Translation deserves its own mention. Supplying a small set of example translation pairs and having the model pick up our house style from them is a much lighter lift than training a full custom model. We fed it a few dozen previously human-translated snippets from our own material, and the output moved noticeably closer to how our editor would have phrased things. It is not a replacement for a human pass on high-stakes copy, but it cut the distance that pass has to cover.
Integration with the rest of Google Cloud is the quiet advantage. We already run infrastructure on GCP, so authentication rides on the same service accounts and IAM roles as everything else, billing lands on the same invoice, and usage shows up in the same monitoring. Wiring the API into a Cloud Function that fires when new content lands in a bucket took an afternoon, most of which was spent on our own logic rather than on the API. The client libraries are mature, the endpoints behave predictably, and error responses tell you what actually went wrong.
Reliability has been unremarkable in the best sense. In well over a year of production use I cannot point to an outage that affected us, and the failure modes we have seen were our own, malformed requests and quota ceilings we configured too low. Quotas themselves are generous by default and adjustable through the console, and because errors come back with clear codes, our retry logic was straightforward to write and has rarely needed to fire. When a service disappears into the background of a pipeline like this one has, that is the service doing its job.
Speed is not something I think about anymore, which is the best compliment I can give it. Synchronous requests come back fast enough for real-time use, and we have used exactly that for translating inbound support messages on the fly. It just responds.
The free tier is genuinely usable rather than symbolic. The first 500,000 NMT characters per month cost nothing, which was enough to run the entire evaluation phase and our early production volume without a bill. For anyone testing whether machine translation fits their workflow, the barrier to a real trial is effectively zero. Review collected by and hosted on G2.com.
What do you dislike about Google Cloud Translation API?
Cost at scale is the honest headline, and it needs active management rather than passive acceptance. The per-character model is fair in principle, but characters add up faster than intuition suggests. Twenty dollars per million characters sounds cheap until you multiply by six target languages, because each target language is billed separately. A single 3,000-word article localized into six languages is not one translation job on the bill, it is six. We now forecast translation spend per campaign the way we forecast ad spend, with budget alerts configured in the billing console, and I would recommend anyone doing volume work set those alerts on day one rather than after the first surprising invoice.
The HTML markup billing behavior is the trap I actually fell into. When you send content with format set to html, every character inside the tags counts toward billing, even though the tags themselves are not translated. On tag-heavy CMS output that inflated our character counts by a meaningful margin before I noticed. The fix on our side was a preprocessing step that strips markup, translates clean text, and reassembles the structure afterward, which works fine but is exactly the kind of plumbing I would have preferred not to write. The documentation does not exactly hide this behavior, but it does not warn you about it in the places a new integrator is likely to read either.
Documentation depth falls off at the edges. The core translate-this-text path is documented thoroughly, with good samples in every major language. Step outside it, toward Adaptive Translation configuration, custom model training, or the finer points of glossary formats, and the material gets thin. I resolved more than one question by experiment rather than by reading, and glossary CSV formatting in particular took a couple of failed uploads before the accepted structure became clear. For a Google product I expected the long tail of the docs to be stronger than it is.
The v2 and v3 split is a migration cost hiding in plain sight. The two versions use incompatible client libraries and different authentication models, v2 with simple API keys and v3 requiring service accounts and IAM. We started on v2 because it was the fast path, then had to rework the integration when glossaries pulled us to v3. If I were starting today I would go straight to v3 and skip the detour, since that is clearly where all new development is happening, but nothing in the onboarding flow steers a newcomer that way.
Two smaller frictions worth knowing about. There is no meaningful visibility into why the model translated something the way it did, so when an output is wrong for our context the only levers are the glossary, adaptive examples, or post-editing, with no way to inspect or nudge the underlying model. And the console UI for translation features is serviceable but clearly built for developers; a non-technical teammate cannot realistically manage glossaries or review batch jobs without help, so those tasks stay with whoever owns the code. Review collected by and hosted on G2.com.
