Weblate Automatic Translation: Bootstrap and Maintain Translations Without Overwriting Human Work
How Weblate's Automatic translation add-on works, a safe bootstrap configuration that never overwrites human translations, and the limits teams hit with machine translation at scale.
04 Oct 2025, 11:37 UTC

The fastest safe way to use Weblate's Automatic translation add-on is to restrict it to untranslated strings (filter_type: "todo"), run it in suggestion mode first, and only switch to direct writes once you have inspected a sample of the output. That combination gives you the speed of machine translation or cross-component reuse without clobbering translations your reviewers already approved.
What the add-on actually does
Weblate ships an Automatic translation add-on (weblate.autotranslate.autotranslate). You enable it per component from Manage > Add-ons, and you can also trigger it manually from Manage > Automatic translation in the component UI. It fills in strings using one of two sources:
- Other components in the same Weblate instance — essentially translation-memory reuse of identical or similar source strings you have already translated elsewhere.
- Machine translation services — whatever MT backends the server administrator has configured (for example DeepL, Google Translate, or LibreTranslate).
The add-on runs as a background batch over the component, so on large projects with an external MT service it is bounded by API rate limits and per-request latency, not by Weblate itself.
A worked configuration
A typical bootstrap configuration, entered in the add-on's settings form when you install it on a component:
{
"mode": "translate",
"filter_type": "todo",
"auto_source": "mt",
"component": "",
"engines": [],
"threshold": 80
}
What each choice means in practice:
filter_type: "todo"— only strings that still need work are touched. This is the single most important setting: it guarantees existing human translations are not overwritten.auto_source: "mt"— use machine translation. Set it to reuse existing translations from other components instead if you want terminology-consistent propagation with no external service involved.threshold: 80— a similarity floor used when matching against existing translations; below the threshold, no match is applied.mode: "translate"— results are written directly as translations.
Exact key names and accepted values have changed across Weblate releases, so before relying on this JSON, open the add-on's settings form in your running instance and compare it against the documentation for your installed version.
Direct writes vs. suggestions
The mode choice is a workflow decision, not just a technical one:
| Mode | Behavior | When to use it |
|---|---|---|
| Translate (direct) | Writes results as translations immediately | Internal tools, low-risk languages, or after you have validated output quality |
| Suggestions | Adds results as suggestions awaiting a reviewer | Any project where MT output must be vetted before it ships |
For most teams the right sequence is: run with suggestions first, inspect a sample for placeholder and markup integrity, then either accept in bulk or switch the add-on to direct mode for subsequent runs. Depending on configuration, auto-translated strings may also be marked as needing edit — check what state they land in and make sure it matches your review workflow rather than silently bypassing it.
Two workflows that work well
Bootstrap a new language. Add the language, run the add-on once with filter_type: "todo" and your MT source, then schedule a human review pass. Weblate's quality checks still run on the results, so strings with broken placeholders or formatting get flagged — which is exactly why you run automation before review, not after.
Keep components consistent. Use the other-components source to propagate identical strings across components of the same project. This costs nothing, sends no data off-site, and keeps terminology uniform. Re-run it with filter_type: "todo" whenever new source strings land, so only the gaps get filled.
Limits and common mistakes
- Overwriting human work. Running without a restrictive filter can replace reviewed translations. Always use
"todo"unless you genuinely intend a full rewrite. - Broken placeholders and markup. MT engines sometimes mangle format specifiers (
%s,{count}) or HTML tags. Keep Weblate's placeholder and markup checks enabled so these surface as failed checks instead of shipping. - Cost and privacy. External MT sends your source strings to a third party and bills per character or request. For proprietary or regulated content this may be disqualifying; the other-components source avoids it entirely.
- Assuming it keeps up automatically. The add-on is best treated as a batch tool: run it at bootstrap, then again only when a meaningful batch of new untranslated strings exists. It is not a substitute for a review workflow.
- Blind trust in quality. MT quality varies enormously by language pair and domain. A short sample review per language is cheaper than a post-release fix.
How to verify it worked
- Pick one small component and one target language as a pilot.
- Run the add-on with
filter_type: "todo", then check the component's translation percentage — it should rise, and previously translated strings should be untouched (spot-check a few you know were human-translated). - Open the failing-checks view for that component and confirm flagged strings are placeholder/markup issues you can triage, not silent corruption.
- If you used an MT service, check the provider's console to confirm the request volume and cost match the component's string count.
If any of these checks fail, adjust the filter, threshold, or mode and re-run — the operation is repeatable precisely because the todo filter makes it idempotent against already-translated strings.
0 replies
A thoughtful contribution can make all the difference. Be the first to share one.