For several posts now, I've been talking about multilingual site strategy with Alex Shyba's Partial Language Fallback module and various enhancements and custom integrations to leverage the concept of Fallback and Enforcing Language Version Presence to its fullest capabilities.
Here I would like to talk about a tool that we implemented at Verndale to help our clients understand where their Sitecore instance stands in integrating languages that have been added to the instance. Manoj Balaraman and Husain Abbasi were a big help in getting the tool cleaned up and looking good from a UX perspective. Summit Phadke and Ankit Joshi also helped with the logic.
When a strategy involves multiple site nodes, very quickly a content author can tell what content is going to appear in which site by simply looking at the content tree. In a solution that has a single site node and multiple versions of a page in different languages, it gets trickier.
When you change the language through which you are viewing your content items, regardless of which language you choose, you are going to see all of your content items in the tree. It is difficult to see what is missing from a language (by design or not), what language has its own unique content, and what language has content that is falling back to the content of another language.
Some of our clients consider the different language versions of their site as different 'sites', from a business perspective. Their users will pick Germany, or Spain, or France, and to the client, that is a different site, even though it is the same site node and potentially some of the same content falling back to English.
Our clients wanted to be able to see what their site content tree looked like in different languages. And thus the necessity for the Language Fallback Report Tool.
This tool has a similar look and feel and even some similar filter options as the Language Migration Tool.
At the top, it outputs the list of fields that are used to check whether a language is falling back. This setting is configured in the Sitecore.SharedSource.PartialLanguageFallback.config:
<setting name="Fallback.FieldToCheckForReporting" value="Headline,Sub Headline,Main Content,Teaser" />
And you should include the fields that are common and important to most items, to determine if they are falling back or not.
Remember, Alex's module is called 'Partial' for a reason, fallback optionally occurs on ANY of the fields individually, depending on whether any of those fields have values explicitly set into them on any language. You could change the Headline on an item and then let all of the rest of the fields fall back. So in that case, would you consider the item as a whole falling back, or unique? In our opinion, it made more sense to consider that unique, if the point of this reporting tool is to figure out what items might still be pending translation, etc. You could update this setting to have more fields in it, but in this example, we are only picking the most important.
The first few filter options allow the user to specify the database and the path in Sitecore to begin the report:
Obviously the less specific you are in the path, the longer the report will take to run. It is recursive and will go down through all of the descendants of the starting path.
The next field allows you to pick the language for which you want to run the report and the way you want to filter the results.
This will allow you to choose from all languages added to the system and defaults to 'en'.
The select box contains 4 options:
If it does not qualify, by default, all of the items will still be output, but the font color of the item name will be gray instead of black.
In order to qualify in the results, the item must have the selected language version
. Items WITHOUT Version In This Language
In order to qualify in the results, the item must NOT have the selected language version
. Items With Content In This Language (explicit)
In order to qualify in the results, the item must have content added to the selected language version in one of the important fields configured and listed at the top of the tool (eg Headline, etc)
. Items WITHOUT Content In This Language (fallback only)
In order to qualify in the results, the item must NOT have content added to the selected language version in ANY of the important fields configured and listed at the top of the tool (eg Headline, etc), all should be null in that language version.
HOWEVER, if you selected the Hide Filtered Content checkbox:
Then the items that do not qualify will not be output at all, with the exception being if a parent item that doesn't qualify has children that DO qualify, then the parent will be output anyway, in gray.
Once the report is run, the results will show below in an expandable tree. A legend will explain the color-coding of the language output to the right of each item.
By default, the languages are hidden and can be toggled to view by clicking the icon to the right of the item name:
Each language version is displayed and will show with an arrow if it is falling back to another language. NOTE, if there is multi-chained fallback, eg: es-US -> en-US -> en, it won't show the full chain, but only the language it is ultimately falling back to.
So if en-US had one of those fields with explicit content set, then es-US would look like this: es-US -> en-US.
BUT if en-US didn't have values set, es-US would look like this: es-US -> en
Clicking the Expand All button will open up all of the children items AND all of the language listings for all items.
An example of a good use of this tool is if a client isn't sure what items remain to be translated into a particular language. They can run this report, set the path to the home node, select the language, and then select 'Items WITHOUT Content In this Language' and check 'Hide Filtered Content'. The resulting list of black colored items will be all the items that still need to be translated.
The addition of this tool should help alleviate any concerns of your client when recommending a solution that uses only one site node for a multilingual site. They can rest assured that they will still be able to quickly see what content exists or does NOT exist in specific languages.
Similarly to the Language Migration Tool, you can make this tool easily accessible by putting the code into your code base, in 'sitecore modules'. Then in the core database, add a new Application item to the Applications node, named Language Fallback Report:
And then add it to your Sitecore Start menu as an Application Shortcut, named Language Fallback Report:
In my next and final post on the matter of multilingual Sitecore sites and Language Fallback, I will discuss additional configurations and settings, layouts and media, conditional rendering, personalization, translator tools, and other cultural considerations.
Link to Resources: