Glossary
The glossary is a shared vocabulary for your team. Define the terms that matter to your product, add how they should be translated in each locale, and your translators will see suggestions automatically while they work.
Why use a glossary?
Consistency. "Workspace" should always be "Arbeitsbereich" in German, not "Arbeitsraum" one day and "Bereich" the next. A glossary makes that expectation explicit.
It also speeds up translation. When a translator sees a highlighted term with a suggested rendering, they don't have to think about it or look it up.
Creating terms
In your Hive view, open the Glossary tab. Click New Term and fill in:
- Term: the source-language word or phrase, like "workspace" or "API token"
- Type: Preferred (the correct term to use) or Alternative (an acceptable variant)
- Part of speech: noun, verb, adjective, etc.
- Definition: a short explanation of what the term means in your product's context
- Alternatives: other ways the term might appear in source text
Per-locale renderings
After creating a term, add renderings for each target locale. A rendering is the translation of that term plus an optional note explaining why.
For example:
| Locale | Rendering | Note |
|---|---|---|
| de | Arbeitsbereich | Don't use "Workspace" (the English word), even if it's common |
| fr | espace de travail | Lowercase, always with "de" |
| es | espacio de trabajo |
Team-wide vs hive-scoped terms
By default, terms are scoped to the current Hive. If you have terminology that applies across all your Hives (like your product name or common UI terms), create a team-wide term from the team settings. Team-wide terms appear in all Hives.
Glossary in the editor
When a translator opens a string that contains a glossary term, the term is highlighted in the source text. Hovering over it shows the suggested rendering for the current locale. Clicking applies it.
If a translator submits a translation that contains the wrong rendering for a known term, they'll get a warning. They can override it, but at least they know.