How to make an existing Umbraco website multilingual

A successful English-language site is ready to reach a French-speaking audience. The pages already exist, editors know the backoffice and the design works. Do you need to rebuild everything?

Often, you can extend the existing Umbraco site. The work is in adapting the content model and visitor experience around the content you already have. This guide focuses on that conversion. For an introduction to languages, variants and domains, start with building a multilingual Umbraco site.

1. Decide what the first language launch should include

Adding a language does not oblige you to translate every archived news article. Choose a useful visitor journey: the homepage, a product or service section, relevant navigation and a working contact route. Agree who will review it and who will maintain it after launch.

For example, a first French release might include ten service pages and the contact page, while older English blog posts remain available only in English. The French navigation should reflect that scope rather than promising pages that have no French version.

• Which audience and language or regional culture are you serving?
• Which pages must be available together for visitors to complete their task?
• Do offers, addresses, imagery or contact details differ for that market?
• Who can approve the language and answer enquiries received through it?

Use the answers to define a first release, a later backlog and content that will remain in the original language. This also makes estimating translation costs more useful.

2. Audit where the existing words live

Open representative pages in the backoffice and compare them with the rendered website. A page may combine a title, nested blocks, shared settings, template text and a form supplied by another package. Translating the main body alone leaves a visibly incomplete experience.

Record the property alias, editor type, whether it should vary, and any required code changes. Pay particular attention to compositions: a property reused across several document types can affect more pages than the one you are inspecting.

3. Rehearse the content-model changes on staging

Take a restorable backup of the database and relevant media, then work on a staging copy with the same CMS version, packages and custom editors. Keep outgoing emails and other integrations under control so testing a form does not create a real customer enquiry.

Configure the target language under Settings → Languages. Enable Allow vary by culture on the relevant document types and review each property's Shared across cultures setting. Umbraco's official multilingual tutorial explains the backoffice controls.

Keep the current default language unless the project deliberately requires a change. Decide whether the new language should be mandatory and how fallback will be used; making it mandatory is a publishing decision, not a translation shortcut.

For a block-based page, test both the containing property and its nested fields. Decide whether languages should share the same block arrangement or allow different compositions, then verify that the editor and templates support the choice. See translating blocks and complex content for the translation side of this work.

4. Protect the URLs people already use

Export or crawl the current public URLs before changing routing. Include important landing pages, campaign links and documents, then use that list to check the original-language site after conversion.

Suppose the English service page is already at /services/consulting/. One possible plan is to retain that address and introduce French under /fr/. Another is to move English into /en/ as part of a wider restructure. Both require a routing implementation; the second also requires a redirect plan for the old addresses.

Configure culture and hostname mappings at the appropriate root node and test the actual URL generated for each language. Do not construct translated links by simply adding a language prefix: page names, URL segments and publication state may differ.

• Existing links still reach the expected content, or a deliberate permanent redirect.
• Each published language has its own stable, crawlable URL.
• The language switcher links to an available equivalent page, with an agreed behaviour when none exists.
• Canonical links, language alternates and sitemaps match the new routing.

Use the multilingual SEO guide for the search-facing details. Avoid forced language redirects based on location; give visitors a clear language choice.

5. Make the complete visitor journey work in the new culture

Review templates and custom code for assumptions about the original language. Check navigation queries, content names, search indexes, cached output and links to related pages. A translated property is useful only if the website requests and displays the intended culture.

Move hard-coded interface labels into Dictionary items or the localisation system used by the relevant component. Populate the target-language values for menus, buttons and validation messages. The Dictionary translation guide covers that part of the workflow.

Follow the journey beyond the page: submit the contact form, read its confirmation, inspect the email and try an invalid entry. Also check cookie controls, site search, error pages and downloadable files. Assign any untranslated parts to the team or integration that owns them.

6. Translate a representative pilot section

Choose a small group of pages that exercises the real site: a landing page, a detailed page with blocks and links, and a conversion page. Include shared navigation and Dictionary text. A plain text page alone will not reveal the difficult parts.

1. Agree the source copy and a short list of approved brand and product terms.
2. Create target-language drafts using editors, professional translators or an AI-assisted workflow.
3. Compare the result with the source, including nested blocks, metadata and link labels.
4. Have a fluent reviewer check accuracy, tone and local suitability.
5. Preview the rendered pages on desktop and mobile, then test the complete journey.

In Diplo Translator Omni, a configured multilingual site can use page or section translation to create drafts from supported content. Check editor compatibility first, preview what will be included and inspect skipped or reviewable results. Provider usage costs are separate from the package licence.

Umbraco backoffice

Enlarge ↗

×

Use coverage to find gaps in the pilot section; a populated value still needs linguistic and page-level review.

Record the pilot's translation costs, review time and manual corrections. Use those observations to plan the remaining sections and improve the glossary or AI profile before scaling up.

7. Roll out the conversion in manageable batches

Separate the tested model and template changes from the editorial work of translating each section. Schedule the production conversion with a current backup and a clear recovery plan. If editors continued working during the pilot, reconcile those changes rather than replacing production with an older staging database.

After applying the conversion, recheck the original-language content and URL inventory. Then introduce reviewed target-language pages in coherent groups, including any ancestors required for routing and publication. Keep incomplete variants in draft and out of public navigation and sitemaps.

Find the pages still waiting for translation

You do not have to open every page and check each language manually. Omni's Missing Variants dashboard identifies pages that exist in the default language but have no saved variant in one or more configured target languages. Filter by the language you are launching, see the pages that still need a variant and start a translation directly from a result. The Content Overview also shows a missing-variant count with a link to the work queue.

For variants that already exist, use Translation Coverage to scan a section for missing target values, pages that need translation and review states. Together, these tools give you a practical backlog for the rollout and help you spot gaps as each batch is completed. See Omni's translation management features and missing-variant walkthrough for the dashboard workflow.

Give each batch an owner and a review deadline. New-language publishing should pass through the site's normal approval process, with an additional check that visitors can complete the intended journey.

Conversion acceptance checklist

• The original-language values remain intact after saving and reopening converted content.
• Existing public URLs work, with tested redirects for any intentional changes.
• Shared and culture-specific properties behave as agreed, including nested editors.
• Target-language pages have been reviewed for meaning, facts, terminology and layout.
• Navigation, search, forms and confirmations work in the new language.
• Language switching handles pages without a published equivalent.
• Canonical, hreflang and sitemap output have been checked on the public URLs.
• Someone owns future source changes and target-language review.

After launch, use a translation maintenance workflow to keep the new language accurate as the original site changes.

Common questions

Do I need a separate content tree for each language?

Language variants can hold translations on the same content items. Separate trees may suit markets with substantially different structures or content ownership. Choose according to the site requirements; adding a language alone does not require duplicating the whole tree.

Will enabling language variants translate existing content?

No. It provides a place for culture-specific values. You still need to create and review the translations and make the front end display them correctly.

Can I add one language now and more later?

Yes. A focused first launch lets you test the conversion and establish a repeatable process. Allow for additional cultures in the routing, content model and editorial plan.

Can Omni convert the site to multilingual for me?

Omni helps translate and manage content once the multilingual foundation is configured. Document-type changes, existing-data migration, public routing and template localisation remain part of the website implementation.