Editing Translations in a Database, Not Files: How Weblate's Component Model Works

Multiple file formats, the same strings, and translators stepping on each other's commits is a common pain point for localization. Weblate's practical answer is to stop editing files directly. Work is organized into projects and components, each component maps to one repository and file mask, and on import Weblate parses supported formats into an internal translation unit model stored in the database. Editing happens against that model, and files are regenerated on commit.

Components isolate format, memory and access

A Weblate project groups related components. A component is the unit of configuration: repository URL, branch, file mask, file format, translation memory scope, access control and VCS settings. That isolation means a .po component, a JSON component and an Android XML component can live in the same project without interfering.

Per-component settings are where format-agnostic workflows become real. The file mask tells Weblate which source and translation files to pull. The format selection drives the parser used on import and the renderer used on export. Translation memory can be limited to the component, shared with the project, or extended to a shared memory. Quality checks and glossary bindings are also scoped per component.

Import, normalize, edit, render

On pull Weblate parses each supported format into a normalized unit with source string, target string, context, placeholders and metadata. The database becomes the source of truth for editing. This decouples concurrent edits from file storage and lets Weblate present a uniform editor regardless of whether the original is gettext .po, JSON, YAML, XML or others.

When a change is saved, Weblate updates the database unit and runs configured QA checks on that unit. Checks cover placeholder consistency, maximum length, forbidden words and similar rules. Severity is configurable per component: warn translators or block commit.

On commit Weblate renders the normalized units back to the component's file format, respecting encoding, line endings and format-specific conventions, then pushes to the VCS. Because rendering is deferred, Weblate can merge parallel edits in the database before a single file write.

Worked example: gettext .po with memory, glossary and suggestions

Component configuration in the admin UI typically includes:

• Repository URL and branch for the source repository
• File mask such as locale/*/LC_MESSAGES/messages.po
• File format set to Gettext PO
• Quality checks enabled for Placeholder consistency and End of line
• Translation memory set to project and shared
• Glossary linked for the language pair
• Machine translation provider configured if desired

In the translation editor for that component, suggestions are assembled from project translation memory, shared memory, glossary matches and machine translation. A translator sees a unified list and can accept or adapt a suggestion before confirming. The suggestion sources are visible in the editor so you can verify which memory contributed.

To check the setup, open Components in the Weblate admin UI and confirm the file mask, repository URL and enabled file format for the component. Open the component's settings for Quality checks and Translation memory to verify which checks are active and how memory sharing is configured. In the editor compare suggestion sources to confirm contributions from translation memory, glossary and machine translation.

Trade-off and limitation

Database-centric storage simplifies collaboration and history tracking, but it adds operational complexity. Very large repositories increase database size and import time. Encoding, line endings and format-specific quirks must be handled correctly on render, otherwise VCS diffs become noisy. Merge conflicts can still occur on export and VCS push if the upstream branch moved since the last pull, and misconfigured branches or permissions can cause push failures or data loss on commit.

File format support and QA defaults are version-sensitive. Machine translation and external suggestion providers are external dependencies with their own limits, costs and availability. Assume correct VCS configuration before relying on automatic commits.

Actionable closing

If you are evaluating Weblate, start with one component and a small sample file. Observe import normalization and export rendering, then enable a focused set of QA checks and a glossary. Verify suggestion composition in the editor and confirm that commits render cleanly back to the repository. Keep component boundaries tight, review per-component QA severity, and monitor VCS push results for merge conflicts.