Runtime: Allow Current Cultures behave in UWP as it does in none-UWP

[tarekgh]

While running inside UWP, CultureInfo.CurrentCulture/CurrentUICulture will behave differently than when running outside UWP apps.
In UWP get or set the current culture from/to Windows.ApplicationModel.Resources.Core.ResourceManager.Current.DefaultContext.Languages. This causes the current cultures global to the whole app.
In the none-UWP app, the current cultures are tied to the running thread. Which means setting current culture will affect the current thread and is not global to the whole apps.

The request here is, Allow a way for UWP apps to force the behavior of the none-UWP apps to have the current culture tied to the thread instead to be global to the whole app.

Initial thoughts to support that uses a config switch the app can declare to force this new desired behavior. The other idea is to provide some new API to force this behavior but I think the API would have some serious problems.

[4creators]

This same problem exists for Thread.CurrentThred.CurrentCulture/CurrentUICulture.

[tarekgh]

This same problem exists for Thread.CurrentThred.CurrentCulture/CurrentUICulture.

Yes. Thread.CurrentCulture/CurrentUICulture is just mapping to CultureInfo.CurrentCulture/CurrentUICulture

when we fix CultureInfo current cultures will fix the thread one automatically.

[pedrolamas]

@ViktorHofer may I ask for some context as to why has this just been closed a few moments ago?

Having written in the past about this particular situation and how to mitigate it, I'm quite interested in the reasoning behind this.

[ViktorHofer]

With .NET 5 we will layer UWP differently, i.e. no extra target framework, to avoid diverging api surface areas. There's no concrete plan yet but we hope to make it behave similar to how we support Windows Nano Sever today (runtime checks). Also more win32 apis are now allowed inside an AppContainer so we hope that we won't hit this issue anymore.