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