User Profile
MartinLaplante
Iron Contributor
Joined Aug 19, 2017
User Widgets
Recent Discussions
Re: Different languages in different sites
As my friend Dave Mehr says, the most foolproof way to ensure that everyone sees the site in one language is to deactivate the other languages of the site. If you want a less foolproof way to do it just for yourself, but more reliable than changing your account language, you can change your profile language, which is different from the account language. This used to be done in Delve, but this is the more current procedure. This changes the user interface language. If the site is using the multilingual page publishing feature and it is the language of the content, not the language of the interface, that is in the wrong language, it is because you once used the small content language toggle, and it remembers on that site for a while. It forgets it when you close all the browser windows and reopen, or if you toggle it back again.Re: Language defaults audit for everything M365
I did a video about how to change the major SharePoint language settings a year ago. If it's not one of those, you can message me I could try to help diagnose the issue. For Teams meetings, it's a bit more complicated. The notification depends on the language of the M365 group, which depends on the settings of the user who created it. You can override that with Set-CsTeamsMeetingPolicy -Identity "Global" -MeetingInviteLanguages "sv-SE"Re: Event Listeners Not Working After Translating SharePoint Page with SPFx Extension
Hi Varsha, I'm sorry to rain on your parade, but when our company first developed our PointFire page translation app, we found that this approach causes this problem and several others. Some issues are specific to some languages, and some will affect one page and not a seemingly identical page. Fundamentally, changing the DOM on a page as it is being rendered is a dangerous technique which should be avoided. SharePoint has a lot of html that translation engines don't like and that will break SharePoint if you change it.Re: Change of notification language
I recognize that notification format you are using. It's the "Automate" rule, and its language setting was done incorrectly by Microsoft. Long story short, it uses the "Locale" in the regional setting of the site, not the "Language" in the language settings, and it ignores the setting that tells it to let the user's locale override the site's locale. That is going against the definition of what regional settings and locales mean in all other Microsoft products, where the regional settings only affect only the formatting of dates and numbers, and language is determined by, you guessed it, the language settings. You set that by going to regional settings in Site settings and selecting a locale for the site.Re: Change of notification language
For list notifications that come from the "Alert me" button dialog, the notification will be in the base language of the site, whatever the language of the user who requested it. There was a time when the notification was in the language of the user at the time, but now only the list name in the notification is in the user's language. However, your notification looks different from the one I get with the "Alert me" button dialog. How did you set up this notification?Re: Default proofing language
OK, different problem. I don't know the right way of doing this, but I'll tell you how I do it. In library settings under Advanced settings, find "Document template" You can edit the template online, but I tend to edit the template.dotx file on my workstation, change the default proofing language and upload it to the right place on the site.Re: SharePoint Regional and Language settings for all sites.
There are several things here, but first the bad news: there is no way to change the site language setting after the site has been created, and en-gb is not a supported language. You can choose that setting, but you'll still get en-US. On to better news. The site's base language and the site region setting are only defaults, they are used when the user doesn't have a setting. The user's language setting is in their M365 profile. If that is not set it will use the browser language. Provided that the site supports the users language setting, and most sites have at least basic support for all 50 languages unless you remove them, the user will see the site's UI in that language. Region settings are a bit different. Region only affects date and numeric format. En(GB and en-US differ only in date format. Again, the user profile can override the site default setting, but only if you check the override setting. What can you do as an admin? If you don't want anyone to see the site UI in any language other than English (en-US) then you can delete all the other languages in the site's language settings in the advanced settings. If you want users to have a choice, then you can provide their initial settings in their profile using AAD, which syncs with their profile.Re: Default proofing language
I wrote about this when it first came out. https://blog.icefire.ca/blogs/post/multilingual-proofing-of-sharepoint-pages There is nothing the site admin can do. Users can change their preferred languages (more: language not region or locale) in their M365 profile, that doesn't always work for me. Changing their browser language preferences works, as does installing the full Microsoft Editor browser extension, which is very configurable.Re: Trying (and failing) to change language settings
aforsher SharePoint has a lot of different language settings, and lots for different caching mechanisms for UI elements that are not good at realizing that your language are changed. Some caching mechanisms are in the browser in local or session storage, some in IndexedDB, even some on the server and for lists and now libraries it's an actual tSQL table on your hard drive. What exactly is not changing language? I can tell you where it's cached and which language parameter controls it. For the multitude of language settings in SharePoint alone, I recorded a couple of video, this one for the most impactful language change in your SharePoint profile and this one for other SharePoint language parameters.Re: File sharing email language
slvedva In my experience, the message is sent in the current UI language of the user who shares at the time that they are sharing. This is determined by the Display language setting in the user's profile, as long as it is one of the alternate languages of the site or the base language, or if no display language is selected in the browser language. The UI language is not based on their country, it is based on either their profile or their browser display language settings and the site alternate languages.Re: Multilingual Hub Menu is not translating
Hi Sabine_DB I have never figured out why most times the changes in Account settings for display language are synchronized to Profile language settings, and sometimes not. If you tinker too much with both, at some point it stops synchronizing until the next day. The account setting for preferred display language is single-valued, while the profile setting is a ranked list. Changes sync from the account to the profile but not the other way around. From the profile, it syncs to every site, slowly but reliably. Changes made at the site level do not sync upwards to the profile. For Hub navigation there are several levels of caching. The one that is covered by the API is here https://learn.microsoft.com/en-us/sharepoint/dev/features/hub-site/rest-hubsitedata-method Note the forceRefresh parameter. Yes, it's a server parameter change in a read request. But that is only part of the story. This API is for the server cache, not the browser cache. The browser cache is not covered by API, and its mechanism changes now and then. Our product development team spends its time tracking those changes and making the cache update.
