Adventures in Regional Settings with Content Query Web Parts & RSS Viewer Web Parts

  • Article

Here's another interesting one I encountered with multilanguage WCM sites while living here in Europe. Seems simple enough, but as always with multilanguage sites, appearances can be deceiving...

The Requirement

This one's pretty basic. We've got a couple of big lines of business for my customer, and they each have large intranet portals that use CQWPs to aggregate intra-site content and RSS Viewers to aggregate content from outside the site collection. In the course of building their portals, the site owners came up with the fairly common requirement of developing site collection-specific styles for presenting content in these CQWPs and RSS Viewers - special formatting for titles, descriptions/content, and authors, images, etc. Rules of engagement for this environment forbade customizations without a strong business case, so we were limited to OOTB web parts, browser-based customizations, and SPD-based customizations. 

The Initial Solution

The RSS Viewer solution was a simple design pattern. Develop the custom XSL, embed it in the .webpart configuration info, and install the .webpart in the Web Part Gallery for the site.

The CQWP solution was only slightly more complicated. Develop the custom XSL, install it in the Style Library, update the .webpart configuration info to reference the custom style sheet instead of ItemStyle.xsl, and install the .webpart in the Web Part Gallery for the site.

The Complication

The site collections involved here had sites in more than one language in each site collection, as they were using variations. This means that the formatting of dates in the RSS Web Parts and CQWPs could be an issue - using a static date format as per the customer's original specifications would be a problem. For example, sites with the English-US region would use the M/D/YYYY date format, while sites with the Dutch-NL region would use D-M-YYYY format for all standard fields. If we hardcoded one of these formats in the RSS Viewers or CQWPs, we could potentially have dates appearing in multiple formats on any given page. Ugly.

Fortunately, there's a handy XSL function in the ddwrt namespace called "FormatDate" for addressing this issue - it takes a string, LCID, and format type as arguments to adjust the date format, as described here. Unfortunately, there are two major problems in getting the right LCID unless you can extend these webparts:

  • The RSS Viewer Web Part has a hardcoded parameter in its XSL that sets the LCID to 1033. It has nothing to do with the Regional Settings for the site.
  • With CQWPs, there is no LCID parameter at all that is accessible to the XSL.

What to do?

The Solution (Browser/SPD Customizations Only)

For the CQWPs, we're fortunate enough to be able to select from the multiple styles at our disposal via the XSL file in the Styles Library. For each item style that includes a date, we can simply create a separate template for each language - the same template, with a different LCID argument and a different name. For example, we could have "Date and Title (Dutch-NL)" and "Date and Title (English-US)" as separate item styles. Train the users to select the appropriate style for that site. Slightly ugly implementation, but user-friendly if you have a limited number of languages, and it sticks to the rules of keeping the customizations within the site collection. Solution architecture remains unchanged - we just have slighly more elaborate XSL.

For the RSS Viewer, things get uglier. The only way of selecting the XSL is by specifying a URL to an external XSL file in the "XSL Link" field. So you have one of two options:

  • Store a version of the RSS XSL for each language and train users to select the right one
  • Store a version of the RSS Viewer for each language and train users to select the right one. I prefer this option since it's simpler from a training perspective.

The Real Solution

Both of the workarounds above are only practical if you have a very small number of languages and can absorb the training costs for a small pool of content authors. For an enterprise-level deployment of this kind of functionality, you need to implement custom versions of the CQWP and RSS Viewer that can pull the LCID out of the SPWeb.RegionalSettings and pass it to the XSLT (or find third-party versions that do the same).