Things to know before beginning a multilingual SharePoint project

Background context

We wrapped up a large SharePoint 2013 implementation project last year that involved managed metadata, search, and a multilingual user interface feature. Each of these features work fine on their own, but when you put them together, the out-of-the-box behaviour is not what one would expect. It is most likely the integration of these features is only 80 per cent done. This post will talk about the less-then-desired behaviours and the solutions we have to address them.  

1. The new solution delivers team sites that support multiple languages. The previous solution had a separate team site per language. The client would like to consolidate language sites into a single site.
2. The solution should allow users to apply multilingual metadata (term set) to content and should be able to find the content by the metadata in any of the supported languages. 
3. The solution should present a refiner in the user’s preferred language for the multilingual metadata.
4. The solution should present content written in the user’s preferred language.

Challenges

First, the Microsoft answer to the multilingual requirement is to use Variation, which we can’t use. We need to deliver a single team site that contains multilingual content. The good news is that you can have a multilingual site title, list title, web part title, and list column display within a single team site. However, the SharePoint search engine indexes content in the default language of the SharePoint Server installation.  

This causes the following behaviours:

• If you have a site with site title “team site” in English and “sitio de equipo” in Spanish and if the default language is English, you will get no search result for keyword “sitio de equipo.”
• If you have a document tagged with a multilingual term “department” in English and “departamento” in Spanish and if the default language is English, search won’t return the document for keyword “departamento.”
• If the multilingual termset is used in the refinement panel Web Part, the refiner only shows the English label of the term even though the term may have multilingual labels defined.
• The content search Web Part only shows the English label even if you use a multilingual termset for your metadata.

Although these behaviors are documented as by-design on TechNet, they are hardly acceptable in any standard. Besides, the first three requirements are not being met by the SharePoint multilingual user interface feature. 

This is not to criticize SharePoint; remember SharePoint is designed to solve 80 per cent of business problems. Our problem just happened to fall into the 20 per cent scenario that SharePoint was not designed to handle. Luckily, this is when a custom solution comes to the rescue. 

These problems are so deep and critical to the organization that it should be easy to justify a custom solution because if you don’t address these search issues, it is guaranteed Spanish users will become frustrated that SharePoint search doesn’t work. We know from experience that what will follow is people will not trust the system, stop putting documents in SharePoint, and refuse to use it all together. 

Solution

A well-defined problem is halfway to being solved. The solution about to be mentioned sounds subtle and trivial, however, a scalable implementation of the solution is not a easy task.  

• To make search find content by keyword in the non-default language, one solution is to use a synonym for “departamento” and “department” such that search will find content tagged with “department” when Spanish users search for “departamento.” This sounds basic, but remember these pieces of content are dynamic, end-user generated content.

To do this:

• Create a pair of synonyms to expand search for every taxonomy term label from non-default language to the default language.
• Create a pair of synonyms to expand search for multilingual list title.
• Create a pair of synonyms to expand search for multilingual site title.
• To make the refinement multilingual, you would create a custom multilingual filter display template and programmatically fetch the correct language label for each refiner. A good client-side caching strategy should be considered.

Two things to consider:

• There is a out-of-the-box API for registering multilingual text: $registerResourceDictionary. You may not want to use it because it expects you register all the multilingual values first and then use Srch.U.loadResource() to fetch the value back later. These APIs are great for a static resource like the title of the refiner but not the refiner values. The same technique can be used to make the content search Web Part support multiple languages.
• To roll up language-specific content respecting a user’s language preference, it should be quite easy because SharePoint automatically detects the language as it indexes the content.  However, our project had a unique requirement where certain documents are not translated into the other language and need to be presented to all users regardless of their language preference. We needed a way to change the alter the detected language by SharePoint somehow. If you like to know how we override the detected language, let us know by writing a comment below.