Redirect makes browser forget values about i18n HOT 9 CLOSED

What 'should' happen here is that the URL localizing (that happens in the post-processing of the HTTP response) picks up the unlocalized URL and patches in a localized version.

It seems that that isn't happening. That could be because the URL is relative i.e. doesn't include scheme and host portion, so the regex isn't picking it up. If it is that, can you making the URL absolute? There is a way with Url.Action to do that, but can't remember exactly how, maybe setting scheme does it.

This issue has also come up with generating URLs for things like 'returnUrl' arguments, where these aren't post-processed. The way to explicitly localize a URL is something like this:

            if (returnUrl.IsSet()) {
                returnUrl = LocalizedApplication.Current.UrlLocalizerForApp.SetLangTagInUrlPath(returnUrl, UriKind.RelativeOrAbsolute, lt == null ? null : lt.ToString()).ToString(); }

from i18n.

I tried this now: var url = "@Url.Action("Search", null, null, Request.Url.Scheme)";
which gave me the full path like so: var url = "http://127.0.0.1:82/AdminRoot/Search";

right now it gives me errors, but probably my code. I think that is the fix.
Would there be a problem to make it pick up relative urls?

from i18n.

ahhh i found my error... an old favorite of mine showed it's ugly head.

When I do: @Url.Action("Search", null, null, Request.Url.Scheme) I get with port 82 but the webserver listenes on port 81.
This is the azure emulator.

Same problem I had back in time here: #49

from i18n.

Would there be any way to make this work with relative urls?

Right now i cant enable the project as full urls messes with my azure emulator and relative urls are buggy as per this thread.

from i18n.

I think the relative/absolute URL distinction is a red-herring here, my fault.

The reason the problem exists is because of the way I am parsing for URLs in the response body. The way this is currently done is semi-interpreting the HTML, looking for HTML attributes that are known to store URLs. See this comment:

        // The goal here to localize same-host URLs in the entity body and so save a redirect 
        // on subsequent requests to those URLs by the user-agent (i.e. Early URL Localization
        // of the subsequent request).
        // We patch all URLs in the entity which are:
        //  1. same-host
        //  2. are not already localized
        //  3. are not excluded by custom filtering
        // Examples of attributes containing urls include:
        //   <script src="..."> tags
        //   <img src="..."> tags
        //   <a href="..."> tags
        //   <link href="..."> tags
        // A full list is available here: http://www.w3.org/TR/REC-html40/index/attributes.html

So, any URLs in the response not within a normal HTML attribute, e.g. in JavaScript code, we pass straight through unlocalized. That is why they get to the Early Url Localization part on the subsequent request unlocalized, which is why you're getting the redirect.

As to the solution, point 1. in your opening post makes sense. It is incorrect to do the UrlLocalization redirect on POST requests, given you say that the browser then responds with a subsequent GET request.

The only problem then is, if the POST request may get handled in the incorrect language. For instance:

1. Default application language is "en"
2. Your original request is being handled under explicit language "fr" (got from the URL)
3. You're not using the "i18n.langtag" cookie to set the language, or the cookie is set to something other than "fr"
4. You're browser language setting "accept-language header" is something other than "fr".

In this case, the POST will be handled as "en", not "fr".

Let me know your views. I suggest for now we restrict the Early Url Localization redirect to GET and HEAD methods only, but the incorrect language problem will still exist.

Have you also thought about a helper function for localizing the URL (as shown above) and substitute that for the Url.Action() calls? In that case, you won't loose the current language.

from i18n.

Thank you for quick and good answer.

I think for me it does not make huge amount of sense with making my own Url.Action as what I love about this project is that it works completely without any custom code.

But I think I am missing something here. If i browse to a page say www.mydomain,com then i should immidiately get forwarded to www.mydomain.com/sv/ and so far so good.

when i now have an ajax function call www.mydomain.com/mycontroller/myajaxpostcall
then sure there is no /en/ in that but cant we use cookie or similar?

I am thinking priority maybe should be

1. url
2. cookie (and if url is not set but cookie is, it still only processes request no matter get or post)
3. browser preferenses

because after all with a cookie, the cookie has been actively set by us just like the url, if the user changes the url to change language we simply update the cookie.

But I think no matter what with post i don't think we should ever do any forwarding as post probably comes with data.

from i18n.

See how you get on with the commit just made. Explanatory notes are in the commit message.

from i18n.

@rickardliljeberg can we close this?

from i18n.

Terribly sorry, been so busy I can't believe it!

I have merged the code, but not tested it yet.
Give me two days and then I will get back to you in full :-)

Thanks!

On 1 July 2013 14:33, Martin Connell [email protected] wrote:

@rickardliljeberg https://github.com/rickardliljeberg can we close this?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/73#issuecomment-20278692
.

from i18n.