Fallback Series Post 1: Introduction to Language Fallback

For the past few years most of the websites I've built have been integrated with Sitecore.  It didn't take very long to run into clients that requested multilingual solutions. 

As anyone familiar with Sitecore knows, it can handle this requirement out-of-the-box.  Items in Sitecore are created for a default 'en' language and those administrators with the appropriate permission levels can add many more languages.  Once these languages have been added to Sitecore, then every item in the content tree can have a version created in that language.  It is important to note that although we say 'language' here, it is truly more like a culture, where the language item can be based on a language/region combination, for example, 'en-GB' is English Great Britain.  This becomes important if the content differs not just based on language translation, but has a completely different message in different regions of the world.

Viewing the front-end of the site can be done through the context of any of these languages, with the setting of the specific language executed in several ways (in order of priority).

  • Set language with sc_lang query string parameter
  • Embed the language in the URL, where Sitecore will add the language between the hostname of the site and the path to the item. For example:
    • This is configured with the LinkManager languageEmbedding attribute (setting it to 'always') and Sitecore will automatically create URLs with the language embedded and parse URLs correctly that have the language in it.
  • Programmatically set the context language by setting the special language cookie that Sitecore's code uses.
    • Note that I typically wouldn't do this unless I had a very specific exception for grabbing a value of an item for a particular language and outputting to the page.  The reason for this is that if the URL doesn't specify the language that the site is being viewed through, then bookmarking the page would potentially not return the user to the content they were hoping to get back to.  This would not be a great user experience.  Additionally, this would have a negative impact on SEO
  • Map a URL to a specific site node and for that site node specify the language that the site should load in. For example:
    • is mapped to en-us (America English)
    • is mapped to de-de (Germany German)
  • The DefaultLanguage setting in the web.config

Whether to use language embedding in the URL with the same hostname or to have different hostnames per language accomplishes the same thing and ultimately is the preference of the client.  Obviously having lots of different hostnames could create a lot of overhead in procuring those URLs.  There may be some SEO repercussions that I won't speak to here, but that has to be a part of your strategy.

In addition to setting the context language in the above ways, there is a way to customize how to determine which context language should be used.  John West has a great blog post here.

You could hook in to check browser settings, GeoIP, cookies, settings saved to an authenticated user account, etc, to determine what the preference might be for the current user and then redirect to the appropriate site URL or set the Context Language.

One of my first multilingual Sitecore clients had an old solution in place from a previous development company.  They had more than 60 language versions for which they allowed front-end users to change their 'country' by selecting one of these languages from a dropdown.  What was super impressive is that they had all of their main content pages versioned into all of these languages.  Even if they didn't have translations, they had still created the language version and copied the text from the 'en' version into every language version for each field.  As you can imagine, that was an ongoing tedious process for their content authors.

When additional clients began requesting multilingual sites, I recognized that pain point had to be avoided and went searching for solutions that might be out there.  Alex Shyba's Partial Language Fallback Module was relatively new, but seemed like the best option. 

In the most basic of explanations, you set whether a language should fall back to another language (at a global level).  Then when you create the language versions of an item, the fields are all null initially, and therefore pull their values from the language it falls back to.  The biggest benefit, which you can see when you think about the example I gave above, is that the content author simply needs to create these language versions and does not have to worry about copying and pasting values from other language versions.

And so began my adventure with multilingual sites and language fallback.  All of this stems from Alex's module.  But I've found several ways to enhance it, fix some issues, and make it easier to use.  In this series of blog posts I will discuss the following topics:

  1. How to Install and Configure Alex Shyba's Partial Language Fallback Module
  2. Enforcing Language Version Presence, Out-Of-The-Box
  3. Enforcing Language Version Presence, Customizations
  4. Using Fallback with the Dictionary
  5. Using Fallback with the Advanced Database Crawler
  6. Defaulting Language Versions for Fallback
  7. Language Migration Tool
  8. Language Fallback Report Tool
  9. Additional Miscellaneous Topics for Multilingual and Language Fallback Implementation
  10. Unsharing layout, versioning media, conditional rendering / personalization by language, translator tools, other cultural considerations: dates, currency, registering custom languages, etc. 

My goal is to give those who are working with multilingual Sitecore websites a single comprehensive place to get all of the necessary information.

Where applicable, I will provide Sitecore packages so you can install elements individually and provide a full Visual Studio solution to see how everything comes together.

Link to Fallback Demo:

  • Hi Elizabeth,  It looks like the databases are missing from Github. Could you add those please.  Thanks again

  • Apologies for not seeing this comment sooner!  Not sure why I am not getting emails about comments.  I have added the DBs to Github, apparently they were ignored because of the name of the folder they were in.

  • I realized recently that there is a bug in the partial language fallback module in regards to clearing the fallback cache upon the publish end remote event.  This basically throws an error on CD sites and does not properly clear the cache.  Items that are falling back to others therefore may take a long time to update.  I want to recognize Horizon Integrations for also catching this and posting a fix:  Basically you need to fix the source code and recompile to fallback dll.  It needs to take into account whether the itemUri is null or not (will be null in a remote publish event for CD sites).  If so, it will just clear the whole fallback cache and not just an entry for that particular item (which it does on CM sites).  The fix must be done in the /Providers/FallbackLanguageProvider.cs file, ClearFallbackBackCaches method:  You can get a copy of the updated file that needs to be updated if you are going to compile your project here:  The compiled dll that includes this update for sitecore 7.2 here:  the compiled dll that includes this update for sitecore 6.6 here: