Localization of your search page

speak the language

Couple weeks ago I was psyched to start a series on our first hand experience dealing with Coveo for Sitecore on a multi-tenant/multi-site Sitecore instance.  Check out my first two posts below:

Link Manager Gotcha
Get Your Links right

Now, last, but, not least when you have such huge instance of Sitecore, you are bent to have things you would want to localize due to multiple languages you are supporting.  I usually see the solution in two folds.

  1. Coveo OOTB component localization
  2. Custom string localization – Like Facets or any strings on your search listing card that are computed field for instance.


The first one is quite simple and easy to do as Coveo carries responsibility OOTB to load most close culture based on context language.  If you go to viewsource on your search page, you will see that Coveo has already done some magic for you.  It loads the culture *.js file based on your context language.    This happens right the view based on below line of code on Coveo Search View. 

<script type="text/javascript" src="/Coveo/js/cultures/@(Model.CultureName).js"></script>

That should take care of your result summary on left top corner above your results.   For your sorting components which you may have added using your DateSortView or RelevancySortView, to localize the sorting header such as “Relevancy” or “Date” in context language, Coveo looks for special data attribute on HTML called ‘data-caption’ and if your HTML element for your facet has this attribute loaded with your title and if that is a existing key on locales dictionary object of your interested culture/language then it is respected and corresponding localized string is shown on your page. 

Now, for the second fold, if you would like to localize your Facet values, Headers, etc., There are few things to consider/answer – Do you show just one language content on your search page per site?  If you are – Life is simple, just ensure you have localized content loaded on your Facet field.  If your facet is based on computed field, ensure you are loading language specific value based on currently indexed item language.   For your facet header to be localized, you have couple of options here as well, you can either read it from your localized dictionary on Sitecore if you have one, if not, load up your JS localize dictionary with new values as noted in the link below.

https://docs.coveo.com/en/421/javascript-search-framework/changing-the-language-of-your-search-interface

Now, the problem actually happens when you have more than one language content show up on your search page, in that case, you will have an issue with mixed values which obviously is not UX friendly.    You can see a good solution and huddle between me and my favorite Sitecore MVP and Coveo champ below(@jflh ). 🙂

https://answers.coveo.com/questions/16338/localize-facet-values-on-multi-site-solution-using.html?childToView=16358#comment-16358

This is the last piece of this series and I am sure there will be more to come, this one is near and dear to my heart and the amount of learning and information I gathered through this Implementation is priceless.  Although, Coveo and Sitecore never fail to amaze me, there is more room to learn and grow with these products every single day. 😉

Happy Coveo for sitecore implementation to every one!

Some helpful links:

https://developers.coveo.com/display/public/JsSearch/Localization

https://docs.coveo.com/en/421/javascript-search-framework/changing-the-language-of-your-search-interface

 

Implement Coveo on Multi Tenant/Multi Language Architecture

I am very excited to start this series as we are almost close to pulling off Coveo Cloud Implementation on a multi site/multi language Sitecore Instance using legacy Coveo For Sitecore Javascript Framework to support web forms Sitecore Implementation.  I am gathering my thoughts around all the challenges we faced while getting Coveo to work seamlessly with complex Sitecore Instance.  Some were very straight forward and some were anything but that. 🙂

I am going to list down each important problem and note options to tackle each.  Do note that though most of the solutions I would attempt to provide are generic, it highly depends on your Sitecore implementation and customization done to Sitecore in general.

One thing that really helped me solve some of these is understanding when and where Coveo connects with Sitecore.   I would recommend to deep dive on this to any one who is attempting to implement Coveo For Sitecore on their multi tenant and multi lingual Sitecore implementation.

I will start by noting the first problem we faced right after Coveo for sitecore installation on our system.  On Diagnostics page, we had the error such as noted in question and answer below.

https://answers.coveo.com/questions/15435/coveo-search-rest-endpoint-invalid-uri-the-format.html?childToView=15530#comment-15530

One of the first question to answer when implementing Coveo For Sitecore is – Does your Sitecore implementation have a custom link manager as that drives what you would need to watch out for or customize if needed, a quick way to check would be

-> Go to your /sitecore/admin/showconfig.aspx and examine what you see in the node below.  if you see default provider as something other than “sitecore”, then, you can ensure that there has been some customization done on this.  To be honest, any medium to high sized Multi tenant instance that has been active on Sitecore for long time would have some customization around it.  So, it is even more important to know how to ensure Coveo works with your custom link provider settings.

link provider section on config

For instance, in our case languageembedding setting on Linkprovider was set to “always” which means that any website/site served by Sitecore, when a link is generated it would append language to it.  That should surely ring some bells, in  Coveo For Sitecore case upon installation of package, you would see three new sites in the <sites> node when you take a peek at showconfig which are named as coveo_website, coveoanalytics, coveorest.  We definitely do not want to add language embedding on these URL’s here to ensure we do not throw off internal business logic on Coveo end.

To gracefully solve this, I would recommend having an ability to use different Link Providers per site.  There is a very decent solution compiled by my favorite Sitecore MVP Jammy Kam below.

Site Specific Link Provider for Multisite Implementation in Sitecore

By doing this we can assure that Coveo specific sites do not have language embedding in it that would cause issue noted on Q&A above.

Of course, if your sitecore implementation was done more on old school style where the answer was – There is a pipeline for that. 🙂

In those cases, check to see where you can ensure to exclude Coveo sites from having language embedding on them.

One open question I do have is would this be any different with Sitecore 9.0+, a short answer might be a NO.  If any one has any input in regards to this, leave a comment.

That is it about our first ever hiccup, more to come soon.  My hope is that this series will help any one who is driven to use Coveo for Sitecore components and power of framework on a complex Sitecore instance, but, are worried that it might be quite a feat or they might be safe using total custom system.  You can re-visit my blog on this topic and I am sure you will get confidence in sticking to framework instead.  🙂

Tune in for more on this series!