Problem

When you invoke the installer, it shows a list of ~100 languages to pick from. When you pick, the translation file is downloaded, and you go over to profile selection page. If you decide to go back in your browser and select a different language, it is not anymore possible. When local files are found, only those are listed in the dropdown.

Although this sounds like an obscure use-case I ran into it multiple times in testing the installer, and I think it is confusing.

Steps to reproduce

  1. Go to the drupal installer
  2. Select Spanish
  3. Go back to the first step of the installer
  4. Note how spanish and english are the only two options and you can't install drupal in a different language anymore.

Proposal

IMHO we should still display all the languages and make it a distro level setting (#1351352: Distribution installation profiles are no longer able to override the early installer screens) if the language offering should be limited to local files only. If there is already a local file, we can/should skip downloading the file from remote as well. Also something to discuss.

#1351352: Distribution installation profiles are no longer able to override the early installer screens
#1386394: Add back the ability for install profiles (or at least distros) to pre-select a language or modify the language-selection screen

Files: 
CommentFileSizeAuthor
#37 1974048-37.png118.79 KBSutharsan
#25 language-selector-1974048-25.patch1.7 KBSutharsan
PASSED: [[SimpleTest]]: [MySQL] 58,793 pass(es).
[ View ]
#25 interdiff-1974048-22-25.patch2.17 KBSutharsan
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch interdiff-1974048-22-25.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#22 language-selector-1974048-22.patch3.05 KBbserem
FAILED: [[SimpleTest]]: [MySQL] 58,830 pass(es), 2 fail(s), and 0 exception(s).
[ View ]
#21 language-selector-1974048.15-21.interdiff.txt1.22 KBpenyaskito
#21 language-selector-1974048-21.patch2.67 KBpenyaskito
PASSED: [[SimpleTest]]: [MySQL] 58,940 pass(es).
[ View ]
#15 drupal-language-selector-1974048-7886473.patch2 KBbserem
PASSED: [[SimpleTest]]: [MySQL] 58,647 pass(es).
[ View ]
#11 drupal-language-selector-1974048-7885605.patch3.21 KBbserem
PASSED: [[SimpleTest]]: [MySQL] 58,722 pass(es).
[ View ]
#9 drupal-language-selector-1974048.patch3.26 KBbserem
PASSED: [[SimpleTest]]: [MySQL] 58,831 pass(es).
[ View ]
#9 1974048 - default.jpg96.62 KBbserem
#9 1974048 - local files.jpg105.34 KBbserem
#9 1974048 - list open.jpg107.28 KBbserem

Comments

Issue summary:View changes

Updated issue summary.

Added steps to reproduce.

Like Gabors proposal, I also believe that all languages should be displayed when the installation is run. No matter if a local file is available.

I believe that, in the Drupal community, it is possible for some people to share a distribution (officialy through d.o or even unofficially) with language files in it. This however shouldn't stop people from testing the distro in their native language.

If that was the case, the installer should also hide English from the list, an approach that I do not find appealing.

I agree with Gabor's proposal to have the installer show all selectable languages regardless of available local files.

Additionally distributions should have the possibility to limit the choice of languages, for example if the distribution is targeted at specific countries and/or languages. Limiting the choice to one language should result in skipping the language selection step.

I am not sure if there is still a requirement to provide translations with the distribution. If so, the distro should have option to disable the download of translations. This would give the distro the option to fully control its (installation) language experience.

Side note: currently the 'download_translation' setting in the installer is broken.

Should we get someone on this issue or do you want to take it? It probably needs more code removed than added :D

Issue summary:View changes

Updated issue summary.

In reply to #6, I could give it a try, if one could point me to the right folder inside drupal...

Assigned:Unassigned» bserem
Status:Active» Needs review
StatusFileSize
new107.28 KB
new105.34 KB
new96.62 KB
new3.26 KB
PASSED: [[SimpleTest]]: [MySQL] 58,831 pass(es).
[ View ]

So, with some help here in the Drupalcon Sprint, I present a patch and explain the logic behind it.

The attached screenshots show the behavior after the patch is applied.
First: Default state, with no local language files (with a bit of changes in the help text).
Second: Local files are available, extra text is being displayed and they have a * in their name.
Third screenshot: The list of languages open, with local languages being marked with a star.

ps: I do not know the proper procedure, do I assign this to myself on no?

Status:Needs review» Needs work

@bserem, thanks for stepping up. But I don't agree with the direction.

+++ b/core/includes/install.core.inc
@@ -1592,10 +1592,18 @@ function install_select_language_form($form, &$form_state, $files = array()) {
+  $local_message = '<p>Local translations were found and are marked with a " * " (star sign) in front of the corresponding language. ' .
+      'They will be used instead of remote ones.</p>';

Do we really want to bother people with this? Remember this is the first time experience with Drupal. Users will see this if
1. they have selected a language before and managed to return to the first installation step. There is no link in the normal process that takes them back. Either they know what they are doing or they are confused. This new text will probably make it worse for them. So, please don't!
2. They have an installation profile which comes with default languages but allows users to select other languages too. They will not be familiar with the concepts 'remote' and 'local'. And why would they bother?

StatusFileSize
new3.21 KB
PASSED: [[SimpleTest]]: [MySQL] 58,722 pass(es).
[ View ]

@Sutharsan do you disagree with the explanation text or with the whole idea of informing people about local files?
Maybe the attached patch is better when it comes to new people and their first installation.

In my opinion though, first time Drupal users might try to re-run the installation, so I believe it will be good to notify them somehow.
Same of course applies to veteran users.

I would like some more clarification on the matter, so that I can get the logic right.

I disagree with bothering first time users with minor important stuff. The "*" and the explanation is noise which should be prevented. So, indeed, I disagree with informing people about this.

... first time Drupal users might try to re-run the installation, ...

I doubt if first time users will regularly re-run the installation. And if they do, they are probably in trouble. We should not give them noise, but clear information which leads them to a good result.

So your proposal for the issue is to completely skip the *, and not mention to the end user whether a local file or a remote file is going to be used. Am I right?
This is actually quite easy to be done!

I would of course like to hear other peoples ideas to, so that I can produce a patch that most of us will find acceptable :)

I agree its better to skip the whole identification of local stuff and just skip the *. I think its a real possibility that someone accidentally picks the wrong language, hits the back button and then would like to pick something else.

Status:Needs work» Needs review
StatusFileSize
new2 KB
PASSED: [[SimpleTest]]: [MySQL] 58,647 pass(es).
[ View ]

Well then, things were way simpler. The attached patch doesn't inform the user about local translation files.
It will however continue with the local file if a user selects a language that has a local file!
If you believe this should be removed please let me know.

I think this looks fine with me.

If you all agree then we can close this issue (not me of course). I'll go check some other issue.

I'm testing and reviewing this.

Status:Needs review» Needs work

OK, reviewed the patch and looks great. However, there is something that still could confuses some users.

As @Sutharsan pointed, users that come back to the first step in the installer are probably really confused, and we are removing the help text for them!

I would suggest that we set $form['help'] no matter of the $files variable.

Assigned:bserem» penyaskito

Working myself on the patch.

Assigned:penyaskito» Unassigned
Status:Needs work» Needs review
StatusFileSize
new2.67 KB
PASSED: [[SimpleTest]]: [MySQL] 58,940 pass(es).
[ View ]
new1.22 KB

In the patch attached, help is shown even when returning back to the installer.

StatusFileSize
new3.05 KB
FAILED: [[SimpleTest]]: [MySQL] 58,830 pass(es), 2 fail(s), and 0 exception(s).
[ View ]

Oh, I must have missed the if(empty($files)) line on the last patch... Thanks penyaskito!

Sidenote, while we are at it: since we out all this effort for first time users. Shouldn't the help text be altered from "if you don't want this" to something like "english is included" ?
After all, we do not care about downloading the language anymore, since we do not display a list of already downloaded languages.

Status:Needs review» Needs work

The last submitted patch, language-selector-1974048-22.patch, failed testing.

+++ b/core/includes/install.core.inc
@@ -1563,8 +1563,15 @@ function install_select_language_form($form, &$form_state, $files = array()) {
+  // Select lists based on all standard languages.
+  foreach ($standard_languages as $langcode => $language_names) {
+    $select_options[$langcode] = $language_names[1];
+    $browser_options[$langcode] = new Language(array(
+      'id' => $langcode,
+    ));
+  }
+  // Select lists based on available language files.
   if (count($files)) {
-    // Select lists based on available language files.
     foreach ($files as $langcode => $uri) {
       $select_options[$langcode] = isset($standard_languages[$langcode]) ? $standard_languages[$langcode][1] : $langcode;
       $browser_options[$langcode] = new Language(array(

We should sort the $select_options based on their key. Otherwise the file added languages will end up at the bottom of the list.

+++ b/core/includes/install.core.inc
@@ -1591,13 +1588,11 @@ function install_select_language_form($form, &$form_state, $files = array()) {
-
-  if (empty($files)) {
-    $form['help'] = array(
-      '#markup' => '<p>Translations will be downloaded from the <a href="http://localize.drupal.org">Drupal Translation website</a>. ' .
-      'If you do not want this, select <em>English</em> and continue the installation. For more information, see the <a href="http://drupal.org/documentation/install">online handbook</a>.</p>',
-    );
-  }
+  $form['help'] = array(
+    '#markup' => '<p>Translations will be downloaded from the <a href="http://localize.drupal.org">Drupal Translation website</a>. ' .
+    '<em>English</em> is included in Drupal.</p>' .
+    '<p>For more information, see the <a href="http://drupal.org/documentation/install">online handbook</a>.</p>',
+  );

This does not help the problem of this issue. Pls remove.

@bserem, please add interdiffs to you patch. This helps reviewers to find those parts recently changed. https://drupal.org/node/1488712

StatusFileSize
new2.17 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch interdiff-1974048-22-25.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
new1.7 KB
PASSED: [[SimpleTest]]: [MySQL] 58,793 pass(es).
[ View ]

As per #24

As per #24

Status:Needs work» Needs review

Needs review

Status:Needs review» Needs work

The last submitted patch, interdiff-1974048-22-25.patch, failed testing.

Status:Needs work» Needs review

Restoring tags.

@sutharsan: File added languages don't end up at the bottom with any of my patches (in opera, firefox, chromium at least). They appear where they should based on alphabetical sorting.

Do you experience a different behavior?

@bserem, then you need to test this with a language which is not in the standard language list (LanguageManager::getStandardLanguageList()).

That would happen in the edge case when a local language file was available in a langcode that is not listed in the standard list of languages.

It will be listed in the list with its language code. See screenshot where drupal-8.0.foobar.po was added to sites/default/files/translations.

Perhaps we should change this. Now we have only langcode, it is both used as langcode and as displayble language.

Current patch:
File: drupal-8.0.fb.po
Langcode: fb
Display: fb

Alternative 1:
File: drupal-8.0.fb.po
Langcode: fb
Display: Language: fb

Alternative 2:
File: drupal-8.0.fb_FooBar.po
Langcode: fb
Display: FooBar
Can be combined with Alternative 1 as fallback.

StatusFileSize
new118.79 KB

1974048-37.png

Is that order algorithm case-sensitive? What happens with drupal-8.0.Foobar.po?

Issue summary:View changes

Updated issue summary.