Two things get called translation
In a multilingual organisation the request "can we have the portal in Dutch" covers two very different jobs, and conflating them is where these projects go wrong.
The first is the chrome: navigation, section headings, column labels, the search box placeholder, the footer. This is a fixed, small vocabulary — a few hundred strings — and translating it is straightforward.
The second is the model content: element names, documentation, tagged values. This is thousands of strings, it changes every week, and translating it means maintaining a parallel model.
Do not translate the model
The recommendation, for almost every organisation: translate the chrome, leave the model alone.
The reason is not cost, though the cost is real. It is that translated model content creates two sources of truth for the same architecture. When an element is renamed in one language and not the other, you now have two names for one thing, and every conversation that spans the language boundary has to establish which is which.
An application called "Payment Orchestration Platform" is called that by the team that runs it, in the runbook, in the incident channel and in the contract. Renaming it in the portal for one audience does not help them — it makes the portal harder to reconcile with everything else they read.
Where model translation is legitimate
There are cases. Public-sector organisations with a statutory obligation to publish in two languages. Business-capability models whose audience is entirely non-technical and entirely one language. Regulatory content where the authoritative text is in a specific language.
Where it is genuinely required, model it properly rather than translating at publication time: a second name field, populated deliberately, reviewed like any other content. Machine translation applied during generation produces plausible-looking terminology that nobody in the organisation actually uses, which is worse than leaving it in the original.
One publication per language
The mechanism that works is to generate the portal once per language, each a complete self-contained site, rather than one site with a language switcher.
This is unfashionable and it is right for a static portal, for three reasons:
- The search index is per language. A switcher means shipping every language's index to every reader.
- Links stay stable. A Dutch reader shares a Dutch URL and the recipient gets Dutch, without a preference cookie deciding otherwise.
- Scoping can differ. In practice the audiences are not identical — the English publication for suppliers often needs a narrower scope than the internal one.
The details that leak
Two things are easy to miss and immediately visible to a native reader.
Dates and numbers. A portal whose chrome is Dutch but whose dates render as 08/06/2026 in US order looks unfinished. Format according to the publication's locale, not the generating machine's.
Sort order. Alphabetical sorting differs by language. If your catalogue sorts with a naive byte comparison, accented characters land in the wrong place and readers notice.
Start with one
If you are not yet publishing at all, publish in one language first — usually whichever your architecture is already documented in. A second language is a small increment on a working portal and an unnecessary complication on one you are still designing. The chrome translation is the cheap part, and it will still be cheap in three months.
Where the translation effort actually goes
Teams budget for translating the interface and are surprised by where the time is spent. In practice the interface strings are the smallest part.
| Item | Effort | Note |
|---|---|---|
| Interface strings | Low | A few hundred, translated once |
| Deciding what counts as content | Medium | A policy decision, not a translation task |
| Locale formatting | Low | Dates, numbers, sort order — but easy to forget |
| Keeping scopes aligned | Ongoing | The real cost, if publications differ in scope |
| Model content | Very high | Which is why the recommendation is not to |
The ongoing item is the one to plan for. If the English publication for suppliers has a narrower scope than the internal Dutch one, those two scopes will drift, and the drift is invisible until someone notices something is missing from one of them.
A note on ArchiMate terminology
One genuinely tricky case: the modelling language's own vocabulary. "Application Component", "Business Process", "Capability" have official translations in some languages and awkward ones in others.
The pragmatic answer is to translate element type names only if your organisation already uses the translated terms in conversation. If your Dutch-speaking architects say "Application Component" in meetings, translating it in the portal makes the portal harder to read, not easier. Follow the organisation's actual usage rather than the standard's translation table.
What a Belgian estate actually needs
The multilingual question is rarely abstract. In Belgium it is Dutch and French with English as the working language of the architecture team, and the requirement is usually legal rather than aesthetic — a federal or regional body has an obligation to publish in both national languages, and the architecture register is caught by it.
That framing changes the answer. If the driver is comprehension, translating the chrome and leaving the model in English is usually sufficient, because the readers are technical and English element names cost them nothing. If the driver is a legal obligation, the obligation attaches to the published content, and element names are published content.
Establish which one you are under before designing anything. Teams that assume comprehension and later discover an obligation end up translating a model that was never structured for it, which is the expensive order to do this in.
A third case sits between them and is more common than either: no obligation, but a stakeholder group that will not engage with an English portal. That is a real constraint and it is worth naming as an adoption problem rather than a translation one, because the cheapest fix is often a translated landing page and summary rather than a translated estate.
Keeping two publications from drifting
One publication per language is the right architecture and it introduces the failure it was chosen to avoid: two artefacts that can disagree. The disagreement is never announced. Someone regenerates the English portal after a model change and the French one keeps showing last quarter's architecture, and nobody notices because nobody reads both.
Three things keep them together, and only the third actually works on its own:
- Generate every language in the same pipeline run, from the same extraction. Separate schedules will drift within two months.
- Fail the whole run if any language fails. A partial publication that leaves one language stale is worse than a failed one that leaves all of them at the previous version.
- Stamp every page with the extraction timestamp and the source revision, in every language. Then a drift is visible to any reader rather than only to whoever runs the pipeline.
The stamp is the one to insist on. It converts a silent correctness problem into something a reader can spot and report, which is the only mechanism that scales.
What translation costs to keep, not to do
The initial translation is a project with an end date and a quotable price. Everyone budgets for it. What is not budgeted is that the estate changes, and every change to a translated field is a change that has to be translated again, forever.
At a realistic rate of change for an enterprise landscape — a few dozen elements touched a month, a handful of new ones — the ongoing translation load is small in hours and awkward in shape: it arrives continuously, in small pieces, and it blocks publication. A translation process with a two-week turnaround turns a monthly publication cadence into a six-week one.
Two arrangements survive contact with this. Either translation is done in-house by someone on the architecture team who can turn it around in a day, or untranslated new content publishes in the source language with a visible marker and is translated in the next cycle. The second is unpopular and it is what most organisations end up doing, because the alternative is a portal that is always six weeks behind the model.
Search across languages
A translated portal with a monolingual search index is half a portal. The reader who navigates in French will search in French, and if the index holds only English names they will conclude the content is not there.
The simplest arrangement that works is one index per publication, built from that publication's own content. It keeps each portal self-contained and it means the French index is genuinely French. What it loses is cross-language recall: a French reader searching for a system whose name was never translated finds nothing, even though the element exists in their portal under its English name.
The fix is aliases rather than a shared index. Index every element under both its translated name and its source name, and display the translated one. This costs nothing at generation time and removes the most frustrating failure mode, which is a reader searching for a system by the name written on its own login screen.
Stemming is the part that is genuinely different per language and is worth getting right rather than clever. French and Dutch stemmers exist in every serious search library; using the English one across all three languages produces results that are subtly wrong in a way that is very hard to diagnose from the outside.
Diagrams are the hard part
Everything above is tractable because it concerns text in fields. Diagrams are different: the labels are rendered into the image, and an image does not have a language variant unless someone makes one.
There are three ways out and none of them is free. Rendering diagrams per language, from the same layout with substituted labels, is the correct answer and requires the publication pipeline to control rendering rather than exporting images from the modelling tool. If the tool exports the images, you get one language and no amount of post-processing will change it.
The second option is to render once, in the source language, and put a translated caption and legend around the image. This is honest and cheap and it is what most estates do. A reader gets a diagram whose boxes are in English and an explanation in their own language, which is adequate for a technical audience and inadequate for a legal obligation.
The third is to avoid diagrams as the primary artefact and lean on catalogues and matrices, which are generated from fields and therefore translate for free. That sounds like a workaround and it is often the better portal regardless of language, because tables answer the questions readers arrive with.
Language selection that does not annoy people
The mechanism for choosing a language is a small thing that generates a disproportionate amount of irritation when done badly, and the bad version is automatic redirection based on browser settings.
An architect in Brussels running an English-language operating system while working on a French deliverable gets sent to the English portal and has to fight it every time. Someone who linked a colleague to a specific page finds the link lands somewhere else. Automatic redirection also breaks the property that matters most for a published register: that a URL identifies a page.
What works is boring. Give each language its own URL prefix, make the switch a visible control in the header that preserves the current page, and remember the choice for the session only. Do not guess, do not redirect, and make sure the switcher lands on the equivalent page rather than the language's home page — being thrown back to the landing page is the single most common complaint about multilingual documentation.
Deciding not to translate
The option least often considered is doing none of it, and for many estates it is the right call. It deserves to be a decision rather than an omission.
The case for a single English portal is that the readers of an architecture register are overwhelmingly technical, English is already the working language of the systems themselves — every error message, every vendor document, every API — and translating the model introduces a permanent maintenance cost and a permanent risk of two portals disagreeing.
The case against is narrower than it looks: a legal obligation, or a specific non-technical audience whose engagement matters and who will not read English. If neither applies, the money is better spent on content than on translation, and saying so early saves a year of half-finished bilingual publication.
The glossary becomes an asset of its own
A by-product of doing multilingual publication properly deserves promotion to product: the translation glossary. Building the per-language publications forces the practice to decide, term by term, what the organisation's architecture vocabulary actually is in each language — and that decision list, maintained as data rather than as tribal memory, quietly becomes one of the most reused artefacts the practice owns.
The reuse starts internally. New architects onboarding in their second language stop guessing whether "capacité" or "aptitude" is the house term for capability. Document generation pulls from the same glossary, so the French solution architecture template and the French portal agree — a consistency readers notice only when it is absent, and then vividly. The search index ingests every glossary pairing as aliases, which is how the Dutch-speaking analyst finds the English-named element without anyone building "multilingual search" as a feature. Then the reuse escapes the practice: the risk team borrows the glossary for their own reporting, the transformation office lifts it for board packs, and the terminology the architects standardised becomes, without a mandate, the organisation's standard — because theirs was the only list that existed, was maintained, and had an owner.
The maintenance cost is one review touch per new term, at the moment the term first appears — trivially absorbed into the modelling workflow. The strategic value is harder to overstate for a Belgian or international estate: terminology drift across languages is where cross-team misunderstanding breeds, and a practice that quietly owns the canonical trilingual vocabulary of the enterprise's own systems has acquired influence that no org chart records. It began as a translation chore; kept properly, it is the practice speaking every stakeholder's language on purpose.