Front-end language not (re)set when opening site

[The3IC]

Running the latest 3.10.0 version.

When I open a site, the front end language cookie is not (re)set, instead the front end language cookie will be set to the language of the last use. This results in the next click "changing language" if the site is opened in a different language than last use.

Site with Finnish as default language and English as other language, using the /en/ format for URLs Use site in English (site.fi/en/...) Front end language is set to en Close site. Reopen site.fi (default, Finnish version) -> shows Finnish version content and language flag but front end language cookie is still set to "en" Click on any link -> link goes to English version (i.e. the language is changed "mid-flight"). Ditto for first using in Finnish and then opening in English.

If I open in "clean window", then accessing the site at the default language does not seem to set the front end language cookie (site.fi is shown in Finnish but the cookie is not set). Clicking on any link sets the cookie (correctly to Finnish).

While I guess my use case is rather marginal (mainly when testing a multilingual site), it would still be nice if the front end language cookie would be set to the actual language on entry. So when opening site.fi -> set language to fi, when opening site.fi/en, -> set language cookie to en.

[herrvigg]

Reopen site.fi (default, Finnish version) -> shows Finnish version content and language flag but front end language cookie is still set to "en" Ditto for first using in Finnish and then opening in English.

There's a problem here. If you re-open the default URL without specifying the language, you should be redirected to site.fi/en due to the front-end language cookie being en after the first visits. It should not stay on site.fi/. I have a similar setup in production and it works for me, I'm redirected.

If I open in "clean window"

What do you mean with clean window? After erasing the cookies? The cookies are shared between all windows belonging the same browser.

[The3IC]

Reopen site.fi (default, Finnish version) -> shows Finnish version content and language flag but front end language cookie is still set to "en" Ditto for first using in Finnish and then opening in English.

There's a problem here. If you re-open the default URL without specifying the language, you should be redirected to site.fi/en due to the front-end language cookie being en after the first visits. It should not stay on site.fi/. I have a similar setup in production and it works for me, I'm redirected.

That would ofcourse also make sense. There could also be some interaction with the qTranslate slug as the slug (when reopening) takes the Finnish slug and appends it to /en/? After resetting language then slug also behaves OK.

If I open in "clean window"

What do you mean with clean window? After erasing the cookies? The cookies are shared between all windows belonging the same browser.

Eg in a Incognito window with with no cookies set.

[herrvigg]

Indeed it could be a problem with qTranslate slug that I don't know well enough (not using it). Do you have possibility to disable it just to see if QTX alone behaves normally?

[The3IC]

Need to test on my staging site, BRB.

[alex-balint]

Got something of a similar problem, found a quick hack/solution. My setup: Use Pre-Path Mode, Hide URL language information for default language, no cookies, no lang auto-detect.

Problem: after switching to other language than default through the link generated by qtranxf_generateLanguageSelectCode(), switching back to default lang resulted in a 302 redirect back to non-default language. Also, qtranxf_generateLanguageSelectCode() still putting the pre-path lang code for the default.

To clarify: default lang 'ro', other lang 'en'. So, for 'ro', http://host/slug, for 'en' http://host/en/slug. From http://host/en/slug, clicking on http://host/ro/slug GENERATED BY generateLanguageSelectCode() got to http://host/ro/slug, got 302 redirect back to http://host/en/slug, BUT going directly to http://host/ro/slug (from browser bar) worked fine (loading http://host/slug as expected)

First, I changed in -widgets.php the generateLanguageSelectCode() part that created the href (line 248) from: qtranxf_convertURL( $url, $language, false, TRUE ) to qtranxf_convertURL( $url, $language, false, FALSE ), so got the link to be generated correctly for default, without the pre-path lang code ( http://host/slug ) However, the redirect back to 'en' still happened, even if the link was clean, without lang code! So I got to checking the HTTP headers to see what's different when loading directly from url bar vs. clicking and saw that from link click, a 'referer' header appeared - being the only thing different in headers, this should be the cause of the problem. Grepped for HTTP_REFERER in code, and discovered the qtranxf_detect_language() in -core.php. On line 161 there's $parse_referrer = qtranxf_is_rest_request_expected(), then below if ( isset( $_SERVER['HTTP_REFERER'] ) && $parse_referrer ), ie. some code that gets the referer and doing something there.

Solution/hack: put a $parse_referrer = false to disable the whole block of if ( isset( $_SERVER['HTTP_REFERER'] ) && $parse_referrer ) and got everything working as expected ;)

I know, not the cleanest thing, but solved my problem. When I'll have some time I'll dig deeper into what that function does for a good solution...

[herrvigg]

My setup: Use Pre-Path Mode, Hide URL language information for default language, no cookies, no lang auto-detect.

Without cookie it's a different problem, also known to be related to referrer, see #886. This is not fixed yet.

[The3IC]

OK, tested now and disabling the QT slug got me the behavior you described. So seems there is something in the slug code that blocks XT. :-(

Kind of emphasizes (in my view) the strong need to get the qT SLug integrated with XT so that this very valuable functionality would be aligned with the translation plugin. Seems still that the base code for the slug is very good as it has withstood over 5 years of Wordpress and qTranslate updates and still delivers reasonably well. Speaks loads of the dev's of the original slug code.