Wednesday, October 5, 2016

Sitecore 8.2 Dictionary Fallback

An important topic while working with Sitecore is how to handle different languages for the websites.

For example, we have a website that supports the English and Russian versions, all labels are stored in a local dictionary, also we have a global fallback dictionary that has just English version, so if there are no items in the local dictionary in Russian we going to use the Global Dictionary and render English labels.


First of all, we need to add Russian language and set the “Fallback Language” field in the language definitions.


Now we need to create a Global Domain item (/sitecore/templates/System/Dictionary/Dictionary Domain) and a Global Dictionary Entry(/sitecore/templates/System/Dictionary/Dictionary Entry). Each Dictionary Entry item has two fields: Key and Phrase.  Key is a Shared Field which means that the field is shared across all language and number versions and is not meant to be different across versions.  The Phrase field is a multiline text field and is an Unversioned Field, meaning it can differ across language versions.
Do the same for our local dictionary, but set the ‘Fallback Domain’ field to the Global Dictionary Domain


And create a Russian version of the Dictionary Entry:

Now we need to configure the Sitecore to use the Local Dictionary:


<?xml version="1.0"?>

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">

  <sitecore>

    <sites>

      <site name="website">

        <patch:attribute name="dictionaryDomain">Local Website Dictionary</patch:attribute>

      </site>

    </sites>

  </sitecore>

</configuration>

</configuration>

Below is a simple peace of code, it should show us a Title from the Local Russian dictionary and a Description from the Global English dictionary

<div>@Sitecore.Globalization.Translate.Text("Title")</div>
<div>@Sitecore.Globalization.Translate.Text("Description")</div>

It doesn’t work yet, but here is the trick: we just need to enable 2 options in the Global Dictionary Entry and the option “Enforce Version Presence” works as a trigger, so you can even clear the cache then uncheck it, save and it will work again. For me it’s a bug and probably I will do additional investigation soon.


Below is what we have now:

4 comments:

  1. What's the advantage of this approach versus just using language fallback on the dictionary item itself? I've been working with this, and if I just set up a dictionary item with my key, then create language versions off that item for the translations, it handles everything just fine. The "enable item fallback" option is automatically assigned to dictionary items as well, so it's all built in and ready.

    It seems by setting up a local and global dictionary as you describe, you have to duplicate the keys, so there's a chance of a copy/paste error, and if you change a key for whatever reason, you have to change it twice. So I'm not sure why you'd use the domain bit, except to designate a dictionary set for a particular site...I don't know that I'd use the fallback in the dictionary domain to go from one entire dictionary to another?

    ReplyDelete
    Replies
    1. Hi Ken! I don’t do any recommendations, there is a lot of topics about and I’ve just done some investigation. All architecture decisions should be made by an architect depend on the project needs.

      Delete
    2. Item language fallback unfortunately doesn't work on Dictionary items, there seems to be a bug I had to enable Enforce Version Presence - Hide this item if no language version exists [shared] first, republish every language and the language fallback worked, but in reality it should never do the language fallback as you checked to make a presence of version, so even if the item is enabled for language fallback it shouldn't fall back to the language identified in the Language settings. This is definitely a bug as it work on the other content no problem

      Delete
  2. Its a good spot, this still isn't fixed in Sitecore 9.0.1 can't believe that will report this to our team tomorrow.

    ReplyDelete