A glossary isn't a nice-to-have. It's a contract between your product team and your linguists. It says: "This term means this, always, in every language." When the glossary is wrong or out of date, the translations are wrong in exactly the same way — times forty.

The compound error problem

When someone on your team changes "workspace" to "project" in the English UI but doesn't update the glossary, here's what happens:

One unreviewed change. Forty inconsistencies. And support tickets in languages your team can't read.

What a functioning glossary looks like

A glossary that actually prevents this has four properties:

  1. Source term + definition: Not just the English word, but what it means in your product context. "Workspace" is ambiguous — "the container where a user's projects, files, and settings are stored" is not.
  2. Approved translations per language: The linguist doesn't guess — they see the pre-approved term and use it.
  3. Change log: When a term changes, the glossary records who changed it, when, and why. This creates accountability.
  4. Review gate: No glossary change goes live without review by the lead linguist in at least the top-5 volume languages.

How we manage glossaries

At Mavy EduSolutions, every project starts with a glossary review — or a glossary build, if one doesn't exist. We extract key terms from your source content, define them in context, and get sign-off from your product team before the first string is translated.

When terms change mid-project, we flag the change, propagate it across all active languages, and send you a diff report showing every string that was updated.


Need help building or auditing your glossary? Start a project — we'll extract terms from your existing content and build a glossary that works across all your target languages.