| Project: | Drupal core |
| Version: | 8.x-dev |
| Component: | locale.module |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Sutharsan |
| Status: | needs review |
| Issue tags: | challenging, D8MI, language-ui |
Issue Summary
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)
Comments
#1
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).
#2
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. :)
#3
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',
);
#4
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/settingson 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.#5
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?
#6
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.
#7
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().
#8
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.
#9
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.
#10
No test provided yet.