World is now on Opti ID! Learn more

Jonas Bergqvist
Apr 3, 2018
  967
(0 votes)

Find 13: New language routing

In order to optimize indexing performance, and increase query precision, indexing documents should be done by specifying language routing. The use of language routing, when indexing, does not require any changes when querying. The only effect language routing has on querying is that it increases query precision. This is done by reducing the number of false positive matches, as documents only are analyzed for a specific language. Previously, all documents were analyzed for all available languages supported, sometimes causing noise when stemming rules for one language collided with stemming rules for another.

Adding language routing on any type of object

Adding language routing for any type of object can be done in different ways.

LanguageRoutingAttribute

One option is to use LanguageRoutingAttribute on the property, and set it to the desired language when initializing the object.

public class WithLanguageRoutingAttribute
{
     [Id] 
     public string Id { get; set; } 
     [LanguageRouting] 
     public LanguageRouting LanguageRouting { get; set; } 
} 
var indexedObject = new WithLanguageRoutingAttribute()

{ 
     Id = "123", 
     LanguageRouting = new LanguageRouting(Language.Swedish) 
}; 

Conventions

Another option is to use the conventions API in Find.

client.Conventions.ForInstancesOf<WithLanguageRouting>().LanguageRoutingIs(x => x.LanguageRouting);

CMS integration

The Find CMS integration automatically adds language routing support for content implementing ILocale. Most content base type, like PageData, ProductContent, NodeContent, and VariationContent, all implements ILocale. The behavior can be changed by either using conventions, or by overriding LanguageRoutingFactory.

Conventions

The following example changes the behavior for all content implementing ILocale, to store the documents in the old way. It’s not recommended to do this, because it prevents the performance improvements.

client.Conventions.ForInstancesOf<ILocale>().LanguageRoutingIs(x => null);

This example changes the behavior only for MediaData. You might want to do this for some specific content types, if it’s necessary to analyze the content using all analyzers.

client.Conventions.ForInstancesOf<MediaData>().LanguageRoutingIs(x => null);

LanguageRoutingFactory

A LanguageRoutingFactory is, by default, used for all ILocale content, to create language routing for content that implements ILocale. It’s possible to change the default behavior by creating your own factory that inherits from LanguageRoutingFactory, and override any of the protected virtual methods. You also need to register your language routing factory using a configurable module.

[InitializableModule]
[ModuleDependency(typeof(IndexingModule))]
public class MyFindInitializationModule : IConfigurableModule
{
     public void Initialize(InitializationEngine context)
     {
     }
     public void Uninitialize(InitializationEngine context)
     {
     }
     public void ConfigureContainer(ServiceConfigurationContext context)
     {
         context.Services.AddSingleton<LanguageRoutingFactory, MyLanguageRoutingFactory>();
     }
}
The following example changes the behaviour, to use all analyzers instead of the “standard” analyzer, for all content which uses a language we can’t map to any analyzer.
public class MyLanguageRoutingFactory : LanguageRoutingFactory
{
     public override LanguageRouting CreateLanguageRouting(ILocale locale)
     {
         var languageRouting = base.CreateLanguageRouting(locale);
         if (languageRouting.FieldSuffix == Language.None.FieldSuffix)
         {
             return null;
         }
         return languageRouting;
     }
}

Reindex the site after upgrade to Find 13

The changes in the language routing make it necessary to reindex the site after upgrading to Find 13. The site will work directly when you start the site, before the content has been reindexed. It will work because queries will still hit the content that hasn’t been indexed using the language routing.

The problem (if site isn’t reindexed) will occur when content is reindexed after being triggered from a content event. The content might be stored in a different way as before, which might make the old content continue to exist. You can end up having the same content stored twice, but in different versions.

Conclusion: After upgrading to Find 13, reindex the whole site as soon as possible.

Apr 03, 2018

Comments

Please login to comment.
Latest blogs
Make Global Assets Site- and Language-Aware at Indexing Time

I had a support case the other day with a question around search on global assets on a multisite. This is the result of that investigation. This co...

dada | Jun 26, 2025

The remote server returned an error: (400) Bad Request – when configuring Azure Storage for an older Optimizely CMS site

How to fix a strange issue that occurred when I moved editor-uploaded files for some old Optimizely CMS 11 solutions to Azure Storage.

Tomas Hensrud Gulla | Jun 26, 2025 |

Enable Opal AI for your Optimizely products

Learn how to enable Opal AI, and meet your infinite workforce.

Tomas Hensrud Gulla | Jun 25, 2025 |

Deploying to Optimizely Frontend Hosting: A Practical Guide

Optimizely Frontend Hosting is a cloud-based solution for deploying headless frontend applications - currently supporting only Next.js projects. It...

Szymon Uryga | Jun 25, 2025

World on Opti ID

We're excited to announce that world.optimizely.com is now integrated with Opti ID! What does this mean for you? New Users:  You can now log in wit...

Patrick Lam | Jun 22, 2025

Avoid Scandinavian Letters in File Names in Optimizely CMS

Discover how Scandinavian letters in file names can break media in Optimizely CMS—and learn a simple code fix to automatically sanitize uploads for...

Henning Sjørbotten | Jun 19, 2025 |