Monday, 4 May 2009

Fix to my Language Store framework for multi-lingual sites

In my last post, I talked about a fix to my Config Store framework for an issue which manifested itself on certain SharePoint builds, with Windows 2008 and a recent cumulative update seeming to be the trigger. Some of you may know that I produced a sister project to this one called the 'Language Store', which is designed to help build multi-lingual SharePoint sites - since this framework is built off the same underlying XML and plumbing, this solution was also affected.  So this post is just a short one to say that the fix has now been applied to the Language Store framework, and the new version is now available on Codeplex at


The problem was effectively that items in the SharePoint list could no longer be edited - well, in fact they could be updated using code, but the list form .aspx pages were not showing the fields correctly so items couldn't be edited in the UI. Since it kind of defeats the point of SharePoint to have to write code to update list items (!), this was a big issue on affected builds. Interestingly some users reported working around the issue by removing/re-adding the content type from the list in the browser, but happily this is no longer necessary since the root issue has now been resolved. The problem was traced to some incorrect XML in my FieldRef elements - see the last post Fix to my Config Store framework and list provisioning tips for the full info.

General recap - the Language Store

If you're still reading, I figure some folks would welcome a reminder/intro on what the Language Store actually does - it's not about replacing SharePoint's variations functionality which is commonly used on multi-lingual sites. I noticed Spence gave it a better name in an e-mail recently where he described it as a 'term store' for multi-lingual sites - this actually captures what it does far better than my name for it. Effectively the idea is to provide a framework for the many small strings of text which are not part of authored page content which need to be translated and displayed in the appropriate language. As an example, here is a page from the BBC site where I've highlighted all the strings which may need to be translated but which don't belong to a particular page:


There are many of these in a typical multi-lingual site, and to help deal with this requirement the Language Store framework provides the following:

  • SharePoint list/content type/site columns etc.
  • API to retrieve items with a single line of code
  • Granular caching for high-performance
  • Packaged as a .wsp for simple deployment
  • All source code/XML freely available

If you want to find out more, see Building multi-lingual SharePoint sites - introducing the Language Store. The solution can be downloaded from the Codeplex site at

Apologies to existing users who were affected by the issue.


Marshal Nagpal said...

Cheers! Chris for solving issue, I will certainly use both store in my future projects :):)

Narayan said...

Hi Chris, Had a small clarification; can this be used to Localize Out Of Box WebPart title field, if yes, can you throw some light how to acheive the same.



Chris O'Brien said...


No, I'm afraid the Language Store can't really help with out-of-the-box web parts - it's for use in your code (e.g. custom web parts etc.)



MOSSBuddy said...

Hi Chris,
I have a simple query on caching that u r doing on config store & language store. As i understand this caching will b done in the W3WP process of the web-app (app-pool) and now if we r hosting lets say 100 site collection all using the language store, and some other stuff doing the HTTP cache do you think there will be memory issues? Or is my understanding about caching and w3wp process is incorrect? Appreciate your advice and thanks again for all the best utilites you have been providing to the larger community.

Chris O'Brien said...


Great question. In one of my recent projects we used the Config Store in a solution with around 90 sites, where there was a 'master' Config Store in one site collection but 'override' Config Stores in the other sites. Because the caching only stores small text values, it would take many thousands of list items (cumulatively) to start to cause a memory issue. Our testing showed that with a few hundred items it was using around 1MB of memory on each server - a tiny chunk if your servers have say 4GB.

If you had 100 app pools that would be different, but other capacity limitations in SharePoint would prevent you using such a design anyway.