Building a multilingual website sounds straightforward enough. Configure the required languages, translate the content, and make sure the correct version is displayed to each visitor. In practice, things become considerably more interesting when a website needs to support six languages, multiple types of content, shared components and data automatically synchronised from an external source.
We recently worked on an Umbraco project that needed to support all six official United Nations languages: Arabic, Chinese, English, French, Russian and Spanish. Umbraco provides some useful tools for managing multilingual websites, particularly culture variants and translations (previously known as dictionary items). What it doesn't do is translate the website for you. That distinction became increasingly important as the project developed.
Multilingual isn't the same as translated
One of the first lessons from the project was that it's useful to separate two ideas: making content multilingual and actually translating that content. Umbraco handles the multilingual side well. A property can vary by culture, allowing an editor to enter an English value, an Arabic value, a French value and so on. But Umbraco isn't responsible for producing those values.
That meant we first needed to decide which parts of the website should vary by culture and which should remain shared. At first, the answer might seem obvious: text should vary and everything else should be shared. Once you start looking at a real website, however, there are plenty of grey areas.
Not everything should have six versions
Duplicating every property for every culture would quickly make the CMS difficult to maintain. Take a configurable block on a page. Its structure might be identical regardless of language. Settings such as whether a feature is enabled, which layout is selected or how the component behaves don't necessarily need separate values for English, French and Arabic. Those properties can remain shared.
The text displayed within the block is different. A heading that reads one way in English obviously needs an appropriate Arabic, Chinese or Russian equivalent. Those properties therefore need to vary by culture. This gave us an important principle for structuring content:
Share the structure and configuration where possible, but vary the content where necessary.
It sounds simple, but establishing that distinction early prevents a multilingual CMS from becoming unnecessarily complicated for editors.
Then there are the words that aren't really content
Another challenge was dealing with text that appears on the website but isn't necessarily editorial content. Consider a dropdown menu. The value stored by the application may need to remain consistent regardless of the visitor's language, while the label displayed to the visitor needs to be translated. Creating six different underlying values would introduce unnecessary complexity. Instead, this is where Umbraco's translation functionality becomes useful.
A consistent value can be used internally while its display text is retrieved from the appropriate translation for the current culture. The same approach can work well for interface labels, buttons, status messages and other pieces of relatively static text. By this point, we effectively had three categories of information:
Shared content and settings that remain the same across every culture.
Culture-variant content where editors provide a different value for each language.
Translations for fixed interface text and labels.
That covered most of the content managed directly within Umbraco. But there was another requirement.
What happens when the content doesn't come from Umbraco?
Part of the website's data needed to be automatically synchronised from an external source. That introduced a different problem. The source data wasn't necessarily available in all six languages, and because the process was automated, we couldn't rely on an editor manually translating each record as it arrived. Umbraco could give us somewhere to store the different language versions, but it couldn't create them. The synchronisation process therefore needed to become translation-aware. Instead of simply thinking:
External source → Umbraco
the process became closer to:
External source → Sync process → Translation service → Culture-specific content → Umbraco
A third-party translation service, such as Google Cloud Translation or Microsoft Azure AI Translator, can handle the machine translation stage before the appropriate language values are stored within Umbraco. This adds another layer to the architecture, but importantly it keeps the responsibilities clear. Umbraco manages the multilingual content. The translation service performs the translation. The synchronisation process connects the two.
Translation becomes an architecture decision
This was probably the biggest lesson from the project. Once a website contains multiple languages, asking "How do we translate this?" isn't specific enough. A better set of questions is:
Does this value need to change between cultures?
If it doesn't, it can usually remain shared.
If it does, the next question is:
Where does this content come from, and who is responsible for its translation?
Editor-managed content can use Umbraco's culture variants. Fixed application and interface text can use Umbraco translations. Externally supplied content may require an automated translation pipeline. Thinking about content in this way makes the technical implementation much easier to reason about.
Six languages also expose assumptions
Supporting six very different languages also makes you think beyond the CMS. Arabic, for example, is written right-to-left W3C — Internationalization resources. That has implications beyond simply replacing English words with Arabic ones. Layouts, alignment, icons and other interface elements may need to respond appropriately to the change in reading direction.
Different languages also produce very different amounts of text. A heading or button that fits comfortably in one language may take considerably more space in another. Chinese introduces different typographic considerations again. A component that looks perfect using English placeholder content isn't necessarily a component that works well in six languages.
For us, multilingual support therefore needed to be considered across content modelling, development and front-end design, rather than being treated as something added at the end of the project.
Automation introduces another question: who owns the translation?
Automated translation also creates some less obvious questions.
What happens when the original external content changes?
Should every translated version automatically be regenerated?
What happens if an editor improves a machine-generated translation manually? Should the next synchronisation overwrite their work?
And what happens if translation succeeds for five languages but fails for the sixth?
These aren't necessarily translation problems. They're content ownership and synchronisation problems. Making those rules explicit is important when designing an automated multilingual system. Otherwise, a seemingly simple synchronisation job can unexpectedly overwrite editorial work or leave different cultures with inconsistent information.
What we'd consider earlier next time
The biggest thing we'd take into another multilingual Umbraco project is to establish the content rules as early as possible. Before building document types and properties, we'd classify the information the website needs to manage.
Is it shared?
Is it culture-specific?
Is it a fixed piece of interface text?
Does an editor provide it?
Does it arrive from another system?
And, crucially, who is responsible for translating it?
Answering those questions early makes it much easier to decide whether something belongs in a shared property, a culture variant, an Umbraco translation or an external translation workflow. It also helps avoid pushing everything through the same mechanism simply because it's "multilingual".
Umbraco provides the pieces, architecture connects them
Umbraco gives developers and content editors useful foundations for building multilingual websites. Culture variants provide a flexible way to manage language-specific content, while translations handle smaller pieces of reusable interface text effectively. But a multilingual website is ultimately more than a CMS configuration.
Once shared components, editorial content, application labels, external data and automated translation all need to coexist, the challenge becomes deciding where each piece of information belongs and which system is responsible for it. For our six-language project, that distinction became key. The result wasn't one universal translation solution. It was a combination of shared properties, culture variants, Umbraco translations and automated translation services, each being used for the type of content it handles best. And perhaps that's the most useful lesson we learned:
Don't start by asking how to translate the website. Start by understanding your content, where it comes from, who owns it and whether it actually needs translating at all.