Saturday, March 30, 2013

No silver bullet for multilingual SharePoint websites

In 2007 I wrote an advice on how-to deliver multilingual user experience in a SharePoint 2007 based public facing website. Althought the SharePoint Variations concept promised to fulfill this need, our experiences turned out differently. As result my advice was that we better just made a localized copy of the website per language.
This month I repeated the analysis on multilingual solution directions for SharePoint websites; now for SharePoint 2010 (and looking forward to SharePoint 2013). Sadly, the findings have not really improved compared to the 2007 support.

Aspects of multilingual in SharePoint sites

The information architecture of SharePoint based websites differs considerable from plain, php websites. SharePoint artifacts are typically administrated within the SharePoint content database, instead of physical files on the webserver. The SharePoint platform is also very rich with out-of-the-box capabilities and components that are used to construct a website. And for public facing websites it enables content managers to logical extend the websites with new content and composition pages.
In a SharePoint website the text displayed can come from any of the following places:
  1. Contained within physical .aspx and .ascx files in the layouts folder; typically via Resources mechanism
  2. Contained within code of SharePoint controls: standard and custom
  3. SharePoint content database
On deeper level, the following multilingual aspects can be distinguished in SharePoint public facing websites
  1. Multilingual of the SharePoint standard UI (MUI: Multilingual User Interface)
    • menu’s
    • list and libraries column names
  2. Multilingual of custom developed SharePoint components
  3. Multilingual of the SharePoint content
    • Publishing pages content
    • Static html in Masterpages, PageLayouts and SitePages
    • List and libraries items
    • Localized images
  4. Multilingual of SharePoint navigation: Global, Current, Mega-menu
  5. Multilingual of SharePoint search-discovery items: website title, friendly-urls

Solution directions

Manual website-copy per language

This is the most basic and also most flexibel approach. But it also implies that all multilingual aspects must be performed manual and repeated per language website-copy: at moment of the initial website provisioning, and later for each change to its information architecture and content. The latter also beholds a risk: site content manager forgets to propagate a change on the source site to one or more of the language copy-sites.

Site-copy per language via SharePoint Variations

Variations is an out-of-the-box capability of the SharePoint platform since 2007 version. The concept is that you declare one site in your sitecollection as the Variation root, and create + declare sites for other languages as so-called Label sites. Each change to site structure and publishing pages in the Variation root is propagated as draft to all Label sites. Per Label site, the content manager must next translate the propagated page(s), and publish them. Visitors do not see the content as it is propagated from the root site.
The most important limation of Variations is that it does not cover all the multilingual aspects. It only applies to publishing page content. SharePoint list and libraries are not in scope, and still need to be handled manual.
Another major limitation is that Variations cannot be applied as an afterthought to an already existing SharePoint site. It must be applied at start of provisioning the information architecture of the source SharePoint site.
In SharePoint 2007, the Variations functionality suffers from multiple issues that in general gave it a bad press; and there are very limited organizations that actually (trust to) apply it. In SharePoint 2010 the robustness of Variations behaviour should be a bit improved; but there are still only limited known practisioners in real world. Also noteworthy is that the STSADM VariationsFixUpTool is reported by Microsoft self to be still needed for fixing corruption in Variations Relationships list.

Multilingual in-place in the SharePoint site

The idea of this is that every localizable artefact (text + images) in the SharePoint site is inherent multilingual itself; and it server-side renders in the language of choice of the website visitor. Major benefit of such approach is that you avoid the need to maintain individual language site-copies consistent with each other. Most important limitation however is that it alone is not sufficent. You cannot apply this concept to out-of-the-box SharePoint menu’s, webparts and application pages, and also not without modification in SharePoint Web Content Management (Publishing Pages).

Multilingual via SharePoint Language Store

Basically a similar concept as ‘Resources’, and also somewhat comparable to the ‘in-place’ approach. Essence is that all text-parts are administrated in a Language Store that includes per text-part its translations in the multiple languages. The Language Store can be downloaded from CodePlex, however only for SharePoint 2007. It is not upgraded to SharePoint 2010. This approach has same limitations as the ‘in-place’ approach: does not work for SharePoint out-the-box ui-controls, menu’s, application pages, nor does it combine with SharePoint publishing.

Multilingual in SharePoint site via off-the-shelf products

Well, this in itself is a clear proof that multilingual is a complex matter in SharePoint context… The only 2 products found are from smaller and unknown companies (Oceanik and IceFire). Short evaluation of both propositions already demonstrates multiple shortcoming and functional-robustness issues – examples: mix language content on page, translation support not applied to standard SharePoint aspects (e.g. Reusable Content).


  1. SharePoint multilingual is a complex matter.
  2. Multilingual always implies extra work for SharePoint content manager → automatic text translation is yet immature to trust upon for public facing website
  3. There is no 100% automatic solution for supporting all the SharePoint multilingual aspects


  1. We used the Variations functionality of SharePoint 2010 for public-facing sites, along with the multi-lingual UI. It works quite well, but we did have some problems durign content creation. The automatic propagation would need to be turned off otherwise changes to the source language would constantly create new versions of the pages in another language (which annoyed the content creators greatly :-)).
    Using custom created menu's and other components that used resource files we made those multi-lingual.

    Some points you make are reasonably valid, but when you talk as-if a viable working automatic translation system exists anywhere (or will exist in the future) you are wrong of course. Googl translate works nicely to get a general idea of the content of a page in another language. However, it is totally unsuitable to present to a normal end-user.

  2. Jurgen,
    thanks for your reply; good to know of references that have somewhat been able to deal with the multilingual issue in SharePoint. Personally I consider the approach to disable variation propagation during (EACH) web content creation as unacceptable / unworkable. As it is a manual effort, of disabling + enabling later on; the process is error prone. Also it requires that each of the web content managers have the permission to manage the variations capability.

    Regarding the automatic translation: I thus fully agree that we cannot expect a user-viable solution for this in the near future. Linguistics is a tough area to automate in general, the only feasible results are limited to bounded subject vocabularies / matters.

  3. Excellent article! It's true that each successive version of SharePoint offered only partial solutions whether it's MUI or through Variations, and each requires a lot of repetitive work. 2013 is not much better: No more MUI language selection in the personal menu, and integrating simple machine translation risks embarrassing your organization in public.

    I work for the "unknown" company IceFire that makes the PointFire product used by most large organizations. I am surprised that you saw mixed-language content on pages, or translations not being applied to reusable content on publishing sites. Perhaps you were referring to a different product. If you would like to find out how to avoid such problems, feel free to contact for a personal demo.