Sitecore Internationalization.

Managing a global digital presence using Sitecore.

Sohel Siddique
June 9, 2014

The Content Management System (CMS) Sitecore provides useful out-of-the-box tools for helping create and manage multiple websites across global markets. Tools to create localized and multilingual content, formal governance models and proper workflows all set Sitecore apart from the competition and make it a great choice for scaling a website globally. But even with a great platform, designing targeted, relevant sites across a global network poses particular challenges. Recently, a client asked us to create country-specific sites, each with its own language but all sharing some content in a consistent pattern and style.

Our client has a large presence in the United States, a relatively large presence in some European countries, a growing presence in Asia and wanted to launch in South America. The goal was to create multiple sites in Sitecore and assign access roles to restrict some portions to specific regions. On a technical level, some multi-sites had their own cc-tlds while others either shared a domain or occupied sub-domains. Additionally, we’d have to migrate much of the existing content to the new set-up without compromising SEO.

Here’s how we tackled it.

Content architecture.

It was very important to properly separate content nodes. We created buckets for each country/region and pushed content accordingly. Each country site has its own setting and data folders, accessible through path or Lucene search by folder name.

Here’s an example of a content tree:

This structure also works for Media Library and Templates content nodes, if needed. A good media structure follows this pattern: media library/country/language/media type. For example: media library/Canada/French/image. This structure also helps later when assigning appropriate security roles to Sitecore users.

Content sharing.

Extending a website to new languages in Sitecore is easy. Trickier, however, is sharing the same content across these multiple sites. The first step is designating the origin site. In most cases, this is the .com (global or USA) site.

While sharing content is useful for content creators and efficient for overall site management, Google and other search engines often penalize pages that duplicate content. To preempt this outcome, we added canonical meta tags to duplicate pages that indicate the original page.

Sitecore provides several nifty features that allow content sharing:

1. Cloning.

The Cloning tool is located under the Configure tab on the Ribbon. Cloning lets authors clone content in another place, either within the same site or on another one. Specifically, Cloning copies the content and creates a new item at the destination, one that is subscribed to the original item. So when content authors continue working with the original item, their changes automatically happen in the clones as well.

Conversely, if a regional author modifies a clone, and then the original is modified later, a notification sits on the item allowing the regional content author to view, accept, or reject the change.

Cloning also copies children within the item and all languages associated with the item. Because it is so simple, fast and secure, we suggest cloning whenever sharing content across sites.

2. Referencing.

Sometimes, the original authors of shared content don’t want regional ones to update it. We addressed this by creating a LinkField type item and then a redirection logic on the server side. For example:


Referencing is great for redirecting, but it also adds an unnecessary path to the url: siteB.com/siteA/path1/path2 instead of siteB.com/path1/path2. Another issue is that within this structure, all the site content, including navigation and metadata, comes from the origin site.

3. Content hooks.

Content hooks are similar to referencing, but they remove unnecessary path additions and ensure that the content is true to the specific site’s context. They require more effort to build and maintain, but they do a great job solving the problems inherent in referencing. When rendering, we dynamically loaded UserControls/Partial Views at runtime depending on the Sitecore Rendering Properties of the referenced item type.

Content navigation.

While tempting to share navigation structures across sites like we did with content, we ultimately decided against it. Instead, we kept that structure within the country/region site context. This gives regional authors more control in managing their site’s navigation. Even if the regional navigational structure ends up being the same as the global one, we recommend creating a new one for each country/region.

Content metadata.

As with navigation, we kept content metadata and components within each site’s context. This ensured proper governance and easy management.

Media library.

It’s easy for the Sitecore Media Library to get disorganized. We believe it’s crucial to create a management structure and ensure that content authors stick to it, especially with a global, multi-sute set-up. We took the following approach in our project:

MediaLibrary/Country/Language/Images/ComponentName/…

For example: MediaLibrary/USA/English/Images/Carousels/HomePageCarousel/ImageName.

For videos and files, we recommend the same structure: MediaLibrary/USA/English/Videos/Tutorials/Topic1/VideoName…

Sometimes, it’s worth taking an extra step and disabling or restricting media uploads directly under Root, Country, Language, or Images hierarchy.

Site settings.

Unless there’s something explicitly relevant to a country/region site, we kept all the site settings outside the site structure. We put all site-specific settings in Sitecore/Content/Settings.

Security and roles.

One of the biggest challenges in a global network of websites is governance, or ensuring proper access across the organization. We recommend simplifying to three roles per international site: content author, content approver, and content admin. As their names suggest, the content admin has more access than the approver, who in turn has more than the author. We assigned read-only access to the origin site and no access whatsoever to other international sites in our project. This ensured that the country/region site author can easily copy the original site content via cloning, referencing, or content hooks but can’t create new content on the origin site.

Workflows.

Sitecore’s Simple Workflow works well in most cases – so well that we often duplicated and customized it with further necessary states and actions as needed. When there were further complications and rules, we created a separate workflow for each country/region site. Where they all followed the same states and actions, we simply created one workflow for the origin site and another for all the international sites.

Field DataSource.

We provided a datasource for Sitecore fields, such as DropList, DropTree, or TreeList, in the templates. We needed to ensure that content authors only had access to relevant content, without exposing other sites. Assigning proper security roles and item permissions streamlines content authors’ options.

Branches.

We love Branches in Sitecore. Whenever we thought a content item spanned multiple templates, we created a branch. A good branch creates a blueprint for the site with necessary item containers – a good starting point for content authors. Branches help content authors create new site architecture quickly and easily.

SPEAK UI

SPEAK is a new UI framework from Sitecore that creates a whole new experience for creating apps within the platform. We’re excited about its potential for internationalization because it could eliminate some of Sitecore’s more cumbersome tasks and provide an easy-to-use interface for content authors to spin off new sites and maintain existing content. Plugged in with DMS, this could take personalization to a whole new level.

Designing sites for internationalization is an ongoing and evolving challenge – we’d love to hear your insights and solutions.