Problem/Motivation

I need to disable downloading translations from the server to speed up the installation process.

I use a script php ./scripts/test-site.php install --langcode de to install a minimum profile

For that task we have a special flag download_translation in the function install_state_defaults(), that is FALSE by default.

But, as I see, this flag is never checked in any part of the Drupal Core, and translations are downloaded every time, spending a lot of time on this.

As a result, the installation with non-default language takes too much time (48 sec instead of 4 sec on my local), when I actually don't need to download translations in most cases.

Steps to reproduce

1. Install the minimal Drupal version for tests with language = en:
php ./scripts/test-site.php install --langcode en
See that it takes around 2-5 seconds.

2. Install the minimal Drupal version for tests with language != en, eg with "de":
php ./scripts/test-site.php install --langcode de
See that it takes around 30-80 seconds!

Proposed resolution

Respect the value of the flag download_translation and skip downloading translations if it is false.

And add an option to force enable or disable translation downloading.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Issue fork drupal-3482251

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

murz created an issue. See original summary.

murz’s picture

A fix from me for this is to check the flag value and pass the server_pattern only if the flag 'download_translation' is TRUE, in the file core/includes/install.core.inc:

  // Check whether all conditions are met to download. Download the translation
  // if possible and enabled.
  $server_pattern = $install_state["download_translation"]
    ? $install_state['server_pattern']
    : NULL;

  $requirements = install_check_translations($install_state['parameters']['langcode'], $server_pattern);

- see the MR https://git.drupalcode.org/project/drupal/-/merge_requests/9900

After this, the installing time for non-en languages decreased to almost the same as with en language. But still not equal, so seems it still spends time on scanning files or other operations.

murz’s picture

Title: The 'download_translation' flag in install_state_defaults is not used anywhere » The 'download_translation' flag in install_state_defaults is not respected during install
Parent issue: » #3482349: drupalInstall Nightwatch command with non-default langcode takes too long time to install

This issue causes slow performance of running all tests with non-default language, I reported this as a separate issue: #3482349: drupalInstall Nightwatch command with non-default langcode takes too long time to install

The same issue is true for functional tests using Simpletest and PHPUnit.

murz’s picture

Here are tests of the Nightwatch drupalInstall() on the 11.x branch:

  ℹ Loaded url http://web in 203ms
drupalInstall default time: 3.367 seconds
  ℹ Loaded url http://web in 94ms
drupalInstall fr time: 26.343 seconds
  ℹ Loaded url http://web in 124ms
drupalInstall en time: 4.505 seconds
  ℹ Loaded url http://web in 111ms
drupalInstall de time: 35.939 seconds

and with my fixes:

  ℹ Loaded url http://web in 212ms
drupalInstall default time: 5.515 seconds
  ℹ Loaded url http://web in 114ms
drupalInstall fr time: 8.656 seconds
  ℹ Loaded url http://web in 97ms
drupalInstall en time: 4.087 seconds
  ℹ Loaded url http://web in 91ms
drupalInstall de time: 7.93 seconds

So, at least we got speed up for 5+ times! But still not the same time as with the en language.

The Nightwatch test code to measure on your side:

module.exports = {
  'Compare drupalInstall time with languages': async (browser) => {
    let startTime;

    await browser.pause(5000)

    startTime = new Date();
    await browser.drupalInstall();
    console.log(
      `drupalInstall default time: ${(new Date() - startTime) / 1000} seconds`,
    );
    await browser.drupalUninstall();
    await browser.pause(5000)

    startTime = new Date();
    await browser.drupalInstall({ langcode: 'fr' });
    console.log(
      `drupalInstall fr time: ${(new Date() - startTime) / 1000} seconds`,
    );
    await browser.drupalUninstall();
    await browser.pause(5000)

    startTime = new Date();
    await browser.drupalInstall({ langcode: 'en' });
    console.log(
      `drupalInstall en time: ${(new Date() - startTime) / 1000} seconds`,
    );
    await browser.drupalUninstall();
    await browser.pause(5000)

    startTime = new Date();
    await browser.drupalInstall({ langcode: 'de' });
    console.log(
      `drupalInstall de time: ${(new Date() - startTime) / 1000} seconds`,
    );
    await browser.drupalUninstall();
  },
};
murz’s picture

Status: Active » Needs review

Tested on my tests and it works great, so moving to the "Needs review".

smustgrave’s picture

Status: Needs review » Needs work
Issue tags: +Needs tests

Thanks for reporting,

Seems like an issue that will need test coverage for sure.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.

rudolfbyker made their first commit to this issue’s fork.

rudolfbyker’s picture

Rebased and fixed merge conflicts.

Next up: Write tests.

rudolfbyker’s picture

I refactored this, and wrote a test, but after seeing the existing tests fail and figuring out why, I realize that the current approach is not going to work. Still investigating and planning a new way to solve this.