View Changes is a new SharePoint 2010 Variations feature that compares two versions of a source page relevant to the corresponding target page. View Changes provides a report highlighting the differences between the source version that has most recently propagated to the target and the prior source version that propagated to the target and was published on the target. By highlighting differences, the View Changes button simplifies in-browser content editing using the Variations feature.
I’m Josh Stickler, the Program Manager responsible for Variations. In this post, I will explain:
The most common application of the Variations feature is in multi-language sites. Let’s look at View Changes from the perspective of Anders, an English-to-Danish translator working with the Danish subsidiary of AdventureWorks, an international camping goods retailer.
AdventureWorks is set up with an English (EN-US) site as its source label and target labels for international markets, each corresponding to a different language. Pages from the source label automatically propagate to the target labels when they are published so AdventureWorks’ global web presence is in sync. Translators at each of the targets then process the English-language content for localized consumption. AdventureWorks’ Variations hierarchy looks like this:
Let’s imagine that content authors at AdventureWorks in the United States have just published a new page with a sneak peek of this winter’s new product lineup. Since “Automatic Creation” is enabled (this is the case by default), the page is picked up by the Variations Propagate Pages timer job and copied to all target labels, including Danish (DA-DK).
As the designated owner of the new page, Anders gets an e-mail informing him that this page has been copied to the target label by the Variations feature and is ready for processing.
Anders navigates to the page on the Danish (DA-DK) variation of the AdventureWorks website and sees the English language content. Since it’s all new, he translates all of this content into Danish and submits the page for approval. The page is approved and published and now appears on the Danish variation of the website.
Since Anders received an entirely new page to translate, there were no changes to view; hence, the View Changes button is not available.
Back in the United States, AdventureWorks decides to announce a new product in its sneak peek lineup. English language content authors add a paragraph describing this new product, an ultra light sleeping bag, and publish the page. The page now propagates to the Danish variation.
Anders receives an e-mail notification that new content is ready for processing. He visits the appropriate page on the Danish variation site and the English content appears and is waiting for translation.
But wait, there is a lot of English content here, and Anders has already translated most of it. Only one paragraph has been added. How will Anders know that he doesn’t need to re-translate the whole page?
It’s at this point that the View Changes button comes to the rescue and is available.
Please note that View Changes requires the Variations Propagate Pages timer job to be enabled. View Changes only compares changes between a source version of a page and a target version that has been copied using the Variations Propagate Pages operation.
Anders clicks the button and a version differential window pops up, highlighting the new paragraph that has been added. Now, Anders knows that only this paragraph has been added and doesn’t have to scan through the new and old versions of the English content to determine what he has to translate.
Anders decides he prefers to revert back to the translated Danish version of the page as a basis for adding the new paragraph. With the View Changes window open, Anders knows exactly which paragraph to translate and where it goes. He adds the new content in Danish, submits for approval, and it’s published live on AdventureWorks’ Danish variation site. Fantastisk.
In addition to providing target variation site translators with insight into what content has changed when pages are copied from the source, SharePoint 2010 also enables authors on the source to decide when to propagate content to targets. By default in MOSS 2007, when content authors published pages in the source variation site, that page would automatically propagate to all target variation sites, even for small changes that are relevant only to the source variation site.
SharePoint 2010 provides the ability to disable automatic page propagation; source variation site content authors can then use the Update Variations button to propagate content on demand. See my previous post, “Site and Page Propagation” for more information on how to enable this setting.
Thanks for reading! Keep checking back for new blog posts.
Regards
Josh Stickler
Program Manager
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!
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.
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.
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:
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.
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:
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
$site = new-object Microsoft.SharePoint.SPSite("http://yourserver/sites/abc")
$folder = $site.RootWeb.Lists["Relationships List"].RootFolder
$folder.Properties.Add("DisableAutomaticPropagation", "True")
$folder.Update();
Disable On-Demand Page Propagation:
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
$site = new-object Microsoft.SharePoint.SPSite("http://yourserver/sites/abc")
$folder = $site.RootWeb.Lists["Relationships List"].RootFolder
$folder.Properties.Remove("DisableAutomaticPropagation")
$folder.Update();
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.
Regards,
Josh Stickler
Program Manager