Arkian logo
Start free
Menu
← All articles

Build a localization glossary in 5 steps for localization teams

Build a localization glossary in 5 steps for localization teams

Editor organizing a multilingual localization glossary

A localization glossary is a controlled list of terms and their approved translations, built to keep product language consistent across every market a team ships to. This guide groups the vocabulary you actually need by role, concepts, workflow, tools, and quality metrics, drawing on definitions from the W3C and ISO, then ends with a build checklist and an example from Arkian showing how glossary terms turn into delivery-ready files.

TL;DR:

  • A localization glossary focuses on recurring, high-value terms and must be locked before the final translation pass to prevent rework.
  • Glossaries differ from translation memories by locking specific terms, not entire segments, to ensure consistency across all languages.
  • Proper scope and review with native speakers are essential to avoid translation errors that a glossary alone cannot catch.
  • Automated tools like Arkian can generate final multilingual files in iOS, Android, and JSON formats, streamlining packaging without repository access.
  • Glossary terms depend on standards such as Unicode and CLDR to ensure correct formatting, encoding, and locale-specific details in each targeted language.
Arkian
Turn Glossary Terms Into Outputs
Arkian automates multilingual scripts, voice outputs, validation, and structured language packages for small localization teams.
Explore Arkian

Table of Contents

1. Core concepts every localization team should know

Three terms get confused constantly, and mixing them up leads to scoping mistakes. Localization (l10n) is the work of adapting a product to a specific market’s language, format, and cultural expectations. Internationalization (i18n) is the technical groundwork that makes that adaptation possible without rewriting code, and globalization (g11n) is the umbrella business strategy that covers both. The W3C’s internationalization glossary frames i18n as the prerequisite: a product built without it usually needs expensive rework before it can be localized at all.

Locale is another term worth pinning down. A locale is not the same as a language: it combines a language code with a region, such as “en” for English generally versus “en-US” for American English or “fr-FR” for French as used in France. These codes come from standards maintained by Unicode’s CLDR project, which is also the authoritative source for how dates, numbers, and currency should format in each locale.

Locale decisions have direct UI consequences:

  • Text expansion: translated strings, especially into German, can need noticeably more horizontal space than the English source, which affects button and label design.
  • Right-to-left layout: languages like Arabic and Hebrew flip the interface direction, not just the text.
  • Date and currency formatting: a date written “03/04” means different things in different locales, and CLDR data resolves that ambiguity.

Getting these three concepts straight before writing a single glossary entry saves rework later, because glossary scope depends on knowing whether you are solving a translation problem or a structural one.

2. Workflow terms: from translation memory to sim-ship

A localization glossary and a translation memory ™ solve different problems, and teams that treat them as interchangeable end up with inconsistent output. A TM stores previously translated sentences or segments so they can be reused when similar text reappears. A glossary, by contrast, locks down how specific terms, like a product name, a button label, or a legal term, must be translated every time they appear, regardless of the surrounding sentence.

Understanding how a term moves from raw text to locked entry helps clarify who touches it and when:

  1. Translators apply glossary terms during first-pass translation and flag any term that seems missing or wrong.
  2. Reviewers check translated text against the glossary for consistency, not just accuracy.
  3. Project managers own the glossary file itself, approving additions and coordinating updates across language teams.
  4. Linguistic quality assurance (LQA) staff run final checks, often in-context, to confirm glossary terms render correctly in the live product.

Workflow style matters too. Batch localization sends a full set of strings for translation at fixed intervals, while continuous localization pushes small updates constantly, often tied to a build pipeline. Sim-ship, short for simultaneous shipment, means a product launches in every target language on the same day as its home-market release, which puts pressure on glossary terms being locked well before the final translation pass, not during it.

3. Tools and file formats that carry glossary terms

Glossary terms eventually have to live inside real files, and the format depends on the platform. Recognizing these formats helps a glossary owner understand what “delivery-ready” actually means for a given project.

  • .strings files hold iOS text resources and are the standard target for Apple app localization.
  • Android XML files serve the same purpose on Android, with a different syntax and its own pluralization rules.
  • JSON is the common format for web apps, back-end services, and many cross-platform tools.
  • APIs and SDKs connect a computer-assisted translation (CAT) tool or translation management system (TMS) directly to a content system, letting translators work in context rather than against raw strings.

Two standards sit underneath all of this. CLDR supplies the locale data, plural rules, and formatting patterns that string files rely on, while Unicode governs character encoding and script support. Encoding mismatches, saving a file in the wrong character set, are a common source of garbled text in non-Latin scripts, and collation errors, sorting text incorrectly for a given language’s alphabet, show up just as often when a team assumes English sort order works everywhere.

4. Quality metrics: match rates, concordance, and MT

Translation memory tools score incoming text against stored segments, and that score changes both cost and effort. A “100% match” means the new segment is identical to one already translated and approved, so it typically needs only a quick check. A “fuzzy match” is a partial match, often expressed as a percentage, and lower fuzzy scores mean more editing work for the translator.

Match rates directly shape project cost. A high volume of 100% matches lowers the effort per word, according to the practical distinctions drawn in research on TM and concordance practices, which also separates concordance search, a way to see how a specific word or phrase was translated in past projects, from a TM suggestion, which proposes a whole segment.

Machine translation followed by human post-editing (MT and PE) is increasingly common for high-volume, lower-visibility content. Automatic metrics like BLEU compare machine output to a reference translation, but BLEU has recognized limits and works best as one signal among several, not a standalone verdict on quality.

Translation memory and quality metrics workflow

6. How to build and maintain a working glossary

Building a glossary is a repeatable process, not a one-time document.

  1. Extract candidate terms from the source product: names, UI labels, recurring nouns, anything that shows up often or carries brand weight.
  2. Filter for terms that need enforcement, since not every word needs a locked translation. A game localization guide recommends scoping glossaries to recurring, brand, and UI-critical terms rather than pre-translating every string.
  3. Review with native speakers and subject experts before locking anything, a step terminology work best practices treat as non-optional.
  4. Lock entries and version the file so every translator works from the same approved list.
  5. Export in formats CAT tools accept and import into the TM or TMS so glossary hits surface automatically during translation.

Governance keeps the glossary useful past launch: assign someone to own change requests, assess the impact of any renamed term across existing strings, and set a review cadence tied to release cycles rather than an arbitrary calendar date.

Pro Tip: Lock your glossary before the final translation pass starts, not during it, or you will pay to re-translate strings that already shipped.

7. How Arkian turns glossary terms into packaged outputs

Once a glossary exists, the harder problem is turning it into files a product can actually ship. Arkian automates that step for small teams that do not want to run a full TMS.

  • Arkian generates localized strings directly in iOS .strings, Android XML, and JSON formats without requiring repository access.
  • Built-in validation and packaging cut down the manual review cycles a team would otherwise spend reconciling glossary terms across files by hand.
  • Arkian’s structured packaging bundles voice, string, and metadata outputs into a single delivery-ready set.
  • The Quiet Harbour collaboration shows this approach applied to a real multilingual product release.

8. Knowing where a glossary’s job ends

A glossary keeps terminology consistent, but it will not catch a mistranslated idiom, a culturally inappropriate image, or a legal disclosure that needs a lawyer’s sign-off in the target market. Those problems call for a style guide, linguistic QA, or legal review, not another glossary entry. Pair the glossary with a translation memory and clear governance, and treat it as one layer of a larger localization process rather than the whole plan.

— Arkian

9. Turning your glossary into shipped, multilingual files

A glossary tells you what terms mean. Getting them into a build still takes packaging, validation, and format conversion, work most small teams underestimate until deadline week.

Arkian

Arkian handles that last stretch without asking for repository access or a TMS license. It automates localization strings into iOS, Android, and JSON formats, generates multilingual voice output from the same source scripts, and produces structured metadata alongside the translated text, then packages everything into a reviewable bundle.

  • Automated string, voice, and metadata production from one approved source.
  • Validated, structured packaging without manual file reconciliation.
  • No repository access or TMS setup required to get started.

Check current plans and pricing to find the option that fits your team’s release schedule.

10. Where to verify these definitions yourself

Sources

A few normative sources settle most terminology disputes before they start.

Treat these as the tiebreaker whenever an internal glossary entry conflicts with common usage.

FAQ

What is a glossary in localization?

A localization glossary is a controlled list of terms paired with their approved translations, used to keep product and content language consistent across every market. It typically covers brand names, UI labels, and recurring terms rather than every word in a project.

What is a glossary in game localization?

In game localization, a glossary focuses on character names, mechanics, and recurring UI text that must stay identical across menus, dialogue, and marketing. Guides on game localization recommend scoping it to high-value, repeated terms rather than pre-translating every line of dialogue.

What does the term localization refer to?

Localization (l10n) refers to adapting a product’s language, formatting, and cultural details for a specific market, going beyond direct translation. The W3C frames it as requiring both linguistic and technical adjustment, not just word-for-word substitution.

What is localization in simple terms?

In simple terms, localization means making a product feel like it was built for a specific place, adjusting language, dates, currency, and layout so nothing feels foreign or mistranslated. It relies on internationalization, the technical setup done earlier, to make that adaptation possible without rebuilding the product.

How do I start building a localization glossary?

Start by extracting recurring terms from your source product, then filter for the ones that need a locked, enforced translation rather than free rendering. Review those terms with native speakers before locking the file, then export it into a format your translation tool or CAT software accepts.