`wp_set_script_translations` only sets translations for the default language

[dathix]

With effect of the last update to version >=6.2 wp_set_script_translations stopped working correctly and now only sets translations for the default language. This may be caused by some improvements to i18n in the last release (​https://make.wordpress.org/core/2023/03/03/i18n-improvements-in-6-2/). Rollback to 6.1.3 fixed this issue.

[swissspidy]

Hi there and welcome to WordPress Trac!

Do you have more details on this and perhaps some steps to reproduce this?

[dathix]

I used wp_set_script_translations inside the wp_enqueue_scripts filter. The provided path contains JSON files in two different languages but the translations script tag always contains the default language as of 6.2. Everything worked fine in 6.1.3 and there were no changes to the code.

[dathix]

@swissspidy Any update on that?

[swissspidy]

Looking into it now, though without any code sample I'm tapping a bit in the dark to be honest.
So if you could share your code and exact steps to reproduce this issue, that will greatly help contributors wanting to reproduce this issue.
Given that we haven't had any reports for this so far, it sounds more like a site-specific issue to me rather than a bug in core.

[swissspidy]

Still haven't spotted any issues here, so this really needs a lot more details.

[dathix]

I can happily provide some more information but unfortunately, there is not much to say in addition to my previous message. Down below you will find the code that we are using to load the script translations. The site uses a Sage 10 theme and acorn to bundle the scripts. We want to register the translations to all our scripts so therefore the loop. lang_path() is a helper function from acorn that provides us with the path of the language folder inside our theme. This folder contains two sets of JSON language files (German & French) generated by the i18n CLI command. But as I said this setup works fine with WordPress <6.2.

add_action('wp_enqueue_scripts', function () {
    $app = bundle('app')->enqueue();

    foreach (array_keys($app->js()->keys()->toArray()) as $handle) {
        wp_set_script_translations("app/$handle", 'default', lang_path());
    }
}, 100);

Without the call of wp_set_script_translations() I am getting my default strings in English inside my scripts. The function seems to only registers the German translations from the JSON files. As a test, I deleted the JSON files for the German translation and tried to only register the French ones but in this case, the function returns false and I am still getting the English strings. The default language of the site is set to German (de_CH) and the site uses WPML. But as I already said nothing else was updated except WordPress.

Thanks in advance and appreciate your effort!

[swissspidy]

The function seems to only registers the German translations from the JSON files. As a test, I deleted the JSON files for the German translation and tried to only register the French ones but in this case, the function returns false and I am still getting the English strings. The default language of the site is set to German (de_CH) and the site uses WPML.

Not sure I follow. When you use this function, WordPress just loads the translations for the currently active locale.
If your locale is set to de_CH, WP does not load any French translations. That‘s by design.

[dathix]

Not sure I follow. When you use this function, WordPress just loads the translations for the currently active locale.
If your locale is set to de_CH, WP does not load any French translations. That‘s by design.

I am aware of this but before I installed WordPress >=6.2 changing the frontend language through WPML's language switcher also switched the script translations prior to the update.

After some further investigation, I was able to fix this issue by adding the action below:

add_action('wpml_language_has_switched', function () {
    global $sitepress;

    $lang = $sitepress->get_current_language();
    $locale = $sitepress->get_locale($lang);

    switch_to_locale($locale);
});

I am just wondering why this worked before.

[swissspidy]

Maybe something changed on the WPML side? I recommed checking with them