5 reasons why you should not use variations (and more solutions to keep using them)

For a customer, we're implementing an Internet facing site using variations (and content deployment). For those of you who have worked with variations, you'll know that they are tricky. We ran into 5 concrete problems that I'd like to share with you.

Variations explained
With variations, you create one or more exact copy/copies of a publishing site (MOSS only). The most common reason to do this is to have your site available in multiple languages. Please see this excelent post on how to set up variations.
MOSS creates all variation labels within the same site collection, and that's where the problems begin.

Variation problems

1) Performance
Risk
When you have a large amount of data in your variation source and let that propagate to the other variation labels, it seems MOSS has a hard time getting the job done. This was reported by Jeremy Jameson in a series of 3 blog posts.

Proposed solutions

• create an index on a non indexed column (see Jeremy's post)
• get some high spec hardware for your database server

2) Content types not propagated
Risk
When you add a content type to a page library in the variation source, this type is not automatically propagated to the other labels (see my previous post). If you then create a page with that content type in the variation source, it does get published to the other labels but loses its content type field values.

Proposed solutions

• Set up your site via a site definition that already contains the proper content type bindings to the page libraries. All labels will use the same content types
• Put a good governance plan in place to make sure manual changes are done in every label

3) Values from localised choice lists don't work over variations
Risk
The scenario we were in was having site columns defined in the root level (so above the variations). These site columns were deployed via a feature and used resource files to have the choice values available in all languages.

This seemed to work fine, but when we actually localised the resource files, we realised that the chosen values in the variation source (Dutch) did not exist in the other labels (English and French). What happens:

SharePoint stores the actual values (not the resource key) in the database, so the English page got (after the variation publishing job copied the Dutch page) the Dutch choice value for gender, "Mannelijk" (= Male). I found out by looking in the AllUserData table in the content database. The English choice list doesn't have that value (only "Male" and "Female") and thus did not select anything. This means that with every time you publish a page in the variation source, you'll have set all localised choice values again.

Proposed solutions

• Build a custom choice control that does not store the value but the resource key
• Instead of creating the choices in a field definition/resource file, create a list in the root (above the variation level) and create a column per language. Build a custom control that reads the correct column based on the language.

4) Publishing a page in the variation source overwrites all values in the other labels
Risk
When you first create a page in the variation, that page will need to get localised in the other variations. When that's done, however, any change in the source will completely overwrite the other label's version and you lose all the translation work. For a major change, that would need to be done anyway, but for a minor, it definately wouldn't.

Proposed solutions

• Have versioning and content approval enabled.
• From the White paper: Plan for building multilingual solutions: add a field to the page content type to indicate the cahnge is minor or major. Then add a custom workflow to the content type libraries to delete the draft version in the target variation label libraries if the change is minor.

5) Not all relations between pages work with variations
Risk
Links in pages to other pages will be detected by the varaiation publishing job and set to the appropriate equivalent in the target variations. In our case, however, we used a sort of lookup on other pages as metadata on a page. Example:

We have a publishing page per author. We also have a publishing page per book. Each book is linked via lookup by content type (one of those nifty controls we created @ e-office) to one or more authors. Under the hood we store the GUID of the author(s) with the book. In a variation setting, however, when the pages are published to the English variation, the English book page still links to the Dutch version of the authors.

Another caviat in our case is that Content Deployment out of the box doesn't keep the same GUIDs. I find this a flaw in the product as the API does provide you with the ability to do retain GUIDs in a staging environment (like a lot of these Internet facing site will use). As the UI doesn't have that option, you're forced to write your own Content Deployment jobs. For more info on this, please see Stefan Goßner's blog post.

Proposed solutions

• Do not store the GUIDs but the page URL. Replace the label part with the current label when publishing the page.
• Use the hidden list http:///relationships list to look up the

Conclusions
Let me be straight on this: I think the current implementation of variations suck. I think it's fundamentally wrong to put everything in the same site collection; I'd rather see 3 web applications to keep everything separated or a solution in which you have a language swith in edit mode so you work on the multilingual content in the same page. I'd like to see a solution in which you don't have to hassle with your metadata, and do not have to build a ton of custom controls to handle metadata properly. Not being able to see from the target variations what has changed in the source content is also a fundamental omission in a multilingual product. Looking at the amount of effort you have to put in to make your site multilingual, the missing documentation (does nayone know what translatable columns do exactly?), you realise much is still version 1.0.

However, we decided to keep working with variations as we managed to identify the problems and find workarounds. Not using variations would mean we'd have to write our own sort of variation mechanism. Within the boundaries of time and budget, keeping variations is our best bet.