Intranets and digital workspaces are in constant change and evolution. Multi-language intranets and workplaces are increasingly a common business requirement. In the classic SharePoint we usually take advantage of the publishing infrastructure and publishing sites, and the variations feature to create a multi-language information structure and experience.
In SharePoint Online it is still possible to use the same approach, it’s but limited to the classic experience (and publishing sites).
In the modern SharePoint experience, there isn’t – at least for now – a fully integrated way of having multi-language sites and simple content management.
There are some good articles about this subject in the community worth the read, with techniques, limitations, and recommendations (SharePoint Localization – a (somewhat) comprehensive how-to!, MULTILINGUAL AND MODERN SHAREPOINT). We will talk about our project experience, some of the pieces we use to create a multi-language experience, and their pros and cons.
A multi-language modern site approach
A few notes (not exhaustive) about our scenario:
- Users are from multiple countries and speak different languages;
- Some content needs to be secured/restricted by the user’s country of origin (and other user properties);
- Decentralized content – documents and resources from one site/functional area may be presented in other sites/areas;
Content in each language must be manually translated/managed;
Information architecture & classification
Based on the existing business requirements, we adopted a flat multi-site collection structure (with both modern team sites and communication sites) and some hub sites.
We used English as the default site language and enabled the other languages in the Site Settings > Language Settings option.
We added some managed metadata classification fields (using the SharePoint taxonomy feature), to classify content and resources across all sites.
The intranet required an extensive use of “related content” / “see also” type of features so content classification plays an important role here. The classification tree/tags are centralized and managed in one place by the designated owners, assuring consistent metadata across all organization content.
Content security control
In a multiple site collections structure, the user access & permission’s governance is a crucial subject. There are different approaches for different scenarios.
In our case, for content with restricted access by country (or other user property), we take advantage of dynamic Azure AD security groups. Users may change location periodically, so with this feature, no manual configuration work is required (like removing a user from a SharePoint group and adding it to another – in multiple site collections), and users will be automatically removed and added to the respective AD groups.
The user profile service plays an essential role in this process. Each user has their own language preferences/properties given by the user profile “My display Languages”. Depending on the chosen language, the SharePoint user interface will be presented in that language (assuming that language is available on the site) – Multiple Language User Interface (MUI) feature.
In our custom elements, we read and use some user properties to display a custom content experience/targeted content, using SharePoint Search and KQL.
Pages, documents and resources language classification
The language classification of a page, document or other type of resource is given using the managed metadata fields mentioned before.
Each element instance (page, document, etc.) represents one language. For a page in 3 languages, we need to create 3 pages and make the required classification.
The way content or pages in each site are organized depends on your preferences:
- Folders – you can have a folder for each language, which is a good fit when you need to have segregated permissions – yes, you can have folders in Site Pages library. You also need to have metadata in your pages;
- Metadata – if custom permission is not an issue, you can have a flat page structure organized with metadata. Using views to manage the content;
- Subsites – you can also use subsites for each language, we did not use this one.
We implemented a dynamic tenant-wide menu reliant on on user language. The menu options and addresses changes with user language. Once again, we store and manage the menu taking benefit of the taxonomy features. The Spanish version of the menu will point to the “es” pages, and so on. With this, users will browse content in their language and have a unified navigation experience across all sites.
We also created a redirect mechanism to use in the site’s root page. When users access by direct site URL, we can redirect them to the right language/page.
Custom web parts
Among others, we created a search-based results web part (see this topic) with the ability to filter by user language (as well as some other user properties) and other query parameters. We use it to show relevant content in different places, with specific content classification tags. Many use SharePoint’s Search features to create a dynamic experience.
Putting the pieces in place
By connecting all the elements in our solution, we were able to create a multi-language site experience with a simple content management structure, where users will see and navigate through content in their language.
Information classification & metadata play an essential role, not only for language classification but also to create a personalized user content experience thanks to the content filtering by user properties or other organization rules.
We had to create some custom elements (like web parts and extensions) that detect the user language and adapt the content accordingly.
Out of the box web parts (like Highlighted content web part) can also be used in this scenario. Metadata is our friend here, and we can configure the web parts to filter by the required metadata fields.
After initial setup and key-users training, they quickly became autonomous in creating and managing the content for all languages.
- Simple content management;
- Unified content classification experience;
- Not an over-complex solution and doesn’t compromise the adoption of a future native SharePoint feature for multi-language;
- No internal linking between the “same” page in the different languages – like we have with variations;
- Manual page creation and classification for each language (we ended up creating a PowerShell script to do that);
- A custom solution to redirect users in some scenarios – degrading user experience;
- Requires some additional configuration across sites;
If you wish to leave any feedback or ask some questions, feel free to comment!
Sharing is caring
MCarolina Trigo (@mcarolinatrigo) · February 5, 2019 at 10:17 am
Check the episode here: https://youtu.be/OljMvSIQbss?t=2481
Sam Foster · March 18, 2019 at 12:53 pm
Hi. I just thought I’d drop you a line and make contact. I’m based at Bangor University here in Wales, UK. I’ve just been looking at your post about multilingual Modern SPO sites and wanted to let you know that we’re looking at this at the moment. We have a need to develop a solution for our Intranet which we intend to use modern sites for.
I’ve a developer tenant where I’ve been trying all sorts of things out with regards SPFx, powershell scripts and so on.
I have finally come to terms with the fact that variations are dead to me, and I probably need to think along the lines of metadata columns for the content etc and then implementing an ‘in-page’ language switch.
Do you guys have any code repositories that might contain snippets I could make use of – or anything else you care to share with a weary traveller?
Thanks in advance,
Corporate Web Manager
Luis Ribeiro · March 18, 2019 at 5:06 pm
Hi Sam, thanks for reaching out.
In fact the “variations” concept does not exist in modern SharePoint and there is no straightforward strategy for having multilingual modern sites.
We have – like you said – adopted a strategy that relies on content metadata, user profile preferences (user preferred language/SPS-MUILanguages) and some custom webparts/behaviors.
In simple terms, the core features are:
• Enable the out of the box language translations for the required languages (SharePoint will show the language defined in the user profile property) (this will automatically translate all the “system” labels for the language defined in user preferences)
• the navigation menu (that is a custom extension) that shows the information structure for a given language – so when user navigates using the menu, it will land on the correct landing pages (you need to have copies of each page translated to the required languages) – You need to have n menu structure definitions (for each language)
• a redirecting webpart that is used in key landing pages – that checks the current page language (metadata), the user language (user profile) and if they don’t match, redirect the user to the correct page (defined in webpart properties)
• some search based content webparts that, in runtime, queries for the content in current user language
We are planning to share some of these on github, but we still don’t have a date for that.
I can share some helpful resources:
• Custom navigation menu extension
• Custom search webpart
• Read user profile properties / SPS-MUILanguages
We hope this can help you to understand a bit better our approach.
SharePoint Dev Weekly - Episode 25 - Office 365 Developer Blog · February 5, 2019 at 9:23 am
[…] SharePoint Online Multi-language Modern Sites – real case, pros, and cons – Luis Ribeiro (DevScope) […]