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