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.

This topic contains 4 replies, has 3 voices.

Last updated by karolinaV 2 years, 8 months ago.

Assigned support staff: Otto.

Author Posts
February 2, 2017 at 4:56 pm #1197796


After googling many threads with similar problems I still just can't get this to work. AJAX call just keeps returning finnish strings when I want english. Finnish is the default language.

This is not custom AJAX. I use AJAX the regular WordPress way like this:

add_action('wp_enqueue_scripts', 'qverk_scripts');

function qverk_scripts() {
    wp_enqueue_script('qverk-js', get_stylesheet_directory_uri() . '/js/js.js', array('jquery'));
    wp_localize_script('qverk-js', 'ajax_object', array(
        'ajax_url' => admin_url('admin-ajax.php?wpml_lang=' . ICL_LANGUAGE_CODE), // I pass the language here as a URL parameter
        'txt_confirm' => __('Are you sure?', 'qverk'),
        'txt_select' => __('Select...', 'qverk')

This is an example of an AJAX action setup:

add_action('wp_ajax_qverk_new_education', 'qverk_new_education');
add_action('wp_ajax_nopriv_qverk_new_education', 'qverk_new_education');

function qverk_new_education() {
    echo ICL_LANGUAGE_CODE; // Returns en, which is correct and what it should be
    do_action('wpml_switch_language', $_GET['wpml_lang']); // Here I'm trying to switch the language, but it does not do anything
    load_theme_textdomain('qverk'); // Somebody suggested loading the textdomain (from wp-content/languages/themes) worked for them, doesn't for me

The template uses your regular __()'s and _e()'s. Nothing fancy there. Please ask if you need more information. I might have just missed something very small and obvious.

February 2, 2017 at 5:19 pm #1197824


I tried this:

function qverk_new_education() {
    echo ICL_LANGUAGE_CODE; // Outputs `en`, which it should
    do_action('wpml_switch_language', 'fi');
    echo ICL_LANGUAGE_CODE; // Still outputs `en` even though I changed it
February 3, 2017 at 12:18 pm #1198717


Languages: English (English ) Spanish (Español )

Timezone: America/Argentina/Buenos_Aires (GMT-03:00)


Thank you for contacting the WPML support!

Please apologise for the delay in answering. This is not usual in this forum. I'll take care of your ticket and reply time will be shorter from now.

Can you please try with this hook instead:

Does it return the proper language?

If it does not work, to discard compatibility issues, can you please try the following test?

-Back up your site first
-Deactivate all the plugins that are not related to WPML
-Switch for a moment to a WordPress default theme like Twenty Fourteen.
-If the issue is gone, activate one by one to see with which one there is an interaction issue

Thanks for your cooperation.

Let me know your results, please.

Kind Regards,


February 8, 2017 at 12:19 pm #1202900


Hi, Otto. Thanks for your help.

I was, until now, unable to reproduce this on localhost and it occurred only on production server. The difference between the two is that I use localhost for translating theme strings with String translation plugin. Then I exported the translations as PO, compiled it and uploaded the files to remote /wp-content/languages/themes.

However, I also had to install String translation plugin on remote WP, because I use UltimateMember for registration and such. I had to translate the login forms and that's what I needed String translation for. Only to translate a couple form field titles. So I thought String translation could be the one to blame. But even after disabling String translation, I still had the same problem.

But then I downloaded the theme's mo and po files from remote server and put them in my local /wp-content/languages/theme folder and whaddayaknow, it broke! So I imported the PO file into the String translation plugin in the remote WP for the correct text domain, deleted the translation files from /wp-content/languages/themes and voilá! Worked immediately.

So, your guess is as good as mine. I don't know whose fault this is, whether it's WPML or WP. It has most likely nothing to do with Ultimatemember. I just hoped I could have avoided using the String translation plugin on the remote server, because the server is slow and the business owner is a cheapskate. But because I still have to use it for translating other things, I guess we can deem this issue resolved.

September 25, 2019 at 10:01 am #4637511


Hi, thanks for pointing out the solution. Just confirming, that the annoying issue still exists 😉