SharePoint Variations - How they did Variation Landing Page

When we talk about SharePoint Variation, we usually think of that as making sites multilingual. Yes that's correct.

I will not be describing all in depth of Variations like how Variations can be set up and about installing language packs, there are many good articles that describes that in detail.

What I am really interested in explaining is how SharePoint Variation Redirections happens.

It all starts from creating Variations hierarchies.

When all Variation labels are set up and one presses the create site hierarchies link then SharePoint creates a timer job called Variation Create Site Hierarchies job (SharePoint 2010); what that job does internally is (I tried using reflector here for internals) it creates a variety of sites in different languages referring to web temp files in 14 hives (depending on the language) and also creates a page called VariationRoot.aspx.

Now this VariationRoot.aspx page is set as the welcome page for the site; the idea here is to expose this page to all users and do some action as soon as the user visits this page and redirect them to the appropriate variation site url. In doing that we never actually see or visit VariationRoot.aspx but instead get redirected to Variation Site.

What does VariatonRoot.aspx have?

Well, I looked to see what VariatonRoot.aspx has and I figured out that this page is provisioned by using page layout called VariationRootPageLayout.aspx.

What VariationRootPageLayout has?

Now to dive deeper. The page layout contains a user control called VariationRootLanding.ascx.

The actual process of redirection is done in this control.

I will explain how.

This is generally a browser culture identification approach. When a request comes to this page then the user control tries to get the culture preferences of user's browser and tries to redirect user to nearest available variation site.

Code:

Control maintains two Dictionary objects on each page load of landing page.

Dictionary<string, string> cultureCodeToUrlMapping = new Dictionary<string, string>();

Dictionary<string, string> cultureCodeStrippedToUrlMapping = new Dictionary<string, string>();

The first dictionary object contains the actual language culture code as key and variation site url as value.

Key Value

Example: en-US , http://www.test.com/English

fi-FI, http://www.test.com/Finnish

de-DE , http://www.test.com/German

so this is the primary criteria on which just a simple check is done on the requesting browser's culture and searched in dictionary object.

The second dictionary object contains stripped culture code and url mapping.

Example: en , http://www.test.com/English

fi , http://www.test.com/Finnish

de , http://www.test.com/German

Why is this needed now?

Suppose I have a variation site with culture en-US and user's browser requesting culture as en-IN then what to do in this case?

If the exact key is not found in the first dictionary object then SharePoint searches in the second dictionary object with stripped key to redirect users to the possibly closest culture variation site.

So in this case users with browser culture en-IN will be redirected to en-US variation site.

So basically this is the concept used in OOB VariationRootLanding user control. In the next article I will write something on how we can customize this or create our custom VariationLandingPage.