Weblate is a libre, web-based continuous localization system — a Python and Django application that connects translators to version control so translation happens alongside the code it belongs to, and it is used by more than 2,500 libre projects and companies in over 165 countries.

What it is

Weblate lives in the free and open-source software ecosystem, packaged as the Python distribution Weblate on PyPI and licensed under the GPL-3.0 or later. It runs as a web application built on Django, and it stores and exchanges translation work in the gettext family of formats that most libre projects already use. The project's own description frames it as "a web based localization tool with tight version control integration," which is the normal core of it: translations are tied to the repository, not held in a separate silo.

The concrete problem it replaces is offline, file-based translation handled by mailing .po files back and forth, or translation tracked in a spreadsheet or a proprietary localization platform disconnected from the commit history. Weblate puts the translation workflow behind a browser interface while keeping the source of truth in version control, so strings, plural forms and context stay in step with the code. It also exposes a public-facing translation status widget, and the project publishes an SVG badge endpoint for that purpose.

Key capabilities

• Continuous localization tied directly to version control, so translated strings flow back into the repository rather than into a separate store.
• gettext support, the format named explicitly in the project topics alongside i18n, internationalization, l10n and localization.
• Crowdsourcing workflow, listed as a project topic, which lets a project open translation to outside contributors instead of a closed vendor team.
• Web-based translation interface built on Django and Python, the two named implementation facts.
• Public translation status badge, served as SVG from the project's hosted widget endpoint.
• Accessibility commitment documented in ACCESSIBILITY.md, with a dedicated accessibility issue template for reporting problems.
• Documented release and compliance posture, including REUSE licensing status, a CII Best Practices badge, and visual regression coverage.

Who uses it and how

• Libre projects that want community translators contributing through a browser instead of reviewing patch submissions by hand.
• Companies that need their own instance so translation data and contributor accounts stay under their control.
• Projects distributing across many languages, where the 165-country usage figure reflects the breadth of languages typically involved.
• Teams with public translation efforts that want a live status badge embedded in their README or website.
• Organisations that prefer to skip operations entirely and use the hosted service run by the project.

Getting started

Install the Weblate package from PyPI, with full setup instructions at https://docs.weblate.org/en/latest/admin/install.html, or use the Hosted Weblate service at weblate.org to skip installation altogether.

How it compares

The provided facts name no other localization tools or paid products that Weblate replaces, so it stands alone in this registry. The only comparison the facts support is internal: the same codebase is offered as libre software, as an optional professional support arrangement, and as a cloud hosting offering, with the choice left to the adopter.

When to use it — and when not to

A self-hoster must operate a Django application and its supporting services, and while the facts point to https://docs.weblate.org/en/latest/admin/install.html for setup, they name no database, storage or mail configuration detail here, so the operational scope has to be read from that external documentation before committing. Teams that want zero infrastructure work, or that have no version-control-based translation workflow to attach to, should take the hosted option or look elsewhere rather than run their own instance. The repository shows 493 open issues, and the README itself is thin — installation, support and bug reporting all hand off to external pages and the docs directory — so an adopter should expect to work from the documentation site rather than from the repository front page.