Building a large, multi-national, multilingual site

Sitecore has strong multilingual capabilities right out of the box. As per Scott Powell's blog post, here are the main features of Sitecore around language:

  1. A site can be managed in any number of cultures (for example, US English).
  2. Every field on a template can be marked as unique to a specific language or shared across all languages. For example, a company logo can be common to all languages and on the same item a different field can be unique in any language.
  3. Each language has its own version history.
  4. Items can be pushed through workflow to incorporate the translation process.
  5. When implemented properly, a site will not require software changes to support new languages.

At the simplest level, this means that you can easily set an information architecture to manage multilingual content easily in the same content tree. To Scott's previous top 5 features, I'll add another:

  1. URL structure can use the Display Name when creating the URLs. This means that although your content may exist at the same location in the tree (sitecore/content/Home/Products) the URL will actually be domain.com/products and domain.com/produits. Seth Gottlieb of Sitecore Partner Lionbridge has an excellent blog post on URL strategies for multilingual content.

As you likely know, the way Sitecore manages language versions is fairly unique, in that a language instance of an item is referenced in the exact same location in the content tree. This has a number of advantages, not the least of which is that your code doesn't have to be a mess of "if-statements" for handling newly created language instances. The language context is (generally speaking) automatically passed to your code at runtime, and the correct language information pulled from the appropriate fields. This functionality is all fine and good and works great if you have a simple site with only a few languages (i.e. English, French, Spanish, Chinese, etc.) - however what if you want to get more specific - down into actual regions, where a regional marketer can tweak their text to suit their region specifically? Then cloning is your new best friend.

For example, take a very large German software company where one of the requirements is that their regional sites not only reflect the languages, but also had regional variations in text and even in products. An example use case was with the language of German, and the region of Switzerland. Their translation process was such that most marketing and web content originated in the US and was translated to a German "generic" version. After this, the "generic" version went to the regions and was then further regionalized into "German-German", "Austrian-German", "Swiss-German" etc. Additionally even the product offerings were different for a language within a country. The French speaking areas of Switzerland are served offerings particular to agriculture, while the German areas of Switzerland are served offerings particular to industry, banking, etc.

How can this be accomplished in Sitecore?

Simple Language Use Case (single content tree)

If your site is largely going to show the same products, etc. from region to region, than the simple case is likely sufficient.

Simple Language Case

In this example, you simply have one site root. Different language versions of an asset are stored in the same location in the content tree. One the presentation side, you generally make a component for easily switching the language context, which is then maintained in a cookie.

Advantages:

  • Simplicity - only one site to maintain, only one item to publish

Disadvantages:

  • Less ability for local offices to make local changes.

Complex Use Case (Regional Sites with cloned content)

Complex Scenario

In the example, we have site roots (which can be unique domains, as well) set up as regional sites.

If someone has changed the local instance of some cloned text, and the source document changes, an entry is made in the Sitecore notifications table visually indicating the change and prompting for action. Of course, the question always arises - what if I don't want my regions changing any of the content that is coming from the "source" version? Well then, the answer is simple permissions - simply remove the ability to write for those regional users. Any changes to the source will automatically flow from the cloned item as no user was able to change the text to a local instance of that clone.

Advantages:

  • Unique domains for each regional site
  • Ability to make local changes

Disadvantages:

Complex Use Case (Regional Sites with cloned side-by-side content)

Complex Scenario

Advantages:

  • Regional sites can see the language source side-by-side with their changes. They can then copy/paste and choose what text to take from the clone source. This allows greater freedom for local site managers/editors

Disadvantages:

  • Changes to the clone source do not automatically get pushed down to the local copy. Of course, this may be an advantage, depending on the need, of course.

In addition, there are also the Shared Source modules for language fallback and partial language fallback (presentation by our own Alex Shyba here: http://mediacontent.sitecore.net/Support/LanguageFallbackSolution/ ).

In short, like pretty much anything in Sitecore - there are a number of ways to architect a project, depending on the business requirement. As a developer implementing a multilingual, multi-regional solution, there are a lot of architectural building blocks at your disposal. These include:

  • Separation of content and presentation
  • In-line languages
  • Cloning and the ability to make changes local to a clone
  • Easily managing language versions at the same content tree location
  • Easily determining programmatically if a language version exists
  • Language fallback and/or partial language fallback
    • More code examples can also be found in the Presentation Component API Cookbook (Section 5.2) on SDN

Depending on the business need, you may only take advantage of a few features, all the features - or even mixing and matching strategies as required.

  • Apr 18, 2014