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 asp.net, 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 asp.net 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).

Conclusions

  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

Saturday, March 9, 2013

DataForm and DataView WebParts cannot display data from other site when on SitePage

DataFormWebPart is a powerful webpart to query and render data from SharePoint content sources on pages in the website. In our scenario we intend to utilize it to conditionaly display reusable content on pages. For the reusable aspect we use the standard SharePoint ‘ReusableContent’ capability. For the conditional part, we aimed to utilize the DataFormWebPart, and via ParameterBinding + Query direct it to retrieve specific ‘ReusableContent’ listitem based on a querystring parameter-value.
The ‘ReusableContent’ list is located on rootweb of the sitecollection. A mature website typically consists of a hierarchy of subsites within the sitecollection. To display through DFWP ‘reusablecontent’ in a subsite it is necessary to set it’s WebUrl parameter to ‘{sitecollectionroot}’.
To check the correct behaviour (reusable + conditional) I used SharePoint Designer to create a page in the website, add the preconfigured DFWP to it, and validate the effect in browser. It turned out that it works (reusable + conditional) when the page is created in the rootweb, but for subsites the DFWP gives an error when opening the page in browser (ULS: List Not Found). Strangely in SPD the DFWP on page in subsite can connect to the list in the rootweb, and you do not experience any problem. I was rather puzzled by this, moreover because I followed the exact directions of posts that instructed this is the way to enable DFWP on pages in subsites. Just when I was about to submit a support call to Microsoft, I decided as last attempt to create a Publishing Page (thus in browser, not possible via SPD), and add the preconfigured DFWP. And guess what; then it works!
As our scenario concerns external facing and thus publishing websites, this is sufficient. Just be aware that you cannot use the DFWP on SitePage to connect to SPList in another site.

Thursday, March 7, 2013

Duet Enterprise 2.0 Authentication flow

One of the changes in Duet Enterprise 2.0 is the Single Sign-On handling. Duet Enterprise 1.0 applies SAML to seamlessly authenticate and authorize the SharePoint authenticated user within SAP NetWeaver Gateway. For Duet Enterprise 2.0 this is no longer possible, result from the internal usage of OData for SAP - SharePoint data exchanges. The Duet Enterprise 2.0 SSO approach is X.509 based. On the Microsoft site you can find information that outlines the essential details of the authentication flow: