[Escalated to 2nd Tier] I can't add a new language because the request takes more than 60 seconds

Hi there!

I discussed this with our second tier team and we identified the reason for the slowdown when adding a new language.

At the moment, when WPML adds a new language, it not only downloads the WordPress core language packs, but it also checks and updates the translation packs for *all installed plugins*, even if they are already up to date.

This especially impacts websites using plugins like WooCommerce because they include a very large number of translation files.

Our developers are already aware of the issue and we have escalated it internally.

For now, the workaround is to temporarily add the following code snippet to the site. This prevents WPML from updating plugin translation packs during the language creation process, which should make adding languages significantly faster:

/**
 * Prevent WPML from updating plugin language packs when adding a new language
 */
add_filter( 'option_active_plugins', function( $value ){

    if ( isset($_REQUEST['action']) && $_REQUEST['action'] === "wpml_set_active_languages" ){

        return [];
    }

    return $value;

}, PHP_INT_MAX, 1 );

You can add it temporarily in your theme’s functions.php file or via a snippets plugin.

After the language has been added successfully, you can then manually update translations from:
Dashboard → Updates → Update Translations

This way the language gets added first without the heavy plugin translation update process running at the same time.

Please let me know how it goes after testing it.

I noticed that the access details you shared are for a Local site. Unfortunately, I cannot access Local environments from my side.

Do you have a staging site or a live site where the issue can be reproduced and that I can access? If so, please share the access details with me, and I'll be happy to investigate the problem further.

Thank you for your cooperation!

we previously tested the issue using the Duplicator package you provided. In our test environment, we were able to reproduce the setup and perform several checks.

However, since the issue is still occurring on your site and we are unable to reproduce it in our environments, we need access to the actual site where the problem occurs in order to investigate what might be different there.

Could you please provide access to a staging or live site where the issue can be reproduced? This will allow us to continue the investigation and identify why the behavior differs from our test environments.

Ok thanks.

I have sent to the second tier.

I will let you know as soon as I have news.

Hi there!

Sorry for the delay.

At the moment, it looks like the workaround has not been applied to your site. Without it, we shouldn't expect to see any improvement in the behavior.

Unfortunately, my colleague doesn't have access to your site to verify this directly.

Could you please confirm whether the workaround was applied? If not, please apply it and let me know once it's done so I can continue investigating.

Thank you!