Variations in SharePoint 2010 – Connecting People with Content

When you provision a new SharePoint publishing site, one of the first options you’ll see on the default welcome page is to use the Variations feature to manage multi-lingual sites and pages. My name is Josh Stickler and I'm the Program Manager responsible for Variations. In this post, I'll provide a brief overview of the Variations feature and highlight main improvements in SharePoint 2010.

If there are additional areas that are of particular interest to you, please post in the comments section and I will try to address as many as I can. I’d really appreciate getting any and all feedback. Thanks!

What is the Variations feature?

Variations is a SharePoint feature that facilitates the management and maintenance of content that can be served to multiple audiences. These audiences can vary in terms of different languages, countries, or regions, but they can also represent different brands or devices.


How does Variations work?

For each channel you wish to serve content, you can specify a Variations label. Labels are instantiated as SharePoint publishing sites and the full set of labels in a site collection is referred to as the Variations Hierarchy. I refer to SharePoint publishing sites created and managed by the Variations feature as “variation sites.”

Using variations, target variation sites reflect one source variation site in terms of pages and site structure. When setting up variations, specify one variation site as the source; all other variation sites are targets. By default, pages published on the source variation site are copied to all target variation sites as draft versions and sites created on the source are created (not copied – this is an important distinction) on all target variation sites. You can only have one source variation site per Variation Hierarchy and you can only have one Variation Hierarchy per site collection.

What’s new in SharePoint 2010?

The concept and core architecture of Variations, in which pages and site structure are replicated across multiple variation sites in a site collection remains the same as in Microsoft Office SharePoint Server 2007; however, we have made significant improvements to better meet the needs of enterprise customers serving content across multiple channels.

These improvements can be divided into four categories:

  • Server Citizenship
  • Content Distribution
  • Editing Experience
  • Reliability

Server Citizenship

Variations operations now execute in the background via timer jobs. For the end user, this means that you no longer have to wait at a progress screen for operations to complete.  For the system administrator, this means that the cost of resource-intensive operations like Create Hierarchies can be better managed.


You can adjust the frequency with which Variations operations run in Central Administration. Next, I’ll explain the difference between the “Create” and “Propagate” timer jobs in the context of improvements we’ve made to the Variations content distribution models.

Site and Page Propagation

MOSS 2007 featured two models for distributing pages across your Variations Hierarchy:

1. Automatic Creation: If “Automatic Creation” is enabled on the Variation settings page (it is enabled by default), then publishing a page on the source variation site will cause that page to be copied to all target variation sites.

2. Manual Creation: If “Automatic Creation” is disabled, then the “Create Variations” Ribbon button is the only way to copy a new page to a specific, individual target variation site.

We’ve received feedback that there are often cases in which changes need to be published locally to the source variation site without being propagated to all targets. For instance, if the source variation site has a typo in English, the correction may not be relevant to a target site in German, so if the correction is published in the source page, it can be unnecessarily confusing to copy this changed English version to all target sites.

In SharePoint 2010, we introduce a third, “hybrid” content distribution model:

3. On-Demand Page Propagation

A setting has been added (configurable through the Object Model) to disable Automatic Page Propagation. When the setting is enabled, publishing or approving a page on the source variation site will not cause that page to be copied to any target variation sites. The "Automatic Creation" setting will be ignored for pages. "Update Variation" and "Create Variation” are the means by which a user can distribute content across the Variation hierarchy on-demand.

I’ll go into more detail on content distribution models in a future post. But so as not to keep you in suspense on how to configure on-demand page propagation, here are the PowerShell commands:

Enable On-Demand Page Propagation:

$site = new-object Microsoft.SharePoint.SPSite("http://yourserver/sites/abc")
$folder = $site.RootWeb.Lists["Relationships List"].RootFolder
$folder.Properties.Add("DisableAutomaticPropagation", "True")

Disable On-Demand Page Propagation:

$site = new-object Microsoft.SharePoint.SPSite("http://yourserver/sites/abc")
$folder = $site.RootWeb.Lists["Relationships List"].RootFolder

We’ve also made improvements for target variation site content owners to better understand what has changed on the source variation site when new draft versions appear on a target variation site.

Editing Experience

To make efficient use of their time and effort, target variation content editors need an easy and informative way to determine what content is new when pages are propagated from the source variation.


A new “View Changes” button compares the most recent source version propagated to the target with the most recent source version published on the target.  Changes are highlighted in a pop-up report to enable content processing directly in the rich-text editor.


Highlighted report


Corresponding location in the Rich Text Editor

This button is available on a target variation page after it has been published once and a new draft version has been copied from the source variation site via one of the Variations timer jobs. I will go into more detail on this new feature in an upcoming blog post dedicated to explaining View Changes with screenshots, a sample workflow, and an example scenario.


One of our main goals for Variations in SharePoint 2010 is to make the feature more reliable so enterprise customers can entrust management and distribution of content across multiple channels to Variations.

Now that Create Hierarchies runs in the timer service, we support pausing and resuming this operation during timer service recycles to support long-running operations in large deployments. This also means that the process is not affected by Application Pool recycles. We’ve also made the relationships list, which tracks all target pages linked to a source page, more robust. We now track variations pages using GUIDs for better performance and scale.

Thanks for reading. Check back soon for upcoming blog posts on what’s new in Variations and other exciting developments in Enterprise Content Management.


Josh Stickler

Program Manager

Comments (8)
  1. Mohan Taneja says:

    Based on PowerShell commands above:

    Is the on Demand Page Propagation available only at a Folder level or other levels also i.e. Page Level, Entire Page Library etc.


  2. Mohan Taneja says:

    One of the areas that needed improvement in Variations in MOSS 2007  was Custom Content Types. When custom content types were used – a custom site definition was needed for all destination labels. Is that taken care of in SharePoint 2010 i.e. no need to create custom site definition now?

  3. Andrius Mazeika says:

    Josh, thanks for bringing these amazing news! We are heavily relying on variations in our multilingual implementation (used by ~50,000 users). The major pain areas are listed below. It would be great to hear your feedback as to whether they will be improved.

    1. Robustness of the relationships list. Great news that it’s being improved. We had numerous issues with corruption and ended up running variations fixup tool to fix it. Moreover, in some cases the relationship information in pages themselves got corrupted. Will the relationship information continue to be stored in the relationships list as well as in the page properties?

    2. Performance of the language switcher. The language switcher used to switch between different variations is super slow when you have around 10 variations running. Is this going to be improved?

    3. Delete property for sites. The relationship list stores the information on whether a page in the target variation has been deleted and then looks at the variations settings to check whether it should be re-created when source is re-published. This is very useful. However the same functionality is needed for sites. Unnecessary sites need to be removed from the target. However, due to the lack of robustness, variations fixup tool needs to be run sometimes and re-created the deletes sites. Is this due to change?

    4. Web part updates and web part version history. This is the MAJOR pain for our publishers. We had to turn web part updates OFF because the behaviour was inconsistent. Some changes to web parts were variated and some were not (deleting a Content Editor WP never seemed to trigger WP updates). Moreover, a minor change on a web part cause the whole page to be overwriten in the target variation. Futhermore, it was impossible to tell what has changed in the page and, most importantly, impossible to revert to a previous version.

    I guess these are the main pain areas for us. I might more later though 🙂

    Would be interesting to hear your views on these and also if there are any improvements planned to solve these issues.

  4. Andrius Mazeika says:

    another question:

    Variation Settings and Variation logs. Would it be possible to make some variations settings site specific (instead of site collection?). Some target variation publishers use different publishing practices and might for example prefer to have deleted page re-creation enabled.

    Variations logs currently are absolutely awful. Filtering is impossible, they don’t store older entries, exporting them to excel is impossible, etc. most importantly, they are only accessible by Site Collection admins. With variations being so flaky it makes sense to have it accessible by publishers so that they would know what went wrond with their content and they could send the error to IT support and thus speed up the process.

  5. Vishnu says:


    I am having a small clarification regarding variations in 2010.

    Presently in our project we are having source label en-US.. and in this label we have around 200 Pages , 300 images in Pages and images libraries respectively.

    Content authors were trying to create target labels lets say fr-CH.. But after creating the target label and clicking create hierarchies.. they are getting timer job runs only in this schedule..

    So we suggested them to change the timer job time instance and asked them to click.. Run now option their.

    And they are telling that event though they wait for a long time they are not able to see that hierarchies getting created for targets..

    as there are around 200 pages, 300 images i know that it will take time.. but they are waiting for a lot of time even though they are not seeing any progress..

    Let me know is there any way to check whether the create hierarchies works or any logs we can refer.. as in sharepoint 2007 we can see the error there only if any.. i dont find similiar thing in 2010..

    Let me know the prcedure for checking whether the timer job starts or not.. and how to change the schedule..

  6. Rajan says:

    Can you explain about Translatable Columns? Is these are part of SharePoint Variation?

    Also please tell me how i can translate the content to other languages, as there is no inbuilt tool to translate the content in different languages.

  7. Sandip Patil says:

    Hi Josh,

    I m facing some problems in variation( 2010 ). I have created one site (English) in site collection root and created 10 pages in it.  After that my client need site in Arabic so i decided to use variation feature for this.

    Settings are like below

    Variation Settings

    Variation Home: /

    Automatic Creation: Automatically create site and page variations

    Recreate Deleted Target Page: Recreate a new target page when the source page is republished.

    Update Target Page Web Parts: Update Web Part changes to target pages when variation source page update is propagated.

    Notification: Checked

    Resources: Reference existing resources

    Variation label

    English: Source

    Arabic: Destination

    After  that i created Hierarchies.

    Problem is

    Two sites are created there, one for English and Arabic in site collection.

    URL are like



    My old site also on the same place, URL is below


    What i m expecting is, English site should have all the sites/pages like old site and Arabic site should follow English site.

  8. Hi Josh,

    I hope you, or someone can help here.

    I have a source pages library (in Danish) which contains a lookup column (which displays title from a Departments list in the same SPWeb). The target variation (in English), has been created succesfully, and I have activated a custom feature in order to make the lookup column display title from the Departments list in the target SPWeb (which contains the translated department names)). At first, this appears to work ok.

    However, whenever a new page is created in the source variation, and the Variations Propagate Page Job Definition timer job runs, it seems to do more than simply create the new page in the target variation site. It also appears to update the definition of the lookup column on the target variation, by changing the listid settings to match that of the source, and thereby take data from the Departartments list in the source SPWeb.

    Is this by design? If so, is there a better way to achieve my goal of propogating publishing pages which contain a lookup column, which also needs to be translated in the target variation?

Comments are closed.

Skip to main content