This post was most recently updated on March 20th, 2019.Reading Time: 8 minutes.
Localization – or showing users with different language preferences content in their preferred language – is not SharePoint’s strongest suite. It never was, and probably will never be, unless Microsoft perfects Machine Translation at some point. And even then it would probably require extra subscription, as Cognitive Services APIs are not available (above the peasant-tier) for free now either. In this article I’ll go through a few survival strategies for multilingual organizations – and I’ll try to expand the content as more options pop up!
Please note, that this article revolves mostly around Classic SharePoint. Microsoft’s current implementation of Modern SharePoint offers little-to-nothing for a controlled localization. It offers a curious way to use MUI to offer multilingual chrome with non-localized content, and that’s about it… But some of my tips work in Modern, too.
So, what can SharePoint do out-of-the-box? There are a couple of features one can use – let’s go through them!
SharePoint has had a feature called Multilingual User Interface (MUI) at least from SharePoint 2010. In on-premises installations, it requires language packs to be installed, but in SharePoint Online it’s quite straightforward to use.
In a nutshell, MUI in SharePoint 2013 and later versions, makes it possible to localize all parts of SharePoint’s chrome. You can enable any number of the languages that SharePoint has built-in (that’s some 40 languages, some of which have multiple character sets available). This enables things that Microsoft has put in place to be localized, but for the most part, your content will be left untouched.
There are known issues, though.
First of all, since content is mostly not translated, this doesn’t really resolve any content translation or visibility issues. You’ll need to pair this feature with some of the options on how to localize Content and Structure, described below.
As an exception to the rule, enabling Alternate Languages (= MUI feature) will complicate maintaining some content-ish things, such as web part titles. It requires effort from multiple people, since web part titles ARE localized per-language. See this, for example: Web part title changes not reflected to some users in multilingual SharePoint environment, or this obscure issue: Alternative Languages in SharePoint forcing the (cumbersome) use of localized Managed Properties.
In on-premises scenarios, you’ll also need to install all the language packs for different alternative languages you’re planning on using. If I planned on making any kind of nifty, rich or customized content or functionality on my SharePoint site, I’d definitely first create the site in English and then enable other languages as Alternative Languages. This makes it a bit less likely, that you’ll run into weird issues!
Variations-feature was/is a (kind of a) good idea by Microsoft to enable automatic copying and translations of multiple, independent but connected language versions inside one publishing site collection. When I first read about it, I was really impressed as it resolved some customer requirements really nicely. The structure is copied automatically from a source structure to any number of additional language versions. This makes it possible to have one master site structure with “master data”, which’d be replicated to different language/locale-dependent locations.
If you want to hear more about Variations, check out this great blog post by Stefan Goßner. He explains it way better than I could do! Even though the blog post is a bit dated, Variations hasn’t really improved that much over the years… So the content is pretty much valid.
I wouldn’t recommend using variations, since it’s quite an unstable feature. It’s not reliable, and if you have any “old school customizations” (like custom master page) or you’re using Composed Looks or Themes, it’ll probably trash your site every now and then. I’ve also seen it just stop working, in which case you’ll need to restart services (if it’s on-premises), or contact Microsoft Support (in SharePoint Online – and that might take a while).
Additionally, it’s also limited to copying content inside a site collection – so it’ll inevitably lead to a site collection, that is quite sizable and has a large navigation hierarchy, which is not advisable (especially not in SharePoint Online). You’ll need to be on your toes all the time, so I do not recommend using variations at all – not for localization, not for anything else.
Different out-of-the-box Content and Structure -based localization options
So what can you do apart from using the 2 pretty bad localization features SharePoint offers? Either paired with them or independently from them, you can localize your content in a few ways to affect what content your users see.
Please do note, that these different options are not mutually exclusive – you might need to apply a few of them!
Multiple different user groups want to see different content on home page
If the number of groups isn’t that large, you could use audiences to show certain web parts only to members of certain AD groups. That way you can make just some of the web parts to be visible to some users, and hence make only relevant content show to your users.
It does require a lot of effort from editors, though. Webparts typically have to be edited one by one, and to enable multiple user groups to see different versions of the content (like news roll-ups) you’ll have to create a different version of the rollup for each security group or audience. The worst thing is that this has a detrimental effect on performance – so a lot of manual labor might even lead to bad latencies, and awful user experience!
Bothersome to maintain, performance issues with a lot of webparts, and editing experience might be confusing.
It’s not very complicated, though, so editors typically are able to live with the extra work it introduces.
Using search-based web parts to show content (mainly) in user’s language
For just localizing content, you can do a lot with SharePoint’s search. Using a couple of tricks, it’s possible to separate documents and pages, that are written in a bunch of different languages, even if they are happily mixed together on your SharePoint sites!
Using search-based SharePoint webparts, you can filter or match content to users’ language (if it’s available as a user profile property).
You can then filter either based on user profile properties, site or site collection paths, or even permissions – as in many cases, you can just restrict access to different locations’ sites or subsites.
If you’re just aiming to filter content by language (e.g. you want to show all the documents in a certain language – or match it with a language in users’ user profile properties), you can also use SharePoint’s built-in functionality to tag all the content it indexes with the locale it represents.
Didn’t know this feature existed? Yeah, it’s pretty implicit, and Microsoft doesn’t talk about it too much. Too bad, because it works surprisingly well! You can just add something like this to whatever search-based webpart, and it’ll be filtering by your language of choice:
DetectedLanguage="[2-letter language code]"
See an example below:
This is an awesome resource on how to use DetectedLanguage: https://nickgrattan.wordpress.com/2013/05/31/language-identification/. Also, see all the available languages here!
This probably works a lot better in SharePoint Online than it does on-premises – but I have to admit my experiences from on-premises deployments are very lackluster here. In your on-premises environment, for a lot of localization scenarios, you’ll need the appropriate Language Packs installed. However, for DetectedLanguage and similar linguistics features you won’t need the language packs – they work without them!
If you want to see more about the ways to use DetectedLanguage (a bit more in-depth article), see the blog post below! In that article, I offer more examples on how to use the built-in functionality in SharePoint for localization.
Using search-based webparts is not a real, full-blown localization solution, but rather a simple solution to primarily offer content in certain language. Very useful for targeted content production or certain customizations, though!
Manually creating multiple home/landing pages and the logic to land the users on right page
This requires some custom coding, but you can redirect users based on their user profile properties – and hence, you can have multiple home pages, customized for your different user groups! Performance in this options is good, and different groups can have very different landing pages, so this is a very versatile option.
Redirection adds a delay to user experience. Correct landing page could be also pushed to users using GPO. Management work multiplied by number of pages – but probably your editors will be different for different language versions anyway, so this might not be an issue.
Different commercial options
Let’s face it. SharePoint’s out-of-the-box localization features are bad and finicky. Modern SharePoint is unfinished and doesn’t offer much in regards to localization. Commercial options might actually be your best choice here! I’m just throwing a few completely different scenarios here:
Use in-place localization solution
There are a few decent solutions for in-place localization. They offer varying user experience and functionality… For one of the better and well-known ones, see for example Pointfire’s offering (not an affiliate link).
Segregate your sites based on language, but tie them together using a ready-made solution
Another options is to localize parts of the site, but share and show content from different parts of the site to everywhere else, where deemed proper. In Modern SharePoint this is also even more natural than before, since the hubsites turn the intranets into more modular experiences overall. For example: https://www.valointranet.com/features/#post-13843 (that’s the company I work for – but also an unpaid link 😉).
Copy-pasting from my SharePoint Online tenant, here are the languages available (in addition to English):
- Chinese (Traditional)
- Norwegian (Bokmål)
- Portuguese (Brazil)
- Chinese (Simplified)
- Portuguese (Portugal)
- Serbian (Latin)
- Bosnian (Latin)
- Serbian (Latin, Serbia)
- Serbian (Cyrillic, Serbia)
For all of these languages, the search query DetectedLanguage=”xx” should work – there’s quite a bunch of them, so I’ve moved it to a different article. Available here:
He's been a developer from 2004 (starting with PHP and Java), and he's been bending and twisting SharePoint into different shapes since MOSS. Nowadays he's not only working on SharePoint, but also on .NET projects, Azure, Office 365 and a lot of other stuff.
This is his personal professional (e.g. professional, but definitely personal) blog.