Skip Navigation

This is the technical support forum for WPML - the multilingual WordPress plugin.

Everyone can read, but only WPML clients can post here. WPML team is replying on the forum 6 days per week, 22 hours per day.

Our wait time is higher than usual, please make sure you are meeting the minimum requirement - https://wpml.org/home/minimum-requirements before you report issues, and if you can take a look at current Known Issues - https://wpml.org/known-issues/. Thank you.
Sun Mon Tue Wed Thu Fri Sat
- 9:00 – 12:00 9:00 – 12:00 9:00 – 12:00 9:00 – 12:00 9:00 – 12:00 -
- 13:00 – 18:00 13:00 – 18:00 13:00 – 18:00 13:00 – 18:00 13:00 – 18:00 -

Supporter timezone: Asia/Singapore (GMT+08:00)

Tagged: 

This topic contains 12 replies, has 2 voices.

Last updated by thomasA-35 2 hours, 11 minutes ago.

Assisted by: Kor.

Author Posts
July 11, 2024 at 1:29 pm #15935267

thomasA-35

Background of the issue:
I am trying to switch languages using $sitepress->switch_lang and output strings using the __() function. The issue can be seen on this page: hidden link.

We are seeing this issue on another website as well, but I was able to reproduce it on a clean install with Twenty Twenty-Four. I created a test plugin that outputs this code via a shortcode:

global $sitepress;
$initial_language = $sitepress->get_default_language();
echo '(initial locale)';
echo get_locale() . ' - ' . __( 'Sunday' ) . ' ' . __( 'Cancel', 'sitepress' ) . '';
$sitepress->switch_lang('de'); echo '(switching to German)';
echo get_locale() . ' - ' . __( 'Sunday' ) . ' ' . __( 'Cancel', 'sitepress' ) . '';
$sitepress->switch_lang('en'); echo '(switching to English)';
echo get_locale() . ' - ' . __( 'Sunday' ) . ' ' . __( 'Cancel', 'sitepress' ) . '';
$sitepress->switch_lang('de'); echo '(switching to German)';
echo get_locale() . ' - ' . __( 'Sunday' ) . ' ' . __( 'Cancel', 'sitepress' ) . '';
$sitepress->switch_lang($initial_language);

Symptoms:
When visiting the site in English, switch_lang does not work. Strings are always output in English: hidden link. When visiting the site in German, switch_lang is working as expected and strings are output in the currently specified locale: hidden link.

Questions:
Why is switch_lang not working consistently when switching to English?
How can I ensure that strings are output in the current locale when using switch_lang?

July 11, 2024 at 1:51 pm #15935668

Kor
Supporter

Languages: English (English )

Timezone: Asia/Singapore (GMT+08:00)

Thanks for your patience.

Here is the sandbox site hidden link

Please replicate the issue over there and share the details here so that I could escalate this to our 2nd Tier Support for further investigation.

July 11, 2024 at 2:03 pm #15935754

thomasA-35

Thank you for the sandbox credentials. I was able to reproduce the issue there.

Here is the German page where switch_lang works as expected:
hidden link

And here is the English page where switch_lang does not work. Strings are always output in English:
hidden link

For context again: I created a plugin "ATOM WPML Test" that registers the shortcode [atom_wpml_test]. This shortcode switches between languages using $sitepress->switch_lang and then outputs strings using __().

July 11, 2024 at 5:37 pm #15936932

Kor
Supporter

Languages: English (English )

Timezone: Asia/Singapore (GMT+08:00)

Thanks for your reply.

I've escalated this to our 2nd Tier Support and I will come back to you once I've feedback.

July 15, 2024 at 7:10 am #15952477

thomasA-35

Just writing so the ticket does not get closed.

July 15, 2024 at 9:14 am #15953192

Kor
Supporter

Languages: English (English )

Timezone: Asia/Singapore (GMT+08:00)

Thank you for your response.

I have feedback from our 2nd Tier Support. They advise against directly accessing the method and recommend using the hook instead - you can find more information here: https://wpml.org/wpml-hook/wpml_switch_language/

July 15, 2024 at 1:06 pm #15954583

thomasA-35

Thank you for your reply. I replaced $sitepress->switch_lang('de') with do_action('wpml_switch_language', 'de') in the sandbox. The issue still remains the same. It appears that in some cases the translation files are not loaded correctly.

July 15, 2024 at 2:08 pm #15954892

Kor
Supporter

Languages: English (English )

Timezone: Asia/Singapore (GMT+08:00)

Thanks for your reply.

I've forwarded your feedback and I will come back to you once I hear from our 2nd Tier Support.

July 16, 2024 at 3:51 pm #15961425

Kor
Supporter

Languages: English (English )

Timezone: Asia/Singapore (GMT+08:00)

Thanks for your reply.

This report has reached our developers and I will come back to you once I've feedback.

July 23, 2024 at 10:03 am #15991919

thomasA-35

Do you have any news on this issue? Thanks!

July 23, 2024 at 2:02 pm #15992643

Kor
Supporter

Languages: English (English )

Timezone: Asia/Singapore (GMT+08:00)

Thank you for your response.

I’ve checked the status, and it’s still in the review queue. I’ll get back to you with updates as soon as I hear from them.

September 3, 2024 at 12:22 pm #16135580

thomasA-35

Hi, I just want to emphasise that this is a huge issue for us as we can no longer trust WPML to output the correctly translated content. And looking at the "known issues" page, this seems to be part of a larger problem where translation files are just not loaded under certain conditions.
This ticket is now nearly two months old. In the meantime you released String Translations 3.2.14 which "Fixed an issue with untranslated content being rendered on the frontend in certain cases with WordPress 6.5.". But unfortunately it did not fix the issue in our case.

September 3, 2024 at 2:58 pm #16136421

Kor
Supporter

Languages: English (English )

Timezone: Asia/Singapore (GMT+08:00)

Thank you for your response.

I've reviewed the report, and it appears that no actions have been taken by our developers yet. However, I see multiple reports confirming the issue. I don't have an estimated resolution time at the moment, but I will keep monitoring the situation closely.

April 3, 2025 at 10:02 am #16891134

thomasA-35

Hi, it appears that half a year later this is still not fixed. The issue still occurs in 4.7.3.

Just wanted to ask if you plan on fixing this at all? This is a serious bug affecting the core functionality of this plugin that we paid for. Over half a year of response time is not acceptable for this kind of issue.

April 3, 2025 at 2:06 pm #16892796

Kor
Supporter

Languages: English (English )

Timezone: Asia/Singapore (GMT+08:00)

Thanks for your reply. Sorry, I still don't have any updates yet but I can see that this has reached our devs and it's in a queue for a review.