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.

Click on “classic experience” and you get a few more, but not nearly as many as you get for normal sites.

Something something taxonomy, yada yada.  There are a couple of taxonomy-related hidden features on SharePoint sites.  A little digging and it looks like feature with ID 73EF14B1-13A9-416b-A9B5-ECECA2B0604C is not enabled on Private Channel sites, but is enabled on other sites.  Try this command to turn it back on:

Enable-PnPFeature 73EF14B1-13A9-416b-A9B5-ECECA2B0604C -Scope Site -Force

That did it for me, suddenly there were 20 options of apps that could be added, including Calendar, Tasks, Promoted Links, Surveys, all the good classic SharePoint stuff, plus most of my custom apps.  It works for me, it might work for you.

Did you find this article useful? Have questions? Let us know in the comments.

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:

Different language pairs will have different types of errors.  Again, depending on the types of errors you are getting and how badly you need to correct them, there are different things that you can do.  Take negation errors for example.  These are easily noticeable by users.  A sentence that contains a negative in the source language may be incorrectly missing the negation in the target language, or vice-versa, or may have incorrect scoping: does the not/nicht/kein apply to one adjective, to the whole clause, or to the verb?  Some languages handle negation differently, and it is not necessarily clear to the translation engine what is being negated.  It is a particular problem between English and either Russian, Lithuanian, or German.  Part of the reason is that training sets used to create and tune translation engines don't contain a lot of negation.

Negation is only one category of errors among many others, but a very noticeable one.  Linguistic and statistical measures of quality will say the translation is very, very close, it’s only off by one word, but the client will say not it’s not, it’s as wrong as it could be, it’s the opposite.  It is a very simple error to correct, it requires very little editing time to change it.  Humans and machines have very different evaluation criteria.

Post editing is the simplest and most robust solution.  It means making changes to the translated page or document.  It should be implemented whether or not you implement some of the other solutions.  Machine translation is not perfect, so limited post-editing is good practice.  It is still significantly cheaper than professional translation or editing and may be cheaper than Azure Custom Translator.  PointFire Translator by default saves all documents, pages, and items as drafts, and someone should revise that draft before it is published.  This advice is not what most people want to hear, they want a technology solution because they don’t have the in-house expertise to translate, and would like the technology to solve the problem without involving them.  Sorry.

Who should do this?

The obvious answer may not be the best one.  “We have someone in the office who speaks both languages”.  No matter how clever they are, efficiently editing documents in their other language may not be in their skill set.  And you have to make sure that someone’s ethnicity or cultural background does not mean that they get extra tasks that do not contribute to their career progression or career goals.

What is this “limited editing” that I mentioned?  That is actually very challenging even for professional editors and translators.  You want to limit the time that is spent in this editing step, otherwise you will end up spending more on post-editing than you would have for professional translators.  Remember, professional translators have access to machine translation too.  Today’s translators are already only charging you for machine translation plus the cost of post-editing, and they are very good and quick at doing this.  They have glossaries, translation memory databases, and previous translations at their fingertips and they do this all day. The cost advantage that you have over them comes from the fact that they’re perfectionists and you’re not. 

Limited post-editing means you correct some errors that are show stoppers and easy to correct, like negation errors, and let other errors slide.  You find poor phrasing, not quite the right word, or errors in agreement between the noun and the adjective?  These are errors that do not require reading the original text in a different language in order to correct, and everyone reading it knows what the author meant to say.  And those errors are more time-consuming to correct.  I know it’s hard to see an error on a page that you are editing and leave it there, and not everyone agrees with this advice, but this is how you control costs.  Given the current quality of machine translation, for most documents you will not even hit the edit button, you will click on publish if you can resist the temptation to fiddle with the text until it’s perfect.  Different types of documents require different edit rules. If the text is describing a procedure that must be exact, spend more time ensuring that it is exact.  It’s like a food processing assembly line.  There are some acceptable defects, but also some that cannot be tolerated no matter the cost.

As we will see below, certain errors are difficult to prevent by other methods.  Post editing is the best way to correct them, but if too much post-editing is required or too many errors are missed, professional translators may be a safer or less costly alternative.

While Azure Translator uses the same translation engine for everyone, Azure Custom Translator is an alternative engine that you can re-train on your documents and vocabulary.  It can increase translation accuracy by a few points, particularly for specialized domains.  You’re in the automotive industry?  Tell Custom Translator and your score will already improve over the default engine.

Unfortunately, re-training a translation model, the main component of the translation engine, is not very simple and it requires some knowledge of linguistics and statistics, plus a lot of data and data cleaning, to get the advantage of having your own model.  The new preview interface of Azure Custom Translator is a big improvement, but it still needs some work.  I may blog more in the future about how to use it, but here is a brief introduction.

Besides those 10,000 sentence pairs, you will also need a testing set and a tuning set.  To simplify the process a bit, neural network models train on a training set, but you also need a set of sentences to test on.  If you over-train a neural network translation model, it will become very good with the sentences it has seen, but at some point it becomes worse at the sentences that it hasn’t seen.  It is memorizing the training sentences, but not generalizing.  You have to stop the training when it gets to the highest quality score, and before it gets worse.  The measure of quality that it is optimizing is called the BLEU score.  Again simplifying a bit, the BLEU score looks at the translation that the model produced and compares it to the translation that a professional translator provided. The score is a purely numerical comparison.  For each sequence of 4 words in your translation, does that sequence of 4 words appear in the reference professional translation?  How about for sequences of 3, 2, or 1 words?  The score has other factors as well, but that is the essential.

Those engines went live in March 2022 and are available by invitation.  They will probably be generally available some time next year.  They are particularly good at languages for which there is a smaller training corpus, for example southern Slavic languages like Slovenian, Bosnian, and Bulgarian.  If your language pair is among the ones that get a significant improvement in quality, it’s worth trying to get an invitation.  At the moment, this can not be combined with Custom Translator.

This is a bit strange to say, but English is not a good source language to translate from.  A lot of its grammar is vague or ambiguous.  For example, it often recycles words to mean something else.  Well known examples include “A good pharmacist dispenses with accuracy”. “Dispense” and “dispense with” are very different concepts that use the same words.  It is obvious to humans from context, but how is a computer to know?  “Bill gave the dog water and Sue the cat food”.  Here the conjunction reuses the verb give, but the subject, direct object and indirect object require an educated guess. Is it a single object made up of one noun (cat) describing the other noun (food), or two different objects of the same verb?  English does not have declensions and is stingy with the prepositions that other languages use to make such things clear.  English is infamous for its sequences of nouns where the reader or computer must determine what describes what.  For example, we can figure out “airport long term car park courtesy vehicle pickup point” from our knowledge of airports and car rentals, but can a computer figure out which word describes which other word or group of words enough to translate it?  Machine translation would have more luck with the less common but still correct English phrasing “pickup point for the courtesy vehicles of the airport’s long-term car park”.

But before you decide to write all your original documents in Lithuanian rather than English to improve translation quality, know that it is possible to write in English in a way that is easier to translate.

Microsoft publishes some style guides with sections on how to author documents so that machine translation has fewer errors and is easier to understand.  You can find them here.

Style guides for machine translation are similar to style guides for writing for ESL audiences, where some English language constructs that are potentially ambiguous for non-native speakers are avoided.  Within the Microsoft style guides are some tips about writing so that machine translation will have higher quality.

https://docs.microsoft.com/en-us/style-guide/global-communications/writing-tips

Some of the tips seem to have been written at the time of earlier versions of machine translation which had problems that are less common now, but there is no harm in reducing ambiguity.  The tips include:

• Use articles. Does “Empty container” mean “Empty the container” or “The empty container”?  Articles (determiners) make it explicit.
• Reduce chains of modifiers. Instead of  “well thought-out Windows migration project plan” say “a project plan to migrate Windows that's well thought out”
• Keep adjectives and adverbs close to the words they modify. Pay particular attention to the placement of “only”.
• ·Use simple sentence structures. Write sentences that use standard word order (that is, subject + verb + object) whenever possible.
• Use words ending in –ing carefully. A word ending in –ing can be a verb, an adjective, or a noun. Use the sentence structure and optional words to clarify the role of the –ing word.
• Use words ending in –ed carefully. A word ending in -ed can be a modifier or part of a verb phrase. Use the sentence structure and optional words to clarify the role of the –ed word.
• Add an article (a, an, the, this) before or after the –ed word. “They have an added functionality.”
• Add a form of the verb be. “Configure limits for the backup that are based on the amount of storage space available.”

I would probably add a few more tips.  Be careful with the scoping of negation and of adjectives/adverbs (often a word can be one or the other).  Keep the negation or the adjective close to what it modifies, whether a word, a noun phrase, a clause or the verb, and try to phrase it so it is not easily mistaken.  An example of negation scoping is “All that glitters is not gold”.  Is it saying that everything that glitters is made of something other than gold?  It might, but it is probably asserting that the set of all items that glitter does not coincide with the set of gold items. It depends on whether it means {all that glitters} is-not gold, or {all that glitters} is not-gold.  The “not” could be associated with “is” or with “gold”.  I am tempted to wander into a digression into predicate logic or set theory, but that would take us away from the scoping problem.  Not all who wander are lost 😉

Also be careful with words that can have several senses.  Instead look for a different word with fewer senses.

Some translation issues are not easily solved with these strategies.  This is because in addition to communicating across languages, you may be communicating across cultures.

There are translations that correct but are hard to understand or insensitive for cultural reasons.  Some of them you can change before translation takes place, others can be caught during post-editing, but there is another alternative.

For example, if you talk about hitting a homerun, or about pulling the trigger, or call two things kissing cousins, these are cultural references that may be common in your country but may be hard to understand elsewhere even with a correct translation.  More recent translation engines are better at common idioms, but it’s still risky.  And it’s not just American English that draws from its culture.  For example, Japanese has a term “mikka bouzu” meaning “three-day monk”.  Some knowledge of Buddhism and Japanese culture is required to understand this is someone who gives up too easily.  German has a word “Deppenleerzeichen” meaning “Idiot’s space”, a derogatory term for putting spaces between words that the German language normally sticks together in a large compound word.  Some knowledge of German syntax is required.

Some more difficult cultural issues are better caught in post-editing.  Some correct translations are to be avoided because they sound like slogans used by political parties or extremist groups.  Catch me some day in person and I might tell you about some big yikes.

Another issue has to do with tone.  A perfectly correct translation of communication written in German may sound inappropriate or even rude when translated to Japanese.  That is because the German culture is comfortable with directness while Japanese employees are more comfortable with more indirect phrasing.  Some re-training of the model using professionally translated text where the tone of business communication has been adjusted to be culturally appropriate is useful.  However in some cultures such as Korean, verb forms and vocabulary depend on relative status of the writer and the reader, whether peer or subordinate, or on age difference.  This is called honorifics or register.  Similarly, many languages have differences based on the gender of the person being addressed or of the person who is speaking or writing.  This is context that the computer does not have, so its  phrasing may violate cultural norms.

When it comes to these cultural norms for things like tone, post-editing is the only way to fix these errors but correcting these type of errors can be time consuming, inconsistent with the “limited editing”  that was recommended.  Another alternative is to educate the readers of the translations about the cultural differences and explain that messages from that country may be expressed differently based on their different culture, and that no offense is intended.  Educating the readers about cultural differences may be more cost effective than adapting all translations to the different cultural context.

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.