i think that' been the behaiour for as long as i remember, but with a 303 redirect before 3.6.0.

@andrepereiradasilva
yes your latest PR fixed / restored behaviour of language switching

and the redirections are OK but for cases 2 and 3 in the above example, the response code should not be 301 but 303 ?

if so probably the redirect http status should be conditional if using language cookie language code exists. I think it should be 302 BTW.

This would be in https://github.com/joomla/joomla-cms/blob/staging/plugins/system/languagefilter/languagefilter.php#L404-L410

@infograf768 please advice

fyi, if i remember well, before 3.4 we had a 301.
cases 2 and 3 use the cookie for redirection, which will not be done by search engines. i think search engines loading domain/ don't have browser preferences an therefore will always get deault site language in that case.

would this be more correct? https://github.com/andrepereiradasilva/joomla-cms/pull/55/files

Imho, a redirect of 301 is always wrong because the origin URL is still a valid URL. 301 is meant if the origin address is going to be deleted (or is already deleted) and the clients are supposed to update their links and caches with the new URL.
If you need to tell the browser to not cache the result of the redirect 301, then you used the wrong redirect ?
302 (temporary) or 303 (see other) would be appropriate redirects in our case.
Btw: Google does a 302 to the national domain or your country when you visit google.com (eg redirects to google.ch).

@andrepereiradasilva
https://github.com/andrepereiradasilva/joomla-cms/pull/55/files
yes we should be using:

$redirectHttpCode = $lang_code === $this->default_lang ? 301 : 302;

I think fix is straightforward

IMHO, i think it should work like this:

• if we have a redirect from /sefcode* to /* it should be a 301 Redirect
  (we are using remove language code option set to Yes for default language here)

• if we have a redirect from /* to /defautlang-sefcode1* it should be a 301 Redirect
  (not sure of this one)

• if we have a redirect from /* to /notdefautlang-sefcode* it should be a 302 Redirect
  (we are using lang cookies here to redirect)

do you guys agree?

• First one sounds reasonable, but could be 302 as well since with the default SEF code it is still a valid URL. There is no reason that clients/search engines need to update their cache/links. It's just two URLs that point to the same ressource (of course the canonical URL has to be without the SEF code).

• The other two cases are both 302, not 301. There is no permanent redirect here either. The origin URL (/) is still a valid and working URL. And in fact it's the URL that is expected to be used by visitors.

So imho there is no need to add any switching code, just use a 302 or 303 redirect and all will work fine. And obviously don't try to disable caching if you're requesting the browser to use a permanent redirect (301), that makes no sense at all. It's like saying "Hey look this new URL here, please use this one from now on and forget about the old one. Ah wait, don't remember what I just told you."

ok, well first lets go back to try to understand why this was made:

• Before 3.6.0 all language filter redirects with "303 See other"
• #8894 changed all language filter redirect to "301 Permanent Redirect" , i think because of SEO issues
• #11161 solved the "301 Permanent Redirect" browser cache issue on 3.6.0 after several issues reported.

Now ...
i also believe a "302 Found" for the above two and three scenarios is the correct one, as you can see from my comments in the other PRs

but for the first scenario i believe 301 is the correct awnser because of duplicate content that can have SEO effects (i think that's why #8894 as made after all).

With 303 status we have duplicates in serach index, it is more seriouse problem. I see many pepople looking for solution how to fix it and do a lot of hard code fixed inside of core.

reggarding the browser disable caching it was a quick patch to solve the issue in 3.6.0. it's not needed and can be removed in the following scenario:

• if we have a redirect from /sefcode* to /* it should be a "301 Permanent Redirect" (we are using remove language code option set to Yes for default language here)
• any other redirects shown be a "302 Found"

Update i made those changes in the PR in my repo: https://github.com/andrepereiradasilva/joomla-cms/pull/55/files

I all agree i will submit the PR.

@ggppdk @infograf768 @Bakual please confirm that my previous comment is the best way to deal with this redirects in all possible scenarios.

but for the first scenario i believe 301 is the correct awnser because of duplicate content that can have SEO effects

That's the real point. "Duplicate Content" is a non-issue for SEO. At least as long as the content is on the same domain. It's just expected that there are multiple URLs pointing to the same content.
It's a whole other topic when the same content is found on different domains, as that indicates stolen content.

If you really want to "fix" duplicate content, the real fix is to add proper canonical URLs (the one that should be indexed). The 301 is just a bandaid which produces the issues we now have without bringing any benefit.

please confirm that my previous comment is the best way to deal with this redirects in all possible scenarios.

Imho, a 302 or 303 (decide on one) is the proper answer in all cases.

what issues do you have with this? https://github.com/andrepereiradasilva/joomla-cms/pull/55/files

actually you are right there are issues if we use a 301 redirect, because it stays in browser cache so the language cookie doesn't get updated when doing a "/fr" (not default) to "/" in the first scenario.

The way the language filter plugin is constructed we could never use a 301 redirect because of the language cookie change sent with the redirect. The only way the 301 can be used is to remove the 301 redirect browser cache with HTTP headers, which i agree with you, is not an error, but really doesn't make much logical sense.

Considering this i agree we should move all redirects to "302 Found".

please test #11196

Tested #11206, works, closing this issue