Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem/Motivation
Currently importing of .po files for projects could take unacceptable about of time.
Proposed resolution
I have found that problem related to implementation of locale_translation_status_save();
This could be solved by this changes:
function locale_translation_status_save($project, $langcode, $type, $data) {
// Load the translation status or build it if not already available.
module_load_include('translation.inc', 'locale');
- $status = locale_translation_get_status();
+ $status = locale_translation_get_status([$project]);
if (empty($status)) {
$projects = locale_translation_get_projects([$project]);
if (isset($projects[$project])) {Remaining tasks
Don't see for now.
User interface changes
No changes
API changes
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|---|---|---|
| #22 | locale_translation_import_performance-3074765-22.patch | 756 bytes | Ankit.Gupta |
| |||
| #19 | locale_translation_import_performance-3074765-19.patch | 637 bytes | dxvargas |
| #3 | locale_translation_import_performance-3074765-3.patch | 531 bytes | Chewie |
Comments
Comment #2
Chewie CreditAttribution: Chewie as a volunteer and at Petend for European Commission and European Union Institutions, Agencies and Bodies commentedComment #3
Chewie CreditAttribution: Chewie as a volunteer and at Petend for European Commission and European Union Institutions, Agencies and Bodies commentedComment #4
Chewie CreditAttribution: Chewie as a volunteer and at Petend for European Commission and European Union Institutions, Agencies and Bodies commentedComment #5
Chewie CreditAttribution: Chewie as a volunteer and at Petend for European Commission and European Union Institutions, Agencies and Bodies commentedAdded related issue
Comment #6
Chewie CreditAttribution: Chewie as a volunteer and at Petend for European Commission and European Union Institutions, Agencies and Bodies commentedComment #7
Denes.Szabo CreditAttribution: Denes.Szabo as a volunteer and at Petend commentedWhat do you mean "unacceptable about of time"? How do you calculate the time? How much speed (time) you gained?
Why your solution solve the problem?
Comment #8
Chewie CreditAttribution: Chewie as a volunteer and at Petend for European Commission and European Union Institutions, Agencies and Bodies commentedInitially this issue was detected by executing drush command oe-multilingual:import-local-translations of opensource project https://github.com/openeuropa/oe_multilingual (version: 1.1.1).
I didn't check but probably performance issue could be also reproducible by standard drush command: locale:import.
Comment #10
Sutharsan CreditAttribution: Sutharsan at LimoenGroen commentedI think to remember, from when I wrote this code, that this call in on purpose. I think that there were situations when the list of available projects did not initialize, this may have been a way to overcome that. But that was 7 years ago... I may be wrong.
I think Denes.Szabo's questions are sensible and should be answered before we proceed with a solution.
Comment #13
SpadXIII CreditAttribution: SpadXIII at SIM commentedI ran across this issue as well. Importing the translations would take up to 35 minutes for a single site.
Some info about our site: it uses drupal 8, has about 100 modules enabled, and has 7 languages enabled. It is configured to only look for translations in local files and not download those (as they are downloaded locally). The translations files exist for only 2 of these languages (EN and NL).
Without this change, the method `locale_translation_status_save()` would take about 4.5-4.8 seconds to complete, per project, per language. So a total of about 32-35 seconds per project.
With this change, this was a little bit faster: per project, the first language took 45-50 ms and the languages after took less than 10ms. So a total of about 100-120 ms per project.
I did the quick benchmark by adding a few Timer::start and Timer::read in `locale_translation_check_projects_local()`. This method is called when doing a drush locale:check.
I'm setting this back to needs review, so others will have a look as well :)
Comment #16
heddnre #10, unacceptable is 45 minutes on one site to 2 hours on another during site install. If this brings that down to 5,10 15 minutes, that is a way more acceptable timeframe.
Comment #17
dxvargas CreditAttribution: dxvargas at Webzina for European Commission and European Union Institutions, Agencies and Bodies commentedThe proposed patch #3 makes a huge difference. Installation time came down from +20m to -10m.
I'll mark it as RTBC.
Because of https://www.drupal.org/project/drupal/issues/3150185, I wonder if this one's priority should be considered major.
Comment #18
quietone CreditAttribution: quietone at PreviousNext commentedThis is testing a patch on Drupal 8.7 and Drupal 8 is End of Life. This needs a patch for 10.0.x.
Comment #19
dxvargas CreditAttribution: dxvargas at Webzina for European Commission and European Union Institutions, Agencies and Bodies commentedRight, here it is the equivalent patch for core 10!
Comment #20
heddnI tested this on a 40+ language site with tons of translations in each of the languages and 86 contrib modules. WAY faster install times. And even running the drush command to pull down translations is a LOT faster.
RTBC++
Comment #22
Ankit.Gupta CreditAttribution: Ankit.Gupta at Dotsquares Ltd. commentedReroll the patch #19 with Drupal 10.0.x
Comment #23
dxvargas CreditAttribution: dxvargas at Webzina for European Commission and European Union Institutions, Agencies and Bodies commentedPatch in #22 is basically the same as in #19 which was RTBC.
It is good, I put the ticket back into RTBC.
It would be nice to have this merged, since it brings a good performance enhancement.
Comment #25
catchCommitted/pushed to 10.1.x and cherry-picked back to 9.4.x, nice find and thanks for the various manual testing everyone.