The alternative, according to Microsoft, is to create your own single-tenant app registration in your own tenant’s EntraID, and use a different form of Interactive login.  A command to create such a single-tenant app registration is being prepared by the PnP group, but at the time of writing three days before the deadline, it has not yet been released as part of PnP PowerShell

Register-PnPEntraIDAppForInteractiveLogin

Currently, PointFire 365 has two apps, both of which must be added to the site, named PointFire 365 and PointFire 365 Modern.  In rough terms, PointFire 365 handles classic pages and pages in classic mode, while PointFire 365 handles modern pages.  To use Microsoft’s terminology, “PointFire 365” is an add-in and “PointFire 365 modern” is an app.  To avoid redundant code, the two apps (formally an app and an add-in) work hand in hand.

In recent years, SPFx has added a lot of functionality that it was missing, to the point that it is now possible to put all the functionality into a single app.  The project for doing this started long before the Microsoft announcement.

Another aspect of this new version is changing a lot of the popup and configuration page from full pages as they mostly are now, to panels on the right of the page, as you often see in modern apps and as you have doubtless seen while editing modern pages.  As it happens, doing popups and pages is something that is difficult to do in a modern app and we were planning to do away with those anyway.  Doing the architecture change and the UI change at the same time makes sense.

Version 2.7 of PointFire 365 is the last one where the classic app is mandatory.  Version 3.0 will still have both the classic and the modern app, but the classic app will not have much functionality other than helping with the transition for users who are used to the current apps.  This will happen this summer 2024, long before Microsoft’s 2026 deadline, so the impact on existing users will be minimal.

This article shows you how to use PointFire Localizer to localize your SPFx solutions.

Every SPFx component has its own localization folder (`loc`) which contains a `en-us.js` and `myStrings.d.ts` file. There are ways to simplify this, like using a single localization file for all components, but eventually, you still must maintain all the key/value pairs for all languages.

For instance, starting with a new SPFx project will get a `loc` folder with the `en-us.js` and `myStrings.d.ts` files. If you want to add French, you must create a `fr-fr.js` localization file and include the same key/value pairs as in the `en-us.js` file.

As you can see it correctly picked up typos in the English text, in the French text and in the German text, but it does not do the Portuguese text, it put squiggles under each of those words.

How did I configure it to get those results?  First let’s look at the announcement in the admin centre’s Message Centre.

It’s not much to go on, but further down it also says this: “The Microsoft Editor Spellchecker, now integrated in SharePoint pages, will now be able to proof text in multiple languages. In addition to supporting the Page language, Editor now proofs in the M365 language and the Edge browser language. Any word in any of these three languages, will be spell checked appropriately. ”

In this case I have configured Chrome for three versions of English, one version of French, and one version of German, so three languages altogether excluding the variants.  I also turned off the spell checking.

Next, I turned off the Microsoft Editor browser add-in, whose settings would supersede the simpler version of Microsoft Editor that is built into SharePoint. Lastly, I turned the Editor feature back on, which I had turned off when that setting had become available, by pressing on “Page details” and turning on the “Use Editor” setting.

Now it finds typos in English, French and German, but not in Portuguese.

Next, I added some Spanish text and then changed my Office 365 profile language to Spanish but not my Microsoft 365 account language.  

It then happily spell-checked the Spanish text.

One thing that is interesting about this is that, based on the announcement, on similarities with the Microsoft Editor browser extension, and on sneaking a peek at the code, it theoretically should only support up to three languages.  In actual fact, it supports as many languages as I tried.  I did notice that when you have more than one language, it stops checking for grammar or syntax as well as it does with a single language.

This is a significant improvement in the editing experience for people with multilingual sites, so if you had turned off the Editor feature, now is the time to turn it back on.

I hope you found this article helpful. Feel free to leave me your questions in the comments.

There are relatively few examples or information on what to do next, but we will add a minimalist formatting skeleton.  The syntax is described here https://learn.microsoft.com/en-us/sharepoint/dev/declarative-customization/view-group-formatting

The “group by” headers are within “headerFormatter” within “groupProps”.

The syntax for “headerFormatter” is identical to that of column format, with the important caveat that a lot of it, despite correct syntax, does not work.  Yes, there is a “txtContent”, but things like “@currentField” and “[$FieldName]” are not defined and most special strings, most notably "@UIlcid", are not available.

That makes determining the language and formatting the value depending on the language difficult, because all of the techniques discussed in previous posts are not available.

What is available is "@group", which has three properties,  "fieldData", "columnDisplayName", and "count".  Normally the use of column display names rather than internal names is a mistake.  If you rely on it then things will break badly (like they do for list form JSON formatting) when you change the language, but in this case, that unfortunate design decision can be used to our advantage.

In this case we have already localized the column names by entering the translations in the MUI (Multilingual User Interface)  That means that the “Progress” column has a column display name of “Progress” in English, “Progrès” in French, and “Fortschritt” in German.  The value of “@group.columnDisplayName” therefore tells us what is the current UI language, as long as the column header has been localized and its name is different in different languages.

If we display the value of “@group.columnDisplayName” and of “@group.fieldData” in English we get this:

The benefits of using this technique rather than the one in the earlier post are

1. It is slightly shorter than before
   
2. It does not require an additional Yes/No column in the view
3. It can support all 50 SharePoint languages

The disadvantage (for some)

• It will usually not work without PointFire 365

If you do not have PointFire 365, then the technique in the earlier post is better.

There is an exception to this: Communication sites with the Multilingual Publishing feature turned on.  For the source page in the original site language, it accepts that language and rejects others

This does not work every time for me, but it is difficult to reproduce.  What about if you’re not using the Multilingual Publishing feature, like for example on a Teams sites where the feature is not available, or if there is a need to have text in more than one language, or to not use the feature?

Well, there is always the plug-in.  The Microsoft Editor browser plug-in for Edge and Chrome is a different version of the same Microsoft Editor.  Unlike the version in SharePoint, it does support multiple languages.  Its configuration is a bit clunky and hard to find, but you can set up to three proofing languages with the plug-in.  You must go to a site other than Office 365 that has a multi-line editor and make a spelling error

Do you think that all your content creators are going to be able to configure their browsers and their browser plug-ins to select a list of possible languages?  Maybe not.  So what can you do on the server to turn off the feature altogether?  Until very recently that was not an option either.

In late April 2022, a new feature appeared unannounced with a brief description on the Microsoft site.  While editing a page, select Page Details at the top of a page.  You may have to publish the page first.  In the page details pane, you will see

You can use the slider to toggle the Microsoft Editor on this page.  You have to repeat it on each page.  There is no simple way to toggle it programmatically because it’s not a regular page property, and no way to set it for an entire site or tenant.

Maybe some day the SharePoint version of Microsoft Editor will become as configurable as the other versions or will do proper language detection, but until that happens the two options are to either turn it off on a per-page basis or to install and configure better language detection on a per-workstation basis.