# General Translation Knowledge Base: Google Translate alternatives: General Translation vs. Google Translate
URL: https://generaltranslation.com/en-US/kb/general-translation-vs-google-translate.mdx
Docs index: https://generaltranslation.com/llms.txt
Description: Google Translate is a quick way to translate one-off text, but shipping a product in another language also needs each string translated in context, consistent terms, correct variables and plurals, review, and a release process. General Translation understands each string's context in your code and automates the whole localization workflow, from code to review to every release.
Category: Translation
Last updated: 2026-10-16
Authors: General Translation Team
Published: 2026-10-16

Google Translate is a fast way to read a page in another language or translate a paragraph once. The harder parts of localizing a product are translating every string with the meaning it has in your UI, keeping terms consistent across releases, and getting translations to where your app loads them. Each way of using Google Translate for an app leaves some of that to you.

## Video

The video is narrated in English, with English captions.

[Google Translate alternatives: General Translation vs. Google Translate](https://caxecubb9c64cezv.public.blob.vercel-storage.com/films/kb-general-translation-vs-google-translate.mp4) (44 sec)

Google Translate is a quick way to translate one-off text, but shipping a product also needs each string translated in context, consistent terms, correct variables and plurals, review, and a release process. General Translation understands each string's context in your code and automates the whole workflow: wrap copy in `<T>` with a context note, keep values in `<Var>`, and run `npx gt translate` in your build while reviewers edit in the Dashboard.

## Three ways to use Google Translate for an app

### Let visitors' browsers translate the page

Chrome offers to translate pages in languages the user doesn't read. The translation happens in the visitor's browser after the page loads: Google's translate script replaces the page's text with translated text wrapped in `<font>` elements. You don't see or review the result, and there's no translated URL for search engines to crawl, while Google's guidance for multilingual sites is to publish each language at its own URL ([Managing multilingual sites](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites)).

The rewrite can also break React apps. React keeps references to the text nodes it rendered, so after translation replaces them, the next update can fail with `NotFoundError: Failed to execute 'removeChild' on 'Node'`. React's maintainers closed the issue for it ([react#11538](https://github.com/react/react/issues/11538)) in 2018, explaining that React itself can't work around it without masking other bugs or slowing down common cases. Elements marked with `translate="no"` are left alone.

### Add the Website Translator widget

Google's embeddable Website Translator is limited to academic, government, nonprofit, and non-commercial sites, so a company can't add it to its product ([Google Translate Help](https://support.google.com/translate/answer/2534559?co=GENIE.Platform%3DDesktop)).

### Call the Cloud Translation API

The Cloud Translation API is the option built for developers. It keeps HTML tags intact. For HTML input, its Advanced edition skips text marked `translate="no"` or `class="notranslate"`, and it adds glossaries, adaptive translation from example sentence pairs, and a Translation LLM built on Gemini. A request carries the text, the languages, and optionally a model and a glossary:

```json title="translateText request body"
{
  "contents": ["Save"],
  "mimeType": "text/plain",
  "sourceLanguageCode": "en",
  "targetLanguageCode": "de"
}
```

There's no field for where a string appears. In German, "Save" is *speichern* (store a file) or *sparen* (spend less), and a one-word request gives the model nothing to choose by. The rest of the pipeline is yours to build: pulling strings out of your i18n files, protecting placeholders such as `{{count}}`, producing each language's plural forms, writing results back, rerunning on every change, and giving reviewers a place to fix output that the next run won't overwrite. If you show the output to users, Google also requires attribution: a "powered by Google Translate" badge next to results, a disclaimer for unmodified output, and machine-translation markup on pages that search engines index ([attribution requirements](https://docs.cloud.google.com/translate/attribution)).

## How the options compare

| Approach | Context for each string | Variables and plurals | Search engines | Review and updates |
| --- | --- | --- | --- | --- |
| Browser translation | The visible page text | Translated as plain text | Nothing new to index | No review; reruns in each visitor's browser |
| Cloud Translation API | The text, plus an optional glossary or example pairs | You protect placeholders and build each language's plural forms | Indexed once you publish each language at its own URL | You rerun your script and build review yourself |
| General Translation | The surrounding JSX, a context note, your Glossary, and Custom Prompts | [`<Var>`](/docs/react/reference/components/var) values stay out of translation, and [`<Plural>`](/docs/react/reference/components/plural) branches are translated as whole sentences | Indexed with `gt-next` locale routing, such as `/es/about` | Each build or Locadex pull request translates what changed, and reviewers edit in the Dashboard |

Use Google Translate to read foreign-language content or translate internal text once. Use the Cloud Translation API when you want raw machine translation and will build context, placeholders, plurals, review, and attribution yourself. Use General Translation when the translations ship in your product, such as app UI, docs, or a marketing site that has to read right in every language and stay current with each release.

## What General Translation does differently

General Translation is built for the parts of localization that Google Translate leaves to you. Two things set it apart:

- **It understands the whole context.** A Cloud Translation request carries the text and the languages, plus an optional glossary. General Translation translates each string with its place in your product: the component and elements around it, the variables and plural forms in the sentence, any context note you add, and your Glossary and Custom Prompts. A Context Group applies the same terms and tone to every project you assign it to, so your app, docs, and marketing site use the same words.
- **It automates the whole localization workflow.** Open-source libraries internationalize your code in React, Next.js, Vue, and Node.js, and for Next.js and React apps, [Locadex](/docs/platform/locadex/quickstart), General Translation's AI agent, can write that code for you. [`npx gt translate`](/docs/cli/reference/commands/translate) runs in your build or CI and writes translations to your repository or General Translation's CDN, reviewers edit them on the Dashboard's **Translations** page, and each release ships in every language.

Here's what the context looks like in code. This billing toggle's badge reads "Save 20%":

```tsx title="BillingToggle.tsx"
import { T, Var } from 'gt-react';

export function BillingToggle({ discount }: { discount: string }) {
  return (
    <T context="Pricing page billing toggle. Save means pay less, not store data.">
      <button>Yearly</button>
      <span className="badge">Save <Var>{discount}</Var></span>
    </T>
  );
}
```

[`<T>`](/docs/react/reference/components/t) sends the block as one unit, with its elements (a button and a badge) and the [`context`](/docs/react/reference/components/t#context) note, so the translation can resolve "Save" and place the discount where each language puts it. [`<Var>`](/docs/react/reference/components/var) holds a placeholder for the discount, and its value is never sent to the General Translation API. The Glossary pins terms such as product names in every language, and Custom Prompts set rules such as formal "Sie" in German. (See [Defining context for translations](/docs/platform/dashboard/guides/defining-context-for-translations) and [Reviewing and editing translations](/docs/platform/dashboard/guides/reviewing-translations).) For content that exists only at run time, such as user-generated or CMS text, [`tx`](/docs/node/reference/functions/tx) in `gt-node` translates on request.

General Translation supports 120+ locales. Start with the [Next.js Quickstart](/docs/react/nextjs-quickstart) or the [React Quickstart](/docs/react/react-quickstart).

## Key takeaways

- Google Translate translates text well. Browser translation gives you no review or indexable pages and can break React apps, and the Website Translator widget is limited to non-commercial sites.
- A Cloud Translation API request has no field for where a string appears, and placeholders, plurals, review, delivery, and attribution are yours to build.
- General Translation understands each string's context in your code and automates the workflow around translation, from internationalizing the code to review to shipping every release in every language.

## Related questions

- [General Translation vs. i18next, react-intl, and next-intl: which i18n library should you use?](https://generaltranslation.com/en-US/kb/general-translation-vs-i18n-libraries.mdx): Open-source libraries such as i18next, react-intl, and next-intl don't translate anything. They display translations you supply in a catalog file for each language, written by you, your translators, or a separate service. General Translation's libraries are open source too and do the same job, and General Translation also does the translating, with your code as context.
- [General Translation vs. a TMS (Crowdin, Lokalise, Phrase)](https://generaltranslation.com/en-US/kb/general-translation-vs-tms.mdx): Choose General Translation when developers want translation generation, code-derived context, and review connected to product releases. Keep your existing catalogs and rendering library, or author inline JSX without translation keys. A TMS fits programs centered on language vendors, CAT editors, and XLIFF exchange; its integrations can automate the file transfers.
- [How do I translate conditional text in JSX?](https://generaltranslation.com/en-US/kb/translate-conditional-jsx.mdx): Keep the sentence whole and translate every version of it, because a ternary splits it into fragments that lose their meaning and their place in each language's word order. General Translation does this with `<Branch>` inside `<T>`, which translates the sentence as one unit.
- [How do I handle plurals in React?](https://generaltranslation.com/en-US/kb/how-to-handle-plurals-in-react.mdx): Handle plurals in React by giving each language one sentence per plural form and picking it with that language's plural rules, since English has 2 forms, Russian has 4, and Arabic has 6. General Translation's `<Plural>` component in gt-react and gt-next takes your source forms, and General Translation generates the forms each target language needs.
- [How do I set up SEO for a multilingual Next.js app?](https://generaltranslation.com/en-US/kb/multilingual-nextjs-seo.mdx): Give each language its own prefixed URL, such as /en/about and /es/about, then publish html lang, a self-referencing canonical, hreflang alternates with x-default, a translated title and description, and a sitemap entry for each published language. Mark unpublished versions noindex. General Translation's gt-next routes each language to its own URL and translates titles with getGT.

## Previous and next questions

- Previous question: [General Translation vs. Weblate: which should you use?](https://generaltranslation.com/en-US/kb/general-translation-vs-weblate.mdx)
- Next question: [i18next alternatives: General Translation vs. i18next](https://generaltranslation.com/en-US/kb/general-translation-vs-i18next.mdx)

## Sitemap

See the [Knowledge Base sitemap](https://generaltranslation.com/en-US/kb/sitemap.md) for every article.