Requirements for multilingual SharePoint implementations are quite common in organisations that span across different countries. Providing information and content in a user’s native language is especially important for intranets (and internet sites), where localised communications and corporate information can be an important part of strategy, and perhaps even a legal requirement. But multilingual is difficult and expensive to implement and maintain in SharePoint: Project costs related to design, development, testing, and training will increase, as will ongoing costs associated with change, governance and support. Weighing up whether or not you should implement multilingual is a big decision that needs careful thought. This two-part series therefore aims to address the main points that need to be factored in when considering multilingual and SharePoint. These are:
- What are my options?
- How much will it cost me?
This post relates primarily to SharePoint Online within Office365, but the information can also be applied to SharePoint 2013 and other, older versions of SharePoint Server.
What are my options?
Out of the box, SharePoint provides two main options for multilingual:
- MUI (Multilingual User Interface); and
- Variations framework.
These two features are often used in conjunction with one another to provide a full-fidelity multilingual user experience, or just the MUI to provide a pared-down version of multilingual. In other words, this isn’t so much a case of “MUI versus Variations”, more a decision of whether to use one or both.
It’s also worth noting here that if you are willing to embark on a lot of custom development work, further options are definitely possible. However, this post is mainly concerned with the two bits of out of the box functionality.
MUI – Multilingual User Interface
MUI references the language settings in your profile and automatically translates some of the page “furniture” and out of the box elements. It provides the means of translating “non-content” elements of SharePoint pages.
How the MUI works
Things that are translated automatically by the MUI are:
- Default column titles;
- Settings menus; and
- Office Ribbon.
The MUI also allows you to specify alternative language labels for the following elements:
- Terms/term sets;
- Custom column titles;
- Custom content types;
- List/Library titles;
- User profile properties; and
- Custom web part properties.
The MUI does not translate any content. This means that content will display in whatever language the person who created it wrote it in. Content might include web pages, values within free text columns, and information within documents.
If you are using SharePoint Server on-premises, you will need to install the language packs you require for your users as a pre-requisite. If you are using SPOL (SharePoint Online), this step has been done for you.
To enable the MUI on a site, you need to go to Site Settings and then Language Settings. From this screen, you can specify the languages you want to enable for the site.
Users can specify their preferred language via Office365 settings (for SPOL), or via their user profile settings (for SharePoint 2013 on-prem). Note that the browser’s default language is the default for SP2013 on-prem, but users can change it via their profile.
The page “furniture” will now display in the language the user has chosen, provided the site administrator allowed the use of that language in Language Settings.
- SharePoint search results will only include the default label for terms, not the alternative labels you specify for other languages. This means you will need to create a custom refinement panel control if you want to utilise your labels in search.
- With SharePoint on-prem, it is good practice to install language packs regardless of whether you need multilingual. This is so that search finds plurals and different tenses of queries written in other languages.
- It is also good practice to always install SharePoint in English, simply because there is a lot more community information available in English than in any other language.
- You don’t need to install language packs for SharePoint Online; they’re already installed by default!
- Remember, the MUI does not translate content, only page “furniture”.
- Translated labels are often longer than their default language counterparts. This can affect the UI of a site, e.g. causing the top navigation to wrap onto a second line. Always test in every language to make sure issues like this are ironed out.
- It’s a good idea to define all of your translations as part of your Information Architecture definition. Implementing the labels at the same time you implement all of your content types, metadata columns, term sets etc. is less effort than retrofitting them later on.
Variations provides a framework to facilitate the publishing and translation of content. Content is created in a source site and then replicated to local language target sites where it can be translated and published. Variations work well when you need to have the same content replicated in different languages.
At this point, it’s worth addressing the elephant in the room: Variations have a bad rep amongst SharePoint professionals, and rightly so. They used to be quite temperamental in SharePoint 2010, and a complete waste of space in SharePoint 2007. But in SharePoint 2013 and SharePoint Online, the functionality is substantially improved: Improvements in reporting, error logging and a more robust publishing timer job mean that Variations are now a reliable means of facilitating a multilingual SharePoint solution.
How Variations work
From an end user’s perspective, the experience of using a Variations-enabled SharePoint solution is pretty seamless. When a user initially accesses the site collection, they are ‘bounced’ from a landing page to an appropriate site for their language (based on the language settings of their internet browser application).
They can then consume all pages and content that the site owner of their local site has chosen to translate and publish. The theory is that they will get the same experience in terms of content for any language they access, though this is largely down to whether the local site owners have translated and republished the replicated content.
From a site owner’s perspective, pages and/or lists are replicated in the target sites in a draft state. It is still up to the local site content authors or owners to translate and then publish the content.
Pages and lists are replicated via timer jobs that run periodically (every 30-60 minutes with SPOL, and these settings can be configured with SP2013 on-prem). When a Page or list is replicated to the target sites, a designated contact for the local site is notified and can translate and localise the content for their audience. Content authors on target sites have a few different options for actually translating the content:
- Manual translation: the content author can edit the page/item manually and localise it themselves.
- Machine translation: the machine translation service is used to automatically translate the content (note that this is the equivalent of using Bing translate, so it is about 60-80% accurate at best).
- Export translation file: the content author can download a translation package in an industry standard format (XLIFF) that can be sent to a third party translation company. A package in the same format can also be uploaded and published by the content author.
When you create a site from a Publishing template (or when you switch on the Publishing Infrastructure and Publishing features), some extra options will become available within the site settings menu of the site collection root web. Under the Site Collection Administration heading, you will see options for Variations Settings and Variations Labels. As you can probably guess from the fact it’s a site collection scoped setting, Variations only work within a site collection, not cross site collection.
There are plenty of very good blog posts out there that will explain in detail how to set up variations, so I won’t recover well-trodden ground here. Specifically, the technet article about planning variations is well worth a read, as is this series of blog posts, which provides step-by-step instructions for setting them up.
A few tips for Variations
Things to keep in mind when implementing Variations:
- Variations work great for out of the box content, but when you add customisations to a page, these web parts and apps will not be variations-aware. You will need to do some dev work to ensure all elements on a page can be translated, either by the MUI or manually by a content owner.
- Content synchronisation is one-directional: you cannot sync content back from a target site to the source, or from target to target. You can only synchronise content from source site to target site(s).
- Variations only work within a site collection. If you need to push content across site collection boundaries, you should take a look at the cross-site publishing functionality.
- Content synchronisation (and hierarchy creation) are run from timer jobs. These run every 30-60 minutes in SPOL, and can be configured in SP2013 on-prem. The synchronisation is not instantaneous.
- If you want the page “furniture” (e.g. settings menus and the ribbon) to be translated, you will need to use Variations in conjunction with the MUI.
Choosing an option
As mentioned earlier in this post, it’s not actually a choice between using the MUI and Variations, but a choice between the MUI on its own versus MUI + Variations. Two key factors that should influence a decision either way are:
- Do you need the same content in different languages?
- Do you have processes and people in place already that support the localisation of content?
If you answered ‘yes’ to these questions, Variations plus MUI is probably a decent route to go down. If you answered ‘yes’ to number 1, but ‘no’ to number 2, you should do some serious investigation into how much work you think it will take to localise content once you are live. It could get expensive. The other big factor is the amount of customisation you are implementing for your SharePoint solution: making web parts and apps MUI-aware and translatable will increase design, development and testing costs (and increase the costs of changes and upgrades in the future). This segues nicely into the subject of the second (and final) post in this series, which is all about how much it will cost to implement multilingual in SharePoint.
Thanks for reading!
Part 1: What are my options?