by zebsadiq
9. March 2015 21:52
While working on a SharePoint 2013 project, I have had the requirement to fulfil a multi-language requirement. In trying to work up a solution to this requirement, I have been looking at the functionality offered by variations during which I have discovered a few limitations.
The first thing to point out here is that most of the limitations are documented in Microsoft’s documentation. However they are not explained in much detail. There are no scenarios given to accompany these limitations.
Here I will try to outline my scenario and how the limitations constrain my objectives.
Constrains of our current solution:
- Our SharePoint solution a sandboxed solution (build as a cloud friendly solution).
- It is installed on an on premise environment.
- It consists of various branding assets, content types, page layouts, master pages etc..
- It contains web templates (which are sandbox compatible).
The client is a world wide organisation. It has many regions in different countries. Each region needs to be treated equally.
Client’s requirement:
- Region Wales needs it’s content to be translated from English into Welsh.
- This is going to be unique content that will be created especially for the Welsh region.
- The Welsh region is currently a sub site of the root site collection.
- A region site is made up of different web templates, page layouts and content types.
- There can be a requirement for Scotland to also have it’s content translated into the Gaelic later. Therefore the solution needs to be replicable.
This following information assumes that you are familiar with the terminology outlined in Microsoft’s documentation about variations.
Limitations in my scenario
- For the source label site (in my case British English ‘/en-gb/’), one can only select the site templates ‘Publishing site’ or ‘Publishing site with workflow’ – This is a problem for us as we have already developed the region sub site template using a web template, which is in a sandboxed environment. It would be quite extreme to use feature stapling on the out of the box publishing site template as this may affect any other usage of that template. Therefore this is a problem.
- There can be only one site variation root per site collection – This causes another issue, what if we want to have multi-language functionality for another region in the same site collection? e.g. Scotland. This would be mean that we may have to create Wales and Scotland as their own site collections rather than being able to have the same site structure for each region. We could make all region sites inside their own site collection or risk causing a political problem within the organisation.
- Variations do not synchronise custom list – We are able to create a sub site under /en-gb/ (British English source site) using our custom region web template. The variations services successfully replicate these sub sites under the target language sites however, it does not replicate any custom lists in the source site. The only lists that are created in the target sites are the out of the box lists such as Documents and Pages. This is a problem for me as we have many custom lists inside our solution at various different levels.
- There is only one way synchronisation between the source language and target languages – This is potentially another issue as pages created under the English section do get replicated under the target language sections, however pages created in the target language section do not get created in the source section. Therefore this could end up causing inconsistencies between the source and targets.
- Pages do not get synchronised until they are published – Therefore one version of the page has to be ready before the target version of the page can even get translated and worked on. I think this quite a big flaw as users will have to wait for the target language version to become available. This is not good in a politically sensitive environment.
I’m look at the alternative to variations at the moment. Hopefully Microsoft will look at this important feature and remove these limitations in future versions of SharePoint.
Further reading: