The PointFire Blog - The PointFire Blog for Multilingual SharePoint , Uncategorized

Big Changes to PnP PowerShell Scripts on September 8, 2024

Thu, 05 Sep 2024 10:37:17 -0400

On August 21, 2024 Vesa Juvonen, Principal Product Manager at Microsoft announced on behalf of the PnP PowerShell and CLI for Microsoft 365 groups that the “PnP Management Shell” multi-tenant app registration would be deleted on September 8, 2024. This means that on that day, every script that uses the recommended “Interactive” login to connect to SharePoint or to Microsoft Graph will stop working.

This has a major impact on most people using PnP PowerShell scripts. The interactive login method is often the default method used, since it supports a lot of authentication methods including most forms of Multi-Factor Authentication (MFA), and it does not require tenant-specific parameters in the script. This allows PowerShell scripts to be signed for extra security.

Why is it called a multi-tenant app registration? This is because the maximum permissions that can be used by scripts that use Interactive connections to SharePoint are set in an AzureAD/EntraID app that is maintained by Microsoft Patterns and Practices (PnP) group in their tenant and is made available to be used by any tenant. The actual permissions are limited to the lower of those permissions and the permissions of the user that is logging in to SharePoint.

Until September 8, any tenant that wanted to use the “Interactive” login would have needed to invoke the “Register-PnPManagementShellAccess” command, once only, in order to have access to this “PnP Management Shell” app registration from within this tenant. Consenting to this could only be done by Azure AD administrators or Global administrators. After September 8, that consent within your tenant disappears because the original app registration itself will disappear, along with all its permissions. Anyone trying to use a script with Interactive login will fail, since the authentication relies on that app registration.

What is the alternative?

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

With time running out, PointFire is releasing its own script, which uses existing PnP commands to register an app called “PointFire PnP login” in your own tenant. It also stores the app ID in an environment variable named ENTRAID_CLIENT_ID that is used by all scripts that use the “Interactive” parameter, overriding the “PnP Management Shell” app registration that would normally be used. This way, existing scripts will not have to be modified. The new script is called “UserAuthentication.ps1” and will be included in all upcoming releases of PointFire 365 and PointFire Translator, but you can also request it directly from PointFire support.

Localize your SPFx solutions with PointFire Localizer

Mon, 25 Mar 2024 15:02:44 -0400

Managing multilingual SharePoint Framework (SPFx) solutions can get tricky as you need to ensure all translations are in place and take care of localization files from languages you need help understanding yourself. This was a problem we faced when developing our products.

To be sure we always included all localization key/value pairs in our releases, we created some scripts that were only internally used.

We decided to make those scripts available to the community for free so you can also benefit from them. That is why we created a new open-source project called PointFire Localizer. This project is a GitHub Action that helps you translate your localization files for your SPFx solutions.

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

Maintaining localization files

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.

You can read more about simplifying localization in SPFx projects in the following article:

Simplify localization in SharePoint Framework projects · Elio Struyf

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.

```javascript

define([], function() {

return {

"PropertyPaneDescription": "Description",

"BasicGroupName": "Group Name",

"DescriptionFieldLabel": "Description Field"

}

});

```

The tricky part is that you need to keep all those files in sync, so it gets more complicated with the more languages you need to support. Our PointFire Localizer solution helps you localize your SPFx solution, so you do not have to worry about missing translations.

What is PointFire Localizer?

PointFire Localizer is a GitHub Action that helps you translate your localization files for your SPFx solutions. The Azure AI Translator is used to translate your localization files to the desired languages.

The GitHub Action adds the missing translations to your localization files so you can be sure that all key/value pairs are included in all languages. When a human has already translated a key, it will not be overwritten by machine translation. The GitHub Action favors human translations.

Our GitHub Action is designed to be easily integrated into your existing build pipeline. Thus, you can automatically translate your localization files when you build your SPFx solution.

How to use PointFire Localizer?

As our builds are already running on GitHub Actions, we created a GitHub Action that can be used in your workflows. This way, you can easily integrate the localization process into your existing build pipeline, and you are sure that on release, all localization files will include all key/value pairs for all languages.

Here you can see an example of a GitHub Actions workflow for packaging a SharePoint Framework solution:

```yaml

name: Build

on:

push:

branches:

- dev

- main

workflow_dispatch:

jobs:

build:

runs-on: ubuntu-latest

steps:

- uses: actions/checkout@v4

- uses: actions/setup-node@v4

with:

node-version: 18

cache: 'npm'

- name: Install dependencies

run: npm ci

- name: Package solution

run: gulp bundle --ship && gulp package-solution --ship

- name: Upload sppkg

uses: actions/upload-artifact@v4

with:

name: spfx-solution

path: ./**/sharepoint/solution/*.sppkg

```

Add the Azure AI Translator API key to your GitHub repository

The prerequisite for using PointFire Localizer is that you have an Azure AI Translator service. You can create a new service in the Azure Portal. Once you have created the service, either the free or the paid tier, you can get the API key from the Azure Portal. You can find more information in the get your authentication keys and endpoint article.

You can make use of the free tier from Azure AI Translator.

Follow the next steps to add your Azure AI Translator API key to your GitHub repository:

Go to your GitHub repository
Go to the `Settings` tab
Go to the `Secrets and variables` section and click on `Actions`
Click on the `New repository secret` button
Add a new secret with the name `TRANSLATOR_API_KEY` and the value of your Azure AI Translator API key

Once you have added the Azure AI Translator API key to your GitHub repository, you can add the PointFire Localizer GitHub Action to your workflow.

There are two ways how you can use PointFire Localizer in your workflow:

1. By a predefined list of locales

2. By automatically detecting the locales

Using a predefined list of locales

If you want to use a predefined list of locales, you can add the following step to your workflow file right after the `install dependencies` step:

```yaml

- name: PointFire Localizer

uses: IceFireStudios/pointfire-localizer-action@v1.0.0

with:

api-key: ${{ secrets.TRANSLATOR_API_KEY }}

api-region: "westeurope"

default-locale: "en-us"

locales: "nl-nl,fr-fr,de-de"

summary: true

```

In this example, we use the predefined list of locales `nl-nl,fr-fr,de-de` and the default locale `en-us`.

The GitHub Action will do the following:

· It will first look for all the `en-us.js` files in the SPFx solution

· It will then translate all the missing or empty key/value pairs to the locales `nl-nl`, `fr-fr`, and `de-de`

o If a localization file does not exist, it will create a new one

o If a localization file already exists, it will add the missing key/value pairs

The advantage of this approach is that those localization files can be created during the build process, so you do not have to make them manually if there are no human translations available.

Automatically detecting the locales

If you want to detect the locales automatically, you can add the following step to your workflow file right after the `install dependencies` step:

```yaml

- name: PointFire Localizer

uses: IceFireStudios/pointfire-localizer-action@v1.0.0

with:

api-key: ${{ secrets.TRANSLATOR_API_KEY }}

api-region: "westeurope"

default-locale: "en-us"

summary: true

```

In this example, we are using the default locale `en-us`. As we did not specify any locales, the GitHub Action will automatically detect them based on the existing localization files.

The GitHub Action will do the following:

· It will first look for all the `en-us.js` files in the SPFx solution

· It will retrieve the linked locales per the default locale

· It will then translate all the missing or empty key/value pairs to the linked locales

In this case, the GitHub Action will only translate the existing locale files in the SPFx solution.

Trick to Uncripple Teams Private Channel Sites

Thu, 27 Apr 2023 13:20:08 -0400

Here is a trick that I never realized was not common knowledge. When you create a private channel in Teams, its SharePoint site can’t add certain apps, both custom apps and standard ones, including Calendar and Tasks.

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

Now for the longer explanation. When you try to add an app to this type of site, you find very few options in Modern view.

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

For some apps “From your organization”, particularly the ones using the Add-in model in my case, there are some “You can’t add this app here” messages.

Usually “Find out why” is not that helpful, but for one such app, it gives an actual reason

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.

Script Files That Download Rather Than Executing

Thu, 12 Nov 2020 01:11:00 -0500

It started with an intermittent problem from a client. In some cases their users were being prompted to download a JavaScript file that had our product's name somewhere in the file name.

That file was a localization file that SPFx uses. When you create an SPFx webpart or application customizer, there is a "loc" folder in which you put files that contain the character strings that vary according to language. You can find more details about SPFx localization here. Each file in that folder will have a name corresponding to the locale, for example "en-us.js" and "fr-fr.js". These files will then be packaged under a longer name, consisting of

(the name in the project)_en-us_(some long hex string).js

It turns out that this file was the one that was sometimes downloaded. Looking more deeply at why it was being downloaded sometimes when other JavaScript files weren't, it turns out that there was a difference in the http headers that were being sent.

The major difference between the .js file that was sometimes being downloaded and the ones that weren't was that the ones being downloaded had a "content-disposition" header and the the others didn't. In theory, a content-disposition of "attachment" with a file name means that this file should be downloaded, not sent to whatever is responsible for the MIME type represented in the Content-Type header. In practice, browsers know that web servers often get the http headers wrong, so they look for other evidence of the intent. Most of the time they look at the content-type and only download the file if its value is "application/octet-stream". They apparently also look at the context in which is it being called.

In the case of the client, the download usually came when the user had just logged out and logged back in again. Their authentication was not the usual one, so it involved some redirection to and from their on premise identity management. If the caching of this JavaScript file had expired but other files were in the cache, it could very well be the first file being fetched from the SharePoint Online domain, so no context is available for the browser to take into account. In that case, it seemed, it respected the incorrect Content-Disposition header. Also, they were not using and did not want to use any CDN to serve these files, unlike most of our other clients with a similar architecture. Files served by a CDN tend to have the correct http headers.

That behaviour is easily reproduced, by going directly to the appropriate folder of the App Catalog's ClientSideAssets library and clicking on the file name. That file prompted the user to download it, while other .js files in the same folder did not.

I won't bore you with everything that we tried to figure this out. As some point we were convinced that this happened to with application customizers but did not happen to webparts. As it turns out, the problem was with our naming convention. using the words "modern application customizer" in the name rather than "modern webpart" made a difference.

The difference was the name of the JavaScript file, specifically the length of the name. The file name was already pretty long, but the difference between the words "webpart" and "application customizer" took it over some magic threshold. Our naming convention sabotaged the attempt to reproduce the problem with a "hello, world" test. If looks like a file with a name of 81 characters has the correct http header, but one of 87 has the wrong one. I'm still not sure what is the exact limit, and whether it is a limit on the file name or the path or the full URL. None of those lengths seem close to some magic number, but it doesn't matter since shortening the part of the file name that we are responsible for fixes the problem.

How to make SharePoint API calls language-independent

Sun, 20 Sep 2020 04:09:00 -0400

SharePoint's API has gone through several iterations, from the 2010 API, to the 2013 API, and now Graph API. Throughout, it has struggled with being language-independent, particularly when dealing with lists and libraries. Everything works fine when the site is in English and the user's language is English, but many things don't work like the examples when the API encounters a different language. If you are writing software, or even a Power Automate flow that uses the API, you need to be conscious of the fact that that the API may stop working if the user is using a different language, or the site was created in a different language.

Let's use a simple problem to illustrate. Suppose you want to know whether a user is a site administrator. That information is kept in a handy hidden list on the site, called (in English) the User Information List. Let's retrieve that information using the SharePoint 2010 API, the one that starts with "_vti_bin/ListData.svc/". The REST API call would be:

{Site URL}_vti_bin/ListData.svc/UserInformationList(4)/IsSiteAdmin

Here, I am using a "4" to indicate a specific user's ID on this site. This query returns a single line of xml with (in my case) the value "true". Simple, right?

Unfortunately, that only works if the user's current UI language is English. If it's French, that API call fails. Instead you have to use this call

_vti_bin/ListData.svc/ListeDInformationsUtilisateur(4)/EstLAdministrateurDuSite

This is because the list name and the column name used by the list webservice are localized by the MUI

In Dutch, it's

_vti_bin/ListData.svc/LijstMetGebruikersgegevens(4)/IsBeheerderVanDeSite

In Hindi,

_vti_bin/ListData.svc/उपयोगकर्ताजानकारीसूची(4)/साइटव्यवस्थापनहै

Don't forget to URLencode those Hindi Devanagari characters!

_vti_bin/ListData.svc/%E0%A4%89%E0%A4%AA%E0%A4%AF%E0%A5%8B%E0%A4%97%E0%A4%95%E0%A4%B0

%E0%A5%8D%E0%A4%A4%E0%A4%BE%E0%A4%9C%E0%A4%BE%E0%A4%A8%E0%A4%95%E0%A4%BE%E0%A4%B0

%E0%A5%80%E0%A4%B8%E0%A5%82%E0%A4%9A%E0%A5%80(4)/%E0%A4%B8%E0%A4%BE%E0%A4%87%E0%A4%9F

%E0%A4%B5%E0%A5%8D%E0%A4%AF%E0%A4%B5%E0%A4%B8%E0%A5%8D%E0%A4%A5%E0%A4%BE%E0%A4%AA

%E0%A4%A8%E0%A4%B9%E0%A5%88

(line breaks added for formatting)

All of that means that your code has to be ready with 50 different versions of that API call depending on the language of the end user.

It's a little better when you are using the 2013 API. You still have to give it the list's title, but it's the list's internal name, not the display title for the current language. To get the list, the 2013 API call is

/_api/web/lists/getbytitle('')

Better, right? Unfortunately, the internal name of this and many other standard lists and libraries still depends on the language in which the site has been created. When you create a new site, whether classic or modern, the site has a base language. So if the site was created in English, you can get the information with this call

_api/web/lists/getByTitle('User Information List')/items(4)/IsSiteAdmin

That call will work no matter what the user's current language is. But getByTitle() is still not language-independent. Using getByTitle is always a bad idea unless you know that no one is creating sites in other languages, but there aren't a lot of other options. If your site was created in Hindi, the call has to be

_api/web/lists/getByTitle('%E0%A4%89%E0%A4%AA%E0%A4%AF%E0%A5%8B%E0%A4%97%E0%A4%95

%E0%A4%B0%E0%A5%8D%E0%A4%A4%E0%A4%BE%20%E0%A4%9C%E0%A4%BE%E0%A4%A8%E0%A4%95%E0%A4%BE

%E0%A4%B0%E0%A5%80%20%E0%A4%B8%E0%A5%82%E0%A4%9A%E0%A5%80')/items(4)/IsSiteAdmin

(line breaks added for formatting)

It's only a little better than the 2010 API. The API call depends on the site, not the user, and the "IsSiteAdmin" column is not localized. Why the internal name of a hidden list, something that only programmers will ever see, is localized is anybody's guess. So compared to the 2010 API, you're not much better off. You still need to have 50 different versions of the API call, even though it's based on the site language and not the user language.

How do you make the API call independent of language? One way is to find the list using another characteristic that is not language-dependent. One such characteristic is the EntityTypeName, essentially the template for the list or library. There will only be one User Information List per site, and its Entity Type is "UserInfo". There could be several pages libraries, but there typically is only one, similarly for Site Assets and so forth. So the trick it to find the list using an OData filter like

/_api/web/lists?$filter=EntityTypeName%20eq%20%27UserInfo%27

and use the result to retrieve the list Id, which is a GUID, and then use that GUID to retrieve the information from the list, for example

_api/web/lists('0040809f-5e97-4920-9068-0b36e2aa4b16')/items(4)/IsSiteAdmin

That's two API calls rather than just one, which is unfortunate if you're trying to cut down on queries, but at least you don't have to code 50 different possibilities.

For this specific list, the User Information List, there is also a second solution. It's based on the fact that this particular list also has a fixed URL that does not include the list name, at "_catalogs/users/detail.aspx". We use this trick to retrieve the list by URL, using the less well known GetList method. On my ”/sites/Hi” Hindi site, the API call could be

_api/web/GetList(@listUrl)/?@listUrl=%27%2Fsites%2FHi%2F_catalogs%2Fusers%2Fdetail.aspx%27&FilterField1=ID&FilterValue1=4

Neither of those tricks is completely general for all lists and libraries, but I haven't found one that applies in every case.

How about the Graph API? The Graph API suffers from the same problems as the 2013 API, but does not support the same solutions to those problems. So for instance after you retrieve the Site ID, you can use it to retrieve the list by name in the same way as for the 2013 API. If the site is in English, it would be

https://graph.microsoft.com/v1.0/sites/{Site ID}/lists('User Information List')

If it’s in Hindi, you would have to use

https://graph.microsoft.com/v1.0/sites/{Site ID}/lists('उपयोगकर्ता जानकारी सूची')

or you can use

lists?$filter=displayName eq 'उपयोगकर्ता जानकारी सूची'

I have not yet succeeded in getting it to filter by EntityTypeName (Graph API calls it “list/template”) or by URL, or even to find the isSiteAdmin property. I have only succeeded in collecting an impressive set of OData filter expressions that aren't supported, so I'm afraid I don't yet have a good solution for the Graph API. Maybe someone more clever than me will find one.

SharePoint 2019 Machine Translation Service is back!

Thu, 13 Aug 2020 03:08:00 -0400

When SharePoint 2019 was first released, its Machine Translation Service did not work. The service could be installed and was running, but most attempts to use of it would result in the error message "The service application required to complete this request is unavailable. Try this operation again later. If the problem persists, contact your administrator."

The ULS log would have a message of "Unimplemented method" with a stack trace in Microsoft.Office.Web.Conversion.Framework.

Microsoft has now resolved that error! If you install the July 2020 or later Cumulative Update for SharePoint 2019 then the service is working again.

The Machine Translation Service is used by two optional features of PointFire 2019: the machine translation of user interface elements and the translation of classic pages and documents in SharePoint libraries.

These functions now work as expected. The next release of PointFire 2019 will have some performance improvements that were delayed because of the difficulty in testing improvements to a feature that very few could use.

Because of the ongoing problem, all users of PointFire 2019 have been able to get free annual licenses for PointFire Translator, which can translate documents, pages, lists, and UI elements in SharePoint 2019 with higher quality than the free Machine Translation Service (although check out this secret setting). PointFire Translator can also translate modern pages Excel, PowerPoint, and PDFs, which the Machine Translation Service cannot do, and covers more languages. This free license program will soon end. If your free PointFire Translator license is expiring, contact us about transitioning to the Machine Translation Service or renewing the license.

SharePoint Multilingual Page Publishing Feature in Detail

Tue, 17 Mar 2020 08:03:00 -0400

The new multilingual page publishing feature for Modern sites is now available in Targeted Release. This is a good time to go through its main features in a bit more detail.

This SharePoint Online feature enables the publishing and consumption of pages and news in multiple languages in a modern SharePoint communication site. Multi-lingual page publishing means that on modern communication sites, site owners can determine in what languages they want to translate individual pages and news posts. This is different from Variations in that the translated pages are on the same multilingual site, but similar in that it copies pages and you have to translate them to the other language.

Turning it on

This feature must be turned on before it has any effect. The activation is not, as you might think, in the site features section, but in Language settings.

Language settings was there before, this is where you used to set the Alternate languages for a site. You can still do that more or less like before if you don't turn the feature on, by clicking on "Show advanced settings"

The new option is called "Enable pages and news to be translated into multiple languages"

The switch to turn on that feature appears on Communication sites, either new ones or existing ones. It does not appear on Classic sites and it does not even appear on Modern Team sites.

If you click on "Show advanced settings" without enabling the feature, you can pick the list of alternate languages like before, and like before they are all turned on by default.

Parenthesis, what is Overwrite translations at the bottom? It’s the same as before, with a different wording. It has to do with what happens when you change MUI-enabled text in the site default language when it has has already been translated, will it leave the translations alone, or will it overwrite them with the new text in the original language as an indication that they need to be re-translated.

The second that you turn on the feature, even if you immediately turn it off again, all the site alternate languages are unselected. You have to turn them on again one by one, using a different interface if the feature is activated.

The list of languages is the same as it was before with one exception, Serbian (Latin) has been dropped.

To select alternate languages, you can type a few letters of the language name or select it from the dropdown list.

Selecting a language has two effects: it adds it to the list of alternate languages which determines the languages supported by the multilingual user interface (MUI), and it adds it to the list of languages to which site pages can be translated.

For each language you can select one or more "translator". These are accounts that are notified by email whenever a page on this site should be translated to that language. Naming someone as the translator does not give them rights to edit the pages, it simply sends them the email that contains a link to the page. It is possible to send the email to external users, and it is possible to send it to people with no access to the list or to the site. Sending it to a group works as well.

However if you type an email that’s not in AAD, then it gives a message when you save “Can’t save setting now. Try again later”. Always remember to hit save.

Adding pages

Since this is a Communication site, pages in the site default language can be added to the Site Pages library like before using Add a Page or by creating a News post. Jumping ahead, creating a page, even with a different language selected, or using a language-specific News web part will always create pages that are assumed to be in the site default language and are in the root directory of the Site Pages library.

"Translate" pages

You notice in the page menu bar that there is a "translation" button. This will open a translation pane on the right.

As it clearly explains, this does not actually translate (unless you have PointFire Translator), it creates a nearly exact copy of the page either in all languages or in one language at a time. You can do this with a draft or a published version, but keep in mind who can and cannot see drafts. If you do not create them all at once, you can create the others individually or for all remaining languages at once.

All created pages are drafts initially. It is then possible to get to that page in at least four ways.

1) Follow the "view" link

2) Follow the email link in the email that is sent to translators when the page is created

3) follow the little "Available languages" page navigation dropdown in the top right corner

Notice how this page navigation reminds you which page is published and which is a draft.

4) Navigating to the folder

When a translation page is created, it is put in a language-specific folder, with the same file name. These folders use the PointFire naming convention, a two-letter code for languages where SharePoint supports only one variant, and language-dash-country or language-dash-script where there are more variants.

When you first visit the language-specific copy, you will notice that the title is changed to “Translate into {Language name}: {Original title}”. You will also notice a message at the top, "This page has not been translated into {Language name} yet. Edit to start translation".

This message remains until the page has been Saved once, even if you went in edit mode and changed nothing and it autosaved. You (or someone else) are responsible for translating the content of the page, its title and the title and content of every webpart. Remind translators to delete, not translate, the “Translate into {Language name}: ” part of the title.

User Language and Issue with Right-to-Left languages

Depending on the user's SharePoint language, there is a possibility of the user being redirected to the version of the same page in the user's language. This redirection is not persistent, it is easy to navigate to pages in other languages without changing your own language.

When you go to a page in a right-to-left language while your current language is one that has left-to-right layout, you will see it with a left-to-right layout while editing. The letters are RTL but the layout is LTR.

If your current language is a right-to-left one, then you will see a right-to-left layout. The layout depends on the user’s language, not the language of the page or of the site. For those interested in the technical details, the "lang" and "dir" properties of the page's html element follow the user language settings.

Language of the user interface

This may be a good time to point out that while the feature will let you translate and navigate to pages in other languages, what you will see is only the page content in that language, the entire user interface will not switch to that language. That's why in the first Arabic picture above you see the UI in one language and the content in the other language. In the second Arabic picture, the content language and the UI language match, because the user's language setting matches the page language. Changing your own SharePoint language is no easy feat.

Does this feature translate the UI? No. There are a number of UI elements that support MUI, and out-of-the-box elements are mostly populated with localized elements, but any customization that you do, for example to the navigation, will not be translated unless you translate it manually. Here is how to localize your SharePoint navigation, but the same technique should be used for all localizable UI elements, including title/description of sites, lists, columns, content types, and views.

Can you translate custom SPFx web parts? Almost never. Whoever developed the webpart might have given you the ability to change certain strings on the page, but developers should probably also follow the guidance to localize the webpart. This localization will follow the user's language, not the page or site language.

Deleting pages

What if you make a change to the original page? Can you re-copy it to the translations? No (again, unless you have PointFire Translator). However now is a good time for human translators to discover the new SharePoint page version comparison feature to highlight what has changed and determine what need to be re-translated.

It won’t re-copy unless you delete the translated copy. The feature adapts well to deleting the translated copy. The “Available languages” menu adapts, as does the translation pane.

If you delete the original, the copies stay. However they feel some distress. If you click on the “Available languages” menu while on one of the orphaned copies, it spins and never returns.

f you turn off the feature, all the pages stay, but most of the language functionality is removed. The functionality returns if the feature is turned back on again.

News Webpart language filtering

One cool automatic feature I'm still trying to find the limits of is the filtering of News and Highlighted Content webparts by language. If you have a News webpart on a default language page, it will only show published news items that are in the default language. However if that same webpart is on a translated language page, the webpart only shows published news items that are in that language. The filtering is automatic, there are no explicit filter conditions that are added or can be modified. If you turn off the feature, then the filtering stops. Does it work with Hub news or on the SharePoint home page? Stay tuned, not certain yet.

How PointFire Translator completes the functionality

For more details see the blog post about machine translation for multilingual page publishing. Here is a video that shows how this automatic machine translation works.

Essentially, the machine translation process can be completely automated. When you view the new page for the first time, what you will see is not a copy of the original page for you to manually translate, but a translated page for you to approve and publish. This saves huge amounts of time and money.

It's official, Variations are a deprecated feature

Tue, 24 Jul 2018 18:07:00 -0400

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

Do Hub sites support MUI?

Wed, 28 Mar 2018 01:03:00 -0400

Spoiler: they do in part, but very very slowly.

SharePoint Online Targeted Release tenants are starting to get the new Hub Sites that were promised last September.

Hub sites are a way to organize different sites together, without a site hierarchy. Hub sites are just ordinary sites, typically communication sites, that are designated as hubs. You can read about search, rollup and inherited theme elements elsewhere. For the purpose of MUI, what is important is that Hubs have an extra navigation menu, and this navigation menu is inherited by all the sites that are associated with the hub.

Sites that are associated with the Hub, let's call them Spokes, will get this extra navigation menu, but do not have the ability to edit this menu, only the Hub site can edit it.

The Hub navigation menu consists of two parts: the Hub site display name and the navigation links.

The hub site display name defaults to the name of the hub site, but it can be changed by going to the Hub site settings in the gear menu. Now the bad news: the display name does not support MUI. It is invariant.

The navigation links can be edited on the Hub site by clicking on "Edit"

This is a multilevel menu, and is similar to other navigation menus on modern sites. And like other navigation menus, this one is MUI enabled. You can change your language and change the text of the the navigation menu in that language.

However this menu is more aggressively cached than other menus. If you change your language preference, it can be quite a while before you see the correct language version of the hub navigation menu appear on the Hub site itself, and don't expect to see it appear on Spoke sites until the next day.

In fact, in the course of testing this, it fails to load the correct language version of the menu more often than not, even on the next day. I will update this post if I figure out the pattern when it succeeds and when it fails.

PointFire 365 v2.0 is released

Wed, 08 Nov 2017 11:11:00 -0500

Nearly 3 years ago, we put together a roadmap for what we wanted to see in a SharePoint Online version of PointFire. Today, we deliver the last of the features on that original roadmap.

At the time of the original roadmap, several of the features were technically impossible. Today, some of the features are still impossible, but we implemented them anyway. The software changes the time zone over and over until it time travels to when Microsoft supports these functions.

As SharePoint Online expanded its programmability, more and more became possible, and after a few false starts and several months of beta testing, version 1.0 came out over a year ago. It was only the major features and some were slow or limited, but it found several takers. Versions 1.1 and 1.2 covered more and more ground.

Version 2.0 has several major new features. One of them is the instant language toggle. This is one of the impossible features. It is not possible to change your language quickly, it should take a few minutes for the language change to take effect. But PointFire has a little spinner animation that implants a hypnotic suggestion that the language has already changed. It won't work if you don't stare at the spinner animation but no one can help it.

Another feature is a rich set of PowerShell scripts to provision and manage PointFire features. PointFire is an enterprise solution, and entreprise solutions need this.

The big new feature is translation of the user interface. It's as simple as 1, 2, 3.

1) Scour the site for translatable text elements and puts them into the Multilingual Translations list

2) Machine translate the text to all the site's languages. In addition to machine translation it also looks up built-in translations and translations coming from the top level site's translations list. You can check the translations list before and after the machine translation.

3) Apply those translations to the interface

UI translation covers the following elements

Site names and descriptions
List/Library/Calendar names and descriptions
View names
Column names and descriptions
Content type names and descriptions
Most types of navigation
Custom Actions
Selected webpart names

All this in addition to the existing features, webpart visibility by language, filtering of lists, libraries, and calendars by language, language filtering of content search webparts, and machine translation for documents, list items, pages, and events, including translation of all text, richtext, and html metadata.

Coming up in the next few weeks: PowerShell scriptable machine translation. This uses the new neural translation engine, which is much better than the previous machine translation engines, and in addition to text, html pages, and Word documents, it handles PDF, Excel, and PowerPoint.

Also in the pipeline, version 2.1 is coming in a few weeks will have support for modern lists, libraries, and pages, including the new Communication sites. Stay tuned!