The main problem with this is that this means that when a test enables a language or module through the UI and locale.module is enabled, it tries to download translations. I think that might be slowing down a few tests right now (assumption, have not checked if that is actually true).

Fixing it is easy.

- Verify that this is actually the case (Run a test that tests the language UI locally, look at the debug output check if there is a translations downloaded message)
- Define a setting (config(), not variable_get()), default it to TRUE. No UI necessary at this point (can be discussed separately)
- Adjust testing profile .install to set it to FALSE.
- Verify that the translations are still downloaded by efault for you (a re-install might be necessary to update the config defaults)
- Re-run test and verify that there is no such message anymore. Write a simple test for this (add an assertNoText or similar)

#13 interdiff-1887480-11-13.patch1.41 KBwebflo
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch interdiff-1887480-11-13.patch. Unable to apply patch. See the log in the details link for more information. View
#13 locale-disable-import-1887480-13.patch3.02 KBwebflo
PASSED: [[SimpleTest]]: [MySQL] 57,898 pass(es). View
#11 locale-disable-import-1887480-11.patch2.08 KBSutharsan
FAILED: [[SimpleTest]]: [MySQL] Invalid PHP syntax in core/modules/locale/locale.module. View
#9 locale-disable-import-1887480-9.patch2.54 KBSutharsan
PASSED: [[SimpleTest]]: [MySQL] 54,476 pass(es). View
Members fund testing for the Drupal project. Drupal Association Learn more


Sutharsan’s picture

Issue tags: +language-ui

Some time ago I heard an other use case for not automatically importing translation. When enabling a module using drush users may not want to download the translation immediately. With the current setup Drush has no way realize this situation. A state variable or the mentioned config() setting would be enough for Drush to do this (in the future).

YesCT’s picture

Issue tags: +challenging

The install has a message telling people to install english to avoid phoning home. I wonder if installed in English and then a language is added later, do people get a similar warning about automatic translation downloads? Could locale module expose such a config setting in the UI also to control that in general? (Maybe it does already? Need to check.)

This looks like a good issue for people to jump in to help with, challenging but not epic. :)

vijaycs85’s picture

Look like @Berdir assumption is true. Here is the trace:

1. locale_modules_installed($modules)
2. locale_system_update($modules);
3. locale_translation_build_projects()
4. locale_translation_default_translation_server()
5. update_get_available()
6. locale_translation_batch_update_build()
7. _locale_translation_batch_status_operations()
8. _locale_translation_fetch_operations()
9. Finally:
  $batch = array(
    'operations' => $operations,
    'title' => $t('Updating translations'),
    'progress_message' => '',
    'error_message' => $t('Error importing translation files'),
    'finished' => 'locale_translation_batch_fetch_finished',
    'file' => drupal_get_path('module', 'locale') . '/',
Gábor Hojtsy’s picture

Well, if your update checking is set to local files only, then it will not phone home or download .po files in any way when adding new languages. See admin/config/regional/translate/settings on your site. I think having a prompt as part of the language addition process is too excessive to ask for this. Notifying people that their site will automatically get translations might be interesting (as YesCT notes). But asking them whether they want it sounds out of place to me.

Berdir’s picture

I don't think we need a UI prompt either, that's not what this issue is about.

All I want is to prevent that automated tests are trying to download translations when languages are enabled in tests, except when explicitly testing for that. Can we use the existing setting for that? Should it maybe default to local and only be set to something else manually/in the installer/standard profile?

Gábor Hojtsy’s picture

I think we generally want real life use of locale to enable this by default, because people want their site be translated. The goal of this feature, is so they get the interface translated effortlessly. If we put in more barriers just to make the testing system simpler, that is not a good trade-off :) The enabling of the feature can be made conditional of it being in the test system or something along those lines.

Berdir’s picture

This is now causing weird test failures as you can see in #1905152-63: Integrate config schema with locale, so shipped configuration is translated.

Which makes this probably even major as it's not only a performance problem but can also cause unexpected site effects.

Discussed this in IRC, maybe we can just add an overridden locale.settings.yml to the testing profile or, if that doesn't work (it might not yet but probably should?), add a condition check to locale_install().

Gábor Hojtsy’s picture

The reason it causes fails there is because we use a concrete real life langcode for the test, which most other tests don't do to avoid any other real-life logic to kick in. We are modifying our test there to use the xx langcode like almost all tests do. I still fully agree this should be fixed.

Sutharsan’s picture

Assigned: Unassigned » Sutharsan
Status: Active » Needs review
2.54 KB
PASSED: [[SimpleTest]]: [MySQL] 54,476 pass(es). View

This patch introduces a setting (without an interface) that controls the translation import. Using this importing the translation upon module enable, theme enable, language add can be inhibited.

Sutharsan’s picture

No test provided yet.

Sutharsan’s picture

Issue tags: +sprint
2.08 KB
FAILED: [[SimpleTest]]: [MySQL] Invalid PHP syntax in core/modules/locale/locale.module. View

Re-rolled the patch. We should disable the configuration with this variable too. But that needs input whether this has unwanted side effects.

Status: Needs review » Needs work

The last submitted patch, locale-disable-import-1887480-11.patch, failed testing.

webflo’s picture

Status: Needs work » Needs review
3.02 KB
PASSED: [[SimpleTest]]: [MySQL] 57,898 pass(es). View
1.41 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch interdiff-1887480-11-13.patch. Unable to apply patch. See the log in the details link for more information. View

Fixed syntax error and rerolled.

Gábor Hojtsy’s picture

Status: Needs review » Reviewed & tested by the community

Looks like the proposed change is fully implemented. Nice! Will be good for testing use.

alexpott’s picture

Status: Reviewed & tested by the community » Fixed

Committed dc6aeae and pushed to 8.x. Thanks!

alexpott’s picture

Committed dc6aeae and pushed to 8.x. Thanks!

Berdir’s picture

We need a follow-up to disable this check in the tests and only enable it when we actually want to test it. Because every test that adds languages through the UI currently triggers this process. Opened #2031175: Translation imports take a lot of time in tests even when not needed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Gábor Hojtsy’s picture

Issue tags: -sprint

Yay, this will be very useful.

Sutharsan’s picture

Assigned: Sutharsan » Unassigned
Issue summary: View changes