vNext
0 stars
0 members
Dashboard

Get started

  • Welcome
  • Documentation
  • Pricing
    Soon

Research

  • Playground
    Soon
  • Languages
  • LLM Models

Developer Tools

  • Connect Your Engine
  • I18n MCP
  • CLI
  • CI/CD
  • Compiler
    Beta

Lingo.dev

  • How it works
  • API
  • MCP

Localization Engine

  • Brand Voices
  • Instructions
  • Glossaries
  • LLM Models

Quality

  • Reports
  • Scorers
  • Playground

Admin

  • API Keys
  • Team

Glossaries#

A glossary gives the localization engine exact control over specific terms — either enforcing a precise translation or preventing translation entirely. Glossary rules take precedence over the model's own judgment, so the engine applies them consistently across every request.


How it works#

Each glossary item belongs to a localization engine and matches on a source locale and target locale pair (or * for any locale). When the engine processes a translation request, it retrieves relevant glossary items using semantic search — matching the meaning of the input text against stored terms, not just exact string matches.

FieldDescription
Source localeThe locale of the source text, or * for any source
Target localeThe locale of the target text, or * for any target
Source textThe term in the source language
Target textThe required translation (or the same term, for non-translatables)
Typecustom_translation or non_translatable
HintOptional context to disambiguate the term (e.g., "noun, the product feature")

Glossary types#

Custom translations#

Force a specific translation for a term. The engine will always use your translation instead of the model's.

Source textTarget textSource localeTarget locale
DeployBereitstellenende
911112ende
workspaceespace de travailenfr

Use custom translations for:

  • Product terminology with established translations
  • Cultural adaptations (emergency numbers, measurement units)
  • Terms where the model consistently picks the wrong synonym

Non-translatables#

Prevent a term from being translated. The engine keeps the source text as-is.

Source textTarget textType
Lingo.devLingo.devnon_translatable
OAuthOAuthnon_translatable
GraphQLGraphQLnon_translatable

Use non-translatables for:

  • Brand names and product names
  • Technical protocols and standards
  • Proper nouns that should remain in the source language

Semantic matching#

Glossary items are matched by meaning, not exact string comparison. When the engine receives a translation request, it generates embeddings for the input text and finds glossary items with semantically similar source terms.

This means a glossary entry for "Deploy" will also match "Deploying", "deployment", and "deploy your application" — without needing separate entries for each variation.

Hint field

Use the hint field to disambiguate terms with multiple meanings. For example, a glossary entry for "bank" with hint "financial institution" won't match "river bank" in the input text.


Wildcard locales#

Set source or target locale to * to apply a glossary item across all locale pairs.

Common patterns:

Source textSource localeTarget localeUse case
Lingo.dev**Never translate the brand name in any language
APIen*Keep "API" untranslated across all target locales
DeployendeUse specific German translation for this English term

Wildcard items and locale-specific items combine — they don't override each other.


Glossary vs. instructions vs. brand voices#

Each serves a distinct purpose in the engine's configuration:

GlossaryInstructionBrand Voice
ControlsIndividual termsLinguistic rulesOverall tone and style
GranularityPer-termPer-rulePer-locale
MatchingSemantic (by meaning)All included for localeAll included for locale
PrecedenceHighest — overrides model judgmentMedium — guides the modelLowest — sets context
Example"Deploy" → "Bereitstellen""Abbreviate Straße to Str.""Use informal du, technical tone"

Rule precedence

Glossary terms take the highest precedence in the engine's rule hierarchy. If a glossary item conflicts with an instruction, the glossary wins. Design instructions to complement the glossary, not duplicate it.


Using glossaries with the API#

Glossary items are applied automatically when you call the localize endpoint. The engine retrieves semantically relevant items for the source and target locale pair and includes them in the prompt.

No additional parameters are needed — the engine handles retrieval and injection.


Managing glossaries via MCP#

If you use the Lingo.dev MCP server, your AI coding assistant can manage glossary items directly:

text
"Add a glossary entry: translate 'workspace' to 'espace de travail'
for English to French."
text
"Mark 'GraphQL' as non-translatable for all locales."

Next Steps#

Brand Voices
Define overall tone and formality per locale
Instructions
Add linguistic rules for specific locale pairs
Scorers
Monitor glossary compliance automatically
API Reference
Integrate the localization API into your workflow