Today I Learned

nathanwells2014Leave a comment

A colleague of mine highlighted something today that I didn’t know about, so thought I’d share it here too:

To view Followed documents or folders in SharePoint Online, you need a OneDrive for Business license.

ODFB Following

It struck me that this was slightly odd, as the ‘documents I’m following’ view is a piece of functionality that’s been in SharePoint since the days when the OneDrive area was called My Site, and it is what I’d call SharePoint functionality, not OneDrive-specific. But still, such is the life of a SharePoint professional: the sands are ever shifting. Worth keeping in mind if you’re leveraging any of the ‘follow’ functionality in other areas of SharePoint, e.g. displaying a feed of the user’s followed documents on an intranet homepage.

You get OneDrive for Business licenses on both E1 and E3 plans.

 

Is SharePoint Dead? My thoughts on Microsoft’s Latest Announcements about SP2016.

nathanwells20144 Comments

I recently read an article by Dan Holme on IT Unity, in response to Microsoft’s blog post outlining the strategy for SharePoint and O365. Sometimes when I read or hear a particularly good line, I get that amazing feeling of something ‘slotting into place’; that feeling you get when something that’s been in your subconscious for a long time (but you have never quite been able to articulate or form some coherent thinking about) suddenly reaches clarity. This is the line:

“After a decade, I still struggle to answer the question, “What is SharePoint?” because I have to start by asking questions like, “It depends… what are you trying to do as a business?” SharePoint has always been too big of a story to tell. Ask me what OneDrive for Business is, or what PowerBI is, or what Yammer is… I can tell you. The granularity helps a lot.”

Nobody can succinctly explain what SharePoint is, what it does, and the benefits it brings to a business because it is just too big. When a friend or family member asks me, “So, what is SharePoint?”, I usually roll out some analogy about a box of LEGO bricks, or start using buzzwords from the SharePoint Pie of Despair. The person usually ends the conversation more confused than they were at the start. I don’t think this is a particular reflection on my ability to articulate concepts either (well, I hope not), because I have never heard anybody give a good explanation or definition of SharePoint. It’s just too intangible as a concept; too hard to envision for people who have never seen or used the platform.

Microsoft’s approach to break down the services and capabilities provided and supported by SharePoint into smaller, bite-sized “experiences” makes perfect sense, and makes my life a lot easier to boot. It’s much simpler to explain and articulate the business value of an individual use case than it is to do the same with SharePoint as a whole. As a consultant, it means I can focus on guiding customers towards the experiences and portals that provide the most benefit to their users without having to explain, “We’re giving you SharePoint, but we’re only doing 20% of what it’s theoretically capable of at this stage of the programme”. It means that we can look at Office365 in a more holistic way, rather than SharePoint requiring a completely different project approach to the rest of the products in the suite. Strategic roadmaps are easier to define, explain, and obtain executive buy in for. It means organisations can better identify their requirements and aspirations when going out to tender. It helps to stop the blurring of the lines between different concepts in SharePoint (such as publishing portals versus team sites/collaboration spaces), increasing our ability to govern the solution and aiding user adoption. And it may, at some point in the future, allow Microsoft to give their customers more granular licensing for individual areas of functionality or features that currently come under the SharePoint umbrella.

So is SharePoint dead? Well, no, but as a concept and a brand, it is probably terminally ill. The functionality it provides will carry on and continue to evolve, and the skills/people needed to implement and support it will be in just as high demand as ever. I’m really excited to see what the next 12-24 months holds for SharePoint, and I am fully behind Microsoft’s “experiences” vision.

Migration

Migration Projects – Things You Should Know

nathanwells2014Leave a comment

Introduction

Recently, I’ve seen a few questions flying about on the various SharePoint community Yammer networks, forums and LinkedIn groups about migration. I thought I’d weigh in with my usual approach to migrating content into SharePoint, which will hopefully help you to facilitate a smooth, successful, on-time, on-budget migration project.

Analysis of source data

Before you can think about what tooling to use, how you’re going to communicate the migration, or any other activities, you need to know what it is that must be moved. Your analysis of the source data should include the following information to help you make sensible, informed decisions later in the migration process:

  • What is the total size of data?
  • How many files must be moved?
  • How frequently read is the info?
  • How frequently updated is the info?
  • When was the last time the info was read?
  • When was the last time the info was updated?
  • What types of files exist?
  • What is the average size of file?
  • Are there any specific permissions applied?
  • How is the data apportioned into different ‘buckets’ within the source system?
  • Who is the owner of this information?
  • Are there any unique IDs that need to be migrated?
  • Do old versions need to be migrated?
  • Are all users of the old system in SharePoint (user mapping)?

This analysis piece will likely take the form of some analytics stats, perhaps presented in a graph to help make sense of it, plus an extract in .xlsx or .csv format that captures the granular detail about individual files.

If your source system is SharePoint…

If your source data is stored in SharePoint, there is some additional analysis you will need to do in order to prepare for a migration:

  • Are there any full-trust code solutions on the system?
  • What is the database count?
  • What is the site collection count?
  • Are there any unghosted files?
  • Are there any custom site definitions?
  • Are there any lists with a large (>100k) number of items?

A good tool to use to gather this information is AvePoint’s Discovery Tool.

Prioritisation of source data

Using your analysis, you need to make some high-level decisions about what is going to be migrated. Key things to keep in mind are that if you are migrating to a comms publishing portal (intranet), then you probably don’t want to take working documents over – you only need published content. Based on usage stats, you can also start to formulate a plan in terms of which are the big ticket items that must be moved, which are the quick wins, which areas can wait a while, and which content is not worth migrating at all. This is also the time to start involving the business in some of the decision making. I find a workshop where the analysis is presented and discussed works well, and it sets the wheels in motion ready for the ‘Housekeeping’ activities (see below).

If you’re migrating from SharePoint, this is also the time you need to start worrying about full-trust code (server side code). If you’re migrating to O365, you will have no option but to rebuild these solutions as provider-hosted apps. Even if you’re migrating to an on-premises SharePoint environment, you should still consider following best practice and rebuilding any full-trust solutions as apps.

Housekeeping

The big thing to avoid with migration projects is moving rubbish from one bucket into a newer, shinier bucket. A migration is your chance to clean up some of your content and ensure your new system is better used and more organised. You need to engage the business and empower the content owners of each logical area to remove, change or add any information they feel they should. Buy in from senior stakeholders within the business is essential for this process, because people are never very motivated to do any housekeeping unless their boss is breathing down their neck making them do it.

Target system information architecture

If you’re moving content to a ‘greenfield’ SharePoint environment (i.e. one that is brand new and isn’t currently being used), you have the luxury of being able to design your information architecture from scratch. In SharePoint terms, information architecture is how your site collections, sites, libraries, lists, and folders are structured; how to classify information (metadata and content types); how to secure information (permissions); how navigation works; and how search works. If you’re starting with a blank slate, you can design your IA with the migrated data in mind, in order to make the migration process as easy as possible. A few things to keep in mind when designing your IA are:

  • Content size boundaries (such as the 200Gb content database size limit for SP2013 on-prem);
  • The list view threshold (5000 items);
  • The lookup threshold (8 columns); and
  • Avoiding item-level permissions.

If you’re migrating into a ‘brownfield’ SharePoint environment (a pre-existing, already-used system with live content and users), things tend to become a lot more difficult. You might have to refactor some of your original IA in order to accommodate your new content while still ensuring the system is scalable and does not exceed any defined size boundaries.

Something to avoid – particularly when migrating from file shares – is simply replicating the source system folder structure. Though folders aren’t necessarily an evil thing in SharePoint (as some consultants might lead you to believe), you are still likely to face issues around usability and maximum URL characters (256) caused by deeply nested folder structures. A flatter, metadata-driven structure is often a better alternative, though it takes more work to plan out.

Mapping and categorisation

You will need some way of knowing where content from the source system should land in the new system, and how it should be profiled with metadata. It’s important to do a mapping exercise to define this. You can define mapping for buckets of content, specifying the location they should be moved to in your new system, and you can do some categorisation on an item by item basis to provide any metadata that will be required for the migration. If you’re building some sort of custom tool or script to move your content, this step is especially important: You need to be prescriptive about precisely where each item needs to be moved when you are scripting the process.

Select the right tool for the job

There are several third party migration tools available from the likes of AvePoint, Metalogix and ShareGate. Personally, I have used Metalogix and AvePoint tools and found them to be more than adequate. I’ve not used ShareGate yet myself, but everyone I’ve spoken to about it has sung its praises. Therefore it probably comes down to your project’s budget and your organisation/implementer’s existing partnerships which tool you select. I suggest you assess all three of these tools. If you’re moving from SharePoint to SharePoint, a third party tool is almost always the way to go, at least in my experience.

An alternative to using a third party product is to build your own tool, or write a custom script. This is often a cheaper alternative to buying a product, and can often be the best option if you’re doing a relatively low complexity migration, for example from a file share into SharePoint. The thing to keep in mind is that your mapping logic will need to be sound, and you will probably need a complete extract of all the source data.

The final option is to get users to migrate content manually. I find this is a good choice if you have lots of rubbish in your source system that needs serious housekeeping: if your business people are migrating content themselves, they are inherently more motivated to do some proper housekeeping by virtue of the fact they will be reducing their own workload when they come to actually move the files. It is also a solid option for web pages if you have defined some nice new layouts in your target system, but still need to take across page content (particularly true of content stored in Content Editor Web Parts on SP2010 and MOSS 2007).

Trial run

Before migrating into your production environment, it’s worth doing a trial run into your pre-PROD or User Acceptance Testing environment (you’ve got a UAT environment, right?). You can test your mapping logic, tooling, and – perhaps most importantly – get a good idea for how long the process will take. This information will allow you to plan downtime, change freezes etc. more accurately, and ensure you can set the expectations of your stakeholders correctly.

Testing

You need a plan for verifying a) that the content has all been moved, and b) it’s in the right place with the right metadata in your target system. Another key thing to test for is broken links, which will almost certainly be a problem if you’re migrating any pages. Users and content authors don’t tend to understand the concept of relative URLs, so it’s likely any links between pages on your old system will be broken post-migration.

The actual migration

You need a solid plan in place for the actual migration into live, and you may need to communicate/enforce a change freeze in the source environment. An alternative to a change freeze is to migrate, get your users on the new system and then go back and ‘mop up’ the delta between your first migration and the go-live on the new system. A good time to do migrations is usually over a weekend, since they often cause disruption (either through change freezes or ‘locks’/performance problems when extracting or importing data).

Change Management

From the outset of the migration project, you will need a solid communication plan in place. You need to tell your stakeholders what will be expected of them and when, plus informing any users of the source system what is going on. You need to explain to users why the migration is happening, when it is happening, and anything they need to do (or not do).

You will also need to train your users with the new system: content authors will need to know how to create/edit/publish pages; users will need to know how to upload documents, categorise information and navigate the system; and site admins will need to know how to add new libraries, folders etc. The type of system you are migrating from should also impact how much training you need to do (for example, migrating from MOSS 2007 to SP2013 won’t be a massive step-change, but going from an ancient file share to an all-singing, all-dancing SharePoint system will be a major shock to the system for your users).

Governance

One final thing: if you don’t want your new system to descend into chaos, you will need a well-defined, enforced governance plan in place. Governance is a big topic, so I won’t open that particular can of worms here, but it’s something you need to ensure you have in place in order to realise many of the benefits of migrating to SharePoint in the first place.

Bringing It All Together

So that concludes my whistle-stop tour of how to approach a migration project with SharePoint. The complexity of migration should not be underestimated, and it is rarely a case of a seamless “lift and shift”. Even for simple migrations, there is a lot of analysis, stakeholder engagement and planning that you need to do in order to ensure success.

Thanks for reading.

Multilingual

Multilingual in SharePoint: Part 2 – How much will it cost?

nathanwells20141 Comment

Introduction

In the previous post in this series, I discussed the options you have available if you are considering implementing multilingual in SharePoint, as well as some of the factors that should influence which of these options to choose. In this second and final post in the series, I will talk about how to assess the true cost of implementing multilingual.

CapEx Costs

The upfront costs to implement multilingual are often considerable. There needs to be careful design planning, as well as changes to how you develop custom functionality and deploy it. After code-complete, the costs of content creation and training will also increase. For multilingual, the following upfront activities need to be taken into consideration on top of the costs you have already projected for SharePoint:

Design

If you are implementing variations in any form, you will need to consider the following additional activities as part of your solution design. You should also refer to the TechNet article about planning variations and utilise the resources provided there.

  • Determine which languages are required;
  • Plan which variations sites you require;
  • Plan which language site will be your source;
  • Plan your information architecture around the site collection limitations of the variations framework (i.e. variations works within a site collection, not across the web application/farm/tenant);
  • Plan timer job schedules (on-premises only);
  • Define who will be the designated contact for each of your variation sites;
  • Plan how search will work in your new multilingual architecture; and
  • Define your content translation process and any custom workflow required.

If you are implementing MUI (Multilingual User Interface), you will need to do the activities detailed below. If you are implementing MUI + Variations, you will need to do the activities below in addition to the activities above:

  • Define and document the translations required for all terms within your taxonomy, for all required languages;
  • Define translations for custom content type names;
  • Define translations for custom column names;
  • Define translations for managed property names;
  • Define translations for custom web part titles;
  • Define translations for lists and library titles;
  • Define translations for custom text within web parts; and
  • Define translations for custom user profile property names.

Build

As part of your development costs, you also need to account for the following tasks:

  • Provision custom site columns to support localised names;
  • Provision custom content types to support localised names;
  • Provision document libraries and lists to support localised titles;
  • Provision custom web parts to support localised titles;
  • Provision custom web parts to support localised content;
  • Create a custom control for search refinement panels (if you intend to use anything other than the default language label for a term in your search filters);
  • Provision your taxonomy with language labels for each term;
  • Provision user profile properties with labels for each language;
  • If using taxonomy-driven navigation, develop global navigation in such a way that it supports awareness of localised term sets;

Term Labels

Test

You need to test a multilingual solution in all languages. You will often find that your test execution estimates will multiply by the number of languages the solution will support, unless you opt for lightweight smoke testing. You also need to consider the following additional testing tasks:

  • Test UI in all languages to ensure the desired layout is still achieved with different word lengths for different languages;
  • Test content synchronisation processes;
  • Test search experience in all languages; and
  • Ensure all spellings are correct for all languages.

Deploy

For variations implementations, you will need to consider the following additional deployment tasks:

  • Configure variations timer jobs (on-prem only);
  • Configure variations settings and labels; and
  • Create variations hierarchies.

If you are implementing MUI-only, you will need to perform the below deployment tasks. If you are doing variations, you will need to do the tasks above and the tasks below:

  • Download and install all required language packs (on-prem only); and
  • Configure the language settings for sites.

Create content

Something that is often overlooked as part of multilingual implementations is the need for content to be created. In a typical intranet, dozens (perhaps hundreds) of sites will need page content and supporting documentation created and uploaded by devolved owners before the system is ready to be rolled out to the organisation. With multilingual, it is likely that the content creation effort will multiply by the number of languages the solution must support. All content must be localised for the correct language, including pages and documentation.

Business Change

Additional communication and training will be required to enable your content owners to use the solution correctly on an ongoing basis. This becomes much more relevant and important for variations, but should also be considered for MUI-only multilingual situations. You need to account for the following additional business change activities above and beyond what you would do in a “normal” SharePoint implementation:

  • Assign responsibility for the translation/localisation of content to appropriate people for each language;
  • Create governance plan (or add a new section to your governance plan) specifically for multilingual, and the rules and policies that govern how it is to be enacted in your organisation;
  • Communicate the publishing and translation process to all stakeholders;
  • Train source site content authors how to publish content to target sites;
  • Train target site content authors how to translate and publish content to their site; and
  • Train administrators how to monitor and report on variations.

OpEx Costs

Additional up-front investment is only half the story: by implementing multilingual, you are also introducing increased costs on an ongoing basis.

IT Support

Multilingual is technically complex, introduces risk and therefore increases your support costs. Your service desk will almost certainly need to field more calls for a multilingual implementation than they will for an equivalent single language solution. Support costs could increase by as much as 50% per month, depending on the exact solution.

Content Translation

So you’ve implemented a lovely multilingual solution that is reliable and works well, but you still need human intervention to localise content. This will be the single biggest cost increased incurred from going multilingual, but it is very hard to project. It largely comes down to whether you will localise content yourself, internally, or whether you will outsource the translation to a third party supplier.

If you need to translate/localise content using internal resources, you will almost certainly need additional headcount. The best way to estimate the increase in work is to get some stats for how many pages get produced per month (or year) and how many languages these will need to be translated to. News articles are the biggest source of ‘churn’ in terms of new pages on a typical publishing intranet, so these are a good starting point.

A company producing 500 news articles per year and implementing just 5 foreign language sites is going to require 2500 localisations of pages per year. That’s a lot of work. It’s also worth noting that you’ll probably need at least one translator per language site, because it’s tough to find people with the ability to speak more than two languages to a fluent, professional level.

If you outsource the translation of content, there will obviously be costs incurred. I would advise seeking quotes from translation companies, which are typically based on number of words to translate.

Future changes

Any future changes to your system will incur increased design, build, test and deployment costs in order to accommodate multilingual – just like the points outlined in the CapEx costs section of this document. This isn’t necessarily something you can allow for in a business case, but should definitely be kept in mind. The increased costs will keep on coming for every new investment you make in your multilingual platform.

Bringing It All Together

There’s a chance after reading this series of articles that you’re feeling a bit bummed out about the prospect of implementing multilingual in SharePoint. It’s expensive, but sometimes the business case will stack up because the need for localised content outstrips the costs incurred. For those companies that have the cash, SharePoint’s MUI and variations framework offers a robust means of delivering a multilingual solution. But you should never underestimate the increased effort, risk, and cost that must be absorbed in order to deliver such a solution.

Thanks for reading, and thanks to my colleagues Paul Ryan (http://paulryan.com.au/) and Chris O’Brien (http://www.sharepointnutsandbolts.com/) for facilitating some of my thinking in this area.

—————————————————————

Part 1: What are my options?

Part 2: How much will it cost?

Multilingual

Multilingual in SharePoint: Part 1 – What are my options?

nathanwells20141 Comment

Introduction

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:

  1. What are my options?
  2. 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:

  1. MUI (Multilingual User Interface); and
  2. 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:

  • Navigation;
  • 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.

365 Language Settings 2

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.

Language Site Settings

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.

MUI translations
There are a few “nuances” to be aware of with the MUI. Keep the points below in mind if you are planning on using it:

  • 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

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

Redirection Hub

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.

Content sync

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.

Translation
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:

  1. Do you need the same content in different languages?
  2. 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?

Part 2: How much will it cost?