Unable to set Language on WPF WebView2 when using PRISM

[ijardillier]

Hello,

We use WebView2 in one of our WPF project. In this project, we use PRISM to manage navigation, view caching, events...
We also have an event triggered when a user change his current language.

But when this event is fired, I try to implement the change of the Language on the WebView2 but it isn't applied (the property Language of the component iw updated but event after a refresh on the component, webpage stay on the previous language. I have to restart my application in order to use the correct language.

With others WPF components, event if they are cached with PRISM mechanism, if we change the Language property, it is applied on the fly.

Is there a way to update immediatly the Language in my case ?

Thanks for you reply.
Ingrid

AB#34784444

[champnic]

Hey Ingrid - What is the behavior you are hoping to achieve by setting Language property on WebView2? Currently I don't think we are handling the WPF FrameworkElement.Language property in the WebView2 control, but we do have an option in CoreWebView2EnvironmentOptions.Language. However that requires creating a new environment, and creating a new WebView2 control using that language. I don't there's currently a way to do this on the fly.

[ijardillier]

Hello @champnic

For example, I display the bing.com url on my WebView2 control which was initialized with the fr-FR language (as you said, by creating CoreWebView2EnvironmentOptions with Language property to "fr-FR". Bing displays all text in french. OK.

The user change its current language (feature available on our product) and swith to English. I am able to get this event (culture changed), but event if I recreate the CoreWebView2EnvironmentOptions with the new culture (en-US), and if I call the Reload() method available on WebView2, the Bing page is still in french.

Thanks.

[champnic]

Instead of reload, you need to close the current WebView2, create a new environment using those environment options CoreWebView2Environment.CreateAsync(..., ..., options); and then create a new WebView2 using that new environment WebView2.EnsureCoreWebView2Async(env);. Can you give that a try?

[DevReportOne]

Hello, I probably have the same issue.
In the code, at each startup of the application, I create a new instance of CoreWebView2Environment & CoreWebView2EnvironmentOptions as suggested by @champnic.

On a fresh execution, I set the language to FR in the code, I open the WebView, I press F12 and I type in the console "navigator.language", I have "fr", it's normal. I close the debug.
Now I set the language to EN in the code, I reproduce the same scenario as before and in the console, it still shows me "fr" in the navigator console.

I have the latest version of WebView2.
See applications : WpfApp1.zip

Any idea?

[champnic]

That's interesting. I have "en-us" by default on my machine. When I set Language to "fr-fr" I see french UI in the DevTools, but indeed the navigator.language is still "en-us". I wonder if the runtime is automatically picking up my Windows settings. I'm going to open this as a bug on our backlog to take a closer look - thanks!

[mpPrevas]

I have noticed this as well.
In our application we create C++ MFC dialogs with WebView2 in them and then close them when entering/leaving a view. The user have the option to change the language of the application during runtime andoptions->put_Language(... is used to set the new language next time a dialog is created.. This will change the menu language in WebView2 correctly, but the web page language (Accept-Language header) is only affected the first time the language is set and remains like that.
#833 (comment) seems to see the same behavior.

[ShaunLoganOracle]

I am also encountering the same issue using
WV2 SDK 1.0.902.49 and WV2 RT 99.0.1150.46 with a WPF window on Win 10 (in an Excel add-in).

[pwsimon]

i found that the language specified with the very first creation of the environment is accepted.
with further environments using the same UDF (User Data Folder) the language specified will be ignored.
the setting from the UDF will take effect.

clear your UDF and with the next environment your setting will take effect.
i guess that, if you patch the language-setting within your UDF you can change single settings without clear the entire set.
The thing with such an approach is: there is no documentation about the structur/content/... of the UDF

[AlexDavisOracle]

@champnic I see this issue has been tracked as a bug for about a year now. Can you set our expectations regarding when we might see a fix? Our product runs in many cultures. So, getting the language right is important to our customers. Please let us know. Thanks!

[champnic]

This bug in particular is low priority on our backlog, so probably no fix for a while. Just want to make sure you are aware of the language options currently available though (also described earlier in this thread):
https://docs.microsoft.com/en-us/dotnet/api/microsoft.web.webview2.core.corewebview2environmentoptions.language?view=webview2-dotnet-1.0.1264.42

[AlexDavisOracle]

Thanks for the quick reply, @champnic ! My understanding of this issue is that setting CoreWebView2EnvironmentOptions.Language does not affect the Accept-Language header sent by WebView2. Have I misunderstood?

[champnic]

It will affect the Accept-Language as well. Though there does seem to be an issue if you are changing the language after the User Data Folder has already been created. @pwsimon mentions that there may be a way to selectively clear that information from the UDF. Or you can probably handle the WebResourceRequested event and change the request headers as a workaround in the meantime.

[ShaunLoganOracle]

We confirmed that we're running into the issue:

if you are changing the language after the User Data Folder has already been created

If we start with an empty/missing UDF, we see Accept-Language on the first request made by msedgewebview2 get sent as we expect (reflects the value set into CoreWebView2EnvironmentOptions.Language). But with any subsequent re-use of that UDF are stuck with that first value and initializing a new WebView2 instance with a different CoreWebView2EnvironmentOptions.Language still uses the first language (from the UDF) in Accept-Language - that is - the new CoreWebView2EnvironmentOptions.Language is ignored.

This is the same issue reported by @pwsimon above

[malylemire1]

I use an event to override accept-language header. See #833 (comment)