# Weblate: continuous localization wired into your Git history

> Weblate is a GPL-3.0 Django application that turns translation files in a Git repository into a browser-based workflow. It fits teams that already version their strings and want translators to commit through a review queue instead of emailing files.

**WeblateOrg/weblate** — Web based localization tool with tight version control integration.

- Repository: https://github.com/WeblateOrg/weblate
- Website: https://weblate.org/
- Stars: 6,090 · Forks: 1,365
- Language: Python
- License: GPL-3.0
- Published: 2026-08-04 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/weblateorg-weblate

## The problem Weblate targets: translations that drift away from the code

Translation work usually starts in a repository and then leaves it. Strings get exported, edited in a spreadsheet or a proprietary platform, and merged back by hand. The merge is where the work breaks: a source string changes, the translated file still holds the old text, and nobody notices until a user reports a mistranslated button.

Weblate keeps the file in the repository as the source of truth. The README describes it as a "libre software web-based continuous localization system", and the phrase continuous localization is the actual claim: translation is treated as a stream tied to commits, not as a periodic export. The README states the project is used by over 2500 libre projects and companies in more than 165 countries. Those numbers come from the project itself and describe adoption breadth, not quality.

The audience is specific. You are a maintainer or a localization lead with a Git repository that already contains gettext .po files, JSON, or another format the translate-toolkit stack can parse. You have translators who will not clone a repository and run msgmerge. Weblate sits between those two facts.

## How the Git integration actually works

Weblate is a Django application. The repository layout confirms this: manage.py sits at the top level, the application package is weblate/, and pyproject.toml pins a setuptools build backend with translate-toolkit as a build requirement. The setup.py file defines a BuildMo command that compiles .po files into .mo files during the build, which tells you the project treats gettext catalogs as first-class build artifacts.

The data flow is a loop. Weblate holds a working copy of your repository. It parses the translation files into database records so the web UI can present strings, comments and suggestions without touching the files on every page load. When a translator saves a translation, Weblate writes it back into the file format and commits to the repository. Your developers then pull those commits like any other contribution.

That design has a consequence worth stating plainly: Weblate is not a translation memory service that lives beside your code. It is a client of your repository. If the remote is unreachable, the loop stalls. The pyproject.toml dependency groups show the surrounding machinery: celery-types appears in the types group, which points to asynchronous task processing, and selenium plus pytest-django appear in the test group, which indicates the UI is exercised through a real browser in the project's own test suite. The README does not document what happens to queued commits when a remote rejects a push, so treat conflict handling as something to test on your own repository before you invite translators.

## Installing Weblate and translating your first string

The README does not inline installation steps. It points to the setup instructions at https://docs.weblate.org/en/latest/admin/install.html, and the repository ships a rundev.sh script at the top level for a development environment. Because the README gives no command sequence, the safest path for a first real use is the documented installation guide rather than a guessed one.

If you want to see the application before deciding, the README offers the Hosted Weblate service at weblate.org as an alternative to installing it. That is the fastest way to answer whether the UI fits your translators.

For a local checkout, the repository provides a development launcher. The script is present in the top-level listing as rundev.sh; run it from the repository root after cloning:

```bash
./rundev.sh
```

The script expects a Python environment with the project dependencies installed, since the build backend requires setuptools and translate-toolkit. The README does not state which Python version rundev.sh requires, so check the installation guide before running it.

Once an instance is running and a project is connected to a repository, the workflow is: add the component, let Weblate parse the translation files, then open a string and submit a translation. Weblate commits that change back to the repository. Verify the commit landed by checking the repository log, not the web UI alone.

For scripted access, pyproject.toml lists wlc in the docs dependency group. wlc is the Weblate command line client, and the related searches include people looking for the Weblate API. The API exists; the README itself does not document its endpoints, so consult the documentation before writing automation against it.

## Where Weblate is the wrong tool

Weblate assumes a repository. If your translation source is a database, a CMS plugin, or a spreadsheet that a product manager owns, you will spend more time building an export pipeline than translating. The tool is not a general-purpose translation memory that ingests arbitrary content.

It also assumes operational capacity. A Weblate instance is a Django deployment with a database, background workers and a writable checkout of every connected repository. The pyproject.toml dependency groups include celery-types and selenium, and the repository ships a dev-docker/ directory, which indicates the project expects container-based deployment to be part of the story. The README does not describe a single-binary install. If nobody on your team can run a Django service, Hosted Weblate is the realistic option, and the README explicitly presents it as an alternative to installing.

One more boundary: the README states the licence is GPL-3.0. If you modify Weblate and distribute it, the licence terms apply to your distribution. The README does not discuss commercial relicensing or exceptions, so do not assume one exists. The README does mention optional professional support and cloud hosting offerings at https://weblate.org/hosting/, which is a support arrangement, not a licence change.

## Weblate compared with Crowdin and other hosted platforms

The related searches include "Weblate alternative" and "weblate vs crowdin", so the comparison is one people actually make. The difference is architectural, not a feature checklist.

Hosted platforms typically own the translation data. You upload files or connect a repository, and the platform stores strings in its own system; the export back to your repository is a sync step. Weblate inverts that. Your repository is the store, and Weblate is a client that reads and writes it. The README's framing of Weblate as libre software with optional professional support and cloud hosting means you can run the same software yourself, which a proprietary platform does not offer at all.

The trade-off runs both ways. Self-hosting means you own upgrades, backups and the Git remote configuration. A hosted platform removes that work and charges for it. Weblate's answer to the operational burden is Hosted Weblate, described in the README as a service at weblate.org, so the project competes on both sides of that line.

A second difference is format coverage. Translation files are parsed through translate-toolkit, which appears as a pinned build requirement in pyproject.toml. That is the layer that decides which file formats Weblate can round-trip. If your format is not handled there, no amount of UI configuration fixes it.

## Maintenance, release cadence and upgrade cost

The repository is not archived. The last push was on 2026-08-07, and the most recent release listed is weblate-2026.8.1 on the same date, with weblate-2026.8 on 2026-08-03 and weblate-2026.7.1 on 2026-07-10. The version scheme is calendar-based, and the gap between those releases is weeks, not quarters. That cadence is the upgrade cost: you are tracking a moving target, and each release can touch the database schema of a Django application.

The dependency pins in pyproject.toml reinforce this. Sphinx, mypy, pytest, Django stubs and translate-toolkit all carry exact versions, and the build backend pins setuptools==84.0.0 and translate-toolkit==3.20.0. Exact pinning makes builds reproducible and makes upgrades deliberate work rather than an automatic pull.

On licence: the README states GPL-3.0, and the repository carries a LICENSE file plus a LICENSES/ directory and REUSE.toml, which is the REUSE compliance tooling for per-file licence metadata. Running Weblate as a service for your own team does not trigger distribution obligations in the way that shipping a modified binary does. This is a description of what the files say, not legal advice; get your own counsel for a redistribution question.

Because the README does not document rollback, verify your database backup and restore path before upgrading across a release boundary. That is the one operational detail the project's own front page leaves to the installation guide.

## Conclusion

Adopt Weblate if your source strings already live in a Git repository and you want contributors to translate through a web UI that commits back to that same repository. Skip it if you only need to translate a handful of strings once, or if you cannot give it a persistent Git remote and a database, because the whole design is built around a long-lived checkout. Before committing, verify three things in the installation guide at docs.weblate.org: which database backend the version you install expects, whether your Git remote is reachable over the protocol you plan to use, and how you will keep the GPL-3.0 source obligation satisfied if you modify and redistribute the code.

## FAQ

### What is Weblate used for?

Weblate is a web-based continuous localization system: it holds a checkout of your repository, presents translatable strings in a browser interface, and commits translations back to the same repository. It is used by projects that keep their translation files under version control.

### How to install Weblate?

The README does not inline the steps; it links to the setup instructions at https://docs.weblate.org/en/latest/admin/install.html. The repository also ships a rundev.sh script at the top level for running a development instance.

### How to use Weblate?

Connect a component to a Git repository, let Weblate parse the translation files, then open a string and submit a translation. Weblate writes the change back into the file format and commits it to the repository, so you confirm the result in the repository log.

### Is Weblate free?

The README describes Weblate as libre software under GPL-3.0, so you can install and run it yourself. The project also offers optional professional support and cloud hosting, listed at https://weblate.org/hosting/.

### What is Hosted Weblate?

The README presents Hosted Weblate at weblate.org as an alternative to installing the software yourself. It is the same project offered as a service rather than a local deployment.

## Sources

- [Official documentation](https://weblate.org/)
- [Official README](https://github.com/WeblateOrg/weblate#readme)
- [Project repository](https://github.com/WeblateOrg/weblate)
- [Release notes](https://github.com/WeblateOrg/weblate/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/weblateorg-weblate