This post was most recently updated on August 26th, 2022.
3 min read.Localization and targeting of content in multilingual SharePoint installations is always an issue. SharePoint offers a multitude of ways to profile content based on user language (or other properties), but none of the solutions are foolproof. This post describes how to fetch only localized results from the SharePoint Search index, which solves at least some of the issues.
Description
SharePoint Search index can be used in quite a few different ways. Probably the most typical way is by searching on SharePoint or using webparts like Content Search or Content Results. However, one can also build custom functionality, custom client-side liftups, webjobs, single-page applications, mobile applications, and a ton of other things that fetch data from the SharePoint search index. However, on multilingual tenants, results are, by default, not localized at all. That means, that typically everyone will get the highest-ranking results back, despite them being in the wrong language. And that’s one of the many, many ways to annoy your users!
What does this mean in practice? If the organization has an active, Spanish-speaking unit or office, and they have very popular documents about things like “SharePoint”, or “Valo Intranet”, also the French-speaking employees will typically see these documents (in Spanish) when searching for “SharePoint” or “Valo Intranet”. That’s not always useful, is it?
Luckily, there’s a simple (even if only partial) solution!
Solution
SharePoint actually does language locale identification behind the curtains. It works a lot better than you’d expect, too! Which is to say it’s far from perfect but still decent.
Testing the locale identification makes it obvious, that even if it isn’t flawless, it’s quite decent. See a couple of screenshots below! I did not think I had any Spanish content on the site, but apparently, one of the icons uploaded is detected to have a Spanish name.
That’s slightly funny, though – maybe SharePoint ignores accents and weird characters altogether? Google Translate just figures it’s a Turkish word… :)
Anyway, how about content in Finnish on my site?
Oh yeah, there’s a lot of stuff. Just a few of the first results here – and it definitely works! I’m clearly getting back localized results from the SharePoint Search service.
But that’s certainly not all there is to it! Since DetectedLanguage is a Managed Property, you can use it in different search-based content rollups. See below:
You probably realized this already, but this is actually just a nice way to access the same language information that you can use to filter search results on the good old SharePoint Enterprise Search Center, as a refiner. SharePoint automatically recognizes and tags the content’s language.
However, what’s the extra value, then? This isn’t that automatic, is it – you have an option to filter content by language, but it still doesn’t really automatically give users content in their own language, right? True – but you can actually automate this a bit!
Advanced use case – use the user’s language!
Now, how to combine this with user profile properties to make the filtering dynamic? You can use SharePoint’s User Profile Service’s properties for this!
For example, for matching a document “Department” field to the user’s Department -property (using Managed Properties), you can do this:
DepartmentOWSText:{User.Department}
In general, these properties work like this:
{User.<name of the property>}
(For more information about how to use the profile properties, check out this great blog post by Benjamin Niaulin!)
However, by default SharePoint doesn’t crawl language properties from your user profiles. You’ll have to either change a property to be indexed or add a new one.
So, in short, combined with DetectedLanguage this would be something like this:
DetectedLanguage:{User.LanguageCode}
… in which “LanguageCode” would be a property you’ve created to contain a 2-letter language code, such as “en” or “fi”.
Well then, I guess that’s about it! DetectedLanguage is quite flexible and super useful, so make sure to try it out! :)
References
Nick Grattan has an awesome blog post about this.
He's been a developer from 2004 (starting with PHP and Java), and he's been working on .NET projects, Azure, Office 365, SharePoint and a lot of other stuff. He's also Microsoft MVP for Azure.
This is his personal professional (e.g. professional, but definitely personal) blog.
- CSOM suddenly throwing exceptions when trying to access list contents in SharePoint? A weird fix. - April 2, 2024
- “Predefined type ‘System.Object’ is not defined or imported” and other System namespace stuff missing in your solution? - March 26, 2024
- How to import GraphQL schema to Postman in Windows? - March 19, 2024
