One Topical Map, Two Languages: Building Multilingual Content Networks
A bilingual topical map is one ontology and one node graph that feeds two document editions — English and Arabic. Every structural decision is made once; every language layer is decided per locale. Two maps translated into each other drift by design.
On this page — 5 sections
Should You Build One Topical Map or Two?
Quick answer
One. Two maps — however faithfully translated — drift in coverage, anchors and merge decisions. One ontology serving both editions makes the drift structurally impossible: a node either exists for both languages or the asymmetry is a logged decision.
The drift is not dramatic; it is administrative. One team approves a node the other never hears about. A merge lands in the English map and the Arabic twin keeps both topics. Anchors rotate differently, so the two link graphs slowly describe two different sites. Within a quarter, the audit is grading two corpora — and neither report describes the actual site.
One ontology closes the gap structurally. The map is decided once — demand scoring, SERP-overlap checks and merge decisions all run against the shared node graph, and each decision is logged — and bilingual scope becomes a build-time property: every node produces two documents, one per language. Coverage asymmetry between languages then becomes structurally impossible; any deliberate asymmetry is a logged decision, not an accident of translation.
What Actually Localizes in Each Edition?
Quick answer
The prose. Question-form H2s re-asked in the reader’s language, date labels, the author role line, and terminology lockstep — one agreed Arabic rendering per technical term, so topical map is always خريطة الموضوعات, never a coin flip.
Language enters exactly where a reader touches it. Prose, obviously — but also the H2s, re-asked as questions in the reader’s language rather than translated word-for-word, the date label, the author role line, and the register of the whole document: formal MSA with Arabic punctuation, not English syntax wearing Arabic words. The AR edition is a native document, not a mirrored template.
Terminology lockstep is the discipline that keeps it coherent. Every technical term has one agreed rendering per locale — topical map is always خريطة الموضوعات, ontology stays الأنطولوجيا, EAV stays EAV — decided once and applied everywhere. Without lockstep, each document improvises its own vocabulary and the bilingual corpus reads like it was written by a committee that never met.
Which Parts of a Page Should Never Be Translated?
Quick answer
Brand and entity names — iPhone, Search Console, JSON-LD — numerals, and structural ids. These are addresses, not vocabulary: translating them breaks recognition and orphans any code span, schema name or anchor id pointing at the Latin original.
Brand and entity names are addresses in the reader’s memory, and addresses do not translate. iPhone, Google, JSON-LD, Search Console stay Latin in the Arabic edition — exactly as a searcher who typed the brand name expects to find it. Translating them does not localize the page; it orphans the reader’s own query and merges the glossary into the brand. Recognition is the whole asset.
Numerals and structural ids follow the same logic. Numbers stay Western digits, the convention most Arabic web publications follow for statistics. Section ids, slugs and schema names are functional machinery — a translated id breaks the table-of-contents anchor that points at it. If a string exists to be matched by a machine or found by a URL, it is infrastructure, and infrastructure keeps its spelling.
How Does the Audit Judge Each Language Separately?
Quick answer
Per locale, with per-locale checks. Arabic human-voice and normalization checks run on the AR edition; snippet budgets are language-specific — EN 30–45 words, AR 25–35. Each edition passes or fails on its own evidence; neither inherits a verdict from the other.
The audit re-reads each edition as its own artifact, through per-locale checks. The Arabic human-voice and normalization checks run on the AR edition; a dedicated bilingual/Arabic syntax check examines native-voice signals the way the English checks examine theirs. Snippet budgets are language-specific: 30–45 words for an English extractive answer, 25–35 for Arabic — because the languages differ, not because one edition is graded easier.
Separate grading does not mean separate truth. Both editions draw their claims from the same set of verified facts, so a price band observed once is stated consistently in either language, and a claim that cannot trace to evidence fails in both editions at once. The fact record and its evidence rows are language-independent; only the prose that reports them localizes.
This article is part of the Arabic & Multilingual SEO series — What Arabic and bilingual sites must get right: spelling variants, Gulf and Egyptian dialects, right-to-left layout and one map for two languages.
About the author
Mohamed Youns
Semantic SEO Engineer · Author & system developer
Mohamed Youns writes about how search engines understand content — the same standards he applies when building semantic systems at Nut Hub. nut-hub.org