You should probably take another look at using Sitecore Dictionary Domains

I’ve seen a couple of posts recently regarding custom implementation of the Sitecore Dictionary or some sort of custom functionality for handling multilingual content labels. My question is Why?

Ever since Sitecore Dictionary Domains were introduced in Sitecore 6.6 I’ve thrown away my custom Dictionary functionality in favour of the new out-of-the-box Dictionary Domains.

Dictionary Domains are great because:

  1. No more Dictionary under the System node – You can add a dictionary anywhere in the content tree. You are no longer tied to using the default dictionary located under the System node in the content tree. The default dictionary is not in an optimal location since most content authors will not have the proper security permissions to access it in that area. Instead you can now add one or more dictionaries under the Content node so you can easily add/deny access rights like any other content. This alone is enough for me to use Dictionary Domains!
  2. Separate dictionaries for multi-site solutions – You can add many different dictionaries to better separate multilingual labels. You can imagine that this is fantastic for multi-site solutions since it is incredibly easy to add/deny users access to certain dictionaries depending on what sites they have access to. Furthermore, you can set each dictionary to have a fall back dictionary so that it can reference a different dictionary if it can not find the proper key itself.
  3. Enhanced re-usability with separate dictionaries for modules  Having separate dictionaries is also great when creating reusable packages or modules. You can create dictionaries in a modular fashion that can be installed on their own so it’s easy to discern which dictionary items belong to which modules.

I find that a lot of people have had pretty poor experiences with the built in Sitecore dictionary in the past. And rightfully so! Personally I don’t think the Sitecore dictionary was ready for prime time until the Sitecore 6.6 release.

Sitecore 6.6 introduced the Dictionary Domains (that I spoke about above) and also fixed a NASTY bug in Sitecore 6.5 that rendered the Sitecore dictionary unusable in a multi-server environment. I can assure you that things are now in good shape and it’s probably time to give the Sitecore dictionary another chance if you’re not using it.

You’ve probably seen the following code snippet to call the default Sitecore dictionary.


And here is the snippet to call a specific dictionary domain. The first parameter is the name of the dictionary domain you are referencing.

Sitecore.Globalization.Translate.TextByDomain("Site1 Dictionary", "text-label-key");

Having said everything above, there are definitely still situations where it makes sense to create your own custom dictionary functionality. One of the more interesting implementations I’ve seen was from Tim Braga where he creates a model of the Sitecore dictionary so dictionary terms can be referenced as objects much like you would reference Sitecore items in an object mapping framework. Pretty cool!

Posted in Sitecore
6 comments on “You should probably take another look at using Sitecore Dictionary Domains
  1. tbraga1983 says:

    Thanks for the kind words, it recreates the dictionary reference file every time you create/save so once you create the dictionary item you can reference it right away 🙂

  2. mawkstiles says:

    I was on the fence but you’ve covered the issues I was concerned about. Mostly the location. Allowing content editors to access the dictionary under the system node was always a problem. I also like to separate the dictionary by site. Scalability is almost always overlooked.

    Keep up the good posts.

  3. What about page editor? Can dictionary domain be edited in the page editor as a usual field?

  4. […] code of the class above must supply the Domain name for the Sitecore Dictionary via the Domain property on the […]

  5. […] allow you to have separate dictionaries per site, or however you would like to separate them. More info can be found here. If using Domains, you’ll need to modify the code […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s