Forcing redirect to wrong language

  • Resolved aegisjester

    (@aegisjester)


    2 weeks, 1 day ago

    We are using this plugin to translate our landing/sales pages.

    Twice now we have had a critical bug that required disabling the plugin – it decides our homepage is something other than its default, and redirects all users to some other lanuage.

    Specifically, our language is in English. The first time this happened, it started redirecting every user to Spanish (and so we disabled the plugin, purged everything, and changed a bunch of settings).

    Today it decided every user needs to go to French – no settings or anything else could convince it otherwise, so we had to disable again. In my chrome “network” debugger, I see it put in a redirect to the French page.

    I de-activated again, purged all caches, removed every detectable language, re-enabled, and FOR NOW it is resolved. But why would it be forcing myself and my users to some language other than the default (which shouldn’t be translated at all) unless we ask for it?

    This bug is absolutely plugin-breaking

    The page I need help with: [log in to see the link]

Viewing 10 replies - 1 through 10 (of 10 total)
  • Thread Starter aegisjester

    (@aegisjester)

    2 weeks, 1 day ago

    I don’t know the details of the plugin mechanics, but Spanish and French are our most-used second languages for our site. So if there is some override condition on “this is requested most” or something, that absolutely would break it for us.

    Plugin Author Gerard Kanters

    (@gkanters)

    2 weeks, 1 day ago

    Here’s what’s probably happening:

    The plugin has a setting called “Detectable Languages (Auto-Translate)” (separate from the languages shown in your pages). For any new visitor who doesn’t yet have a language cookie, the plugin reads their browser’s Accept-Language header and — if it matches one of your detectable languages — issues a redirect to that language version before the page loads. This is an intentional feature for auto-routing visitors to their native language.

    The reason it appeared to affect every visitor (not just Spanish- or French-speaking ones) is almost certainly a caching problem, not random plugin behavior: if you have a CDN, Cloudflare page rule, or a full-page cache running in front of WordPress, it can cache that first redirect response for your bare homepage URL and then serve that same cached redirect to every subsequent visitor, regardless of their own browser language — until the cache is purged. That matches exactly what you saw: everyone routed to the same non-default language, a different language the second time (whoever happened to load the homepage first and “seed” the cache), and it only resolved after you purged caches.

    To prevent this permanently, rather than only purging caches when it recurs: go to the language settings and make sure “Detectable Languages” is empty/unchecked (keep only your manually enabled switcher languages). That fully disables the browser-based auto-redirect for anonymous visitors on your homepage, so there’s no redirect for a cache to accidentally serve to everyone else.

    Let me know if this fixes the problem

    Thread Starter aegisjester

    (@aegisjester)

    2 weeks, 1 day ago

    I am an American living in Chicago. I have staff in Montreal, a bi-lingual city.

    2 weeks ago we were all routed to Spanish – which could not be any of our detected languages. I disabled the plugin, changed some settings, and re-enabled it this week.

    Today we were all (both Canadians and myself) routed to French – all simultaneously, and all of us anglophones (so our browser language could not have been the culprit).

    I disabled the plugin again for 30 minutes, then after re-enabling we were again being served English. Something is forcing some other language.

    Plugin Author Gerard Kanters

    (@gkanters)

    2 weeks, 1 day ago

    That is indeed possible if you use some form of CDN like cloudflare. If a previous user had Spanish this could be cached in cloudflare and then all users get Spanish. Disabling the plugin forces cloudflare back to English. Next time some Canadian speaking French comes along and all is French, since this is his default browser language and the CDN again caches it.

    But besides the fix I advised above, I can do something in the code to use the browser header. Most caching solutions respect that setting, but there is no guarantee. It can be overwritten by settings or even by default from caching servers (mostly called aggressive caching).

    Thread Starter aegisjester

    (@aegisjester)

    1 week, 3 days ago

    We had to disable the plugin entirely for now. Even turning off auto-detection entirely, our team was getting pointed to some other language virtually every day.

    • This reply was modified 1 week, 3 days ago by aegisjester.
    Plugin Author Gerard Kanters

    (@gkanters)

    1 week, 3 days ago

    Try to reinstall the plugin, so remove and install the latest version. This has some extra protection against cloud based caching.

    If that does not help, I really need more information about the setup to determine the exact cause.

    Thread Starter aegisjester

    (@aegisjester)

    1 week, 2 days ago

    I did that but I haven’t seen a version change since before I started this thread (so I believe I just re-installed to the same version I already had)

    Plugin Author Gerard Kanters

    (@gkanters)

    1 week, 2 days ago

    I did not update the version, since it was a minor fix which also needed to be verified. It had to be a development version, but that is more difficult to install. So it is different, but has the same version.

    Plugin Author Gerard Kanters

    (@gkanters)

    1 week, 1 day ago

    I checked your sites headers and your site is hosted by Kinsta. They use edge caching on top of Cloudflare, which is causing the problem. The fix I provided would work with Cloudflare, but not fully with Kinsta.

    Here is what you can do:

    To prevent Kinsta’s edge cache from bypassing the plugin’s server-side redirect rules on your homepage, add a cache bypass rule in your Kinsta dashboard:

    1. Log in to MyKinsta and go to your site stocktrak.com.
    2. Navigate to Edge Caching in the left sidebar.
    3. Scroll down to Edge Caching > Exclude additional URLs from cache (or look for a “Custom Cache Rules” / “Bypass Cache” section — the exact label depends on your Kinsta plan).
    4. Add a new rule with these settings:
      • Match type: Cookie contains
      • Cookie name: ai_translate_lang
      • URL pattern to apply to: /
      • Action: Bypass cache

    This tells Kinsta: “when a visitor arrives on the homepage and they have a language preference cookie set, skip the cache and let WordPress handle the request normally.” Visitors without the cookie still get the fast cached homepage, so there’s no performance impact for first-time visitors.

    Note: If your Kinsta plan doesn’t expose a cookie-based cache rule in the dashboard (some plans limit this to URL patterns only), you can open a support chat with Kinsta and ask them to add it for you — their support can usually apply these rules server-side.

    If this does not work, let me know. I will provide a JS solution that will specifically make sure that cookie settings will be respected despite the edge caching of Kinsta.

    Plugin Author Gerard Kanters

    (@gkanters)

    1 day, 11 hours ago

    Closing ticket

Viewing 10 replies - 1 through 10 (of 10 total)

You must be logged in to reply to this topic.