This post was most recently updated on December 27th, 2018.
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 properties on the search center of that site collection. 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. 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 service API returned results with “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.
How to get rid of the practically unusable localized managed properties
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, 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. Would’ve been easy, but SharePoint rarely is…
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…
Latest posts by Antti K. Koskela (see all)
- Fixing “-2147024891, System.UnauthorizedAccessException” when accessing SharePoint SOAP Web Services - January 17, 2019
- “500 Internal Server Error” after switching a WordPress site to PHP 7.3 - January 15, 2019
- Azure Functions failing on “OPTIONS” call? Quick fix! - January 9, 2019
- Thanks for an amazing 2018! - December 28, 2018