xflow

Having the same problem.

VERY annoying, for paying customers to have such a wonderful error message being visible to everyone visiting the website…

Using Yoast 7.5.1 as well as latest WP version.

Well, filtering works and extracts the default language content, but there’s quite some unusual (not nice) behaviour left as the plugin starts posting things while automatic posting option is disabled. To boot that automatic posting publishes the same article 3 times. Check the following screenshots below:

3 equal posts on Facebook

Automatic posting disabled

Sorry guys, but paying for the pro version was wasting money…

Ok, got it. Thought you’re talking about a hook and a plugin I would have to code myself.

AFAIK qTranslate’s filtering works according to an externally given language code that’s normally part of the URL (or a cookie). Both things (URL and cookie) are provided by the browser, but the cron job initiating Micro Blog Poster kind of works internally.

So, how can I tell Micro Blog Poster what language it has to use?

Ok, thx, that might help.

Are you talking about filters in the meaning of WP hooks?

What’s the name of the filters/hooks that I have to use? Is there any documentation available?

ups… ok…

so actual state url
example.com/portfolio/myphotos

target state url
example.com/myphotos

that is how i want ‘portfolio’ to become removed from the slug

Thx, it’s clear to me now. And thanks for quick response ??

Hi

No. I’ve got a gallery script using the regular <img> tag. If I use it with an absolute URL is good, but when I use it with a relative path then the language code gets added as pre-path. Example

Good and working, but absolute URL
<img src="<em>[Link redacted]</em>">

Not working, but relative flexible URL
<img src="/myfolder/<em>[Link redacted]</em>">

The latter one gets the language code added in front (pre-path mode), hence the links isnt /myfolder/<em>[Link redacted]</em> anymore, it gets converted to /en/myfolder/<em>[Link redacted]</em> (if English is set as language).

Florian

[Moderator Note: Please be aware of the example domains you’re providing and never use a porn site. Use example.com instead.]

Hi John

With v3.2.2 the default language problem is back. I’ll apply kuchenundkakao’s function replacement again.

Florian

Thx for your commitment! The updated code works.

@baga: What does that hreflang-problem do??? I noticed the redundancy as well as an actual technically wrong URL for default language as actually there shouldn’t be a pre-path language code. (wwww.xflow.eu/de is wrong).

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.

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 ??

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, I use it as a widget, but it’s not the language chooser as you have the same problem when entering the URLs manually.

PS: Enabling/disabling the option “Detect the language of the browser and redirect accordingly” shows absolutely no effect…

Having the same problem here, with 3 different WP installations. VERY annoying…

Example:
View my latest photo report here. It’s a German article. German is the default language of my website and set as #1 language in qTranslate X settings.

Then switch to English using the language picker in the header image or use this link

Now the website keeps on redirecting you to English content, no matter what URL you call; so just use the language picker in the header image again or use this link

The funny thing: Once I explicitely add the default language code in front the URL then the correct content gets displayed again and no automatic redirection occurs.

(Forcing Pre-Path Mode to use DE as actually no DE has to be used as DE is default language)
https://www.xflow.eu/de/2015/02/19/victoriafaelle-simbabwe/