Sitecore Dictionary Structure Best Practices

An important topic while working with Sitecore is how to handle different languages and regions for your website.  Sitecore’s answer to this among other things, is the use of a Dictionary Item which basically just represents a Key/Value definition.  This dictionary item though, can be setup to have different language versions, which pretty much allows you to have a Dictionary item for the “Submit” button text.  And then another version of that item in the Canadian Region, that would maybe use text that would be more region specific, or possibly a Spanish version that is in that language.

This topic is nothing new within Sitecore, however what should be considered is the proper setup/configuration for storing these types of items.  On projects I’ve worked on at my current job, they have typically been stored in the Master database, in the System/Dictionary folder, however I don’t believe that takes full advantage of what Sitecore is capable of doing.  Also storing dictionary items in the system folder has obvious implications, such as standard content editors rarely have access rights to this part of the tree.  In Sitecore version 6.6, they introduced the feature of having a Domain Dictionary.  This allows for more flexibility and allows the Content Creator to have dictionary items that are Site specific (as well as storing those dictionary items in the content tree), and allows for those same dictionaries to fallback when not found in those specific site dictionaries, to other global dictionary folders.

Another feature which I believe less people are actually aware of, is that Dictionary definitions are used throughout the Sitecore CMS interface, especially within the Content Editor.  When you specify a field name, that matches the domain dictionary that’s used within the Shell, it will use the dictionary value for the field name.  So what this means is that you could create CMS specific dictionary items to represent your field names, and then you could create field names that are language specific, without actually having to go in and manually create multiple language versions of your template.

To test this new theory and to show some examples of my recommended best way to handle dictionary items, I am going to walk you through the following implementation, which will create site specific domain dictionaries, a global dictionary, and then a CMS specific dictionary for Sitecore Template fields.

To start, make sure you have a copy of Sitecore running, preferably running Sitecore 6.6 or higher (I’m using Sitecore 8.1).  Once you are running Sitecore, go into the Content Editor.  You will need to create a couple of Dictionary Domains for your site.  I think the best method here is to create at least 2 to 3 dictionary domains.  I would create one at the site level which would contain site specific dictionary items.  Sometimes when initially developing a website, it may be hard to plan where a dictionary item should go (either at the site level or at the global level for all sites), just use your best judgement they can always be adjusted later.  At the site level, I would create an insert option to add a dictionary domain, that makes it easier to add this for future sites.  Also it may be wise to create a Site specific branch that would get created when you create a new site in the content tree, which would automatically create this domain dictionary.

Once you’ve created a site specific domain dictionary, next I would create a domain dictionary in the global folder.  This allows you to put dictionary items that are shared across all the sites in one location.  Again it would be a recommended best practice to include the insert options for the global part of the content tree to include this domain dictionary.  Potentially you might want more than one domain dictionary in your global folder.  Once that is complete, it’s optional but you could add another domain dictionary in you system folder.  The purpose of this domain dictionary is for the template fields you create for your content items.  I will go into more detail about this hidden feature of Sitecore in this **post**.

Once you’ve created the domain dictionaries, your job is not complete.  The next step is to specify fall back dictionary domains, which allows for Sitecore to fallback to another domain dictionary, if the item you are using as the key is not found in the current domain.  So on your Site specific domain dictionaries, you would want to specify the global domain dictionary.  That way, when you specify to look at the site specific dictionary in your site definition file, if the dictionary key can not be found, it will fall back and look in the global domain dictionary next.  This would create a well structured setup that would allow you to organize the dictionaries according to site specific or globally specific dictionary items.

The last step of this setup of course, is to define the dictionary domain in your Site Definition patch file.  I generally like to have the SiteDefinition.config in my Solution so that I can make changes to it, such as this one.  To extend an existing Site Definition from your patch file to include your custom domain dictionary, you would add the following to the patch file:

For the attribute above, just specify the name of the dictionary.  It’s important that you give the dictionary domain name’s a distinctive name.  For example, the site specific dictionary domain’s should be given the name of the website to some variation.  You can call the global domain, just Global Dictionary or something to that affect.

Lastly if you want to define a full Site Definition for the default site in Sitecore, that include’s the domain dictionary, you could do so like this: