Here’s another SharePoint search classic that instantly became my favorite: IE Language settings in Search Queries.
Recently, one of our customers implemented an internet facing web site and used a search engine. After a week or so in the air, the Q/A team encountered some nasty and unexplained behaviors regarding the Word Breaker that is used for keywords. We’ve investigated this issue some more and found out some “small words” in the MOSS manual: if you index content using one wordbreaker but your client uses another wordbreaker for searching content – the result will be terrible since non of them will be used. In other words: if you index your content in one language but the user is configured to use another language – you’re screwed!Now, and this is where this becomes interesting: the client configuration is determind by IE (or any other browser) and not the regional settings of the OS. This configuration is also known as the “ACCEPT-LANGUAGE” header of the browser. SharePoint Search was developed to intelligently capture the browser accept-language header when processing the query and use it to set the user’s language. By the way, this setting is also used in the “Spell Checker” feature in MOSS – it will appear only when the Spell Checker for the client’s language is installed. This means that different clients will see different results (some with Word Breaker and some without) and the Speller will appear in what looks like total randomness. If we need to summarize this weird story: Microsoft had a good idea (giving different languages – different behaviors) but the implementation was “problematic” at best and most of the time will be categorized as a bug and not a feature. Hardly the first time…
So, can we work around it? Is there a way to execute a MOSS search query without taking the IE language settings into account? Well, the quick answer is of course: NO (Damm). However, we were able to bypass it with a nice little trick.
Basically, when a configuration is taken from the browser – it could easily be manipulated via code. This gives us a very simple solution to the IE Language problem. Here’s what you need to do:
Create your own search results page (can be done by copying the default)
Configure the search to use your new results page.
Now, use the new page and code it to set a hard-coded culture – The code should be executed in the page load event. That’s it. Effectively, this will make a unanimous culture for all of the clients in the system and the speller/results will always the same.