Built-in language versioning in Sitecore leaves a little bit to be desired. There are 2 major issues we see in the stock implementation of language versioning in Sitecore:
- If you attempt to retrieve an item from Sitecore that doesn't exist in the current context language, Sitecore returns an empty, useless item.
- When a version is added for a given Sitecore item, it inherits NONE of the values from any existing version. This means any image, treelist value, droplist value, etc. are all empty/blanked out in the new language item, and you are starting with a blank slate.
Depending on how the site is structured, the first item can be less of an issue. If we're supporting another language on a page or a whole site, it's obvious we'll need to translate any needed content into the new language. It can be painful to add new item versions in Spanish (for instance) for every single item a page may make use of.
What's even MORE troubling is the second issue: any new language version of an item starts from scratch. Any treelist, droplist, or droplink fields, image/media selections, etc. are all empty! This poses a big problem, as content editors then have to click back and forth between the original language and the new language versions and essentially "recreate" the state of the item and its data.
Shared Source to the Rescue
Luckily, we're not the first people to come across these challenges. After a bit of Googling of the issue, we came across this great blog post and video from Alex Shyba of Sitecore USA:
the module itself can now be found at:
We believe the partial/field-level language fallback solution he created as a Sitecore shared source module is a very elegant and powerful solution to the second problem discussed above.
What is Language Fallback
Briefly, language fallback is the concept of allowing a language version of a Sitecore item to "inherit" its content from a version in another language. For us in the USA, this normally means when we create a new version in Spanish, Chinese, etc., we want it to initially take all of its content from the existing version in English, rather than starting blank. This accomplishes two goals:
- Gives a good starting point for translation. Having valid content in all fields on an item allow a content editor to visually see what still needs to be translated to a new language as they review pages.
- Maintains any existing item selections for images, treelists, droplists, etc., etc. This is a HUGE benefit and time saver for the content editor.
The module can be installed as a Sitecore package, and adds a field to a Sitecore template that allows it to take part in language fallback:
Once a template is configured for fallback, you can navigate to an item based on that template and add a new version of the item in the new language. Any fields configured for fallback will now inherit their values from the fallback language. Any fields that have a fallback value will be marked as so (circled in the image):
A few things to bear in mind when implementing this solution:
- A version still needs to exist for any item the page needs in the new language (see the "Background" section above).
- The shared source module is currently built against Sitecore 6.5, so you may need to rebuild it for the Sitecore environment in use.
- In our case, we build the module against Sitecore 6.3 dlls, and had to resolve a couple of areas that weren't compatible (properties didn't exist, etc.)
- You must configure the site to enable language fallback
- Normally you can use the included Sitecore.SharedSource.PartialLanguageFallback.config file that is included as part of the module in /App_Config/include.
- We already had an include file that contains our site definitions, so the enableFallback key needed to be added to the end of that site definition to get it to work. There seemed to be a "collision" of sorts when the site definition was patched in two separate places, and Sitecore thought the site was being defined twice.
- The "fallback value" labels will not show up if View->Standard Fields is enabled (on the ribbon/toolbar). A separate content editor renderer is used when the content editor is in that "mode."