This post was most recently updated on December 7th, 2019.Reading Time: 4 minutes.
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, unituitive 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:
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 search 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 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, 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. 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, 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?
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’s 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.
Latest posts by Antti K. Koskela (see all)
- Azure Functions host quits with “The system cannot find the file specified” - January 22, 2020
- How to extract more information out of your Azure Functions host failing silently? - January 22, 2020
- WordPress media uploads failing after year/month change? Easy fix :) - January 14, 2020