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.
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:
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.
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;
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.
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.
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.
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.
Additional up-front investment is only half the story: by implementing multilingual, you are also introducing increased costs on an ongoing basis.
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.
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.
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 2: How much will it cost?