Content Query Web Part

My goal was to have multilingual summary links.
I tried to implement it through the combination of custom list and content query web part.
Our web site is in multiple languages. Image you have the OOBT summary links placed on pages in different languages, and that you update them one by one. It would be so painful for a person who does not speak the language(s). And it would br very tidious as well.
So my idea was that I have a custom list containing all links, each marked with a language. And using content query part to filter them. For instance if it is on an Arabic page, it picks up only links marked as in Arabic.

First, I defined my multiligual link content type as an inherited type of the built-in link type.
Then I added; language column (built-in), ImageUrl column (custom) of publishing image (comes with the UI that allows my users to browse thru image libraries to select an image) and LinkSortOrder column (custom. Useful also to group links to the same contents in different languages).

Next, I created a custom list of the type.
# I do not think defining the type, and then defining it as the type of the list was required. You could have a list with those columns directly defined. It was a design choice.

Then I prepared a page layout per language. Again a design choice. I may be able to have just one layout to serve all different languages.

Now to customize the presentation.

As you know, it is to write a XSLT code to render the XML returned from CQWP in a way you like.
First, we want to have a look at the XML. I found a good post here http://www.sharepointblogs.com/radi/archive/2009/03/17/content-query-web-part-getting-a-full-dump-of-the-raw-xml.aspx.

However, the challenge was to figure out how to tell the web part to use my XSL rather than the default one.
I have the CQWP placed on a page layout, not a page. I did not find many who do this on the net. At the beginning, I did not think this export/upload was a solution to my case. I gave it a try nevertheless and found out that it is a hidden attribute. “hidden” here I mean, you do not see it by just creating an instance of the OOTB CQWP. So all you have to do is just add it manually.

<PublishingWebControls:ContentByQueryWebPart … MainXslLink="/Style Library/XSL Style Sheets/myContentQueryMain.xsl" … >

In the XML that I finally managed to look into, of course I do not see those columns I added. So I specified the following value to another hidden attribute.

CommonViewFields="URL, URL;ImageUrl, Image"

The URL is a column defined with the built-in Link type.
To determine the types (comes after comma for each column) was a challenge too. It still is, when I do this again for other purposes.
This document http://msdn.microsoft.com/en-us/library/aa981241.aspx is the most explanatory that I found, but still not stisfactorily clear.
For instance, in addition to the URL type, it says now we have another type called Link. I tried both but did not see the difference. They are the same in the XML. I think Microsoft should give us a table where we see the matching between Content Column type and type should be used in the CommonViewFields and other similar properties of CQWP…

Once you have those columns you added appear in the XML, the rest is just usual XSLT coding that many already talk about on the net.

After having gone thru this exercise, I think now that to deal with a custom list such as this one, a better, more beautiful way would be to have the completely own set of columns appear in the XML using yet another hidden attribute called ViewFieldsOverride. There is a nice article http://sharepoint-tweaking.blogspot.com/2008/04/displaying-listname-and-sitename-when.html.

A better still would be that Microsoft, or somebody (though I would rather not to go to a third party solution) come up with a CQWP-like webpart that generates XML according to the custom list and/or content type specified. It may be difficult though, since then what I could have as the default XSL…