Learning content in other language

[MBlondin]

PROVISIONING NOTE: If you are having issues with the SharePoint look book while trying to provision M365 learning pathways please do not post that issue to this repo as we cannot help you here. Please post all questions and issues for the SharePoint look book to SharePoint/sp-provisioning-service GitHub Issues List.

WEB PART NOT LOADING: If you are getting the error: "Microsoft 365 learning pathways has a configuration issue. Ask your administrator for assistance". Please review the Diagnosing Pre-Check guidance before submitting your bug.

Describe the bug

We provisionned M365 Learning Pathways but when switching from English (Default) to French, the content is not displayed in French

To Reproduce

Use the language toggle to change between french and english

Expected behavior

The content should be displayed in the requested language regardless of my profile language setting

Screenshots

Learning Pathways version number

4.2.0.0

Additional context

I think that content should not be tied to language in the profile but rather the page language. In Canada,

[jellis-thrive]

Hello @MBlondin

The language displayed in the learning pathways web part will depend on the user's personal language and region settings. For more information about setting up a user profile for language and region, please see the below:

https://support.microsoft.com/en-us/office/change-your-personal-language-and-region-settings-caa1fccc-bcdb-42f3-9e5b-45957647ffd7

If the content that you want to display in French is a Microsoft created article, changing the user profile language should display the content in French. If the content is custom created by you, a page needs to be made in each language you would like it to display in. EG if you create an article in French that would display by default in French, but someone else would use English, you must also create a page for the English language. Your content is not automatically translated.

[MBlondin]

@jellis-thrive I understand your point but here is a use case. As part of the public service in Canada we have an obligation to have content available in both official languages (French and English) called Official Languages act. This obligation dictates that on my page I cannot have 2 languages. In addition, having both languages on one pages is a violation of WCAG 2.1 AA Standards to which we also must follow.

Having said this, if we look at user experience and adoption of a tool, forcing users to leave SharePoint to go to their profile in order to change their display language, which will affect the rest of their M365 experience, in order to get their training content in the language their wish is not good UX practice. When using a language toggle, the entire page (Menu, Site title, Footer, Content) should switch.

[juliemturner]

Although your point is well made @MBlondin this is not a learning pathways problem, this is a SharePoint Framework problem. The MUI for the user experience is provided to the web part by the page itself so there is no good way for us to detect that a user has specifically asked for a page in an alternate language without hacking the value from the browser location, which is doable but not foolproof. So unfortunately, what you're looking for is an enhancement that is outside the scope of this project although it has been communicated to the engineering teams, I have not been informed that it is on their backlog.

[MBlondin]

@juliemturner What if the web part detects the page language. As an alternative to the MUI we use PointFire365. PF365 toggles the entire page and sets the page language to the currently viewed page.

[juliemturner]

Ironically, that's "sort of" what the SharePoint Framework does... although not in the way you mean. What you're saying I believe is that you have a third-party product that does actually set the page's language to the language that matches the language selector. Unfortunately, Multilingual pages does not do this OOB. So yes, this would be a work around for those with that product that injects the page language... and we could enhance the web part to validate the page language on every load... but this is an open-source solution that needs to work for everyone and to that end it needs to work consistently for everyone regardless of what other third-party products they have. What concerns me is that this already extraordinarily complicated MUI setting gets more complicated depending on what third-party products a person has that is manipulating the page language. As such I would rather stick to what SharePoint Framework uses. This is not to say that I won't share the idea, and possibly the enhancement will make it in depending on the direction and feedback of the engineering teams that could just fix this in the OOB product.

In the meantime, if you would like to fork the repo and build a version of the solution that detects that then I think that's a great solution.

[MBlondin]

@juliemturner Maybe in the web part have an if statement to see if MUI is active and if not then look at the HTML attribute to set language. With PF365, MUI is not active as it conflicts.

[juliemturner]

I have no idea what you mean by "MUI is active"... there is always a MUI page context property.

[MBlondin]

@juliemturner Is there not a way with SP Framework to see if Enable pages and news to be translated into multiple languages is on? And if not then look at the page language

[juliemturner]

@MBlondin -- of course, that's not my point... the point is that the pages language will be the exact same value as the page context property unless you have a third-party product that is manipulating the DOM outside of the OOB product, which you have which from a support perspective means the solution will work differently. Supporting multilingual pages is already extremely complex as you can probably see from the number of issues submitted around the topic and I am resistant to change it in this way as many others could have a product like this and not be aware, or would not have one of these products and be confused as why they can't get it to work the way they want it to. This all leads to a support situation where some people are reporting that things work one way for them and another way for someone else without even realizing this very subtle reason why. So, to my original response I will absolutely (and already have) shared this additional example (because you are hardly the first to bring it up) that for third party extensions a fix needs to be made to multilingual pages to support this scenario. If that ends up being a bust the team will discuss providing a work around of some kind and what that might mean.

[MBlondin]

@juliemturner thank you !

[dcashpeterson]

closed as answered