SharePoint Localization – a (somewhat) comprehensive how-to!

This post was most recently updated on August 31st, 2022.

This article describes the localization/multilingual capabilities of SharePoint, and your options as an organization using it to achieve a seamless and user-friendly experience for your end-users and content editors. SharePoint’s definitely a powerful platform, but its multilingual features might leave a bit to be desired – and using them successfully requires some understanding of the platform!

Background of Multilingual SharePoint

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 while this article was written around the options in Classic SharePoint, most of the things apply to Modern as well. 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 you can use Search… And some commercial options with certain limitations. This article covers some of my tips for that as well!

Different out-of-the-box localization features in SharePoint

So, what can SharePoint do out-of-the-box to empower your Multilingual intranet experience? There are a couple of features one can use – let’s go through them!

MUI (Multilingual User Interface)

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.

It’s fairly automatic, so as long as you have the language packs installed, the feature “just works”. With some caveats…

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.

Considerations

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

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 would 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.

Considerations

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!

Audiences: Enabling multiple different user groups to see different content on the 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!

Considerations

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 the 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.

Using SharePoint’s DetectedLanguage 

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 filtered 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 slim 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.

Considerations

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 the 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. 

Considerations

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 an in-place localization solution

There are a few decent solutions for in-place localization. They offer varying user experiences 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 hub sites 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 😉).

Footnotes

Which languages is SharePoint available in?

• English
• Arabic
• Bulgarian
• Catalan
• Chinese (Traditional)
• Czech
• Danish
• German
• Greek
• Finnish
• French
• Hebrew
• Hungarian
• Italian
• Japanese
• Korean
• Dutch
• Norwegian (Bokmål)
• Polish
• Portuguese (Brazil)
• Romanian
• Russian
• Croatian
• Slovak
• Swedish
• Thai
• Turkish
• Indonesian
• Ukrainian
• Slovenian
• Estonian
• Latvian
• Lithuanian
• Vietnamese
• Azerbaijani
• Basque
• Macedonian
• Hindi
• Malay
• Kazakh
• Welsh
• Galician
• Dari
• Chinese (Simplified)
• Portuguese (Portugal)
• Serbian (Latin)
• Irish
• Spanish
• Bosnian (Latin)
• Serbian (Latin, Serbia)
• Serbian (Cyrillic, Serbia)

Spoiler alert: That was just a copy-paste from my SharePoint Online tenant. But it’s legit.

Which languages can SharePoint detect and work with automatically?

For all of these languages, the search query DetectedLanguage=”xx” should work – there’s quite a bunch of them, so I’ve moved the list to a different article. Available here:

• Author
• Recent Posts

Antti K. Koskela

Developer / Speaker / Consultant at Koskila / Precio Fishbone / Norppandalotti Software Co / Alter - Experience Ideas Ltd

Antti Koskela is a proud digital native nomadic millennial full stack developer (is that enough funny buzzwords? That's definitely enough funny buzzwords!), who works as Solutions Architect for Precio Fishbone, building delightful Digital Workplaces.

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.

Latest posts by Antti K. Koskela (see all)

• How to import GraphQL schema to Postman in Windows? - March 19, 2024
• How to fix “NoRegisteredProviderFound” when trying to run any aks az cli commands - March 12, 2024
• How to fix annoying mouse/touch device input lag on Windows 11? - March 5, 2024