Sitecore is such an amazing platform to create elegant integrations and authoring capabilities. One such area we enjoy to innovate in is multi-market localization.
In previous posts, we talk about two other approaches for creating multi-market implementations – splitting the content trees and creating a site cluster. Each has its advantages and its disadvantages.
Splitting Trees
When we say splitting trees, what we mean is “creating a unique content tree for each market”. So, we can manage a content tree for the US, another for Canada, and another for each market where I hope to deliver an experience.
Advantages of Split Trees
Splitting the trees has some advantages – specifically, it’s very easy to separate each market from one another, and the markets have no dependencies on the content from other markets. If you have content teams that are also decentralized, splitting the trees requires less governance and coordination between markets. The markets can easily diverge and there is little to no risk of difficulty.
Disadvantages of Split Trees
The main disadvantage is that if there is content that is shared across a significant number of markets, creating copies or linked clones of that content is messy and a bit irrational. Also, if all markets share a single domain name (mycompany.com/en-us and mycompany.com/en-ca for example) creating a single sitemap that properly maps overlapping content with language reference might be difficult.
Site Clusters
Site Clusters create a single tree that is translated, and possibly uses personalization to allow multiple markets to share that tree, but still present content differently in some contexts.
Advantages of Site Clusters
A single tree is easier to manage, and several markets have a very simple ability to share content items that are truly global in nature.
Disadvantages of Site Clusters
If there are a LOT of markets (like over 20), and there is a lot of differences beyond language for those markets – the cluster will be difficult to manage. Also, if your content managers for markets are distributed and centrally located, it is easy for one market to accidentally change another – especially if they share a single culture. Also, defining pages that are market specific within the tree will confuse other markets, and sometimes aggressive content managers will “remove” what they think are stragglers.
Introducing Mastersite
We recently completed a large, multi-market (30) multi-language (27) implementation in Sitecore. The previous site implemented a Site Cluster, and that proved to be hazardous for this organization since they did not centralize content management. As a matter of fact, they distributed it heavily and aspired to create a “follow the sun” content management model where content updates could literally be done globally regardless of the impacted markets.
Another thing about this project – it was a .com – and the organization has grown globally through a number of acquisitions of products built by companies in various markets. In some cases, those products remained market specific, in others, the product is expanded to support other markets. Other differences between the markets included a different segmentation model, case studies, and lots of lifestyle imagery and content. Needless to say, there was a lot of content, and it was really a mix of global and market specific content.
Mastersite Objectives
When we started the project, we had some goals:
- Be able to easily manage globally governed content and deliver it to markets without copies of clones
- Allow markets to create market specific content without risk of damaging other markets
- Make sure content authors are very clear as to what market is being modified, and what language(s) that market supports
- Allow markets to easily “diverge” from the global message where appropriate, but ensure proper governance by the global team to determine when this is allowed
- Do not depend on personalization in order to deliver divergent experiences, even if languages (cultures) overlap multiple markets
The Solution
So we wanted the benefits of each – split trees and site clusters – combined into one without the disadvantages of either. So, we created something new.
The Mastersite
We start by building the Mastersite. Simply put, the Mastersite is a collection of pages defined in a single content tree. These pages can be translated into multiple languages, but this “site” isn’t really a site – it only represents a collection of pages / content that is rationalized to be delivered to multiple markets. For example, if the home page of all (or most) markets is globally governed, the home page would be defined into the Mastersite.
Markets
Markets get their own content tree as well, in this case the screenshot shows 2 markets – United States and Canada. The market identified what language(s) (actually cultures) that are used within that market.
Pages and Proxies
Defining a new market is done by inserting a “market” from the mastersite folder, and selecting the languages used.
When a new market is introduced, the system will automatically start to create items in the content tree that “proxy” the pages in the mastersite. Although they look like pages, they are simply pointers. Content is never copied nor is it cloned.
These proxies are placeholders that show the content manager any content that is being brought to the market from the global team. It shows in the I/A of the market where that content will live as well.
As you add pages to the Mastersite, those pages will automatically flow into the markets (assuming a language version of the page exists for that market or language fallback is being used). So the system does this by automatically creating proxies for those pages to other member markets.
What can you do with a proxy?
The first thing you can do is create pages beneath them. So when a market needs to insert a page that is a child of a globally owned page, they just use Sitecore as it is designed.
Second, proxies can be “moved” within the market if the market needs that page to appear somewhere else in the content tree.
Third, proxies can be “hidden” on a market level – if given permissions, a market content manager can choose to hide the proxy from their market.
Creating and Reverting Local Copies
The final thing you can do with proxies is override them. If a market needs to make some local changes to a Mastersite page, and they are given permission, they can override it. This is done by creating a local copy.
Creating a local copy will convert the proxy to a page matching the original for that market, and will only create language versions of languages used within the market. So in essence it “hydrates” the proxy into a page.
In Conclusion
Sitecore is super flexible for things like this … Localization is a complex thing to do. But it can make a world of difference in your adoption and operational costs, so it’s best you analyze your options before selecting an approach. In this case, it’s really important to think about your content management team structure and governance model.
