Building & Cloud-Managing Technical Glossaries for Arabic Localization

Workshop: Localization for Web 3.0 and AI Applications · Article 4 of 4

Note on this article: The Arabic version — accessible via the orange button at the bottom of the page — is written for Arabic translators and terminology managers building and maintaining glossaries themselves. This English version addresses the localization manager or product owner responsible for commissioning, governing, and scaling the terminology infrastructure across a product or organization.

In Article 1 we built the initial term register — the foundation that makes Arabic localization consistent before a single string is translated. In Article 2 we applied it to the specific constraints of UI localization. In Article 3 we tested whether it actually worked in the live product environment.

This final article addresses the question every localization team faces after the first project: how do we preserve what we built?

A termbase created for one project and then left untouched between engagements is not an asset — it is a deferred liability. In every subsequent project your team will re-debate whether «Gateway» translates as «بوابة» or «مدخل», whether «Node» becomes «عقدة» or «نقطة», whether the «Wallet» in a blockchain context means something different from «Wallet» in a payments context. Decisions made once will be made again, possibly by a different translator arriving at a different answer.

A living glossary — updated, cloud-managed, distributed to the team — converts individual knowledge into institutional memory.

Dead Glossary vs. Living Glossary

Most termbases produced by localization teams are dead from day one. Not because they are wrong — but because they are designed for single use rather than for growth.

A dead glossary is an Excel file built at project kickoff, sent to the translator, used during translation, uploaded to a shared folder, and never opened again. When the next project arrives, a new copy is created — or the process starts from scratch because no one remembers where the previous version was saved.

A living glossary is a system, not a file. It is updated after every project and with every new term, accessible to all team members in real time, connected directly to translation tools so that approved terms surface automatically when the translator encounters the source term, and it documents decisions rather than just terms — preserving not only that we chose «بوابة» for «Gateway» but why, and in what context that choice holds and where it does not.

A good glossary does not just answer “what is the correct term?” — it answers “why is it correct in this specific context, and what are its limits?”

What a Professional Termbase Entry Actually Contains

A simple entry — «Blockchain = سلسلة الكتل» — is insufficient for professional use. A professional termbase entry contains nine fields:

1. Source term: The English word or phrase in its most common form in technical documentation. Normalize to the form most likely to appear in source strings.

2. Approved target term: The Arabic term selected for use in this product or client context.

3. Contextual definition: One or two sentences defining the term as it is used in this product specifically — not a dictionary definition. «In this product, Wallet refers to the user’s cryptocurrency holdings account, not to traditional payment methods.»

4. Usage example: A sentence from the actual product — UI copy or documentation — showing the term in context. If no example exists yet, create a representative one.

5. Forbidden alternatives: Other Arabic terms that might seem reasonable but have been explicitly rejected, with reasons. «Do not use ‘المحفظة الإلكترونية’ — this creates confusion with traditional digital payment wallets like Apple Pay.» This is the most consistently underpopulated field in most termbases, and the most valuable.

6. Domain: A classification tag that enables filtering — blockchain, UI, legal, financial, general. Products that span multiple domains need this to surface only the relevant terms for a given translation task.

7. Stability level: Stable / Under review / Provisional. A provisional term means the decision is not final and requires review before the string ships. This field prevents provisional terms from hardening by accident.

8. Last updated / Approved by: Accountability and traceability. When a term decision is challenged — and it will be — knowing who approved it and when determines whether to revisit the decision or defend it.

9. Notes: A free-text field for any additional context — a discussion held with the client, a reference consulted, a related term to watch for consistency, a market-specific consideration.

Tooling: From Spreadsheet to Terminology Management

A spectrum of tools serves glossary building and management at different scales. Choosing the right level depends on team size, project frequency, and budget:

Level 1 — Structured spreadsheet (Google Sheets / Excel): The simplest and most widely used option. Works well for small teams and solo translators. Key limitations: no integration with translation tools, manual search, no version control when multiple people edit simultaneously. Partial mitigation: use Google Sheets with strict editing conventions — no one modifies an approved entry without leaving a comment explaining why.

Level 2 — SDL MultiTerm or equivalent dedicated TM software: The industry standard for mid-sized localization teams. Integrates with SDL Trados, memoQ, and other major CAT tools — the approved term surfaces automatically for the translator when they encounter the source term. Supports hierarchical term relationships (primary term, synonyms, variants), domain and context filtering, and export to standard TBX and CSV formats for portability.

Level 3 — Cloud TMS platforms (Phrase, Lokalise, Crowdin) with terminology modules: Full-stack cloud platforms that integrate terminology management with translation memory and workflow management in a single system. Every translated sentence enriches the memory; every approved term alerts the translator automatically. Best suited to larger teams running multiple concurrent products or language pairs.

Level 4 — Notion or Confluence with a custom terminology database: A hybrid option for teams already using these platforms for product documentation. Allows linking a term directly to the design decisions and product specifications that motivated it. Less integrated with translation tooling but more flexible in data structure and better for cross-functional visibility.

What Cloud Management Actually Means

“Cloud-managed glossary” is not just a file stored on Google Drive. It is three distinct properties working together:

Simultaneous access: Every team member — the translator in Cairo, the reviewer in Dubai, the project manager in Riyadh — sees the same version of the glossary at the same time. No multiple versions, no “send me the latest copy,” no lost updates between email attachments.

Real-time updates with change tracking: When a new term is added or an existing decision is revised, the whole team sees the change immediately — with timestamp, author, and reason recorded. No decision is made silently. This is the property that converts a shared file into a governance instrument.

Tool integration: A living glossary that does not feed translation tools directly is half a solution. Translators should not have to manually consult a glossary for every sentence — the tool should surface the approved term automatically when the source term appears. Without this integration, adoption degrades within weeks as translators default to memory and habit.

Managing Emerging Terminology: A Practical Protocol

In Web3 and AI domains, new terms appear faster than any static glossary can track. The protocol that keeps a glossary alive in this environment:

Step 1 — Flag as pending: When a translator encounters a source term not in the glossary, they add it with a [PENDING APPROVAL] tag and translate it using their best professional judgment. Work does not stop waiting for approval.

Step 2 — Weekly pending review: The project manager or lead reviewer reviews all terms accumulated in the pending queue during the week. Decision: approve the translator’s choice, modify it, or escalate to the client.

Step 3 — Approve and propagate: An approved term is promoted from [PENDING] to [STABLE] and, if the TMS platform supports it, all files where the provisional version was used are flagged for a targeted review pass. This prevents a temporarily approved term from hardening inconsistently across different translators’ outputs.

Step 4 — Client terminology report: At the end of each major milestone, a report of newly approved terms — with justifications — goes to the client. This converts the client from a passive translation consumer into an active participant in term governance, and significantly reduces surprises at the final review stage.

Translation Memory vs. Termbase: The Distinction That Matters

Newer localization managers sometimes conflate translation memory (TM) and terminology management (termbase). They are different tools that complement each other:

A translation memory stores complete translated sentences. When an identical or similar sentence appears in a new project, the TM proposes the previous translation. Its value is in speed and sentence-level consistency.

A termbase stores individual term decisions. Its value is in ensuring that «Wallet» is always translated as «المحفظة الرقمية» in this product regardless of which sentence it appears in — even a sentence the TM has never seen before.

The common mistake is relying on the TM and neglecting the termbase on the grounds that the memory “covers” terminology implicitly. It covers terms in sentences it has seen before. A new term in a new sentence finds nothing in the TM. The termbase is precisely what fills that gap — and in a fast-moving domain like Web3 or AI, new terms in new sentences are the rule, not the exception.

A Prompt for Post-Project Glossary Maintenance

After each project or milestone, use this prompt to audit your current termbase against newly encountered terms and surface conflicts, gaps, and stability updates systematically:

You are a professional Arabic terminology manager.

I will provide you with:
1. Our current terminology register (as a table: Source | Target | Domain | Notes)
2. A list of new terms encountered in the most recent project

Your tasks:
A. CONFLICT CHECK: Identify any new terms that contradict existing approved terms
   (same source term translated differently, or same Arabic term used for
   different source terms)

B. GAP FILL: For new terms not yet in the register, suggest an Arabic translation
   with justification, marking each as [PROPOSED — PENDING APPROVAL]

C. STABILITY REVIEW: Flag any existing terms marked as [PROVISIONAL] that
   have now appeared in 3 or more projects and may be ready for [STABLE] status

D. OBSOLESCENCE CHECK: Flag any terms that have not appeared in the last
   3 projects — these may need review for continued relevance

Output format:
- Section A: Conflict table (Source | Existing | New | Recommendation)
- Section B: Proposed additions table
- Section C: Stability upgrade candidates
- Section D: Obsolescence candidates

Current register:
[paste your termbase table here]

New terms from recent project:
[paste new term list here]

Run this at the close of every project before archiving the deliverables. The output becomes the agenda for your post-project terminology review meeting — which, if your team has one, should take no more than thirty minutes.

Closing the Workshop: What We Built Together

Across four articles we built a complete Arabic localization system for Web3 and AI products:

• Article 1 established the terminology principles — the three-way choice between phonetic arabization, semantic coinage, and English retention, with a recommended term register for the most frequently encountered terms in the Web3 and AI stack.
• Article 2 applied those principles to the specific constraints of UI localization — space, layout mirroring, numeral decisions, and the cultural register gaps that technical review alone cannot catch.
• Article 3 added the testing layer — verifying that a linguistically correct translation actually functions in its interactive technical environment before it reaches users.
• This article closed the loop with terminology infrastructure — converting the knowledge accumulated in one project into institutional memory that serves every project that follows.

The system is implementable at any scale, with tools ranging from a well-structured spreadsheet to a full TMS platform. What it requires is not budget — it is the organizational discipline to treat terminology decisions as assets worth preserving, and the workflow habits that make preservation automatic rather than optional.

For localization managers who want to understand the commercial dimension of this specialization — how Arabic technical localization is priced, and why value-based pricing rather than per-word rates is the correct model for this category of work — see our article on pricing strategy: (See our article: Value-Based Pricing in the AI Era: Sell Expertise, Not Word Count)

References

1. Wright, S. E. & Budin, G. (1997). Handbook of Terminology Management, Volume 1. John Benjamins Publishing.
2. ISO 30042:2019. Management of Terminology Resources — TermBase eXchange (TBX). International Organization for Standardization.
3. Schmitt, P. A. (1999). Translation and terminology: An insider’s perspective. Terminology, 5(2), 255–278.
4. Lokalise (2024). Terminology Management Best Practices for Modern Localization Teams. lokalise.com
5. Bowker, L. (2002). Computer-Aided Translation Technology: A Practical Introduction. University of Ottawa Press.