Question on what is the most common or preferred content tree structure for a multi-region, multi-lingual setup. Our current content tree looks like this:

    |  |-AboutUs.aspx (en)
    |  |-AboutUs.aspx (en, fr-fr, de-de)

One thing to note about the current setup:

  • Data sources are not being used so the content on the AboutUs.aspx page under Europe in en can be entirely different than the same page under USA.
  • It is extremely cumbersome to add a new region as the whole content tree for a current region needs to be duplicated and every link updated/changed.

What I am looking for validation on is that a content similar to the following is more standard within Sitecore.

    |-AboutUs.aspx (en-us, en-eu, de-de)

Data Sources
    |-AboutUs (en-us, en-eu, fr-fr, de-de)

In this example, we have a single language for each region/language combination. If we wanted to add a new region it would be as simple as adding the supporting language. The data source for the page would be maintained in multiple languages but the visible page would only be available in the published versions of the page. In the above example fr-fr is available in the data source but not on the website.

If anyone has any insight into this it would be great. Thanks!

2 Answers 2


Although Sitecore has great support for multi-site and multilingual implementation, there is no 'silver bullet' design that works for every situation.

Below I described four options we use for our sites. Hopefully you can use one of them or build your own.

1. Separate Site


Every region gets its own web domain and pages. Content can be shared using data sources.

2. Separate Content


Similar to previous option, but now regions are separated as subfolders under the same domain.

3. Shared Content


With this option all the pages are shared. Region specific content implemented using personalization rules or custom code.

4. Mix of Shared and Separate content


This is the most advanced scenario and it combines benefits of previous options. Page is accessible only under one site if it is added under site folder. If you want to share the page it should be stored under shared folder.

That implementation requires some coding:

  • Link Provider to generate links to shared pages
  • Item Resolver to find shared pages per request (subfolders should help identify if request should be routed to shared folder)
  • Sitemap to generate links to shared pages
  • Canonical Meta Tag to make Google and Bing happy

As you can see, in all these scenarios language it is not used for splitting content between regions. Language is used only for translation.

If you you decide to use language for defining regions, remember about potential issues:

  • Not every combination of languages and regions are supported. You can find yourself building artificial language like Brazilian English (en-BR). That language cannot be parsed by .NET and you will get an error.
  • For cases like Canadian French (fr-CA) and France French (fr-FR) version specific content is not shared. These are formally two different languages and content should be duplicated or you need to implement language fallback.

This is a very subjective question as a lot will depend on your requirements.

My general rule is:

  • If the sitemap for all language versions of the site is the same with maybe a few minor differences, and its only the content that will be translated, maybe a few module differences, then I will use option 2. A single site tree with versions for each language. Adding a new region is simple, but you will have to add language versions for all pages that are needed in that new region. This can be easily scripted with Sitecore PowerShell Extentions tho.

  • If you have any requirements for language fallback, then same option as above.

  • If the sitemap for each language varies, e.g the about-us page is visible in en but not in esthen separate the site trees in Sitecore. It can make things very confusing for a content editor when there are lots of items that don't have anything to do with the version of the site they are editing. Adding a region does not have to be a complex task here, you can easily script out adding a new region using PowerShell. This is similar to how SXA does it.

There are other things you need to think about, are the renderings on each version the same, how are you handling translation (each region has different teams, off site translation service etc...) and then any other requirements from the client. But that is a good base to start from.

  • Thanks. I didn't mention fallbacks but that is a huge need. Also another limitation for option 1 seems to be using data sources and specifically setting links. Say was did set a data source for AboutUs.aspx but wanted to link to ContactUs.aspx there isn't an easy way to set the link in the data source so that it will be to the correct page. Commented Oct 31, 2016 at 15:53
  • 1
    That depends on how you have setup your fields. With Final Layout, each of your language version renderings can point to different Datasources. Also, your Datasource field as long as it is Versioned can have different content per language version. It is not complex to set that up.
    – Richard Seal
    Commented Oct 31, 2016 at 15:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.