Automated download of translations when adding languages/enabling modules can not be disabled

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).

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. :)

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') . '/locale.batch.inc',
  );

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.

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.

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.

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.

No test provided yet.

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

Fixed syntax error and rerolled.

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

Committed dc6aeae and pushed to 8.x. Thanks!

Committed dc6aeae and pushed to 8.x. Thanks!

Yay, this will be very useful.

unassigning