We encountered a problem which seemed really strange while provisioning our site collection with PowerShell (New-SPSite). Our provisioning contains programmatic custom list creation to our publishing webs via feature receivers. The procedure is that the feature receiver creates the list with a URL friendly Title and then changes the Title to a UI friendly version. Say, a list “orderform” is created and then the name of the list is changed to “Order Form” would result that we have a list “Order Form” at URL http://sharepointsite/lists/orderform.

What would you say if I told you that you can’t change the Title of a list after it is created with PowerShell or custom console app, if you are working with sites any other language than English. Well it’s true. I’ve tested it with two Team Sites, one in English and another in Swedish and by creating a generic list “Temp” to both of them. Then I tried the following PowerShell commands on both of the sites.

• $web = Get-SPWeb(“http://sharepointsite”)
• $list = $web.Lists[“Temp”]
• $list.Title = “Temp2”
• $list.Update()

The commands above update the “Temp” List’s Title to “Temp2″ when my $web is the English team site but nothing happens if I run the same commands to my Swedish site. First I run the PowerShell commands to the sites

Then I wonder why the Swedish site’s list title has not been updated…

…while the English site’s list title is updated as expected.

The resolution to the problem lies in the API. While trying to figure out what was going on by narrowing our use case which was a pretty large scale provision to the fact that you can’t edit list’s title even with PowerShell consisted of the following steps and remarks:

• The SPList SchemaXml property consists of a root element List, which has an attribute Title: the english site had Title=”Temp2″ while Swedish site had Title=”Temp” but the SchemaXmlInCurrentUiCulture property had a correct Title-attribute in the Swedish site’s case Title=”Temp2″
• After running IISRESET, the first page load in Swedish site’s /_layouts/viewlsts.aspx showed the updated Title “Temp2″ of the list but after that page loads resulted the Title being the original “Temp”
• While Googling, I came across this blog post by Vojtech Nadrovnik, which describes a similar problem but with SPField‘s DisplayName and the fact that Vojtech resolved the issue with reflection after first digging into the SharePoint code with a disassembler
• Following Vojtech’s example, I tried some disassembling myself with ILSpy and found out that there is a very similar condition in SPList’s Title property’s setter (the last if) as seen in Vojtech’s SPField case

Some properties ARE NOT updated if the Thread’s UI Culture IS NOT the same as the web’s UI Culture.

If you have a feature and a receiver which might be activated by some other means than from the UI (_layouts/ManageFeatures.aspx) or any other piece of code that might be run outside SharePoint’s context, you could handle the problems described above by changing the thread’s UI Culture to the web’s UI Culture programmatically and it would work in any language as the following sample illustrates (different from Vojtech’s resolution):

Popularity: 5% [?]