When approaching multilingual Sitecore solutions, it's important to determine at the outset whether you'll be dealing with translated content or localized content as this distinction will heavily influence your data/information architecture. Translated content is, quite simply, content that has been translated from a source language to a target language, often in a very literal word for word fashion. Localized content is translated content that has been adapted to meet language, cultural and other requirements of a specific target locale.

Translated content is typically better suited for multilingual sites that can use the same content tree for each implemented language. Localized content is often better suited for separate content trees. There are pros and cons to both approaches as well as a hybrid approach that attempts to merge the best of both worlds. The approach you choose will naturally be determined by the requirements you need to meet.

Fallback Language

Implementing a fallback language may seem attractive at first as it allows you to establish a presence in a target language without having all of your content translated or localized. There can be unintended consequences implementing a fallback language, however, especially as your target language presence grows. You may find extra time and effort are necessary to accommodate your fallback language functionality. End user experience can also suffer with the use of a fallback language. Users may find it confusing to see mixed-language content on your site and ultimately browse away from your site with a poor impression. Generally, it's not safe to assume that users will comprehend fallback language content. While a convenient short-term solution, using a fallback language should not be part of your long-term multilingual strategy.


Workflow requirements can greatly influence your multilingual implementation strategy. For instance, requirements may dictate that a separate workflow be used for individual languages. Sitecore stores template workflow assignments in shared fields, meaning a separate content tree approach may be a better fit for your workflow needs than a shared content tree. Another scenario might require content authors of target languages to be notified when changes to source language content are made- which may present complications if your content isn't shared in some manner.

Introducing 3rd-party translation providers will also impact your workflow and subsequently your overall multilingual strategy. Translation connectors (such as Clay Tablet or Lionbridge) typically leverage the flexibility of Sitecore workflow to send source language content from your Sitecore instance to a translation provider for translation to a target language. Your translation provider may ask you to provide a mechanism for previewing translated content in the context of your site before it is routed back to your Sitecore instance. Yet another scenario that will influence your multilingual strategy.

As you can imagine, multilingual workflow scenarios can become complex fairly quickly and therefore require careful and meticulous planning prior to implementation.


When choosing a search platform for your implementation, it's important to consider the impact of multiple languages. You'll want to make sure your search platform can distinctly identify and index your content in each target language. In most cases, you won't want users browsing your site in one language to see results from another language. Also be mindful of licensing terms for your search platform. Some search vendors determine license pricing by the number of documents (pages, files, etc...) that will be indexed. If your content is available in multiple languages, generally each item of content will be considered another "document" in the search platform's index. The math spells it out pretty clearly: if you are implementing 7-8 languages and say (conservatively) 1000 documents, you're looking at 7000-8000 indexable documents, which may impact your license agreement.


As if forms aren't complicated enough to manage and support from the outset, form localization introduces another layer of complexity, particularly for content-managed forms. Imagine a form that solicits a user for their mailing address. Address formats and terminology can vary significantly from locale to locale. For instance our imaginary form in the US would ask for City, State and Zip Code while a similar form in France might ask for Postal Code and City/Town (in French of course). And the order of those respective form fields may change between locales. Terminology and field order are just the beginning, though, as you also need to consider field validation (Zip Code is required in the US, but Postal Code may not be required in other locales), form data storage and form feedback (French users wouldn't want to receive a follow-up email in English - c'est grossier!). As mentioned, form localization can be complicated and therefore should be given extra consideration when creating your multilingual strategy.

In conclusion

If I haven't made it painfully (but not too painful) obvious at this point: effective multilingual strategies require a clear understanding of operational needs, diligent planning and a solid underlying architecture. And while there are still many other considerations to make when preparing your multilingual strategy, hopefully the considerations outlined in this post will help you in your quest to craft the Ultimate Multilingual Solution, a.k.a. UMS (I can't let Sitecore adopt all the good acronyms).