When browser language is used, foreign language redirection breaks on the front page.

Looks an interesting & elegant solution. Will have to test this out. I have concerns about either infinite loops situations on the frontpage OR general overhead on frontpage requests for sites which aren't multilingual...

Thanks,
Nick

This patch (and globalredirect in general) seems to function as a work-around for #339958: Cached pages returned in wrong language when browser language used, as it extends the language-prefix redirection to the front page, and so avoids having a language-oblivious cache hit on that page.
I haven't thoroughly tested this patch, but it does seem to work okay, with the exception of problems with drush. The issue with drush (#594326: Breaks Drush) can be fixed with the patch posted in comment 1 of that issue.

Upping this to normal and making it active again as this module does take care of #339958: Cached pages returned in wrong language when browser language used with the exception of the front page.

Tested the initial patch and it almost works, however the front page is still cached in English at e.g. http://example.com.

After an English user hits the front page, redirection stops working for all non-English users. I'm looking into alternative solutions.

Attached is a patch which solves the issue above.

Consider the following scenario:

The front page (http://example.com) is not yet cached and a user with French set as their browser language hits the page, they will be successfully redirected to the French prefixed homepage (http://example.com/fr). That page will then be cached in French with a CID of "http://example.com/fr". However, if then an English user hits the front page (http://example.com), the page will be cached in English at http://example.com. At this point, if the French user hits the front page again, they will see English.

The problem is that Drupal calls hook_init() too late. At that point, it's already detected that the page http://example.com has been cached and loads it without ever calling our redirect code in globalredirect_init().

To solve this, I'm introducing globalredirect_boot() which tricks Drupal into getting and setting the front page cache at http://example.com/en, despite the fact that the (English preference) user is viewing http://example.com.

Given that this solves the major issue #339958: Cached pages returned in wrong language when browser language used, I'm bumping this to major.

Please review and commit if appropriate.

After further testing, this creates other issues later in the page generation. In particular, all forms on all pages are sent to a non-existant location.

This may not be fixable via contrib.

Hi iamEAP,

Any news on this?

Cheers

Bartezz,

I haven't looked at this in quite some time, but I'll summarize my thoughts on the matter:

Regarding the original issue, wrwrwr's original suggestion of redirecting to the prefixed path would be the sound one. This is because Global Redirect does all of its work in hook_init, which does not fire at all on cached page loads. If a user were to conditionally be redirected to a non-prefixed homepage, it would be cached there in whatever language the user happened to be browsing in, and all subsequent visits to the non-prefixed homepage would never see the redirect and instead be rendered from cache in that language, regardless of future users' language preferences.

However, I can think of few clients who would accept that their root domain could no longer be used as the homepage for English-speaking users. As such, I think this issue is not really worth resolving.

Relatedly, Global Redirect is only a suitable fix to #339958: Cached pages returned in wrong language when browser language used if the default language is given a prefix. If not, the moment an English speaking user hits any page, it gets cached at the non-prefixed path in English, and all non-English users will never be redirected.

Given how stale this and the related core issue are, I think it's worth closing this one.

Hi iamEAP,

Thanx for the fast response! I have had the cache issues on the frontpage as you mentioned and have been working around this by excluding <front> from cache with cache_exclusions.module. This works although it's not the best solution as the frontpage get's sh#tloads of traffic.

I can think of few clients who would accept that their root domain could no longer be used as the homepage for English-speaking users. As such, I think this issue is not really worth resolving

I don't agree on this one. On all projects I have done where a SEO specialist was involved there have been remarks about example.com and example.com/en showing the exact same page. Redirecting a user from example.com to example.com/en based on browser language seemed to be the acceptable solution if that was what it took.

Ofcourse a solution to the wrong language cache issue in Cached pages returned in wrong language when browser language used would be great. But then we would still need to redirect example.com/prefix to example.com to prevent duplicate pages and SEO penalties, correct?

Cheers

I guess it's a matter of priorities. If your priority is absolute 100% SEO optimization (which I suppose is the purpose of this module), then a redirect from example.com to example.com/prefix would be welcomed.

However, if maintaining an existing brand identity is your priority, then you're less likely to consider your homepage at example.com/prefix as acceptable.

Would it be worth adding a toggle for this in the Global Redirect configs?

Heck yeah it would :)

Like you said SEO is the whole point of installing this module, I could care less about duplicate pages if it wasn't for possible SEO penalties :)

Cheers

Great. I'm going to set this back to "active" so that it gets more attention. I don't know if/when I'll have the time to work this one up.

Anyone who wants to take a crack at a patch should do something similar to the original patch, but add a way to toggle the front page redirect functionality between "strict" (homepage will redirect to language-prefixed URL) and something looser ("compliant" or "tolerant"?) which allows the homepage to exist at multiple URLs.

There should also be some appropriate help/description messaging about the SEO/branding tradeoffs.

Nice! Will see if I have time but I've got quite a bit on my plate right now...

Cheers

The original patch (thus from the issue summary) does indeed seem to work fine.

1 remark though. The default language must have a prefix as well. If not, a cache entry will be created for the root page eventually and no redirects will take place anymore. In other words: a request to the root of your site must always redirect.

Is this bad?

For SEO? No: Google sees the 301 as part of canonicalization and will thus attribute links to the root URL to the redirected URL (Google answer about canonicalization). This will prevent duplicate content, though that in itself is not a real factor anymore for SEO (Google answer about duplicate content)

For branding? Not that I think. SERP will show www.example.com/en instead of www.example.com.

This patch and performance: the redirect takes place after a full Drupal bootstrap has been done. So I guess, performance won't be optimal. But this module is not about optimal performance but about offering a simple solution that works without the need to edit the .htaccess or other "scary" files. BTW: 301 redirect may be cached by browsers, though I'm not sure that this will be done looking at the standard set of headers that Drupal sends.

The patch is not created with git, but did apply locally when using "git apply 317305.patch" (against the 6.x-1.4 branch). So people can and should still test and review this patch.