turquoiseowl / i18n

Smart internationalization for ASP.NET
Other
556 stars 156 forks source link

Scheme 1 and relative urls with no langtag included #292

Open carodiu opened 7 years ago

carodiu commented 7 years ago

Hello,

I am having this issue: I have some relative links in my application executing javascript code to open new windows. I am working with Scheme1. Those links does not have the language in it. I want the application to get it automatically. When I change the language, and press links with relative urls the application redirects to previous language (not the new one). But when I open dev tools and hit Network setting Disable cache and re run the process everything works perfect.

Can anyone help me. I appreciate it. Thanks

turquoiseowl commented 7 years ago

When I change the language

Do you mean via the browser's language settings?

What type of resource is the URL in question?

Is your issue them same as described here https://github.com/turquoiseowl/i18n/issues/226?

It sounds like the browser is remembering/caching the previous 301 redirect. Can you add a uniquifier search param string to the URLs you're generating?

carodiu commented 7 years ago

Ey! many thanks for your quick response. This is a wonderful project by the way I really love it. Yes via the browsers language setting. The issue is not as #226. I get correctly scripts under selected langtag folder. This is what I have: The link: <a href="javascript:openMore('@(string.Format("/main/offers?type={1}",category.OfferType))')">[[[View more]]] >>>

The openMore function function openMore(offerType) { var nextUrl = location.protocol + "//" + location.host + offerType; window.open(nextUrl, '_self'); }

I tried to debug adding the project. And normally if I dont include the langtag, this url gets patched by i18n component and its redirected correctly. But in this case, it just enters with the previous lang langtag, so I get not correct redirection. A quick fix would be just add the langtag but since I havent add it anywhere I would just prefer to keep it that way.

What do you mean by adding a uniquifier?

Thanks again for your quick response. Very nice.

turquoiseowl commented 7 years ago

Thanks, I'm pleased you like the project.

By uniquifier I mean adding a unique search param to the URL to ensure any browser cache is busted every request. E.g. nextUrl + "?" + Date.now() That's useful for diagnosis at least.

If that doesn't help, it often helps to diagnose at the HTTP level. E.g. what's the HTTP request issued and/or received by the server (in terms of exact URL and headers) that works and what's the request that doesn't, etc..

turquoiseowl commented 7 years ago

Please also note the i18n.LocalizedApplication.Current.PermanentRedirects = true/false; setting which could be relevant here. The default setting of false is what you want I imagine.

carodiu commented 7 years ago

Hello, I have tested changing the PermanentRedirects to false and the behaviour is the same.

Adding the uniquifier makes it work perfect. Would this affect google analytics? I have also checked the http headers and they seem to be the same except for the things that should change as time. In the case I have date in the url the link enters with no language and redirects ok after. In the other case the link enters with the previous language already no redirection needed.

I am getting different values between i18n.HttpContextExtensions.GetInferredLanguage(HttpContext) and i18n.HttpContextExtensions.GetPrincipalAppLanguageForRequest(HttpContext). Shouldnt they both be the same? I have cookie set.

turquoiseowl commented 7 years ago

Hmm, it sounds very much like #226 to me. I.e. when the browser is deciding whether or not it already has the JS resource in its cache, it is NOT looking at the Accept-Language headers (and definitely not at the cookies). Have you tried other browsers?

GetInferredLanguage returns the best assessment of the language being requested, as determined from analysis of the HTTP request. That isn't always what's available, so every request i18n matches against what is available and ends up with the PAL (Principle Application Language) as returned by GetPrincipalAppLanguageForRequest. See https://github.com/turquoiseowl/i18n#principal-application-language.

turquoiseowl commented 7 years ago

Can I close this issue? Thanks.

carodiu commented 7 years ago

Yes thanks