Variation strategy to reduce labels overwrite

There is a lot of discussions and articles on SharePoint Variations which contains good arguments on why the feature isn’t all what it’s prepped up to be.  This will not be a post to debate whether they are useful or not but merely how to make them more useful than what I see in the field.

Update: Variation Strategy #2 available at https://blogs.msdn.com/maximeb/archive/2009/08/01/variation-strategy-2-to-remove-label-overwrites-cancel-updates.aspx

 

First of all, when discussing variations with a customer, he’s likely to be sold on the ‘multilingual’ bullet from a PowerPoint slide.  I sometime hear that the feature should do a complete translation automatically (nothing less :)).  The first thing about Variations is to know when to recommend them and when they aren’t useful enough.  After that, the next thing is to have a good discussion with the customer about what it means to use variations.

Here’s a few quick and simple facts on Variations:

1. Variations are simply a mechanism to provision sites and publishing pages between multiple labels.
2. You can have a single set of variations per site collection
3. You can only have a one ‘source’ variation
4. By default, and in most cases, any published updates in the ‘source’ variation will be replicated on all other labels as a minor version.
5. There is also a web part that allows you to select a page in another language.

 

Problem #1 : Information Architecture usually picks the customer’s default language as the source variation

While this should make sense, the default language is usually also the one with the most content updates.  For example, you set ‘English’ as the source label, and you create 2 labels ‘French’ and ‘Spanish’. 

For the ‘Go-Live’, you create all your content in English and it will copy it over in the other 2 labels.  You will have translators going over and fixing your other labels.

Within a couple days (if not before the Go-Live), you start updating content in your English label and authors start complaining in the other 2 labels as their localized content is ‘reverted back in English’.

What happens is that the French Version 1.0 of a page got bumped by a v.1.1 in English.  While the author can edit the page, go back in history and revert the 1.0, he will have to re-approve/publish the page as a 2.0.  This is very annoying indeed.

 

Problem #2 : While you may want to translate everything for a Go-Live, you probably don’t later

Ask your customer if they really want to translate their complete web site all the time?  This is usually not the case.  They may want their press releases but not all news as they are more targeted.  They may want their products or maybe only a segment of products (i.e.: Corp products versus localized offerings).

 

Problem #3 : Documents aren’t copied over the other labels

Well that' one’s a simple fact, variations are only for publishing pages.  In my experience, while some documents are clearly desired in a few languages, all the documents in the sites are unlikely to be required as translated. 

Also, I often see more of a need of a ‘document set’ where you want to see all languages available for a document from any site (i.e.: show me the French and English document in both the French and English site).

 

Problem #4 : Some customers think that it’s all automated

It’s not.  Simple.  A human is required as the glue in between.  The feature does provide a way to export a label (or a section) and there are 3rd-party products that can take that export and provide a system for translators to work more convivially, but there’s a still a human involved.

 

Problem #5 : Creating labels is buggy

Well that’s true but SP2 fixed it by providing an STSADM to create labels.  The problem was that it took too long for the web process to finish the creation and you were left hanging.

 

Problem #6 (misconception really) : You should not edit content in other labels than the source except to localize content

That’s simply not true.  You can author as much as you want in all labels.  The worst that can happen is if you create a site or a page in a sub label; and then you try to create a content with the same name in the source variation.  What will happen is that content from the source will not be pushed down on that sub label only.

This isn’t necessary bad actually, and the variation log will tell you the issue and you can resolve it if necessary.

 

Solutions?

Well if you want to think outside the box, you can surely come up with some workflows or custom events to do the work.  Is it worth it?  Maybe if you really need all the content to be brought on all languages only one time, but hardly.

 

OOB solution? Create a ‘non-visitor’ source variation!

In my opinion, you usually need roughly 30% of your content in all languages, give or take.  But this works even if you have 100%!  What this source variation is simply a ‘creator’.  If you need content for all labels, that’s the place to go.  If you need to update a page’s content with something major for all labels, that’s the place to go and then you’ll have to update all labels. 

But when you want to change a typo or add some comments in one language, that’s not the place to go.

 

So in our previous sample, we had 3 labels required : English, French, and Spanish.  Instead of picking up English as the source, create a label called ‘Source’ or ‘GlobalContent’ (or something that makes most sense to your authors).  This ‘Source’ will be in English but your visitors will not go there.

 

In order to do that, you can either pick a label language that isn’t yours (i.e.: if you are in the US only, pick English UK as your source;  and then English US for the English sub label).  The other way is to customer the Variation Root Landing logic (https://msdn.microsoft.com/en-us/library/ms562040.aspx).

 

Alright, so now you have 4 variations instead : Source (English UK), English US, French, and Spanish.  You will probably have few Contributors in your source variation, maybe only Hierarchy Managers.  You would then set appropriate permissions in your labels only.

 

Remember, only create or update content in the ‘Source’ when it’s global.  When it’s not, authors should go in their respective label and simply create it there.  This is totally safe and supported.

This way, you will rarely erase ‘French’ or ‘Spanish’ content with ‘English’ at each update.  If you define your information architecture and governance right, and you explain the variation process accordingly with your customer and content authors, this will probably be the simplest solution for variations and should cover most of your customer’s needs.