Default language can't be chosen

Yes, I use it as a widget, but it’s not the language chooser as you have the same problem when entering the URLs manually.

I’ve also noticed that the tags <link hreflang="it" ... rel="alternate" /> are written twice when using qTranslate slug plugin.

@xflow,

when I go to your site it jumps to /en and if I manually put /de it goes to the domain without /en or /de – DNS server settings maybe?

Whe I go to Biographie & Referenzen it is correct in German click then on the English button it is also correct en/biography-references/ going home in the menu it is correct English /en.

Click Biography & References English and switch to German it gets
/en/biographie-referenzen/ but the page name is in German.

You use qTranslate Slug, yes?

How looks your .htaccess file?

At first thx for taking care of this matter ??

it goes to the domain without /en or /de

Yes, and that is intended. If there’s no pre-path language code set by the browser call then the website always jumps back to default language without showing the language code in the URL. Meaning: https://www.xflow.eu/en >>> English, while a normal https://www.xflow.eu call MUST always go to German content as DE is default language. That is at least the behaviour qT and mqT always showed/provided. qTX now seems to be different as it keeps on jumping back to the latest language being selected by the user, meaning https://www.xflow.eu/en >>> English and a normal https://www.xflow.eu call leads to https://www.xflow.eu/en again. It does not jump back to default language.

You use qTranslate Slug, yes?

Yes. If I deactivate “Hide URL language information for default language” then the DE pre-path code gets added into the qT chooser link; then I get correctly redirected to DE site clicking the lang chooser link. The problem is that deactivating this option would change the links and my SEO ranking will drop. qTX always seems to redirect the user to the latest language set.

How looks your .htaccess file?

I use the same .htaccess like Christoffer posted before, without the “procano” statement of course ??

Yes, and that is intended. If there’s no pre-path language code set by the browser call then the website always jumps back to default language without showing the language code in the URL.

But here, cookies and cache cleared, it jumps to /en when I first enter your site and that should not happen.

To understand this step by step – deactivate qTranslate Slug en check – Hide URL language information for default language – than I can look from here if the first step (entering new your site) functions properly.

Let me know

But here, cookies and cache cleared, it jumps to /en when I first enter your site and that should not happen.

Correct, that should not happen. Let me put it like that to make sure we talk about the same thing. And it#s not a qT slug problem.

A multi-language website’s key feature is that content gets displayed in different languages and that you can also navigate through the languages of one and the same post. With original qT and mqT that was always possible, it was no problem to navigate between languages. Whenever you selected English you can read it in English, if you switch back to German then you get German and it stays German without becoming kicked back to the latest non-default language in case you entered a URL without pre-path language information.

A URL with no pre-path language information means that the website MUST always display the content in the default language.

This is not a qT slug problem. Just type in the URLs.

Viewing an English article will set English as further default client language. Any non-default language can be used here. If French would be my second language then “fr” code would do it the same way like “en”.
https://xflow.eu/en/?p=2064

Viewing the same article with no pre-path language code MUST actually lead you back to default language, that is German, but it does not. It leads you to English again and it always KEEPS kicking you back to English.
https://xflow.eu/?p=2064

Solely explicitly including the DE pre-path language code gets you back to German language again. Only that will restore the default language.
https://xflow.eu/?p=2064&lang=de

Using the p-parameter and post IDs (using no translated slugs!) shows you that this problem is not a qT slug problem.

Yes, I could now start to add “DE” to all my links referring to default language content but that would give me quite a drop in search engine rankings. So that is not an option at all.

If that sort of navigation is your philosophy, well, there is surely a reason why, but just for compatibility reasons give us an option to disable that sort of cookie-language-based redirection and all is good ??

Yes, I could now start to add “DE” to all my links referring to default language content but that would give me quite a drop in search engine rankings. So that is not an option at all.

I totally agree with you!

But to find the problem, you must first rule out things.

The intention is also to solve it as you have in mind.

If that sort of navigation is your philosophy

No it is not.

This is not a qT slug problem.

I prefer a step by step research so we can see where it goes wrong.

I think i found the solution after having the exact same problem.

Go to qtranslate_core.php in the qtranslate-x-folder.
Go to line 113. You should see the function qtranxf_detect_language

The problem is that the detection ($lang not set AND option to hide prefix on standard language is active) just happens within the if/then

if( (!$lang || !isset($url_info['doing_front_end']))
		&& (defined('DOING_AJAX') || !$q_config['cookie_enabled'])
		&& isset($_SERVER['HTTP_REFERER'])
	)

In plain english: (Lang not set OR not Frontend) AND (AJAX-Call OR No Cookie enabled) AND (HTTP_REFERER is set)
So, if the cookie is enabled, we don’t get this code:

if(!$lang && $q_config['hide_default_language']
				&& isset($url_info['doing_front_end']) && $url_info['doing_front_end'] )
			{
				$lang = $q_config['default_language'];
			}

(again, plain english: if (lang is not set) AND (hide prefix is active) AND (doing front end) -> set lang to the default language.

SOLUTION: Copy this last code into line 200 (right between the third back-to-back closing brackets ( } ) and the Comment which reads: "//$url_info['doing_front_end'] defines if we are in front- or back-end. Why WP does not have that, or does it?" ).
After that, the switching should work as intended.

Additional: Please check the code which redirects the visitor according to the browser language. The Code detects the language like this: “de-DE”/”en-US” which gets you to a white screen, as the language codes should be like “de” / “en”.

Happy Coding,
Kuchenundkakao

Cheers! Now it’s working the expected way. We should invite you to some Kuchen&Kakao ??

@author: Please make sure to include this solution in the next releases.

added requested solution with a link to this post via github. hopefully it maybe included in future releases.
https://github.com/qTranslate-Team/qtranslate-x/issues/33

Beutiful Kuchenundkakao! Thanks a lot for your fix!
Yes indeed it should be included in the next release of the plugin.

What about this issue?

I’ve also noticed that the tags <link hreflang=”it” … rel=”alternate” /> are written twice when using qTranslate slug plugin.

@xflow I noticed the same problem on your website

I just commented on the github issue with a different fix, as John stated (rightly) that my fix removes the auto-detection which is needed some other times.

So please remove my first fix and instead use the following:
– open the qtranslate_core.php
– go to line 235 where the function qtranxf_detect_language_front starts
– replace the function with the following:

function qtranxf_detect_language_front(&$url_info) {
	global $q_config;
	//assert($url_info['doing_front_end']);
	while(true){
		if( isset($_COOKIE[QTX_COOKIE_NAME_FRONT]) ){
			if($q_config['hide_default_language']){
				$lang = $q_config['default_language'];
			} else {
				$cs=null;
				$lang=qtranxf_resolveLangCase($_COOKIE[QTX_COOKIE_NAME_FRONT],$cs);
			}
			$url_info['lang_cookie_front'] = $lang;
			if($lang) break;
		}

		if($q_config['detect_browser_language']
			&& ( !isset($_SERVER['HTTP_REFERER']) || strpos($_SERVER['HTTP_REFERER'],$url_info['host'])===FALSE ) ){
			$urlunslashed=untrailingslashit($url_info['wp-path']);
			if(empty($urlunslashed)){
				$lang=qtranxf_http_negotiate_language();
				$url_info['lang_browser'] = $lang;
				if($lang) break;
			}
		}

		$lang = $q_config['default_language'];
		break;
	}
	if( !isset($url_info['doredirect'])
		//&& !defined('WP_ADMIN') && !defined('DOING_CRON') && !defined('DOING_AJAX')//will check later
		&& (!$q_config['hide_default_language'] || $lang != $q_config['default_language'])
		//&& !$url_info['language_neutral_path']//already so
	){
		$url_info['doredirect']='language needs to be shown in url';
	}
	return $lang;
}

This should be a better fix for the problem.

Happy Coding,
Kuchenundkakao

@baga: the duplicate hreflangs come from different function names in the action calls. The Qtranslate Slug Plugin tries to remove the function “<plugin_prefix>_header” (in this case “qtranxf_header” while the function in qtranslate x is called “qtranxf_head”. So both actions are executed in the wp_head.

@kuchenundkakao

Just tried your updated code, seems to work much better i.e. less 404 errors and better redirection.

Only one issue when using dropdown nav widget (or manual dropdown – code below) to change back to default language I am unable to do so, but the urls do exist if followed from another link or manually inserted into the browser.
manual insert dropdown code: <?php {echo qtrans_generateLanguageSelectCode('dropdown');} ?>

i.e. from homepage.com to homepage.com/de/ then try to go back to homepage.com doesnt work but any others do like homepage.com/se works
`