BigQuery AI.TRANSLATE is now GA: what data teams should do

On 22 October 2026 Google made the AI.TRANSLATE function generally available in BigQuery. It translates text strings between languages from inside a query, and it covers both standard Neural Machine Translation (NMT) workloads and Translation LLM (TLLM) capabilities. If your tables hold reviews, tickets, search terms or survey answers in more than one language, one step of your pipeline may no longer need to live outside the warehouse.

Key takeaways

• AI.TRANSLATE is generally available as of 22 October 2026, which means it is a supported feature rather than something to test on the side.
• It supports both NMT and Translation LLM capabilities, so the choice of approach is now yours to make per workload.
• The practical win is moving translation into SQL, next to the data, with fewer exports and fewer moving parts.
• Run a small pilot with a native-speaker review before you translate a whole table.
• Look up supported languages, quotas and pricing in Google's documentation, because the release note does not give them.
• Teams can pilot this alone. A partner is worth paying for when governance, cost and reporting design get complicated.

What changed with AI.TRANSLATE on 22 October 2026

The release note is short. It says the AI.TRANSLATE function lets you translate text strings between languages, that it supports standard Neural Machine Translation workloads and Translation LLM capabilities, and that it is generally available (GA).

That last word is the headline. GA generally signals that a feature has moved past the testing phase and is meant for production use. Before this, a function like this was something a cautious data team would try in a notebook and then hesitate to put into a scheduled job. That hesitation has less to stand on now.

The note says nothing about supported language pairs, input limits, quotas, regional availability or price. Those details matter a lot for planning, and they live in Google's function documentation. Read that page before you write a budget line. Don't assume anything about them from the release note alone.

Why translation inside the warehouse matters

Most teams that translate data today do it outside the warehouse. A job exports rows, calls a translation service, writes results to a file or table, and loads them back. That works, but it is a small system with its own credentials, retries, schedule and failure modes. Somebody owns it, and that somebody is usually also busy with something else.

A function you call in SQL changes the shape of the problem. The translation step becomes a column in a query or a transformation in a scheduled pipeline. It sits under the same access controls as the table it reads. It shows up in the same job history. When it breaks, you look where you already look.

Here's a concrete case. A retail brand sells in several markets and collects product reviews in each local language. The analytics lead wants one sentiment dashboard in English. Today that means an export, an external call and a reload. With a warehouse-native function, the translated text can be materialised as a column in a table and fed to whatever analysis already runs on the English reviews.

The saving isn't magic. You still pay for the translation, and you still need to check it. What you save is plumbing.

Who should act on this, and who can ignore it

Not every BigQuery team needs to do anything this week. Here's a rough split.

The people who should look first are analytics engineers and the marketing analytics lead who owns the multilingual reporting. They know which tables hold foreign-language text and which downstream reports depend on it.

If your data is all in one language, you can skip this one without guilt. Not every GA announcement is a to-do item.

How to pilot AI.TRANSLATE without breaking anything

Keep the first run small, boring and reversible. A pilot like this doesn't need a project plan. It needs a sample, a reviewer and a written verdict.

1. Pick one table and one purpose. For example, non-English product reviews feeding a sentiment report. Narrow scope makes the result readable.
2. Pull a sample, not the table. Choose a few hundred rows that cover your real languages, lengths and messiness: slang, abbreviations, product names, mixed-language sentences.
3. Read the function documentation first. Confirm supported languages, input limits, quotas and pricing. Write the numbers down before you run anything.
4. Write results to a separate table. Never overwrite the source column. Keep the original text next to the translation so anyone can compare.
5. Run it with both approaches where the documentation allows. The notes say NMT and Translation LLM are both supported, so compare them on the same sample.
6. Have a native speaker score a subset. Ask for a simple rating plus notes on what went wrong, such as dropped negation, mangled brand names or odd tone.
7. Record cost and runtime for the sample. Scale the figures up on paper before deciding anything.

That's enough to decide whether the function earns a place in production. Most of the effort goes into steps 2 and 6, and that's as it should be.

NMT or Translation LLM: choosing per workload

The notes mention two capability families and don't rank them. I wouldn't either. They're built differently, and the right pick depends on the text.

In general terms, NMT is the established approach for translation: it's purpose-built, and teams often reach for it when volume is high and the text is fairly plain. An LLM-based approach tends to be more flexible with context, tone and awkward phrasing, which can matter for informal or ambiguous text. Cost, speed and consistency usually differ between the two, so the documentation and your own sample should settle it, not a general rule.

Whatever you pick, write the choice down with the reason. In six months someone will ask why one table uses one approach and another table uses the other, and the answer should be in a doc, not in somebody's memory.

How to measure whether it works

Translation quality is awkward to measure, and teams often skip it because it feels subjective. Don't. A few plain measures go a long way.

• Reviewer score on a sample. A native speaker rates adequacy (is the meaning kept?) and fluency (does it read naturally?) on a simple scale.
• Error categories. Count the specific failures: dropped negations, wrong product names, mistranslated numbers or dates, lost sarcasm. Categories tell you what to fix; a single score doesn't.
• Downstream agreement. If the translated text feeds sentiment or topic tagging, compare results against a hand-labelled set in the original language.
• Cost per thousand rows and total runtime. Take these from your sample and compare with your current external step.
• Operational load. Count how many things you can switch off: the export job, the credential, the scheduled function, the alert.

Set the pass mark before you look at results. If the standard is 'good enough for aggregate trend reporting', say so. That is a lower bar than 'good enough to quote a customer in a public page', and mixing the two up is where most disappointment comes from.

What not to do

A few mistakes are easy to make with a function this convenient.

Don't translate everything because you can. A column of text that nobody reads or analyses is just a cost. Translate what a report, model or person actually needs.

Don't overwrite original text. Keep the source language column intact, and store the translation separately with enough metadata to know how it was produced. When a stakeholder questions a number in a dashboard, you'll want to show the original.

Don't treat machine translation as publication-ready copy. For analysis, a translation that gets the meaning across is often enough. For anything customers will read, a human review step still belongs in the workflow.

Don't skip the data protection check. Text columns often contain names, emails and order details. Before you send any of it through a translation function, confirm with your security and privacy owners that the use is allowed and that you understand where the data is processed. Google's documentation is the place to check how the feature handles data.

And don't assume the release note covers what it doesn't mention. Language coverage, quotas and pricing are not stated there. Verify them.

Where an implementation partner helps, and where you can go alone

You can run the pilot yourself. If you have an analyst who writes SQL and a colleague who speaks the target language, that's the whole team. A function call, a sample table and a scoring sheet don't need outside help.

Outside help starts to make sense when the problem stops being 'does it translate well' and becomes 'how do we run this across the business'. That usually means:

• Designing a multilingual data model, so that original text, translated text, language codes and quality flags are stored consistently across tables.
• Setting cost controls, such as limits on which tables get translated, scheduling, and monitoring spend.
• Handling governance for sensitive text, including who may translate what and where outputs may be stored.
• Rebuilding reports and attribution so that markets are compared fairly once text from many languages lands in one place.
• Retiring an existing external translation pipeline without a gap in reporting.

If you're at that stage, start with a short list of firms that have real BigQuery and data analytics delivery work behind them. The BigQuery partners page and the Google Cloud data analytics partners listing are a reasonable place to begin, and the RFP template helps you write a brief that asks for what you actually need, such as a pilot with a written quality result, rather than a vague 'AI translation project'.

A simple rollout checklist

If the answer is go, move it into a scheduled transformation, add monitoring on spend and failures, and keep a small review sample running every month so quality drift gets noticed. If the answer is no-go, you've spent a few days and learned something. Either result is fine.

The feature itself is modest: a function that translates text. What it changes is where the work happens. For teams with multilingual data, that's worth an afternoon of testing, and for everyone else, it can wait.

Sources

• Google Cloud: BigQuery release notes — Release note dated 22 October 2026 announcing general availability of the AI.TRANSLATE function.