Keeping Weblate translations consistent with project glossaries

The problem: the same term, three different translations

You maintain a Weblate project with several components—a web application, its API reference, and a mobile app. Translators working independently render "dashboard" as "panel de control" in one component, "tablero" in another, and leave it untranslated in a third. The product ships with inconsistent terminology, and reviewers catch it late.

What a Weblate project glossary does

A Weblate glossary lives at the project level and applies to every component inside that project. Maintainers add terms, definitions, and example usage. When a translator opens a source string that contains a glossary term, Weblate surfaces the term as a suggestion in the translation editor. Matching is generally case-insensitive.

Glossaries are advisory. Weblate suggests the term but does not block a translation that ignores it, and it does not replace built-in quality checks or human review.

Worked example: add a term and verify the suggestion

1. Open your Weblate project and go to the glossary page. The exact path varies by release, but it is typically found under project settings.
2. Add a term such as dashboard, with a definition like Main control panel view and an example such as Go to the dashboard to review alerts.
3. Save the term.
4. Open the translation editor for any component in the same project.
5. Load a source string containing the word dashboard.
6. Check the editor's suggestion or terminology panel for the glossary entry.

If the term appears, the glossary is active for that project. If it does not, confirm you are viewing a component within the same project and check your Weblate release notes, because glossary UI placement and matching behavior can differ between major versions.

You typically need project maintainer or admin privileges to add glossary terms. Translators usually need only read access to see suggestions. Adding terms changes project state, so test bulk imports or edits on a staging clone before applying them to production translation data.

Limitations and what to pair with glossaries

• Glossary terms are suggestions, not requirements. A translator can override or ignore them.
• Weblate does not automatically block a translation or fail a review when a translation skips a glossary term.
• Bulk import support and supported formats depend on your installed Weblate version.
• Term attributes and editor placement may change between releases.

Pair glossaries with Weblate's quality checks, a reviewer step in the translation workflow, and a documented terminology style guide. Treat the glossary as a memory aid for translators, not a gate.

Closing checklist

• Identify high-impact terms that appear across multiple components.
• Add them to the project glossary with definitions and examples.
• Open a translation editor and confirm the suggestion surfaces.
• Run any bulk changes on staging first.
• Review release notes for your Weblate version before standardizing the workflow.

Glossaries will not enforce consistency by themselves, but they make the right term easier to find—and easier to catch during review.