Sitecore 7.0 introduces a feature called Execution Context. When indexing or searching for content, we allow you to work with your index in a context that will affect the way that content is indexed or queried.
We have abstracted this away into an Interface called IExecutionContext so that you can switch the context of the search based on your implementation. Internally for the Sitecore UI, we use this to switch Analyzers based off the culture of the UI or the Language of the item being indexed. This is the CultureExecutionContext and looks like this.
<param desc="map" type="System.Collections.Generic.List1[[Sitecore.ContentSearch.LuceneProvider.Analyzers.PerExecutionContextAnalyzerMapEntry, Sitecore.ContentSearch.LuceneProvider]]">
<mapEntry type="Sitecore.ContentSearch.LuceneProvider.Analyzers.PerExecutionContextAnalyzerMapEntry, Sitecore.ContentSearch.LuceneProvider">
<param hint="executionContext" type="Sitecore.ContentSearch.CultureExecutionContext, Sitecore.ContentSearch">
<param hint="cultureInfo" type="System.Globalization.CultureInfo, mscorlib">
<param desc="analyzer" type="Sitecore.ContentSearch.LuceneProvider.Analyzers.DefaultPerFieldAnalyzer, Sitecore.ContentSearch.LuceneProvider">
<param desc="defaultAnalyzer" type="Lucene.Net.Analysis.CJK.CJKAnalyzer, Lucene.Net.Contrib.Analyzers">
This uses the Sitecore Factory to construct the mapping of the culture of "ja-JP" to use the Lucene CJKAnalyzer. We have done the full mapping of all supported Lucene.net Analyzers available such as German, Dutch, Thai etc. For SOLR, we have also taken care of this for you. We have seen problems with the CJKAnalyer in the Contrib library for Lucene but can confirm that it works perfectly fine in SOLR. I would suggest that if Multilingual search is a big requirement for you, that you should use SOLR as your provider.
Of course, we can also use this for other things rather than just switching on Language. Lucene and SOLR both have many other Analyzers that take care of things like Phonetics, Stemming, NGrams, Synonyms and many more. You can implement your own Execution Context to switch into these Analyzers as well. Think of it as dynamic per field Analyzer mapping at runtime.
As a practical example, lets say I am building a product site and users are creating review of my products. I may want to switch into an Analyzer that can convert common spelling mistakes into their corrected word so that when users search for these review with words like "lkie" instead of "like" that the results come back. Of course, you could store both "like" and "lkie" in the index to make them both search-able as well.
We designed this feature with flexibility in mind that language is not the only "dimension" in which a search will differ on the Analyzer that is used. The IExecutionContext is essentially just a marker Interface, with all the specific implementation done with the constructor of the implementation.
An example usage, would be to fetch the IQueryable with an IExecutionContext using the context culture. Then, deep in the Linq Layer it will use this to switch the Analyzer if necessary.
var q = context.GetQueryable<SitecoreUISearchResultItem>(new CultureExecutionContext(culture));
You could even use a line of code like this in your front-end code when a person has changed their preference language to e.g. Chinese, to make sure that when they search, they search with a specific Analyzer such as the SmartChineseAnalyzer or the CJKAnalyzer.
If you wanted to go all the way you could also detect the language on your site (similar to the way Google Translate does) and then switch the Analyzer based off that.
Let's not forget that there are Analyzers from other types of products that we could re-use as well such as Mahout, LingPipe, even RavenDB has some you could use, hence the excitement around this feature.
In later updates of Sitecore 7 we have added the ability to pass in an Array of IExecutionContexts so that you can chain logic from multiple Execution Contexts together.
We have included a few other implementations in upcoming updates including FieldExecutionContext and a DocumentMapperExecutionContext which allows you to switch out the DocumentMapper you would like to use at runtime. This opens up huge possibilities by allowing you to run some of your document mappings with Sitecore's Document Mapper, some with Glass, some with Synthesis and some with a brand new implementation.
Guys, your code markup breaks the entire page layout. I'd really suggest don't use it. Look at the ugly top menu, etc.