This is the first of a series of posts based on my talk "Using Communication, Team, and Hub Sites in a Multilingual Organisation".
Once upon a time, large transnational organizations had many separate SharePoint farms in different countries or regions. This made sense. A SharePoint farm could only handle a few thousand users comfortably before the complexity and the management of the farm wiped out any economies of scale. A large global farm meant you had a lot more to worry about.
You had to worry about access via internal networks, you had to worry about security and network latency for people accessing the SharePoint farm from a different office. You had to worry about access control: who in the organization had enough knowledge of different users across the organization and of various organizational assets stored in the SharePoint sites to manage all of these users across the world and what they are allowed to do, to set up the governance policies and their exceptions? You had to worry about maintenance windows and support hours when operations spanned many time zones.
Very importantly, you had to worry about data residency. Many jurisdictions across the world have laws governing where different types of data can be physically stored. That made it difficult to have a single farm that served several different countries.
The simplest way to deal with all of this was to have separate SharePoint farms in different countries or regions. This is a physical topology. The organization has multiple farms, each farm has multiple web application each web application has multiple site collections, each site collection has multiple sites. All nice and hierarchical.
What if the organization has multiple languages? Where is language in this physical topology? Every farm that needs more than one language needs to have language packs installed. Installing those is the responsibility of whoever is managing that farm, in other words it is a country or regional responsibility. Different farms can have different base languages and different language packs. Every site has a base language, and the site template from which it is created is language-specific. When new sites are created on these farms, they support a single language unless significant effort is put into having some support for other languages. They are unilingual by default.
If you are using Variations, then responsibility for languages is much lower down in the hierarchy. All Variation labels need to be within the same site collection. And with Variations, each site is defined by its one language, so each site is unilingual. Variations creates each site using a language-specific site template. Therefore, responsibility for the language of the content is at the lowest level of the hierarchy, within a site collection, and few people have to manage more than one language at once.
There are two possible exceptions to this general rule: the content type hub and managed metadata service. Both have multilingual features and both are centrally managed. In order for syndicated content types and managed metadata to work properly on sites that support a different language, then whoever is managing these central resources must activate those languages and maintain the translations of the terms and column names and so forth being used. That is an exception, and a topic for another day; in the more general case the physical topology of on premise SharePoint means that language is an issue that is handled locally, within a country and often within a site collection, one language at a time.
SharePoint Online and in particular Modern sites are different. When you create a tenant, every language pack is already installed. When you create a modern site, all 50 languages are already activated. The templates from which modern sites are created are not very language-specific. There is very little difference between a site created in English and one created in Japanese. If you go to a site that was freshly created in Japanese, you will see it in English, if English is your preferred language because every language is activated. Modern sites are multilingual by default.
There are no farms or web applications in SharePoint Online or Office 365, only tenants. If you use modern sites you are discouraged from using site collections. You cannot have two modern sites in the same site collection. There is no hierarchy, it is flat. Sites can be clustered around hubs, but that is not the same thing as the type of hierarchy that you had with site collections. And a site that belongs to one hub today can easily move to a different hub tomorrow. Rather that the inflexible physical topology of on premise farms, you have a flexible logical topology.
There is still the possibility for an organization to have many different tenants, physically hosted in different data centres. Microsoft offers data centres located in over a dozen different countries. What is better, having a single tenant for the entire world, or having different regional tenants, each of them physically located near the users you have in that country?
Even though SharePoint Online resolves a lot of the hosting, security, and scale problems, you still have the issues of data residency laws and of network latency. But there are so many benefits to having a single global tenant, even more so than in the days of multiple on premise farms. Because now, the boundaries between regional tenants are impenetrable. Getting data from across that boundary is just as hard as getting it from the intranet of a competitor. With multiple regional farms, you could share some services across farms. But with SharePoint Online, you cannot search across tenants, you cannot easily share content types or metadata, or benefit from other collaboration opportunities of Office 365 like Groups, Teams, and Outlook. You can't easily transfer staff from one to the other and have information follow them. Office 365 resolves all the other problems associated with a single farm, is solving the data residency and network latency issues worth keeping regional tenants?
Now even that argument is gone. For larger organizations, Microsoft now has multi-geo, the ability for the data of specific employees to physically reside in different data centres while still enjoying the benefits of a single global tenant. A tenant does not need to have all of its data physically residing in one place, and it is easy for an employee to transfer from one region to another. With a single tenant, you get the added benefits of the ability to share and to find information about documents and about employees throughout the organization. One tenant to rule them all! One tenant to find them!
The impact of this move from the old physical topology to a more flexible logical topology, with flatter structure and where both sites and users can move easily, is that the issue of multiple languages now shifts being from a purely local issue delegated to site collection administrators to being a central problem that must be tackled by HQ at the corporate level. The move of modern sites from being unilingual by default to multilingual by default underlines this.
Rather than having language as a leaf node of a hierarchy of farms, web applications, site collections, and sites, support for multiple languages has to be designed into the structure from the start. If a hub site can have sites that are used by people of different languages, even if the member sites themselves are unilingual, then the hub site needs to be multilingual. Right now, it is the hub navigation that must be multilingual, and someone needs to think about multilingual news aggregation and filtering news by language, but in the very near future more and more hub site features will be released, all of which will have to support multiple languages.
In the next post, we will discuss in more details what "multilingual by default" means, whether you use PointFire or just out of the box features of SharePoint.