A first, simple picture before we open the details.

Machine translation means using a computer program to convert text from one human language into another. The language you start with is called the source language, and the language you want is the target language. Machine translation is something most people have already used, for example when a web browser offers to translate a page.

Translation AI is the name Google Cloud uses for its collection of translation services that developers and companies can build into their own products. At the centre is Cloud Translation, a service that you call from your software with a small request containing text, a source language and a target language. The reply contains the translation. Around this core sit extra capabilities: glossaries to protect important terms, document translation that keeps formatting, batch translation for huge volumes, custom and adaptive models that learn your style, and links to speech services for spoken language.

A short history

Google Translate began in 2006 as a statistical service that learned patterns from millions of already translated documents. In 2016 Google moved to neural machine translation, which reads whole sentences and produces smoother, more natural output. The Cloud Translation API made this technology available to developers, first as a simple version and later as a richer Advanced edition with glossaries, batch and document features. More recently Google has added large language model approaches, including a Translation model based on Gemini technology and an Adaptive Translation feature that adjusts to your own examples. Names and features keep evolving, so always check the current documentation.

Why translation matters so much, and why doing it by hand does not scale.

People prefer their own language

Surveys of online shoppers have repeatedly found that people are far more likely to buy when a page is in their own language, even if they speak some English. Support is similar: customers feel respected and understood when they get answers in their language. For software, translation is called localization when it also adjusts dates, currencies, units and cultural details, not only the words.

The cost of human-only translation

Professional human translators produce excellent work, but they are limited by time and money. A single product catalogue with fifty thousand items in twenty languages would need a million translated entries, and prices change every week. Hiring translators for every request is slow, and some content, such as chat messages, needs an answer in seconds.

What good translation must achieve

Four big ideas in the history of translation by computer, told simply.

The key idea behind neural translation

A neural translation model has been shown many millions of pairs of sentences, one in each language. During training, it practises guessing the target sentence one small piece at a time and adjusts millions of internal numbers whenever it is wrong. After enough practice, it learns patterns such as word order, agreement and meaning. The most successful design is called the Transformer, which uses a mechanism named attention to decide which words in the source sentence matter most when writing each word of the translation.

Why context matters

Many words have several meanings. The English word “light” can mean not heavy, not dark, or to ignite. A good model uses neighbouring words to choose the right meaning. Context can also come from outside the sentence, such as the type of document, the product category or the audience. Modern services let you supply some of this context through glossaries, custom examples or instructions.

How we judge a translation

People who study translation need ways to measure quality. A classic automatic score called BLEU compares the machine’s sentence with a human reference, rewarding matching word groups. Newer learned scores such as COMET and MetricX try to judge meaning more like a human reader. The gold standard is still careful human review, often using a checklist called MQM that counts errors by type and severity. We will return to measuring quality in a later chapter.

A small vocabulary that makes the rest of the guide easy.

Characters, not words

Translation services usually measure and bill your usage in characters, meaning letters, digits, punctuation and spaces, not in words. A short English sentence of forty characters costs less than a long paragraph of four thousand. Knowing this helps you estimate cost: count the characters in your content, multiply by the number of target languages, and compare with the current price per character.

Synchronous and asynchronous

A synchronous call means you send a request and wait a moment for the answer in the same connection. It suits short text where you need the result at once, such as translating a chat message. An asynchronous call means you submit a job and come back later for the results. It suits large files and big sets of text, where waiting on an open connection would be unwise.

Detecting language

When you do not know the source language, the service can detect it. This is useful for user-generated content such as reviews and messages. Detection is usually reliable for longer text and less reliable for very short phrases, names or mixed-language messages, so give extra context when you can.

Which services exist, and how they fit together.

flowchart LR
  A["Websites and apps: text strings"] --> T["Translation AI services in Google Cloud"]
  B["Documents: PDF, Word, slides"] --> T
  C["Audio and video: speech and subtitles"] --> T
  T --> O1["Translated text for users"]
  T --> O2["Translated documents with layout kept"]
  T --> O3["Live captions and spoken translations"]
    

The main members

How the pieces connect to the rest of Google Cloud

• Cloud Storage holds files for batch and document translation and receives the results.
• Pub/Sub, Cloud Run and Cloud Functions trigger translation when new content arrives.
• BigQuery can call translation from SQL, which is handy for translating many table rows.
• Document AI and Vision read text from scanned images before translating.
• Dialogflow and contact center tools use translation for multilingual conversations.
• IAM, Cloud Monitoring and Cloud Logging provide access control, observability and audit trails.

The first practical decision for most teams.

Cloud Translation Basic, sometimes called version two of the API, is the simple edition. It translates text, detects languages and lists supported languages. It is easy to try, and it can use simple API keys for access. It is a good fit for quick experiments and for apps that need only plain translation.

Cloud Translation Advanced, version three of the API, adds the features that serious projects need. It uses stronger access control through service accounts, lets you choose a processing location, and supports glossaries, batch translation, document translation, custom and adaptive models, and newer large language model translation. Most new production projects should plan for Advanced from the start.

What sits between your application and the translated text.

flowchart TD
  CL["Your application or script"] --> EP["Cloud Translation API endpoint: Basic or Advanced"]
  EP --> NMT["Neural machine translation model"]
  EP --> LLM["Translation LLM"]
  EP --> CUS["Custom or adaptive model"]
  GL["Glossary stored in the chosen location"] -.-> EP
  GCS["Cloud Storage for batch and documents"] -.-> EP
  IAM["IAM and service accounts"] -.-> EP
  MON["Cloud Monitoring and Logging"] -.-> EP
    

Reading the diagram

Your application never talks to a model directly. It talks to an API endpoint, which checks who you are, applies quotas and decides which model should do the work. The model might be Google’s general neural model, a large language model tuned for translation, or a model adapted to your data. Glossaries and files live in the background and are attached to the request when needed. Access control, logging and monitoring wrap around everything.

sequenceDiagram
  participant App as Your Application
  participant API as Translation API
  participant GL as Glossary Store
  participant M as Translation Model
  App->>API: Send text, source and target language, optional glossary
  API->>API: Check credentials and quota
  API->>GL: Load glossary terms if requested
  GL-->>API: Term pairs
  API->>M: Translate sentences with glossary rules
  M-->>API: Translated text
  API-->>App: Return translations and detected language
    

The request step by step

A gentle look under the bonnet, with no mathematics required.

Step one: breaking text into pieces

Computers cannot read letters the way we do. Before translation begins, the text is cut into small units called tokens. A token may be a whole common word, a part of a long word, or a single character for rare words. Cutting words into reusable pieces lets the model handle names, new words and spelling mistakes without panicking, because it can still recognise familiar fragments.

Step two: turning pieces into meaning numbers

Each token is converted into a long list of numbers called an embedding. Words with similar meaning end up with similar numbers. The word for “dog” sits near “puppy” and far from “invoice.” These numbers are the model’s private way of representing meaning, and, importantly, they work across languages: the English “water” and the Spanish “agua” land in similar places.

Step three: the encoder and the decoder

A classic translation model has two halves. The encoder reads the entire source sentence and builds a rich understanding of it. The decoder then writes the target sentence one token at a time, consulting the encoder’s understanding through attention before choosing each next token. It stops when it decides the sentence is complete.

flowchart LR
  S["Source sentence"] --> TK["Split into tokens"]
  TK --> EM["Convert to meaning numbers"]
  EM --> EN["Encoder builds understanding"]
  EN --> AT["Attention picks relevant parts"]
  AT --> DE["Decoder writes one token at a time"]
  DE --> TS["Target sentence"]
    

The diagram shows a simple line, but the middle steps repeat many times. The decoder writes the first token, then uses that token and the source understanding to write the second, and so on. If you have ever finished someone’s sentence in your head, you have done something similar.

Choosing among many possible sentences

At each step the model does not pick a single certain word. It scores thousands of candidates. A technique called beam search keeps several promising partial sentences alive at the same time and finally chooses the best complete one. This reduces the chance of a sentence that starts well and ends badly.

How training teaches the model

Training uses very large collections of parallel text, meaning sentences and their human translations side by side. Sources include public documents translated by international organisations, multilingual websites and curated datasets. The model repeatedly predicts a translation, measures how far it is from the human version, and adjusts its internal numbers a tiny amount. After billions of such adjustments the model becomes skilled. Languages with lots of parallel text, such as French or Spanish, are usually translated better than languages with little written material online.

Low-resource languages

A low-resource language is one with little digital text available. Research teams use clever tricks to help, such as training one model on many languages together so that knowledge from big languages helps small ones. Quality for these languages is improving, but it can still lag behind, so treat important output with extra care.

The everyday job: send words, get words back.

What a request contains

• The contents: one or more strings of text to translate.
• The target language code: required, for example fr for French.
• The source language code: optional. If omitted, the service detects it.
• The format: plain text or HTML, so tags are handled properly.
• Optional controls: a glossary, a model choice, labels for cost tracking, and a location.

What comes back

For each input string you receive a translated string. If detection was used, you also receive the detected language and sometimes a confidence value. When a glossary was used, you may receive a second translated version that shows the glossary effect so you can compare.

Translating HTML safely

Web pages contain tags such as bold or links. If you send them as plain text, the model may translate or damage them. When you tell the service the content is HTML, it keeps tags in place and translates only the visible words. You can mark parts that must never be translated, such as brand names or code snippets, using a “do not translate” attribute or a special class that the service recognises. Check the current documentation for the exact marker.

Size, batching and limits

Each request can contain only a limited number of characters and strings. If you have a large list, group strings into sensible batches rather than sending thousands of tiny requests. Tiny requests waste time on network overhead, while a single enormous request may exceed limits. Keep batches modest, and design your code to split work automatically.

Caching to save money and time

Many applications translate the same phrases again and again, such as menu labels, product categories and error messages. Store each translation in a cache, a fast memory store keyed by the text, language and glossary version. Next time the same phrase appears, you read it from the cache and skip the paid call. Remember to clear the cache entry when the source text, glossary or model changes.

flowchart TD
  R["Text to translate"] --> C{"Already in cache?"}
  C -->|"Yes"| H["Return cached translation"]
  C -->|"No"| API["Call Translation API"]
  API --> W["Save result to cache"]
  W --> H
    

Handling special content

How to make sure your brand and technical terms are always translated your way.

A glossary is a list of source terms with the exact translation you want for each. Without one, the model might translate a product name as an ordinary word, or translate a technical term in several different ways across your site. With one, the service replaces or guides the translation of those terms every time.

Two kinds of glossary

Where glossaries live

You prepare the glossary as a simple file, for example a table of columns separated by tabs or commas, or a translation memory exchange file. You upload it to Cloud Storage and then create a glossary resource in the Translation service, in a particular location. When you translate, you reference the glossary by name. The glossary and the translation request must use the same location.

Glossary design tips

• Keep entries short and exact. Long sentences belong in a translation memory or adaptive dataset instead.
• Include different word forms where the language needs them, since glossaries match terms, not the grammar around them.
• Decide whether matching should ignore capital letters, and test the effect.
• Avoid contradictions, such as the same source term mapped to two different targets.
• Give every glossary an owner who approves changes.

When the general model is good, but your content is special.

General models know everyday language well. Your company, however, may use special vocabulary, a particular tone, or a style that only your past translations reveal. Google Cloud offers two ways to teach the service about your world.

Adaptive Translation

Adaptive Translation uses a small set of your own example sentence pairs, called a dataset. At translation time, the service picks the most relevant examples for the sentence in front of it and uses them to steer a large language model. You do not run a long training job; you simply upload examples and the service uses them immediately. This works well when you have a modest amount of high-quality approved translations, such as a few hundred or a few thousand pairs.

Custom models

A custom model is trained on a larger collection of your sentence pairs, building on Google’s base model through a process called fine-tuning. It requires more data, more preparation and a training run, but results can be tailored deeply and reused at scale. Google has changed the AutoML-style offerings over time, so check which custom training options are currently supported and recommended before starting.

Preparing good data

Quality beats quantity. Collect translations that human experts approved, remove duplicates, fix alignment errors where a source line is paired with the wrong target, and split off a separate test set that the model never sees during training. Remove personal or confidential data that should not travel into a dataset. Keep records of where each pair came from.

flowchart LR
  A["Approved past translations"] --> B["Clean and align pairs"]
  B --> C["Split into training and test sets"]
  C --> D["Create adaptive dataset or train custom model"]
  D --> E["Evaluate on the test set"]
  E --> F{"Better than general model?"}
  F -->|"Yes"| G["Use in production"]
  F -->|"No"| H["Improve data and try again"]
  H --> B
    

Using large language models when you want flexibility, tone and context.

A large language model, or LLM, is a very large neural network trained on huge amounts of text. It can translate, but it can also follow written instructions. That makes it useful when a plain translation is not enough. You can tell it who the audience is, which tone to use, which words to keep and what the text is for.

Google Cloud offers LLM translation in two main ways. One is a Translation LLM option inside the Cloud Translation family, tuned specifically for translation. The other is general Gemini models on Vertex AI, Google Cloud’s platform for building with AI models, where you write a prompt describing the translation task. Availability and names change quickly, so check the current model list.

What LLMs add

• Tone and register control: formal or casual, marketing or technical.
• Context awareness: understanding of surrounding paragraphs.
• Rewriting and explanation: simplifying, summarising, or explaining while translating.
• Few-shot learning: following a handful of examples inside the prompt.

What to watch for

• Consistency: results can vary slightly between runs.
• Over-helpfulness: the model may add explanations or skip hard parts unless you instruct it clearly.
• Cost and latency: often higher than the classic model for the same text.
• Prompt sensitivity: small wording changes can change results, so test prompts like code.

When you have thousands of files, do not wait at the counter.

Batch translation lets you submit many files at once. You place them in a Cloud Storage bucket, tell the service the languages you want, and name an output bucket. The job runs in the background, and the translated files appear in the output location when finished. Because it is asynchronous, the service returns an operation, a kind of receipt, which you can check for progress and completion.

flowchart LR
  IN["Input bucket: source files"] --> B["Batch translation job"]
  B --> OUT["Output bucket: one folder per language"]
  B --> OP["Operation status"]
  OUT --> PS["Pub/Sub message or workflow step"]
  PS --> BQ["Index in BigQuery or publish to website"]
    

Typical settings

• Input files and MIME types: plain text, HTML and other supported formats.
• Target languages: you can request several in a single job.
• Output location: a Cloud Storage prefix; results are organised by language.
• Glossaries and models: optional, per language pair.
• Labels: tags such as team and project for cost tracking.

Designing a reliable batch pipeline

Translating files such as contracts, manuals and presentations without breaking their look.

Document translation accepts whole files, such as PDF, Word, PowerPoint and Excel files, and returns a translated file in the same format. The service reads the text, translates it, and puts it back in the same position with similar fonts, tables, headers and images. This saves hours compared with copying text out, translating it, and rebuilding the design by hand.

Scanned documents

A scanned PDF is really a picture of text. The service may use OCR, short for optical character recognition, which is software that reads text from images. Quality depends on scan clarity. Blurry pages, handwriting, unusual fonts and complex tables increase errors. For important scans, consider a separate extraction step with Document AI, review the extracted text, then translate it.

Things to check after translation

• Text that became longer and overflowed boxes, since German or Finnish can be much longer than English.
• Fonts that lack characters for the target script.
• Tables and footnotes that moved or merged.
• Text inside images, which usually stays untranslated unless OCR handled it.
• Page numbers, references and tables of contents that need updating.

flowchart TD
  U["Upload document"] --> T{"Scanned or digital?"}
  T -->|"Digital"| TR["Translate with layout preserved"]
  T -->|"Scanned"| OC["Read text with OCR"]
  OC --> TR
  TR --> QA["Automatic checks"]
  QA --> HR{"High risk content?"}
  HR -->|"Yes"| REV["Human review"]
  HR -->|"No"| PUB["Deliver translated file"]
  REV --> PUB
    

From the spoken word in one language to captions or voices in another.

Translation AI works on written text. To translate speech, you chain services together. First, Speech-to-Text listens to audio and writes down what was said. Then Cloud Translation converts that text into the target language. Finally, if you want a spoken result, Text-to-Speech reads the translated text aloud in a natural voice. Google has also offered dedicated speech translation products in the past, and these have changed over time, so verify what is currently available.

flowchart LR
  MIC["Speaker audio stream"] --> STT["Speech-to-Text"]
  STT --> TR["Cloud Translation"]
  TR --> CAP["Live captions on screen"]
  TR --> TTS["Text-to-Speech"]
  TTS --> LIS["Listener hears translated voice"]
    

Why speech is harder

• Errors add up: a mistake in listening becomes a mistake in translation.
• No punctuation in speech: sentence boundaries must be guessed, and wrong guesses hurt translation.
• Accents, noise and overlapping voices reduce accuracy.
• Latency matters: a three-second delay can ruin a conversation.

Practical advice

• Use streaming recognition for live events, and show captions as partial results arrive.
• Wait for a natural pause before translating, to avoid translating half-finished sentences.
• Supply speech hints such as product names to improve recognition.
• Allow users to see the original transcript next to the translation, so they can notice mistakes.

A simple decision guide for the most common situations.

flowchart TD
  S["What are you translating?"] --> Q1{"Spoken audio?"}
  Q1 -->|"Yes"| SP["Speech-to-Text, then Translation, then Text-to-Speech if needed"]
  Q1 -->|"No"| Q2{"Whole files with layout?"}
  Q2 -->|"Yes"| DOC["Document translation"]
  Q2 -->|"No"| Q3{"Large volume, not urgent?"}
  Q3 -->|"Yes"| BAT["Batch translation"]
  Q3 -->|"No"| Q4{"Need special tone or context?"}
  Q4 -->|"Yes"| LLM["Translation LLM or Gemini"]
  Q4 -->|"No"| Q5{"Need fixed terms or your style?"}
  Q5 -->|"Terms"| GLO["Advanced with glossary"]
  Q5 -->|"Style"| ADA["Adaptive Translation"]
  Q5 -->|"Neither"| BAS["Basic or Advanced text translation"]
    

How to know whether a translation is good enough to publish.

Quality is not a single number. A translation can be fluent but wrong, or accurate but awkward. A good measurement plan looks at several angles and matches the effort to the risk of the content.

Build a test set

Collect a few hundred representative sentences per language pair. Include easy cases, tricky ones with idioms and numbers, text with placeholders, and examples of your key terms. Have a skilled person write or approve the reference translations. Re-run this test whenever you change models, glossaries or prompts so you can compare results fairly.

Risk-based review

How translation fits into the way teams actually ship products.

Localization is the full process of preparing a product for a language and region. Translation is one step. Others include adapting dates, currencies, images, colours and legal text, and testing the result with local users. Many teams manage this in a translation management system, a tool that tracks strings, versions, reviewers and deadlines.

A translation memory is a database of past source sentences and their approved translations. When a new sentence is identical or very similar to an old one, the system reuses the approved translation, saving cost and keeping wording consistent. Machine translation fills the gaps where no match exists.

flowchart LR
  A["Developers add or change text"] --> B["Extract strings"]
  B --> C{"Match in translation memory?"}
  C -->|"Yes"| D["Reuse approved translation"]
  C -->|"No"| E["Machine translation with glossary"]
  E --> F["Human review where needed"]
  F --> G["Save to translation memory"]
  D --> H["Merge into product"]
  G --> H
  H --> I["Test with local users"]
    

Habits that make localization smooth

• Internationalise first: design software so text, dates and numbers can change without code changes.
• Never glue strings together: write whole sentences with placeholders, since word order differs by language.
• Give translators context: screenshots and notes reduce ambiguity.
• Plan for text expansion: allow extra room in layouts.
• Treat language as continuous: new text arrives every sprint, so automate the flow.

Translation is most useful when it is wired into your workflows.

A common event-driven pattern

A new article is saved to a bucket. A storage event notifies a small service. The service starts a translation job for each target language, saves the results to another bucket, and announces completion through a message. A final step publishes the pages and updates the search index. Because each step is small and independent, failures can be retried individually.

Translation often touches sensitive text, so protect it carefully.

Who can call the service

Access is controlled with IAM, Google Cloud’s identity and access management system. You grant roles, such as a role allowing the use of the Translation API, to specific people or service accounts, which are identities for programs. Follow the principle of least privilege: give each program only the permissions it needs. Basic can use API keys, but keys are easy to leak, so restrict them to specific APIs and applications, and prefer service accounts wherever possible.

Protecting data

• In transit: calls use encrypted connections (TLS).
• At rest: files in Cloud Storage and glossaries are encrypted by default, and you can use your own keys for extra control where supported.
• Data use: read Google’s current terms for how customer content is handled and whether it is used to improve models. Confirm this for your edition and contract.
• Sensitive details: consider removing or masking personal data such as names and account numbers before translation, using a data loss prevention tool, and restoring them afterward.

Location and residency

Advanced lets you choose a location for processing and storing glossaries and models. If laws or contracts require data to stay in a region, choose accordingly, and confirm which features and models are available in that region. Additional perimeter controls, such as VPC Service Controls, can reduce the risk of data leaving your protected environment; verify support for the Translation APIs in current documentation.

Audit and accountability

Audit logs record who called which admin operations and, depending on configuration, data access. Review them regularly, alert on unusual patterns such as a sudden jump in usage from one account, and keep an inventory of who owns each glossary and dataset.

Compliance thinking

Regulations such as privacy laws, healthcare rules and sector standards may apply to the text you translate. Ask your compliance team early. Keep records showing that translations of regulated content went through the required human review, because a machine alone is usually not accepted as the final authority for legal or medical meaning.

Keeping translation fast and dependable when traffic grows.

Quotas

A quota is a limit on how much you can use in a period, for example characters per minute or requests per minute. Quotas protect the shared service and also protect you from runaway bills. You can often view current values in the console and request increases. Plan for peak traffic, not average traffic, such as a sales day when many pages are translated at once.

Handling errors gracefully

Networks and services sometimes fail briefly. Good clients retry failed calls after waiting, and the wait grows with each attempt. This approach, called exponential backoff, prevents a crowd of clients from hammering a struggling service. Add a small random delay, called jitter, so retries do not all land at the same instant. Do not retry errors that will never succeed, such as invalid language codes or permission problems.

sequenceDiagram
  participant C as Client
  participant API as Translation API
  C->>API: Request 1
  API-->>C: Temporary error
  C->>C: Wait a short time with jitter
  C->>API: Request 2
  API-->>C: Temporary error
  C->>C: Wait longer
  C->>API: Request 3
  API-->>C: Translation returned
    

Fallbacks

Decide in advance what happens if translation is unavailable. Options include showing the original text with a small notice, showing a cached older translation, or queuing the request for later. Never block a whole page because a single comment could not be translated.

Speed techniques

• Translate in advance for stable content, not at the moment of the visit.
• Cache results at several levels: application, edge and browser.
• Send several strings in one request, within limits.
• Translate only text that changed.
• Place your services in the same region as the translation location to reduce travel time.

See what is happening and keep the bill under control.

What to watch

Cloud Monitoring collects metrics from Google services and lets you draw dashboards and set alerts. Cloud Logging stores log entries. Together they answer questions such as: Did usage double overnight? Are errors rising for one language pair? Is one service account suddenly very busy?

Understanding the bill

Translation is generally billed per character translated, with different rates for different features, such as standard text translation, document translation, custom models and LLM-based options. Some plans include a monthly free amount. Because pricing changes, use the current pricing page and the pricing calculator rather than relying on old numbers.

Putting the pieces together for a made-up but realistic business.

Imagine a shop called “Lotus Home” that sells kitchenware. It has twelve thousand products, a help centre, customer reviews, and a support chat. It wants to serve customers in Spanish, German, Hindi and Japanese. The team plans the work in layers, using the right tool for each type of content.

An honest balance sheet before you commit.

Key trade-offs

Habits that help, and habits that hurt.

Helpful patterns

Anti-patterns to avoid

A checklist you can use on your first project.

Best practices

• Begin with a clear list of languages and content types, ranked by business value.
• Choose Advanced for production, and the simplest method that meets quality needs.
• Create glossaries early, with owners and approval steps.
• Build a test set and keep scores over time.
• Mark machine-translated content honestly when users might rely on it.
• Design layouts for text expansion and right-to-left languages.
• Use service accounts, least privilege, budgets and alerts from day one.
• Keep source text clean: fix typos and ambiguity before translating, since errors multiply.
• Write short, clear source sentences; they translate better.

Common mistakes

• Assuming all languages have equal quality.
• Forgetting that glossary and request locations must match.
• Sending HTML as plain text and breaking tags.
• Translating code, product IDs or URLs.
• Ignoring user feedback from native speakers.
• Treating pricing, limits and product names as permanent.

Troubleshooting guide

Illustrative scenarios showing how organisations typically use Translation AI.

Quick definitions of the words used in this guide.

They share technology, but Google Translate is a consumer product. Translation AI in Google Cloud is the set of services developers use to build translation into their own applications, with business controls such as access management, glossaries and billing.

The core service supports well over a hundred languages, but the exact number and which pairs work with each feature change. Check the current supported languages page.

Use Basic for a quick experiment. For anything going to production, plan on Advanced because glossaries, batch, documents and finer security are there.

Yes. Use a glossary that maps the brand name to itself, or mark that text as not to be translated in HTML content.

For HTML text, tags are preserved. For files, document translation keeps layout as far as possible, though you should check the result, especially when text becomes longer.

Choose an LLM when tone, context or rewriting matter, such as marketing text. Choose the classic model for speed, low cost and stable results on large volumes.

Usually not at first. Try the general model, then a glossary, then adaptive examples. Custom training is for cases with large, clean data and a clear need.

Data is encrypted in transit and at rest, and you control access with IAM. For details on how customer content is used and where it is processed, read Google’s current terms and location documentation, and involve your compliance team.

Mostly by the number of characters processed, with different rates by feature and sometimes a free monthly amount. Check the pricing page for current numbers.

Yes, by combining Speech-to-Text, Translation and optionally Text-to-Speech in a pipeline.

For high-stakes content, yes. For everyday content, machine translation with sampled review is often enough. Humans also create the glossaries and approved examples that make the machine better.

Cache translations, translate only changes, filter out text that needs no translation, use the simplest suitable method and set budgets with alerts.

The whole guide in one short page.

Translation AI in Google Cloud is a toolbox, not a single tool. It begins with fast neural translation of text and grows to include glossaries for consistent terms, adaptive and custom models for your own style, large language models for tone and context, batch and document translation for scale, and speech chains for live and recorded audio. The best results come from matching the method to the content, measuring quality honestly, protecting data and keeping humans involved where the stakes are high.