Default language can't be chosen

[Lesrad]

Hi Guys,
Seems like development is going on at a hectic pace for qtranslate-x, thought I would bring this post to your attention as it has a proposed solution included in post 25.
https://wordpress.org/support/topic/default-language-cant-be-chosen?replies=26

[johnclause]

Well, the solution you wrote there may work for you, but it is not a solution for all cases, because you disabled further analysis in qtranxf_detect_language_front, which is still needed in other cases.

That thread is very long, could you re-state the problem here in a concise and complete way?

[kuchenundkakao]

Well, the problem is that the "auto-detection" by cookie collides with the "hide prefix in standard lang"-option.
I agree with you that it removes the auto-detection which is bad (and i should feel bad ;) ).

Having looked another time at the code, maybe this would be a better fix:
-1 Remove the Fix i inserted
-2 change the qtranxf_detect_language_front like this:

     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'];
                                        $url_info['lang_cookie_front'] = $lang;
                                } 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;
     }

So this way, if a) no Lang information could be gotten from the url (because the prefix is hidden) AND b) the cookie is set (because the visitor is already on the site), if the "hide prefix" option is activated, we get the standard language.

Another little thing.

the function qtranxf_get_browser_language, which gets called when i visit the website the first time and no cookie is set, returns the ISO language code ('de-DE'), while the plugin needs the short language code ('de'), which leads to the cookie being set on "de-DE", which leads to a blank page, please look into that.

Regards,
Kuchenundkakao

[johnclause]

Hi @kuchenundkakao, I am sorry for the delay in reply, too many things are going on at once. I uploaded to github 3.2-b2 (https://github.com/qTranslate-Team/qtranslate-x/archive/master.zip), could you try it? It should fix "de-DE" problem, and may be that is all what you actually need to change. I cannot test it, because it is when function http_negotiate_language is in use, which my server does not have, but yours apparently does, since you got this problem. Please, let me know what you find out. Thanks a lot.

[kuchenundkakao]

Great! I just replaced the qtranxf_http_negotiate_language and the qtranxf_get_browser_language and the ISO-Code Problem leading to a white page when no cookie is set and the default language is hidden is gone!

Now for the "bigger" fish in the sea, the "main" problem of the issue. Did you check my fix of the qtranxf_detect_language_front which i inserted above? Running now some days on my site and no problems whatsoever.

[qtranslateteam]

I would appreciate if you could actually test the whole new thing, since
there are some other changes there, and the main problem might also
disappear. I'll talk to you later, Thanks a lot.

On Thu, Feb 26, 2015 at 12:02 AM, kuchenundkakao notifications@github.com
wrote:

Great! I just replaced the qtranxf_http_negotiate_language and the
qtranxf_get_browser_language and the ISO-Code Problem leading to a white
page when no cookie is set and the default language is hidden is gone!

Now for the "bigger" fish in the sea, the "main" problem of the issue. Did
you check my fix of the qtranxf_detect_language_front which i inserted
above? Running now some days on my site and no problems whatsoever.

—
Reply to this email directly or view it on GitHub
#33 (comment)
.

[kuchenundkakao]

Nope, still the same problem.

[johnclause]

What bothers me is that I cannot reproduce this problem and neither apparently can other a few thousands users. I am very afraid to break someone, while fixing someone else. I would feel comfortable if I could reproduce it and then I would clearly see what the problem is. Would it be possible for you to try to list the precise steps how to reproduce it with a publicly available theme and minimum set of plugins?

[kuchenundkakao]

OK, Steps to recreate the Problem:
First: install Wordpress (4.1.1) + twentyfifteen + qtranslate-x. Nothing else
Activate qtranslate x,
configure like this:

• show displayed lang prefix when content is not available for...
• Detect lang of browser and redirect according
• Pre-Path-Mode
• Hide URL Information for Default language

Now you go to the frontend / default language -> switch to second language -> remove the lang prefix from url -> hit enter. BAM, you're still on the second language.

http://vorschau.impuls-wa.de/wp4beta2/ -> Gets me the german lang first time
Then i switch to english:
http://vorschau.impuls-wa.de/wp4beta2/en/ -> nice, everything in english
Then back to german (by url)
http://vorschau.impuls-wa.de/wp4beta2/ -> gets redirected to /en again.

I think you can not recreate the problem because you use the language switcher of qtranslate-x, which puts the path into the url even if "hide prefix" is enabled, which gets then redirected. And indeed, if i enter
http://vorschau.impuls-wa.de/wp4beta2/de/ into the url, i get redirected to
http://vorschau.impuls-wa.de/wp4beta2/ and switched to german.

So why don't we just use the qtranslate-x lang-switcher?
Because if i have switched to second language, which means the cookie for english is set, then i still want to see the default lang if i visit the default language path, coming from google or whatnot. Second (and more important even), when i use qtranslate slug for SEO reasons, i have to use its version of the switcher, which takes the option "hide prefix for default lang" into account when creating the url to switch to.

So concluding: when "hide prefix" is set AND cookie is set AND the website is called prefix-less, the "normal" behavior should be: the language which was called by url (none, so default) should have bigger priority than the language that was set in the cookie before.

Regards,
Kuchenundkakao

[johnclause]

Now you go to the frontend / default language -> switch to second language -> remove the lang prefix from url -> hit enter. BAM, you're still on the second language.

And URL is redirected to the second language, is that right? This is correct, since cookie now drive the language detection. Once we see user set one of the languages, we stick with it, until it is explicitly changed.

http://vorschau.impuls-wa.de/wp4beta2/ -> Gets me the german lang first time

Ok, I switched my browser to German to achieve this.

http://vorschau.impuls-wa.de/wp4beta2/ -> gets redirected to /en again.

This is correct since the active language now is English. You cannot switch language with a url, which does not have language information. If url does not have language information, then language is determined by referrer url (if cookie is not set), then by cookie, then by browser, then by default, and cookie set with whatever result is to be kept on further browsing until user explicitly switch language through menu or widget,or a url with language.

for SEO reasons

This is not a problem for SEO, because robots do not keep cookie and do not have referrer, that is why they will always get default language on a url without language.

which takes the option "hide prefix for default lang" into account when creating the url

Option "hide prefix for default lang" has nothing to do with URL modifications, it is for showing language prefix on the content, when content is shown in other than the active language because it is not available for active language. Did you mean "Hide URL Information for Default language"? But that was already discussed?

So far, I see it works by design. If you wish to troubleshoot Qtranslate Slug plugin, then let us again consider exact steps to reproduce the problem, like you did this time, which was almost perfect (mentioning default language and browser language should have been specified for the sake of completeness, let me know if I did wrong guess on those too, I set both to German to be able to reproduce your steps).

With the new information, mentioned here, does it make sense to you now? Do you have more concerns?

Thanks a lot, I appreciate this discussion very much, it helps to improve the whole thing.

[johnclause]

I wrote this article: https://qtranslatexteam.wordpress.com/2015/02/26/browser-redirection-based-on-language/. If it does not address some of your concerns or you have a suggestion how to improve further, please, re-open the issue then. Thanks a lot for helping me to clarify the things for all the users.

[kuchenundkakao]

Hi again!
Sorry, that was a miscommunication. This is really about "Hide URL Information for Default language" and the fact that after going to the secondary language, visiting the site without language path gets you to the secondary language again.

Thank you for the clarification about your reasons to "get" the language in the order that it does. I see many things clearer now and i can understand the reasons.

I think the reason that so many "mqtranslate-to-qtranslate-x-switchers" like me have a problem with this is that its completely opposite to what we were used to from mqtranslate or qtranslate. mqtranslate didn't use cookies or Browser Redirection, so this is new to us and sometimes breaks functionality on existing websites.

Maybe we (you) can implement a compatibility function that uses my "fix" above if activated. It could be called "mqtranslate redirect compatibility" or something like this ;)

Happy Coding,
Kuchenundkakao

[johnclause]

breaks functionality on existing websites

Can you give an example when it breaks functionality? In your case, you were trying to do what normal users would not do.

I was not actually aware that this is different from mqtranslate logic, but the logic I use now was also determined based on users requests. Like I mentioned at the end of article, there is ambiguity which split people in two camps ;) So, somehow we need to resolve it. If we change it as you suggested, then some other sites will get broken. It seems to me that the logic implemented now makes a good enough sense, made a few new sites come aboard, and as long as people understand how it is, we can stick with it from now on.

mqTranslate's solution was not perfect either and did not work well for some sites. People for whom it did not work, left and do not use mq now, but they may come back aboard with this new logic, while current mq- users are still fine, as long as they understand what and why is changed for them. Does this make sense?

[kuchenundkakao]

Like i said, i fully understand WHY the order in qtranslate-x is like it is. I think it is even a better approach on some websites. I for my case like the "old" approach of "the url decides the language".

So that's why i proposed the idea of an additional option like "use URL-Encoded Language detection first if cookie exists". It would give the users the possibility to decide to keep using the old method of qtranslate etc. or use the shiny new detection features (which are really neat by the way ;) )

I think implementing this option is easier for the usual "plug and play"-user than explaining the changed language detection every time ^^ Hell, if you want me to, i'll write a pull request XD

I really hope you understand that i do NOT want to lower the detection logic that you wrote. I just want to make the switching from other plugins to your plugin easier.

Is that ok? ;)

[johnclause]

Let me understand what we would achieve with this. If we make url without language to be the default language always, then I do not see how we can preserve consistency of language during browsing. Like I mentioned in the article, some plugins and themes make links without language encoded regardless the active language. How would we then make those links to show the language other than default to preserve browsing language consistency?

[kuchenundkakao]

Yeah, i see the problem. But you don't seem to see that i want to give the user the option to CHOOSE.

If you make a new website with qtranslate-x, default is "use cool logic with cookies and stuff". The other plugins and themes which "make links without language encoded" (how does this even work? Do you have an example? I thought every plugin uses functions like "get_permalink" or stuff?!?) work out-of-the-box, everybody is happy.

If you "switch over" from mqtranslate (or worse: old qtranslate) and find that your website doesn't work as intended anymore (because the theme was written with m-/qtranslate in mind), you can activate the "use boring old logic" switch. Everything else still works like -x should: First time visitors get language detection by browser negotiation and the other great stuff, but the switching to default language may happen through URL if the "Hide URL Information for Default language"-option is active.

Going to bed now, see you tomorrow ;)

[johnclause]

Yes, people complained about unexpected language switch when a bare url was on a page and active language was not the default one. Unfortunately, I did not save the links, we can probably look it up, but there are other things to do more urgently.

I do not mind to pull in a new option, please, help me to see the value in it. Even your site is actually just fine from user perspective. A normal site visitor is not going to do the test you did. A user expects to see the same language during the browsing until it is consciously switched. So, what exactly this option would do good to a user?

Yes, there are themes, which adjusted their code to cope with and to offset former qTranslate imperfections. As I mentioned in the 3.0 release notes https://wordpress.org/support/topic/updated-to-release-30-and-all-stopped-working-read-this-first-%E2%80%A6, such themes will have undo their tricks now. It is a short-term pain, which will pay back in the long run.

So far, I do not see value in this option, IMHO, it will introduce further confusion, while not improving anything. Please, convince me in the opposite, if you strongly feel that there is a value. Start from your own site. How would your users benefit? I personally, as a user, do not see a problem with your site.

Cheers,
John

[leiit]

I seem to have the same issue, using also qtranslate-slug with urls like /lang/slug with primary lang prefix hidden and the browser lang detection supposedly off:

• switch to secondary lang from anywhere (using lang chooser), points to correct url
• you get redirected to /en/primary-lang-slug (??)
• impossible to switch to primary lang anymore

So whatever this intelligent behaviour is supposed to do, it's effectively breaking my site :) Started happening with the most recent update, I think. I have the primary language set to non-english but my browser is in english. Would also appreciate the old behavior of primarily respecting the given urls and not redirecting (no prefix -> go for primary language)

[johnclause]

I am not sure what is going on with -slug. It needs to be better integrated with -X. The author of -slug is currently busy with his errand and cannot do much. I may take a look at it later when the most urgent issues are resolved.

Would also appreciate the old behavior of primarily respecting the given urls and not redirecting

This is going to break people's sites as explained above. How would you deal with that? Same question I already asked, what are the benefits to your users? They have no idea about all those technical details, they only want to have the same language during browsing until they consciously switch the language, and that functionality is confirmed to work fine, is not it?

[leiit]

I haven't really looked into the implementation, and not sure if using -slug has any effect on this, unless it's the lang chooser that's bugging. What I mean is, all the urls will automatically have the wanted language in them; be it the default lang or with the /lang/ prefix if the user has chosen something else. So at least for me, I don't have much need for it to be any more intelligent than actually using those and not doing anything unexpected. I'm not really clear how that would break stuff, isn't that the way it has always worked before?

Anyhow the main problem is that once you get that cookie set (or whatever it is that happens), there's no way to switch back and reach the non-prefixed pages that are written in the default language, even though the lang switcher points to the correct urls. It's quite a major annoyance, so I might have to roll back to mqT for a while.

[johnclause]

@leiit: Yes, please, roll back until we resolve issues with -slug. Yes it has a lot to do with it.

As to your other questions, please, read this document https://qtranslatexteam.wordpress.com/2015/02/26/browser-redirection-based-on-language/ carefully and all my explanations on this issue, since you are asking questions that have already been answered.

BTW, when you say "impossible to switch to primary lang anymore", which method of switching you use? Widget? Menu?

[leiit]

Alrighty, that explains it then. Using the menu (qts_language_menu)

[justanewbie00]

Have the same problem. In the General Settings, I thought that the default language I chose will be the language if I erased the language shortcode in the URL. And it is said that "Usually, it is the language of your site before it became multilingual." But I don't think it is working fine. I open my site, select the other language, closed it, open the site again but instead of the default language, it is getting the last language I selected.

[HardLink]

I check a checkbox Hide URL Information for Default language
the default language is English.
the second language is Spanish.
the language change widget always contains a link: site.com/en/page/ this creates a 302 redirect.
I want the default language switch to have the form site,com/page/
how to do it?
otherwise I have a lot of redirects on the site