How to Build a Game Localization Glossary Before Translation

Why a glossary matters before translation starts

Game localization breaks down when the same thing gets translated several different ways. A menu label changes between screens. A character title sounds formal in one quest and casual in another. An item name in the store page does not match the name inside the build.

These problems are not always caused by bad translators. They often happen because the team never wrote down the terms that needed to stay consistent.

A game localization glossary, sometimes called a termbase, is a small source of truth for important words and phrases. It tells translators, reviewers, and AI systems how key terms should be handled before thousands of strings start moving through the pipeline.

Start with terms players will notice

Do not try to document every word in the game. Start with the words players will remember, search for, compare, or complain about.

Good first glossary candidates include:

• character names,

• faction names,

• location names,

• item names,

• ability names,

• currencies,

• UI labels,

• difficulty names,

• game mode names,

• genre-specific mechanics,

• terms used in trailers and store pages.

If a term appears in both marketing copy and in-game UI, it belongs in the glossary.

Add context, not just translations

A weak glossary is only a table with source term and target term. That helps, but it does not explain why the term matters.

Each important term should include context:

• where the term appears,

• what the term means in the game,

• whether it is a name, UI label, item, verb, or joke,

• whether it can be translated,

• whether it should stay in English,

• any character limits or UI constraints.

Context prevents literal mistakes. For example, "charge" can mean money, an attack, battery power, or a cooldown state. Translators need to know which one the game means.

Mark terms that should not be translated

Some terms should stay unchanged. This can include proper names, brand names, invented species, control labels, file names, commands, or community terms players already use.

Do not assume reviewers will guess this. Add a clear field:

• translate,

• do not translate,

• transliterate,

• translate only in UI,

• keep English in marketing copy.

This is especially useful when a game has stylized names. A fantasy item, sci-fi faction, or invented resource can look like normal English to an AI system unless you mark it.

Include tone notes for key terms

Games are not just functional software. A term can carry humor, genre, mood, and worldbuilding.

For terms that affect tone, add a short note:

• cute, not childish,

• technical, but readable,

• dark comedy,

• pirate slang,

• cozy and informal,

• formal royal address,

• arcade-style action.

This gives translators permission to adapt the term instead of copying the English shape too closely.

Connect the glossary to real strings

A glossary is easier to trust when it points to examples. Add one or two source strings for high-risk terms.

For example:

• Source term: "Signal"

• Context: resource used to activate train stations

• Example string: "Spend 2 Signal to reopen the north platform."

• Note: not a radio signal, use the approved resource name.

Examples turn abstract terminology into practical guidance.

Keep UI constraints visible

UI terms need special handling. A beautiful translation that does not fit a button is still a problem.

For interface terms, add constraints when you know them:

• maximum character count,

• appears on a button,

• appears in a narrow table column,

• appears beside an icon,

• used as a menu heading,

• reused in tutorial text.

This helps translators choose shorter terms early instead of fixing overflow later.

Decide who owns glossary updates

A glossary is not a one-time document. It changes when design changes, when reviewers find better terms, and when the community starts using different language.

Assign one owner for source terms and one reviewer per target language when possible. The owner does not need to translate every term, but someone must decide which terms are approved.

Without ownership, every reviewer fixes terminology in their own file, and consistency slowly disappears.

Use the glossary with AI translation

AI translation can move faster when the source terms are clear. It can also make confident terminology mistakes if you do not constrain it.

Before generating drafts, provide:

• approved translations,

• do-not-translate terms,

• tone notes,

• short examples,

• context for ambiguous words.

After generation, review the output against the glossary before reading for style. Terminology errors are cheaper to catch first.

Keep the first version small

The best first glossary is not complete. It is useful.

For a small game, start with 50 to 150 terms. That is enough to cover the words most likely to create visible inconsistency. Add more terms during review when you see repeated questions or corrections.

Do not wait for the perfect glossary before translating. Build the first version, use it, and improve it as the project gets real feedback.

Final checklist

Before translation starts, make sure your glossary answers these questions:

• Which names must stay unchanged?

• Which UI terms need short translations?

• Which genre terms have approved wording?

• Which jokes or tone-heavy phrases need notes?

• Which terms appear in both store copy and in-game text?

• Who can approve changes?

If the glossary can answer those questions, it is ready to help the localization process.