A trilingual data estate does not need three catalogs. It needs one catalog with an authoritative language declared per business term, the other two maintained as approved translations, and a search layer that resolves all three plus their transliterations to the same asset. Everything else — duplicated glossaries, per-language catalogs, translation projects — produces drift.

The problem is specific to organisations like the ones in this market, and the standard governance frameworks are silent on it.

Why does a trilingual estate break a catalog?

Because a data catalog's core promise is that one concept has one entry. Three languages break that promise in four places at once.

Business terms exist three times. "Active customer" was defined in Azerbaijani for a regulatory process, in English during a vendor implementation, and in Russian in the documentation of a system installed fifteen years ago. All three are plausible; none is marked as the one that governs. Reports built from different sources diverge, and nobody notices until reconciliation.

Technical metadata is mixed within a single schema. A table named musteri_hesab sits next to CLIENT_ACCOUNT and next to a legacy table whose columns are transliterated Russian. This is not disorder — it is the archaeology of an institution that has been running systems since before the language and script environment settled.

Script variation multiplies the problem. Azerbaijani in Latin script is the standard, but legacy documentation and older systems carry Cyrillic-era conventions, and users type without diacritics half the time. Müştəri, Musteri and Mushteri are one word to a person and three tokens to a search index.

Ownership fragments by language. The person who approves the Azerbaijani definition is frequently not the person who maintains the English one, so the two are governed by different people with no mechanism to keep them consistent.

The cumulative effect is a catalog where search returns nothing for a term the organisation uses daily, which is the fastest way to lose users — as covered in common data governance challenges, a catalog that fails a user twice does not get a third attempt.

What is the authoritative-language rule?

The rule that resolves most of this: every business term has exactly one authoritative language, and the other two entries are marked as translations of it.

Which language is authoritative depends on the domain, and the choice should be made deliberately per domain rather than uniformly:

Regulatory and legal terms — authoritative in Azerbaijani. The requirement is written in Azerbaijani, the supervisory conversation happens in Azerbaijani, and a translated definition that drifts from the statutory language creates a compliance exposure rather than an inconvenience.

Technical platform terms — authoritative in English. Lakehouse, data lineage, orchestration, partition, connector. Practitioners in this market use the English terms in speech and in search, and translating them produces entries nobody looks for. This is also why the technical vocabulary in this article stays in English.

Domain and product terms — authoritative in whichever language the business actually operates in. Usually Azerbaijani for retail-facing concepts; sometimes English in institutions with international ownership; occasionally Russian in older operational domains where the working vocabulary never changed.

The mechanism is what matters. The authoritative entry carries the approver and the date; translations carry a reference to it and a translation approver. When the authoritative definition changes, the translations are flagged as stale rather than silently diverging. That flagging is the whole point — a translation that cannot go stale is a translation nobody is maintaining.

Ownership follows the same rule: the steward who owns the term owns the authoritative version and approves the translations. Splitting ownership per language is the structural mistake that guarantees drift.

How should the glossary be structured?

Three practical decisions, and they compound.

One term, three labels — not three terms. The glossary entry is a single object with a label per language. If the catalog models it as three linked entries, they will be edited independently and diverge. This is a modelling decision made at configuration time and expensive to change later.

Synonym rings, populated generously. Every term needs its alternates registered: the three language labels, common abbreviations, the transliterated forms, the internal jargon, and the names of the columns that implement it. A user searching NPL, qeyri-işlək kredit, non-performing loan or NPL_FLAG should reach the same entry. Synonym rings are cheap to populate and are the single highest-return configuration task in a trilingual deployment.

Definitions written natively, not translated. A machine-translated definition reads as machine-translated to a native speaker and quietly loses precision on exactly the terms that matter — regulatory concepts where a word choice carries legal weight. Have the steward write it, or have a domain speaker write it and the steward approve it.

How do you make search work across three languages?

This is where trilingual catalogs succeed or fail in practice, and it is a configuration problem with known answers.

Diacritic-insensitive matching. Users type musteri and mean müştəri. The index must fold ə/e, ü/u, ö/o, ş/s, ç/c, ğ/g, ı/i for matching purposes while preserving the correct form for display. Without this, roughly half of real user queries miss.

Transliteration mapping for Cyrillic. Legacy assets and older documentation carry Cyrillic strings. Mapping them to Latin forms at index time makes them findable by users who no longer type Cyrillic.

Cross-language term expansion. A query in one language should match assets described in another, via the synonym ring. This is the feature that makes one catalog viable for a trilingual organisation, and it is worth testing explicitly during a proof of concept rather than assuming it.

Measure it with real queries. Take fifty terms people actually search for, in all three languages, and check the results. This is a half-day exercise that predicts adoption better than any feature comparison. It is also the concrete test to run when evaluating platforms — the questions that separate them are in OvalEdge vs Collibra vs Alation, and multilingual search behaviour belongs in that evaluation.

What about technical metadata in mixed languages?

Technical metadata — table and column names — cannot be normalised, and should not be. Renaming production tables to satisfy a catalog is the wrong trade.

The catalog's job is to bridge, not to fix. Three mechanisms do the work:

Business-term linkage. The column musteri_hesab.qaliq is linked to the glossary term for balance. Now a user searching for balance in any language finds the column, regardless of what it is named.

Descriptions in the authoritative language plus translations. The physical name stays; the human-readable description is governed.

Naming standards applied forward only. New assets follow a documented convention — usually English for new platform work, since that is where the tooling and documentation live. Existing assets are left alone and bridged through the glossary. Retroactive renaming projects consume quarters and break lineage.

A pragmatic detail from implementations: crawling picks up whatever comment or description fields the source system already has, and in older systems those are frequently populated in Russian by whoever built them. That content is worth preserving and indexing rather than discarding — it is often the only surviving documentation of what a column means. OvalEdge ingests source-level descriptions during the crawl, which turns fifteen years of scattered comments into searchable metadata without a documentation project.

How does this affect AI retrieval?

The trilingual problem becomes sharper the moment an AI assistant is put over the estate, in a way worth planning for.

A query in one language must retrieve documents in another. A user asks in Azerbaijani; the authoritative policy document is in English; the operational procedure is in Russian. If retrieval is purely lexical, the user gets nothing and concludes the system does not work. Embedding-based retrieval handles cross-language matching considerably better than keyword search, but the quality varies by language, and Azerbaijani is far less represented in general-purpose embedding models than English or Russian.

Glossary terms improve retrieval materially. Feeding the synonym rings into the retrieval layer as query expansion is a cheap and effective intervention: the user's Azerbaijani term expands to its English and Russian equivalents before retrieval runs. This is one of the concrete ways a governed catalog improves an AI system rather than merely constraining it.

Answer language should follow question language. And the source citation should name the document in its original language, so a user can verify. Answering in Azerbaijani from an English source is correct behaviour; hiding that the source was English is not.

The broader relationship between context quality and enterprise AI results is developed in why context matters in enterprise AI, and the language dimension is the part most often discovered after the pilot disappoints.

What does implementation look like?

Trilingual configuration adds roughly two weeks to a catalog implementation, and it is worth scheduling explicitly rather than absorbing.

During discovery, inventory the language situation: which systems carry which language in their metadata, where Cyrillic remains, which domains operate in which language day to day.

During configuration, set up diacritic folding, transliteration mapping and the synonym ring model before loading the glossary, because retrofitting the model after terms exist means re-entering them.

During the glossary phase, assign authoritative language per domain in writing, and have stewards write the authoritative definitions natively.

Before go-live, run the fifty-query search test in all three languages and fix what misses.

In the operating cadence, add one item: when an authoritative definition changes, its translations are flagged and re-approved within the same cycle. Without this step the model degrades to three independent glossaries within a year, which is the state it was designed to prevent.

Key points

  • One catalog, one term object with three labels — never three linked entries, which drift.
  • Declare an authoritative language per domain: Azerbaijani for regulatory terms, English for technical platform terms, the operating language for business domains.
  • Translations reference the authoritative entry and are flagged stale when it changes. A translation that cannot go stale is unmaintained.
  • Synonym rings covering all three languages, abbreviations, transliterations and implementing column names are the highest-return configuration task.
  • Search needs diacritic folding, Cyrillic transliteration and cross-language expansion. Test with fifty real queries before go-live.
  • Do not rename existing technical assets. Bridge them through glossary linkage and apply naming standards forward only.
  • For AI retrieval, expand queries through the glossary synonym rings and cite sources in their original language.

Yukon Labs configures OvalEdge for trilingual estates as part of the standard implementation, including search tuning and the authoritative-language model. For the wider programme context, see data governance in Azerbaijan, and for where this sits in overall programme maturity, the data governance maturity model.