# General Translation Knowledge Base: General Translation vs. Weblate: which should you use?
URL: https://generaltranslation.com/en-US/kb/general-translation-vs-weblate.mdx
Docs index: https://generaltranslation.com/llms.txt
Description: Weblate is a self-hostable, Git-based localization platform built for translating repository files with a community or team. General Translation integrates translation generation into development and releases, using marked JSX and shared product context. Keep your gettext files or adopt inline authoring to remove source-catalog maintenance too.
Category: Workflow Tools
Last updated: 2026-10-16
Authors: Kevin Wu, Jackie Chen
Published: 2026-10-16

Weblate is an open-source, web-based translation platform built around Git. You connect a repository, Weblate reads its translation files, people or configured translation services fill them, and Weblate commits the results or opens a pull request. It's a common home for open-source projects with community translators. General Translation puts translation generation in your build: new copy and its translations can ship in the same release, with Dashboard review for your team.

## What Weblate does well

- **Copyleft open source.** Weblate is [licensed under GPL-3.0-or-later](https://github.com/WeblateOrg/weblate), and you can download and run the whole platform at no cost, with paid support plans if you want help installing and maintaining it.
- **Free hosting for libre projects.** Hosted Weblate runs on EU infrastructure, and public libre projects can get its Libre plan at no charge, with the same limits as its 160k-string plan.
- **Git-based continuous localization.** Weblate pulls changes when your forge sends a webhook (or on a daily fetch), commits translations with lazy commits that group changes by author, and pushes them to your branch or [opens pull requests](https://docs.weblate.org/en/latest/vcs.html) on GitHub, GitLab, Gitea, Bitbucket, Azure DevOps, and Pagure. Hosted Weblate also connects through a GitHub App.
- **Very broad file support.** Weblate's docs list [about 50 formats](https://docs.weblate.org/en/latest/formats.html), including gettext PO, XLIFF 1.2 and 2.0, Android and Apple strings, ARB, i18next JSON, Fluent, Java properties, .NET RESX, Ruby YAML, PHP and Laravel strings, Qt Linguist, CSV, Excel, and Markdown.
- **Add-ons for file chores.** [Built-in add-ons](https://docs.weblate.org/en/latest/admin/addons.html) update PO files from a POT template, generate MO files, squash commits, and run automatic translation.
- **Machine translation and LLMs.** [Integrations](https://docs.weblate.org/en/latest/admin/machine.html) include DeepL, Google, Azure, Amazon, and LibreTranslate, plus OpenAI, Azure OpenAI, Anthropic, Mistral, and Ollama, whose prompts include matching glossary terms and your style settings, alongside Weblate's own translation memory.
- **Quality checks.** [Dozens of checks](https://docs.weblate.org/en/latest/user/checks.html) cover placeholders, missing plural forms, maximum length, ICU MessageFormat syntax, and unchanged translations, and automatic fixups correct whitespace and ellipses.
- **Community translation.** Volunteers can suggest translations and comment, reviewers approve them, and a project can [commit only approved strings](https://docs.weblate.org/en/latest/workflows.html). Screenshots, glossaries, and source references give translators context.

## What Weblate still leaves to your engineers

Here's a Python app using gettext, with a Spanish catalog translated before the last line was added:

```python title="app.py"
import gettext
t = gettext.translation("messages", localedir="locale", languages=["es"])
_ = t.gettext
print(_("Inbox"))
print(_("No messages yet."))  # new copy, added after the last translation round
```

After extracting the POT template, translating only "Inbox" in `locale/es/LC_MESSAGES/messages.po`, and compiling it with Babel 2.17.0, a Spanish reader sees the new line in English:

```text title="Output"
Bandeja de entrada
No messages yet.
```

That line stays in English until a round trip finishes:

1. Wrap the string in `_()` and regenerate the POT template with `xgettext` or `pybabel extract`, then commit it.
2. Weblate picks up the change from a webhook or its next fetch, and its `msgmerge` add-on adds the new entry to each PO file.
3. Translate with volunteers, translators, or configured machine translation, and review the results if you require approval.
4. Weblate commits the changes and pushes them or opens a pull request. Your release process merges them, compiles MO files, and deploys.

Edits to the same files outside Weblate can cause merge conflicts, which [Weblate's docs suggest avoiding](https://docs.weblate.org/en/latest/admin/continuous.html#avoiding-merge-conflicts-by-locking-weblate-while-doing-outside-changes) by locking the component while you change files. And a translator sees each string with its source references and screenshots, not the code that renders it.

Self-hosting is free. Hosted Weblate is priced by hosted strings, which are source strings times the number of languages plus one, and every plan includes unlimited languages, projects, and translators. (See [Weblate hosting](https://weblate.org/en/hosting/), checked October 2026.)

## Weblate vs. General Translation at a glance

| Feature | Weblate | General Translation |
| --- | --- | --- |
| Where strings live | Translation files in your repository, mirrored in Weblate components | In your code inside [`<T>`](/docs/react/reference/components/t), or in the resource files you already have |
| How code connects | Weblate pulls from Git, then pushes commits or opens pull requests | [`npx gt translate`](/docs/cli/reference/commands/translate) in your build, or [Locadex](/docs/platform/locadex/quickstart) pull requests |
| Who translates | Volunteers, your translators, machine translation, or LLMs | AI with context from your code, Glossary, and Custom Prompts, reviewed by your team in the Dashboard |
| Context for each string | Source references, screenshots, glossary, and translation memory | Marked JSX structure with inline libraries; source context in supported catalogs; shared Glossary and Custom Prompts |
| File formats | About 50, including XLIFF, ARB, Fluent, and Java properties | JSON, YAML, PO, Markdown and MDX, iOS and Android strings, and more |
| Hosting | Self-hosted for free, or Hosted Weblate | Hosted platform; open-source libraries and CLI |
| Pricing | Self-hosted free; hosted plans by hosted strings; free Libre plan for public libre projects | [Usage-based translation](https://generaltranslation.com/pricing) |
| License | GPL-3.0-or-later | MIT-licensed JavaScript libraries and CLI |

## Why teams choose General Translation over Weblate

General Translation makes translation part of the release that introduces new copy. Keep gettext and generate PO files in your build, or use the inline libraries to keep source copy directly in components inside [`<T>`](/docs/react/reference/components/t).

- **Faster.** [`npx gt translate`](/docs/cli/reference/commands/translate) produces translations before deployment. For React and Next.js projects, [Locadex](/docs/platform/locadex/quickstart) can prepare the changes as pull requests. Adding a locale in `gt.config.json` starts generation for that language on the next run.
- **Cheaper to run.** General Translation runs the translation service, so your team has no translation server to install, upgrade, or back up. With inline authoring, engineers also stop maintaining a separate source catalog.
- **Higher quality.** Inline translation carries the marked JSX's elements and plural branches with the sentence. For gettext, source comments and `msgctxt` provide meaning alongside each entry. Shared [Context Groups](/docs/platform/dashboard/guides/defining-context-for-translations) apply your Glossary and Custom Prompts, and your team refines the result in the [Dashboard Translation Editor](/docs/platform/dashboard/guides/reviewing-translations).
- **Lower risk.** Your repository holds the translated files and your release process controls when they ship. Keep gettext and standard PO files, or use General Translation's MIT-licensed JavaScript libraries with bundled translations; neither delivery path needs a runtime call to General Translation.

Profound's platform and docs run in 47+ locales on General Translation. (See [production deployments](https://generaltranslation.com/enterprise).)

## When Weblate is the better fit

Choose Weblate for community translation, a fully self-hosted platform, or its extensive catalog-format support. Choose General Translation when you want new product copy translated as part of each release, with code context for inline authoring and a direct CLI path for existing JSON, YAML, PO, or Markdown files.

## Using both on gettext files

General Translation's CLI translates the same gettext files Weblate reads. Point a `pot` entry at your template and map each output to the folder layout Weblate uses:

```json title="gt.config.json"
{
  "defaultLocale": "en",
  "locales": ["es", "fr", "pl"],
  "files": {
    "pot": {
      "include": ["locale/messages.pot"],
      "transformationFormat": "PO",
      "transform": {
        "match": "locale/messages\\.pot",
        "replace": "locale/{locale}/LC_MESSAGES/messages.po"
      }
    }
  }
}
```

With `gt` 2.26.5, this config maps `locale/messages.pot` to `locale/es/LC_MESSAGES/messages.po` and the same path for each locale. For plural entries, General Translation writes the target language's `Plural-Forms` header and fills each `msgstr[n]` form. Give each language one owner, for example General Translation for languages your community doesn't cover and Weblate's volunteers for the rest, so the two don't edit the same file. For gettext folder names with underscores, such as `pt_BR`, add a [`customMapping`](/docs/cli/reference/config#custom-mapping) entry that maps them to the standard `pt-BR`. (See [PO / POT](/docs/cli/reference/formats/po-pot-files).)

## Is General Translation an alternative to Weblate?

Yes. General Translation combines translation generation, shared product terminology, and Dashboard review with your release process. You can keep the gettext files shown above and switch how their translations are produced, without replacing the application's gettext calls.

## Key takeaways

- Weblate is a strong copyleft platform for open-source and community translation, with Git-based continuous localization, free self-hosting, and about 50 file formats.
- Its translation workflow centers on repository catalogs, contributors, and Git synchronization.
- General Translation generates translations before deployment. You can retain gettext and standard PO files, or adopt inline authoring for code context without a separate source catalog.

## Related questions

- [Why use General Translation instead of a TMS (Smartling, Lokalise, Phrase, Crowdin, or Transifex)?](https://generaltranslation.com/en-US/kb/general-translation-vs-tms.mdx): A translation management system (TMS) such as Smartling, Lokalise, Phrase, Crowdin, or Transifex coordinates translators, but engineers still extract strings, send them out, wait for translations, and wire them back into the product. General Translation translates content in your code with its context, ships every language with each release, and runs on open-source libraries with no lock-in.
- [General Translation vs. GNU gettext: do you need both?](https://generaltranslation.com/en-US/kb/general-translation-vs-gettext.mdx): Keep GNU gettext for extraction and rendering, and add General Translation to generate and maintain the PO files. General Translation carries translator notes and message context into generation, applies shared terminology, and gives reviewers a Dashboard editor. Your existing gettext calls and compiled catalogs stay in place.
- [General Translation vs. Tolgee: which should you use?](https://generaltranslation.com/en-US/kb/general-translation-vs-tolgee.mdx): Tolgee combines keyed messages, in-context editing, and AI translation in a self-hostable platform. General Translation keeps readable copy directly in your components and generates translations from the marked JSX, so you can ship new copy in every language without maintaining message keys.
- [General Translation vs. Django's translation framework: do you need both?](https://generaltranslation.com/en-US/kb/general-translation-vs-django-i18n.mdx): Use Django's translation framework and General Translation together. Django handles message extraction, language selection, and rendering. General Translation fills its PO files, including plural forms, with your product terminology and Dashboard review. Your templates and URL patterns stay the same while translations update with your code.
- [What is the best localization software for developers?](https://generaltranslation.com/en-US/kb/best-localization-software.mdx): Look for one system that covers the whole pipeline, from the i18n library in your code to translation and delivery, instead of stitching together a separate library, translation management system, and translation vendor.

## Previous and next questions

- Previous question: [General Translation vs. vue-i18n: which should you use?](https://generaltranslation.com/en-US/kb/general-translation-vs-vue-i18n.mdx)
- Next question: [next-intl vs gt-next: which should you use for Next.js?](https://generaltranslation.com/en-US/kb/next-intl-vs-gt-next.mdx)

## Sitemap

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