Weblate: Continuous Localization That Lives in Your Git Repository

Translation workflows break in predictable ways. Developers export strings to a spreadsheet, translators fill it in, someone re-imports it three sprints later, half the new strings are missing, and the German locale is two versions behind. Every release is a manual reconciliation.

Weblate solves this by treating translation as a continuous process integrated with version control. Translators work in a browser, Weblate commits their work back to your Git repository automatically, and you can see translation status across every language at a glance — like CI status on a branch. The spreadsheet disappears. Translation becomes part of the normal development workflow.

What Weblate is

Weblate is an open source web-based localization platform with tight version control integration. Written in Python and Django, licensed GPLv3+. Current release: 2026.6 (June 2026, new calendar versioning). Previously v5.15.2 (January 2026). Around 4,600+ GitHub stars, used by 2,500+ projects across 165+ countries — including LibreOffice, phpMyAdmin, Fedora, Debian, F-Droid, Kodi, and Tor.

Weblate s.r.o. — the company behind it — was incorporated in Czechia in October 2024, giving the project commercial backing while keeping the codebase fully open source.

Continuous localization model

Traditional localization is batch-based: export, translate, import, repeat. Weblate's model is continuous: translations live in your repository alongside the code, synchronized automatically in both directions.

When a developer adds a string and pushes to Git, Weblate pulls the change and flags it as needing translation. When a translator submits in the web UI, Weblate commits directly to a branch — or opens a pull request. The repository is always the source of truth. Translators never need Git access. Translation completeness becomes a measurable quality gate in CI.

Version control integration

Supported VCS: Git, GitHub (pull requests), GitLab (merge requests), Gitea/Forgejo, Gerrit, Subversion, Bitbucket. The typical GitHub workflow: Weblate monitors your main branch, creates a weblate translation branch, commits translations there, and opens a PR against main when ready. Your normal review process applies — the translation PR goes through CI like any other change.

File format support

Weblate supports virtually every localization format in practical use:

• gettext PO/POT — standard for open source and Python/Django apps
• JSON variants — flat, nested, i18next, go-i18n, WebExtension
• XLIFF — enterprise XML format
• Android strings.xml and iOS .strings / .stringsdict
• Java properties, PHP arrays, Ruby YAML, Qt TS
• CSV, INI, Desktop files, AppStream metadata, and more

Translation editor and quality checks

The web editor shows source string, current translation, translation memory matches, and machine translation suggestions side by side. Built-in quality checks flag automatically:

• Missing or extra placeholders (%s, {name})
• Inconsistent translations of the same source string
• Punctuation mismatches, overly long translations, glossary violations
• Unchanged translations (possible copy-paste errors)

Critical checks block saving; warnings allow saving with a flag. Translations are structurally correct before they land in the repository.

Machine translation and AI

MT integrations as suggestion sources: DeepL, Google Translate, Microsoft Translator, LibreTranslate (self-hosted), OpenAI-compatible APIs, MyMemory, Apertium. MT results appear as suggestions — translators review and accept, reject, or edit. For self-hosted instances, configure LibreTranslate or a local LLM to keep all translation data on your infrastructure.

Translation memory and glossary

Translation memory — a database of previously translated string pairs. When a new string resembles something translated before, the memory surfaces it as a suggestion. Particularly valuable when translating new versions where most strings are unchanged.

Glossary — project-level canonical translations for key terms. When a glossary term appears in a source string, the editor highlights it. Violations are flagged as quality check failures, enforcing consistent terminology across all translators.

Docker Compose deployment

Three containers: Weblate, PostgreSQL, and Valkey (Redis-compatible):

services:
  weblate:
    image: weblate/weblate:latest
    restart: unless-stopped
    ports:
      - "80:8080"
    env_file: .env
    volumes:
      - ./weblate-data:/app/data
    depends_on:
      - database
      - cache

  database:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_DB: weblate
      POSTGRES_USER: weblate
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - ./postgres-data:/var/lib/postgresql/data

  cache:
    image: valkey/valkey:8-alpine
    restart: unless-stopped
    volumes:
      - ./valkey-data:/data

Key .env variables: WEBLATE_SITE_DOMAIN, WEBLATE_ADMIN_EMAIL, WEBLATE_ADMIN_PASSWORD, WEBLATE_EMAIL_HOST, POSTGRES_PASSWORD. Put Traefik in front for HTTPS. Minimum: 2 CPU, 2GB RAM — 4GB recommended for active projects.

Projects, components, and Workspaces

A Project is your application. A Component is one translatable resource — typically one file per language. Multiple components per project: UI strings, docs, email templates, each synchronized independently. Workspaces (new in 2026.6) group related projects with shared teams and billing — useful for agencies or organizations managing multiple products.

Weblate vs Crowdin

Crowdin is the leading commercial TMS — polished, hosted, no setup. Priced per source word: 100k source words costs $299/month. Weblate self-hosted: $0 + server, unlimited words, unlimited projects, unlimited users.

Crowdin wins on ease of getting started and for non-technical teams who shouldn't see Git. Weblate wins for developer teams who want Git-native translation, have data residency requirements, or face per-word pricing at scale.

Weblate vs Lokalise

Lokalise has a strong developer experience — CLI, API, CI/CD integration. Priced per user ($120+/month for a small team). Weblate's Git integration achieves similar CI/CD automation self-hosted. For Git-centric teams, Weblate matches Lokalise's key proposition at a fraction of the cost.

Who it's for

Good fit:

• Open source projects — Hosted Weblate is free for libre software
• Dev teams that want translation in the Git workflow: automatic commits, PRs, CI gates
• Organizations with data residency requirements
• High string volume projects where per-word pricing becomes expensive

Not the right fit:

• Non-technical teams with no Git exposure — VCS model adds overhead
• Teams needing deep Figma or CMS integrations — Crowdin/Lokalise cover more
• Small one-time translation projects where setup cost isn't justified

My take

Weblate's core insight — that translation should be continuous, Git-native, and visible as a quality metric — is correct. The spreadsheet-based workflow is a solved problem and Weblate solves it well. The 2,500+ project adoption including Fedora and LibreOffice signals it handles real scale.

The deployment is genuinely straightforward: three Docker containers, environment variables, Traefik for HTTPS. Python/Django is lighter than Rails. The GPLv3 license means you can deploy it for internal use freely — copyleft conditions only apply if you distribute modified Weblate source to others.

For open source projects: use Hosted Weblate, it's free. For commercial teams localizing to multiple languages with volume: self-host and eliminate the per-word bill entirely.