RickStrahl / Westwind.Globalization

Database driven resource localization for .NET applications
544 stars 135 forks source link

Globalization and Iframes #113

Closed mtugnoli closed 6 years ago

mtugnoli commented 6 years ago

I just testing Westwind.Globalization in my new .net core 2 project in this project when user logon is set Thread.CurrentThread.CurrentCulture and Thread.CurrentThread.CurrentUICulture with user culture (it-IT). but when load an iframe inside this the culture is en-US. so a part of project is globalize in Italian and another part in English. Any Idea ?

RickStrahl commented 6 years ago

The new ASP.NET Core auth system doesn't change the thread's culture but relies entirely on dependency injection to get access to the localizers. If you change the thread culture it'll have no affect on the localization of the string localizers.

If you're loading things into a frame you're loading things on a completely separate request so depending on where the request loaded from the behavior will rely on that location.

mtugnoli commented 6 years ago

the frame is created in javascript, I tried to set also to set the language in a filter public override void OnActionExecuting (ActionExecutingContext filterContext) but did not seem to care for anything. Can I set the language globally?

PS: i've tried also with CultureInfo.DefaultThreadCurrentCulture but nothing :(

RickStrahl commented 6 years ago

Doesn't matter an iFrame is still a separate request. You need to run that request through the same pipeline as the main page to get the same localization functionality. Like I said the StringLocalizer totally ignore thread and default culture settings and get everything they need from DI. You can change the thread culture until you're blue in the face it's not going to change the way the string localizer localizes.

This isn't really an issue with Westwind.Globalization but a general localization issue.