IceFire Studios

IceFire Blog

Tips on using SharePoint in a multilingual environment

Multilingual Publishing for Modern SharePoint Sites

The promised Multilingual SharePoint Pages was finally revealed in public a few hours ago.  Compared to a fully-featured product like PointFire it's a bit, let's say rudimentary, in that the list of what it will not do is longer than the list of what it does, but it's an important part of the multilingual landscape.  The initial release is still months away.

In general terms what can it do?  It does allow modern pages in the site pages library to be copied and manually translated to other languages.  It does allow a user to navigate from one language version of such a page to a different language version by using a language toggle in the page header.  This language toggle is different from the PointFire language toggle (or from the SharePoint 2010 language toggle) in that it navigates to a different language version of the page without changing the language of the user interface.  It does detect the user language, and certain web parts will be given additional ability to filter list of pages by language.

What it is not is a full replacement of Variations for Modern pages.  It does not include multilingual lists or libraries.  It does not include any classic pages.  It does not include automatic redirection to the page in the correct language based on the user's language although it some cases it does go to that page, and it does not include machine translation of either the pages or the UI elements.

In the brief demo by DC Padur of Microsoft, a typical set of steps was shown.

1. Setup


To start, the site-scoped multilingual feature is enabled.  This requires entering the list of supported languages and the email addresses of the translators (not in the screenshot).  Interestingly,  Microsoft's demo showed the configuration screen at the URL where one can currently choose the site's alternate languages, but the interface seems to show a more laborious way of searching for languages and adding them one by one, rather than the current modern experience of activating all languages, and using check boxes to select and unselect.


Setup includes the following feature "If a site user has manually translated site navigation or site info such as Title or Description, overwrite their changes when the same info is updated in the default language.  This setting does not apply to page or news content"  It is not entirely clear what this does.  It sounds like the "Overwrite Translations" message that you see on that page today, but the phrasing is different enough that it might mean something different.  The current message says "User-specified text, such as Title and Description of the site, can be translated into the alternate language(s) supported by the site. Specify whether the changes made to user-specified text in the default language should automatically overwrite the existing translations made in all alternate languages."

2. Starting translation

After a modern page has been created in the site's default language, while in edit mode a site user can begin the translation process.  This creates copies of the page to special folders in the same library that correspond to the desired language of the translation, and sends an email to the translators.  These folders seem to correspond to a 2-character language code.  Subsequent edits to the original page can result in new emails to the translators, but not in a new copy of the page.

The copies of the page are originally in the initial language.  Presumably the translator will have access to the site with sufficient permissions to edit pages and to change the site name and description, and then change all the text that they can find to the target language.


3. Users can switch between different language versions


When a user wants to see a different language version of a page, they first go to the page in the current language, then click on the language selector in the site header, next to "Share site" to see a different language version of the page that has been modified by a translator.  Translators may have a similar experience, allowing them to navigate to a given language version then edit it.

The MUI and user language selection are essentially unchanged.  There is a fair bit of discussion about how they are a key part of the multilingual pages experience, but all of the functionality mentioned is functionality that already exists.

Because the user language and the site language are separate, editors will not see exactly the same screen as the end users.  They will see the content in the user's language, but any navigation, or list names, column headings, and so forth will not necessarily be in the same language.  This is what Microsoft used to call "a mixed-language experience".


The setup step is something worth watching in the next few months.  Will there be a single list of languages supported by a site, or will there be two lists: the list of alternate languages supported by the UI and the list of languages supported by modern site page translation?  Is SharePoint moving away from the "multilingual first" model where all alternate languages are automatically enabled at site creation?  Also what are the consequences of adding or removing languages after pages have already been created?  Will pages in a deleted language be deleted or orphaned?

The "separate folders" approach is a bit old-fashioned.  After decades of telling people to use metadata not folders, SharePoint succumbs to the temptation of using folders to represent language.  It's still better than separate sites like Variations did.

As expected, machine translation is not part of this new feature.  PointFire is announcing today that PointFire Power Translator will be extending its existing machine translation of modern pages to add support for the pages that are created by this new feature.  It will be the same product as currently exists, which already supports modern and classic pages, and also modern and classic lists and metadata, and various document formats, on SharePoint and OneDrive, but with the additional ability to use the "language" folder structure of this Site Pages library.

What about PointFire 365?  For now, organizations will have a choice between the limited functionality of the new multilingual modern pages or the full multilingual SharePoint functionality of PointFire 365.  For some organizations, this manual translation of certain pages and UI elements is sufficient.  We will provide a migration path to upgrade from Microsoft's feature to PointFire 365 for those who later realize that it is not enough.

All the Languages Supported by PointFire.

PointFire 365 and PointFire Power Translator support a lot of languages, but language support is not the same for all languages.  Here is a current chart of which languages are currently supported and to what degree.

Language Quality SharePoint
Afrikaans Neural N
Arabic Neural Y
Azerbaijani  - Y
Bangla Neural N
Basque  - Y
Bosnian (Latin) Neural Y
Bulgarian Neural Y
Cantonese (Traditional) Statistical N
Catalan Statistical Y
Chinese Simplified Neural HP Y
Chinese Traditional Neural Y
Croatian Neural Y
Czech Neural Y
Danish Neural Y
Dari Neural (Persian) Y
Dutch Neural Y
English Neural Y
Estonian Neural Y
Fijian Statistical N
Filipino Statistical N
Finnish Neural Y
French Neural HP Y
Galician  - Y
German Neural HP Y
Greek Neural Y
Haitian Creole Statistical N
Hebrew Neural Y
Hindi Neural HP Y
Hmong Daw Statistical N
Hungarian Neural Y
Icelandic Neural N
Indonesian Statistical Y
Irish  - Y
Italian Neural HP Y
Japanese Neural HP Y
Kazakh  - Y
Kiswahili Statistical N
Klingon Statistical N
Klingon (plqaD) Statistical N
Korean Neural HP Y
Latvian Neural Y
Lithuanian Neural Y
Macedonian  - Y
Malagasy Statistical N
Malay Statistical Y
Maltese Statistical N
Norwegian (Bokmål) Neural Y
Persian Neural N
Polish Neural Y
Portuguese (Brazil) Neural Y
Portuguese (Portugal) Neural (Portuguese) Y
Queretaro Otomi Statistical N
Romanian Neural Y
Russian Neural HP Y
Samoan Statistical N
Serbian (Cyrillic) Statistical Y
Serbian (Latin) Statistical Y
Serbian (Latin, Serbia) Statistical Y
Slovak Neural Y
Slovenian Neural Y
Spanish Neural HP Y
Swedish Neural Y
Tahitian Statistical N
Tamil Statistical N
Telugu Neural N
Thai Neural Y
Tongan Statistical N
Turkish Neural Y
Ukrainian Neural Y
Urdu Statistical N
Vietnamese Neural Y
Welsh Neural Y
Yucatec Maya Statistical N

SharePoint itself supports 51 languages.  PointFire 365 supports all of those languages.  All user interface elements can be shown in any of those languages, all content can be filtered to show content to users in any of those languages.  They are indicated by a "Y" in the "SharePoint" column.

PointFire Power Translator supports even more languages.  If you are unaware of the PointFire products, PointFire 365 is the one that handles localizing the user interface and filtering content by language, while PointFire Power Translator is the one that carries out machine translation of documents and metadata in SharePoint Online and OneDrive, and of the content of any library, list, or classic or modern page in SharePoint Online.  Where the language is one that is supported by PointFire 365, the combination of both products means documents and SharePoint pages immediately show up in any of those languages.  For example if you send a news page to translation using PointFire Power Translator, it will translate it into the other languages of your site within seconds and all users who prefer one of the other languages will see the version in their language rather than the original.

However the quality of machine translation can vary.  In the back end, PointFire Power Translator uses one of four different translation technologies, powered by Azure translation technologies.  The technology that most people are used to, which powered the old Bing and Google translation engines, is statistical machine translation.  This was the state of the art until a few years ago, using syntax-based statistical translation models with a few additional tricks to improve language quality.  It trains on large corpora of text that is already translated, trying to mimic the translation process using statistics.  This technology got better and better over the years.  For several languages we are still using these statistical models.

Around 2015, based in large part on algorithms developed at the University of Toronto and Université de Montréal, Neural Network models emerged as a better alternative to statistical models.  These deep networks require enormous amounts of computing power to train.  Interestingly enough, large software companies like Microsoft and Google tend to publish their results and make their insights and tools available to each other, so that they can each improve on one another's work.  Because of this, neural machine translation technology has progressed quickly.  It still requires massive amounts of computing power to train such models, something like 100 processors for a week for each training run, but Microsoft is a leader in technologies to use less processing power so it uses a fraction of that.  For most major languages, PointFire is using neural translation.

Then in March 2018 Microsoft announced it had achieved "Human Parity" for some translation tasks.  Mind you this is a controversial claim and neither the humans with whom parity was achieved nor the people doing the rating of translation quality were professional translators, but we use the "HP" label to refer to the technology being used, not necessarily to the quality level.  These initial engines were not suitable for production, they were far too massive.  Microsoft then improved on the size and performance of these complex models, using groundbreaking techniques.  For example they use a large deep neural network to train a much faster wide shallow network, gaining a huge performance improvement and improved translation quality.  They train a separate neural network to detect and correct errors in the input data.  They use the trick that so many of us have used to hilarious effect: it translates sentences from English to another language, then translates that translation back to English to see whether it is the same.  These new "human parity" engines have been sweeping international competitions of translation quality and, as opposed to a lot of the other entries, these are available in production.  Chinese and German were released in late November 2018, and French, Hindi, Italian, Spanish, Japanese, Korean and Russian, to/from English are now available.  More details on the Microsoft Translator blog if you are interested.

The highest quality of any translation engine on earth is still not good enough for you?  We offer an even higher quality.  Using Microsoft's Custom Translator, you can re-train an existing neural machine translation engine using your own professionally translated documents so that it adopts your vocabulary and your style.  If you're keen, you can even train it on a different dialect or language.  PointFire Power Translator supports these custom models as well as the standard ones in the table above.

There is a lot of overlap between the languages supported by PointFire 365 and those supported by PointFire Power Translator.  Some of them are the same language, but some of them have a mapping that you may need to be aware of.  For example, SharePoint supports Dari but not Persian, while the translator supports Persian and not Dari.  Written Persian and written Dari are close enough that we have declared them to be the same.  When you check the translations, keep it in mind.  SharePoint supports two versions of Portuguese.  The translator supports only one. It is a hybrid but it looks more like Brazilian Portuguese.  We use the same engine for both, but it's a good idea to check the translations.  For Norwegian, SharePoint explicitly uses bokmål, while the translator uses a different language code that may refer to nynorsk.  From the limited knowledge of Norwegian available to our team, the language code looks like a mistake and we believe that both use bokmål.

The Balkans present their own challenges.  Certain languages of former Yugoslavia are similar to certain other languages. It's a sensitive subject so we will not discuss in writing how we bridge some of the gaps between language codes.  However it has been made clear to us that using a Bulgarian translation engine for the Macedonian language is not acceptable and therefore we do not provide machine translation functionality for Macedonian, until a compatible translation engine specific to the Republic of North Macedonia is available.

There are a number of languages for which PointFire Power Translator can provide translations of SharePoint or OneDrive documents, but which SharePoint itself does not support.  The Item Language column of these translations will be tagged with the language code of these languages, whether or not it is an allowable language code in PointFire 365.  Be aware that PointFire 365 will not filter these documents.  These languages include Icelandic, Kiswahili, and Maltese.  There are in theory two versions of Klingon, one that uses the Latin alphabet and the other that uses the Klingon scripts.  We regret that the version using the Klingon font, if you have installed this font, is no longer working :-(  and we have not invested the time to find out why.

Modern SharePoint Sites: Multilingual by Default


In most versions of SharePoint on premise, and in classic SharePoint sites, you have to declare the language of the site when you create it.  You can also declare it when you create a modern site such as a Communication site, but with modern sites that has a completely different effect.

In classic sites, the language of the site or site collection determines the template that is used for the site, and that template is very language-specific.  The names of libraries, the sample content and many other components are created in a specific language.  In addition, on premise the possible alternate languages on the site are limited by the SharePoint language packs that have been installed on the farm.  By default when you install a new SharePoint farm, it will install it in one language, with no language packs.  

Installing language packs is a slow and laborious procedure.  They are not bundled.  You must download and install each one separately on all servers, and then when SharePoint updates are released you have to update for each language for which you have language packs in addition to the base update.

Once the language pack is installed, you can create new sites in that language, and you can also make that language an alternate language for sites that were created in another language.  That will allow you to localize certain UI elements so that they display in the user's preferred language, but some user interface elements such as error messages, notifications, and dialog boxes do not display in the user's language but in the site's base language.  Given how laborious is the installation of language packs, farm administrators will only install the minimum number of language packs required.

When a classic site is created, it will be created with a base language and no alternate language.  Someone has to add alternate languages to each site, picking from among the languages whose language pack has been installed.  Classic sites are unilingual by default.  The typical way to make a site multilingual is using Variations: creating multiple subsites each of which are also unilingual but in a different language.

For modern sites, this is turned around.  All language packs, over 50 of them, are always installed.  And when you create a new modern site it automatically has all of the languages selected as alternate languages.  Modern sites are multilingual by default.  This applies to all modern sites, including OneDrive.

In addition, Modern site templates are not very language-specific, so selecting a different base language makes little difference.  

For instance, go to the SharePoint start page and create a new site, but select the Irish language, as shown in the image.


Don't worry if your Irish language skills are a little rusty, you will see barely a word of Irish.  Everything is in English.  Almost everything.  The System account is called "Cuntas an chórais" and if you look on the browser tabs, certain pages are called things like "Irish - Form Templates - Gach foirm".  Even the home page with the Hero web part is in English.  Why is that?  It is because the user interface elements and the site templates are designed to be multilingual.  You created the site in Irish, but SharePoint automatically added all the other languages as alternate languages.

It recognizes that Irish is not one of the languages in your user profile, so it renders everything in your language, including the sample content of the Hero web part.  If you want to see your Irish site in Irish, you have to change your language preference to Irish.

This is part of what multilingual by default means.  You don't have to take a lot of actions to ensure that sites can be used in different languages, they can be used in different languages as soon as they are created, and you have to be aware that they will be used that way.

Next post in this series: Multilingual Features of Hub Sites

SharePoint 2019 Machine Translation Service is broken

It's been a busy week at PointFire, with three version releases.  Version 2.2.3 of PointFire 365 came out, with several improvements, the much anticipated version 1.1.0 of PointFire Power Translator, and the final beta of PointFire 2019.  PointFire 2019 v1.0 was scheduled to be released this week, but instead it still remains in beta.  The reason: SharePoint 2019's Machine Translation Service is broken.

The list of deprecated features for SharePoint 2019 was clear; it said "The Machine Translation Service will remain supported but deprecated for the SharePoint Server 2019 release."  But version after version, farm after farm, we could never get the service to work on SharePoint 2019 farms.  Finally a week ago our support ticket with Microsoft reached a conclusion:  the Machine Translation Service does not work.  At all, under any configuration they tried.  The product group is aware.

PointFire 2019 has the option of using the Machine Translation Service for certain translations.  The other option (besides, you know, humans) is to use PointFire Power Translator with its better speed, accuracy, scriptability and flexibility.  The benefit of the Machine Translation Service is that it is free.  But we can't release something with a feature that we never fully tested.  Microsoft might, but not us.  So PointFire 2019 is still officially in beta, and we will see in a few weeks whether we remove the option or whether SharePoint 2019 gets fixed.

Localization of SPFx webparts in Microsoft Teams tabs

This post was prompted by a conversation with Bob German, a Partner Technology Architect for Microsoft.

In his talk at the Collaboration Summit in Branson MO, he touted the localization features of developing custom tabs for Teams using SPFx.

We chatted a bit after that, and discussed the fact that Microsoft Teams has a language setting that is independent of the language settings in the Office 365 user profile, which SharePoint uses.  I was of the opinion that even within a Teams tab, the SPFx webpart would follow the SharePoint language setting.  So let's try it out.

There is some very useful very complete guidance for localizing SharePoint SPFx webparts here

It is simple to create a small example webpart and localize the manifest, the property pane, and the content using the SharePoint guidance.  In this case, it was localized in English and Dutch.  Turning that webpart into a Microsoft Teams tab is just a matter of adding an extra manifest file and zipping it.

Add the webpart's sppkg file to your site catalog and ensure that the “Make this solution available to all sites in the organization” option is checked, so that the web part can be used from Microsoft Teams, then Deploy.


Then in Teams, select "Manage team" then the Apps tab, then "More apps" and "Upload a custom app".  Upload the "manifest.zip" file created earlier, which refers to the app in your app catalog.  Then click on the app name and click on Install, then setup and Save.  Let's have a look.

Here, both my Teams language setting and my SharePoint language setting are English. 

Let's change the Teams language setting.  You can do that by clicking on your picture then on Settings and selecting a new language.


I picked Dutch and re-started the Teams app.  So now the Teams interface, near the top of the screenshot, is mostly in Dutch, while the webpart is still in English.


If we do it the other way around, with the Teams setting in English and SharePoint in Dutch, we have the opposite effect, the Teams interface is in English and the webpart/tab is in Dutch.  So the SharePoint language setting determines the language of the localization of the custom tab.


We will go further still. Go to the SharePoint site that was created when the team was created.  Go to the site settings and remove Dutch as an alternate language of that site without removing it as your personal language preference.


Go back to Teams and now the webpart is back to English.  This is because the language of the tab is not just determined by your Office 365 profile language setting, it is determined by the ability of the associated SharePoint site to render its interface in that language, as though the tab was a webpart on that site.

Many thanks to my colleague Srikanta Barik for his help.

Physical vs Logical Topology: How the move to modern sites changes who is responsible for languages

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.

New product releases for SharePoint Online and SharePoint 2019

PointFire Power Translator is Released 

9 months ago we showed how PointFire Power Translator can be used to translate modern SharePoint pages. Nothing else does this. It uses the latest neural network translation engines, not the old Bing engine.  Thanks to all the beta testers, the final product is simpler to install and easier to use.
 
It's still command-line, but the GUI version, integrated into SharePoint, is coming out in beta this month.

Download free trial



PointFire 365 v2.2 update
 
The latest version of PointFire 365 for SharePoint Online has simpler installation and licensing, better support for mobile, and improvements in Manage Variations and in date/number formatting.
 
The PowerShell scripts for provisioning and upgrading have been enhanced.


PointFire 2019 is coming!

SharePoint 2019 is coming, and PointFire 2019 will not be far behind.  It has all the features of PointFire 2016 and more!  Support for modern sites and improved interface translation are going to be among the new features.  If you would like to get access to beta versions before everyone, contact sales @ icefire.ca

Come see us in a city near you


We are continuing to sponsor SharePoint shows throughout the world.  Come see the latest PointFire tools in person!  If you're in Belgium, we're sponsoring the free event SharePoint Saturday Brussels on Oct 20, 2018.  We're sponsoring SPS Ottawa on November 10, and SPS Detroit on December 8.

The European SharePoint Conference is November 26-29 in Copenhagen, and our CEO Martin Laplante is giving a non-commercial talk about multilingual features of SharePoint Online. Come hear the talk and visit our booth.

Modern Sites Will Let You Choose Site Language: Why It's Not A Big Deal

For the past two years, when you were creating a new modern Team or Communication site, SharePoint would not let you specify the language of the site.  This was unlike classic sites, when the language could always be chosen.  But soon in Targeted Release, the modern site creation dialog will include "Select a language" with a dropdown of 50 languages.  How useful is that feature?

Not very useful.  This is because classic sites and modern sites are different, and modern sites were never very language specific, unlike classic sites.

Modern sites get created with MUI and all alternate languages activated

In classic sites, when you create a site, it has a default site language and no other language.  If you want to use the MUI (multilingual user interface) you have to install language packs (if on premise) and then activate the alternate languages that you want on every site, then make sure that users have their language preferences set.

In modern sites, all of the alternate languages are already set when the site is created.  Setting the user language in the user profile or in the browser is still as troublesome as ever but, since organizations with Office 365 tend to have one global tenant, where before they would have had many regional server farms, there is a greater possibility that users will have set their language preference that differs from the default language.

When alternate languages are set and user language settings are set, then the MUI springs into action, displaying the site's MUI-enabled UI elements in the user's language rather than the site language.  That includes out-of-the-box navigation, and names of lists, libraries, columns, etc, and almost all menus.

There are no Variations

For Classic sites, the site default language had to be set if you wanted Variations to work.  Each Variation label needed to have a different language-region combination.  Each one of them had a fixed site template which only needed to work in that label's language, while Variations deposited content into that fixed site template container.

But Modern sites do not support Variations, and never will.  So that reason for having a site language does not apply.

Modern site templates are mostly language-independent

Classic sites had lots of language-specific text in their templates.  That meant that the MUI never quite translated the entire interface, because a lot of strings were hardcoded in the template.  But modern sites have a lot less that is language-specific.

For example, if you create a new modern site it will have a sample Hero webpart in it, which comes with a lot of sample text like "Welcome! Click Edit at the top right of the page to start customizing" or "Make an impression", "Share your strategy", and so on.  Now change your profile language and reload the same page.  If you haven't changed the Hero webpart yet, then entire text of the Hero webpart will switch to the new language.  The Hero webpart template is not language-specific. This is discussed in How Much Multilingual Support Do SharePoint Online Communication Sites Have?

The same thing happens for most out-of-the-box modern webparts, apart from the odd bug which will be cleaned up eventually.  Similarly for dates: date formatting in modern webparts that have dates by and large follows the language of the user, unlike dates in classic webparts.

The only major difference when you create a modern site in a different language is that the URLs and internal names of standard lists an libraries, like "Shared Documents" and "Site Assets" will be created in the language of the site.  The title that is visible to users will change according to the user's language, so it will always be called "Site Assets" in English, while it is called "Éléments du site" in French, that is just the MUI doing its bit, but the name that is visible to programmers will be different.  That is more of a hindrance than a help, programmers have to deal with the fact that the list/library URLs are not fixed.

So what do you gain when you use this new SharePoint Online functionality?  Not much, really.  If you're a programmer it is helpful to test what happens to your customizations and apps if someone installs them on a tenant whose default language is different from your own, but for normal use, it doesn't change anything.

What would be nice would be if developers would routinely follow guidance about making custom webparts and customizations language-independent.  It is possible to localize SPFx webparts if you really set your mind to it, but it requires extra effort since the process is quite involved.  It's not as simple as using .resx files, but the principle is the same.  Then it won't matter what is the language of the site, the entire UI, including the UI of the customizations, will be language-independent.

It's official, Variations are a deprecated feature

SharePoint 2019 public preview is out!

It brings most of the SharePoint Online experience to the on-premise environment.  But as a follow-up to the announcement 4 weeks ago about the retirement of the machine translation service and possible end of Variations, in SharePoint 2019 the list of deprecated features includes this:
  • Machine Translations (and Variations)
    The Machine Translation Service will remain supported, but deprecated, for the SharePoint Server 2019 Public Preview release.
This is the second shoe to drop from the Variations centipede.  This means that the Machine Translation Service is still there in SharePoint 2019 and they will repair it if it breaks, but no new features will be developed.  Among the features that will not be developed is the ability for modern sites to participate in Variations, and for modern pages to be translated using the Machine Translation Service.  And since "Classic is dead like Latin" you can expect all new features to be produced as Modern pages and to have less and less of SharePoint supported by Variations before the plug is finally pulled.

Some people are saying Microsoft wouldn't drop these essential features without a replacement.  The SharePoint 2019 announcement does not suggest any alternative for those that need the feature.  The SharePoint Online deprecation announcement does suggest investigating the Bing translation APIs, but that suggestion simply will not work.  I will spare you the obligatory ad, you know where to find the one alternative to Variations.
Office365™ - office.microsoft.com IceFire Studios is a Microsoft Partner SharePoint™ 2013 - Microsoft.com