This post was most recently updated on July 31st, 2022.
3 min read.Localization and multilingual environments in SharePoint are an endless source of interesting issues and blog post topics. In one case, we had a tenant created originally in English, and a site collection created in Finnish. In this particular case, SharePoint somehow messed up the language settings and ended up requiring the use of localized managed property names on the search center of that site collection. Nowhere else, though. That ended up being unexpected, unintuitive, and unusable for the end-users.
Description of the issue
Typically, when you use SharePoint Search, you can use managed properties to search for values in certain fields or columns of any items in the index.
Whereas typically you’d search for something like this:
Department:HR Title:John
This returned nothing for us, even though we definitely had John working for HR – this we could verify from the User Profile Service. Furthermore, Managed Properties didn’t work for normal searches either. Any amount of KQL with any property names didn’t seem to return anything.
To be more precise, our particular use case involved searching SharePoint’s people results for users of certain departments.
“Department” is a managed property on its own, and gets info from – surprise, surprise – a field called “Department” in the user profile service in SharePoint Online. In our case, the Search API returned results (tested with a tool like Chrome SP Editor) with KQL “Department:HR”, but the search center did not.
After a lot of playing around, it turned out the search center required us to use localized versions of the names of managed properties. In this particular case, the search required the Finnish name (“Osasto”) for the property.
Before this, I didn’t even know that was a thing! In all of the installations I’ve seen, the plain English internal names of the managed properties worked just fine – so, in this case, “Department”.
I did not find a way to configure this to work in any other way, and this was very cumbersome for the customer. They expected SharePoint to be using the same, plain English, names for the managed properties that were used everywhere else!
There were very few resources about this issue online, at least in English… Which in hindsight makes sense, since it’s a localization issue, that probably never, EVER concerns any English speakers… :) Anyway, we needed a solution, but we couldn’t find any configuration options that made any difference… Or even any kind of indication ANYWHERE, that the search center was using localized managed properties. Yet, it clearly was, since “Osasto:HR*” was returning the results, that “Department:HR*” on other sites did.
Also, just to clarify: nobody had set up any aliases for the property. Nobody had tried to localize the properties either. The customer was fine with the managed properties being in English. This was all Microsoft.
How to get rid of the localized managed properties
Having to use localized names of the properties for all search queries is bothersome – being unable to search “Title:Contoso” and instead having to experiment long enough to find the correct property (note: these are not documented anywhere) is not a meaningful way to use one’s day.
So, we did what any good client of Microsoft would do… We opened a ticket with Office 365 Support for the issue.
However, it went like it usually goes. Which is to say, the support person sat on the ticket for a while, then told us it’s not progressing, there’s no resolution, and archived the case. :) Microsoft’s process for handling the tickets is often just a little bit frustrating!
However, since we independently found a workaround, it didn’t matter that much.
The first thing we tried was setting up an alias “Department” for a property called “Department”. Unfortunately, apparently, SharePoint doesn’t exactly support that. The name is reserved, even though it doesn’t work.
Would’ve been easy, but SharePoint rarely is, right?
The workaround was luckily quite simple, but unfortunately, it probably does NOT suit all of the situations:
Since the only part of the intranet that struggled with the localized managed properties was the search center, we figured it was a weird or hidden configuration on the site or page. And lo and behold – recreating the results pages fixed the issue.
So, in short: Recreating the search results page resolved the issue. The actual root cause is once again a mystery, as Microsoft Support didn’t help that much…
However, a simple best practice to follow when creating any SharePoint sites: Create the sites in English, and enable any other languages as alternative languages. Since SharePoint is an English-first platform, that way you have both functional sites AND your desired localization.
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.
- M365 Copilot claiming “You have turned off web search in the work mode”? Easy fix! - November 19, 2024
- “Performing cleanup” – Excel is stuck with an old, conflicted file and will never recover. - November 12, 2024
- How to add multiple app URIs for your Entra app registration? - November 5, 2024
