Allow to skip translations import

Erm, what happens is the installer forces locale module to be enabled when installing in a foreign language. Otherwise import translations and finish translations would not even be added as batch items, no?

So why does the UI install work then and should we just not add these batch steps for the CLI install either if we are to exit from them immediately?

Why would you expose that to users? Does not sound like something a person who is exposed to Drupal the first time would be able to decide?

Patch #16 work. Tested on custom profile with custom language.

This is a bugfix and should be safe to commit during beta, at least, but is not eligible for commit during RC, so tagging with that deadline.

This totally breaks the default installation flow with language selection, given that of course when the task list is generated, the locale module is not (dynamically) added yet to the list of modules on the profile. So picking a foreign language in the installer does not do anything with this patch. That is a pretty serious side effect :)

What happens with this patch is there is no language download/translation happening after you pick the language in the installer. Then you need to go through the installer in English and it will only get translated once locale is in fact installed (because the additional steps are added then), so your site configuration screen in the installer is then translated but not the prior ones.

@andypost:

1. Go to this link: http://simplytest.me/project/drupal/8.2.x?patch[]=https://www.drupal.org...
2. Install Drupal in a language other than English
3. Observe that the installer is English throughout the installer up until the Configure screen
4. This is not good.

Hi all!
This is a good idea have ability disable translations adding for speedup Drupal installation in specific cases.
Reviewed patch from #16 comment and checked how installer translation works:

1. During first step install_select_language user select not default language, for example French
2. Next step install_download_translation if selected not default language - Drupal download "po" file for selected language: /sites/default/files/translations/drupal-8.2.0-dev.fr.po
3. Next steps check $_GET['langcode'] if it not "en" - translate strings using Drupal\Core\StringTranslation\Translator\FileTranslation (it works with "po" file directly and get translations from it)

Means: We can't overwrite $needs_download variable because we lost installer translation. But we can play with $needs_translations and speedup installation with disabling translations import.

Usage "locale" module state (installed/no) for definition should be translation imported or no is not so good: because in some cases "locale" module can be needed (enabled) and translations import can be be not needed (for more fast installation). We can use additional param like translations_import: no in profile .info.yml file instead.

@all what do you think about additional param in profile .info.yml file usage ?

I don't think this is per-se API-First related. Many/most API-First sites still use Drupal's UI for managing content.

This issue seems to be more "lively" than #2413191, but the approach in #2413191 seems to be less intrusive than patches in this thread.

I am currently experiencing an issue (with 8.7-dev) in a profile where English is the default language, Spanish is being added, I don't have locale enabled, I have even downloaded the Spanish translation and it still breaks. It seems like the $needs_translations check should not just check \Drupal::languageManager()->isMultilingual(), but it should also check if locale is installed.

For those concerned with cases where English is not the selected language, then it probably should be an error if locale has not been enabled at that point.

What exactly are peoples' blockers to having a check for locale to be enabled before trying to enable a translation?

Also is 2413191 a duplicate of this issue, or is this a duplicate of it?

So this came up as daily BSI target

Looking at the code I see

$locale_module_installed = \Drupal::moduleHandler()->moduleExists('locale');
  $needs_translations = $locale_module_installed && ((count($install_state['translations']) > 1 && !empty($install_state['parameters']['langcode']) && $install_state['parameters']['langcode'] != 'en') || \Drupal::languageManager()->isMultilingual());
  

Which was added in #2413191: Shipping a profile with multiple languages without locale module not possible.

So is this one outdated? Credit could be moved over.