Weblate Components: Isolating Workflows Without Forking Projects

Your translation repo is not one workflow. The mobile app ships monolingual JSON, the docs ship bilingual PO, and the website uses gettext with a different review policy. Putting them in one Weblate Project is sensible, but putting them in one Component is not.

The useful takeaway is that Weblate’s component model lets you keep a single project for organizational clarity while giving each set of files its own repository pointer, branch, filemask, format handling, quality checks and access controls.

The problem one project does not solve

A Weblate Project is a container for related translation work, usually named after a product. A Component is the unit of version control integration. It maps a repository URL, a branch name and a filemask to a specific set of translation files.

Without components you end up forking projects for every format difference, or you force a single review rule and machine translation backend onto files that need different treatment. Components avoid that.

What per-component configuration controls

Each component stores its own:

• Repository URL and branch. Different components can point to different repos or branches within the same project.
• Filemask. A glob pattern that selects source and translation files, for example locale/*.json or docs/*.po.
• Source language and file format. Weblate auto-detects common formats and can convert between bilingual and monolingual formats at component level.
• Merge settings and access control. Review requirements, automatic suggestions, and who can push changes can be set per component.

This means a mobile app team can require two reviewers for JSON while documentation uses a single reviewer for PO, without creating separate projects.

Worked example: mobile JSON and docs PO together

Consider a project called Acme Suite with two components.

Component A, mobile-strings, points to the app repository, branch main, filemask apps/mobile/locales/*.json. Format is monolingual JSON with source language en. Machine translation and quality checks are tuned for short UI strings.

Component B, docs, points to the docs repository, branch main, filemask docs/locale/*/LC_MESSAGES/*.po. Format is bilingual PO with source language en. Quality checks emphasize placeholders and terminology, and merge requests are created per component.

Both live under the same Project so users see one product in the dashboard, but each component maintains independent version control integration and workflow settings.

Isolation is a trade-off

Component isolation is intentional. By default translation memory and glossary suggestions are scoped, which can limit cross-component reuse. If you want suggestions from mobile strings to help docs, sharing must be configured explicitly at project level.

Behavior is version-sensitive. Component creation UI, monolingual support and merge request options have evolved across Weblate releases. Per-component permissions and integrations also depend on deployment type and edition, with differences between self-hosted and managed instances. Machine translation backends and quality check plugins available to a component depend on server configuration and licensing, not on the component model alone.

Check the result practically by opening an existing project overview and listing its components to inspect repository, branch, filemask and format settings per component. Review project-level translation memory and glossary settings to confirm sharing scope across components.

Practical next steps

Audit your current projects for files that differ in format, review policy or repository. Group them by workflow need rather than by repo. Create a test component pointing to a sample repository with a known filemask to observe automatic format detection and branch handling before applying changes broadly. Decide explicitly where you want shared memory and where you want isolation, and document that choice at project level.