Default language setting is hard to find

Just adding the D8MI tag, but also agree the the UX could be improved here, as someone who had not tested this in quite some time, I didn't find the setting were immediately apparent. Anyway, I looked at this issue (among others) to try to avoid creating a duplicate ticket for something I was observing.

Anyway, maybe "Language and Localization" would be a good heading for the Language/Translation/Locale -related stuff? I agree that "Regional and Language" is a bit counter-intuitive. I also agree that the Locale and Language are different enough they could be separated, but if under "Language and Localization", they would both start with "L" and there are close enough relationships and good reasons for showing these settings together (mixed feelings), e.g. for language negotiation rules, etc.

+1 on this. It should be added to the page where you add/manage languages for a site, and probably moved to the language module. I was taking part in the global training day yesterday in Nicaragua. There were three different tabs we had to visit to add, then change the default language from English to Spanish. BTW, the training was all done on beta3 of D8.

UI's are not frozen afaik for 8.0.x-dev.

Been bitten a couple of times to set a default language, even a simple help text on the language overview page could be a helpful start.

We moved this setting because it was at a "too easy place". We also wanted to discourage changing the default language. There are options to change default content language per bundle and the fallback language also for the site, so the site default language has little relevance. Unless you keep the settings tied to it which is actually the default :)

See the discussion on #1803638: Improve default language change process (ui and help text). I think we can move it back now that we made so many things independent of it, but its hard to tell which contrib modules may have bad side effects with a site default language change. Core is mostly unshattered now in D8 (unlike in D7).

Basically this issue would undo #1803638: Improve default language change process (ui and help text).

Removed SprintWeekend2015Queue by mistake.

Does this issue need work or review, it's not clear what is left to do here as per #7 comment.
Marking as Needs work for now.
Thanks

I don't have anything against undoing #1803638: Improve default language change process (ui and help text), as said in #1803638-51: Improve default language change process (ui and help text), we landed this 2 years ago for reasons that may not be true anymore. Changing the site default language was much more dangerous back then. I think driving people to change the site fallback language for cases where that makes sense would make sense, but not sure this was the best idea. There were several concerns on the issue from Bojhan, tstoeckler, etc. If the change from 2 years ago did not hold well with actual users (which is what we are getting to now), then it makes sense to move back IMHO.

Note that I wrote my tidbit about the move of this feature in mid 2013 and included this note at the bottom originally:

Changing the default language was moved out of this screen in https://drupal.org/node/1803638 but not everyone who used the system since then agreed this was a clear improvement. We may need to revisit this change and possibly roll it back based on further reviews and changes since then in core with language assignment.

Now edited to have a link to this issue at the end.

Summarizing the issue

Getting back the default settings to the languages page.

Reviewing the patch in #1803638: Improve default language change process (ui and help text) I've found this piece of code:

@@ -740,6 +740,11 @@ function locale_form_language_admin_overview_form_alter(&$form, &$form_state) {
         '#markup' => t('not applicable'),
       );
     }
+    // #type = link doesn't work with #weight on table.
+    // reset and set it back after locale_statistics to get it at the right end.
+    $operations = $form['languages'][$langcode]['operations'];
+    unset($form['languages'][$langcode]['operations']);
+    $form['languages'][$langcode]['operations'] = $operations;
   }
 }

This is part of locale_form_language_admin_overview_form_alter, and looking to that function, I'd say we can move it to LanguageListTest, to the buildForm and buildRow methods, maybe in a followup?

Missed a couple.

The UI looks good. Drupal 7 has the radio button in a default column right before the operations and this one is right after the name. I think that is a minor question and I don't have a preference. The snippet you found in #15 is related to the placement of stats and operations and not connected to this issue.

@karengreen, @swentel, @Garrett Albright, @heddn, @Lomo: what do you think of this?

Updated the issue summary.

The help text also needed updating. I moved the help from the select box that the patch removed to the language page. Funnily enough, the "Selected language" negotiation settings help was never updated to point to the regional settings page to direct people where to set the site default. It still points to the language list, so it is now correct :D The general negotiation help was pointing to the regional settings page. Fixed that.

Updated screenshots.

I'm good with the changes. The screenshots help a lot.

@mon_franco: let us know what you found!

@gábor-hojtsy I found everything correct. I have checked all I could in the page "admin/config/regional/settings" and seems like is working perfectly. Let me know if you need more tests of this issue from my side :)

This issue is a normal bug fix, and doesn't include any disruptive changes and improves UX, so it is allowed per https://www.drupal.org/core/beta-changes. Committed 66b5cb9 and pushed to 8.0.x. Thanks!

Yay, thanks!

Filed follow-up for following #2420239: Default language setting form needs validation

1. +++ b/core/modules/language/src/LanguageListBuilder.php
   @@ -126,12 +147,22 @@ public function buildForm(array $form, FormStateInterface $form_state) {
   +    // Save the default language.
   +    foreach ($form_state->getValue($this->entitiesKey) as $id => $value) {
   +      if (isset($this->entities[$id]) && ($id == $form_state->getValue('site_default_language'))) {
   +        \Drupal::configFactory()->getEditable('system.site')->set('langcode', $form_state->getValue('site_default_language'))->save();
   

   always saved?

2. +++ b/core/modules/language/src/LanguageListBuilder.php
   @@ -126,12 +147,22 @@ public function buildForm(array $form, FormStateInterface $form_state) {
   +    // Force the redirection to the page with the language we have just
   +    // selected as default.
   +    $form_state->setRedirect('entity.configurable_language.collection', array(), array('language' => $this->entities[$form_state->getValue('site_default_language')]));
   

   should use $entity->urlInfo('collection', $options)

Just wanted to say: excellent UI change, I just talked to Gábor about this problem in beta 6, then he tells me it's already solved by this issue :). Awesome work!