Improve default language negotiation

Very, very good stuff! Especially that it covers testing the changes. I agree it is best to change it to be a configurable language. Can you post some screenshots as well? I think the crucial part is that it should have a "Site defualt language" option that just follows the site default language like before, so when people set up their site at the start, they don't need to change languages at different places.

Subtagging for D8MI.

I'm adding the site's default language as another option to the configuration form which requires to extend a bit the language select element type to add the flag "LANGUAGE_DEFAULT", a patch is coming to have feedback about it.

Here is a patch introducing the Site's default language as a potential value for the selection negotiation method.

Let's have that tested again, i'm not sure about the "location" of the tests you wrote, i think they should be in there own method, i believe that they are mixing with the URL negotiation tests (and i'm not sure that's a good idea).
I believe that we should use CMI for the variable_get() (not sure what it implies yet).

In other words, this deserve feedbacks :).

We'll need to convert the existing negotiation settings to CMI but not as part of this patch. If we introduce the negotiation settings CMI setup here, we can port the others to the same config structure later. If we introduce it elsewhere, we can port this to that. I think doing this first makes more sense, because this is feature freeze blocked material, and conversion of the settings is not :)

Re-rolling and restoring the tests.

Re-roll

+++ b/core/includes/bootstrap.incundefined
@@ -236,6 +236,11 @@ const LANGUAGE_LOCKED = 2;
+ * The language state used when referring to the site default language .

Dot should not have space before it.

+++ b/core/includes/language.incundefined
@@ -408,7 +408,7 @@ function language_negotiation_info() {
-      'weight' => 10,
+      'weight' => 14,

Is this change to move it back to the last item?

+++ b/core/modules/language/language.admin.incundefined
@@ -519,6 +519,7 @@ function language_negotiation_configure_form_table(&$form, $type) {
+        '#delta' => 20,

Why did you need to add this?

+++ b/core/modules/language/language.admin.incundefined
@@ -815,6 +816,20 @@ function language_negotiation_configure_session_form($form, &$form_state) {
 /**
+ * Builds the selected language negotiation method configuration form.
+ */
+function language_negotiation_configure_selected_form($form, &$form_state) {
+  $form['language_negotiation_selected_langcode'] = array(
+    '#type' => 'language_select',
+    '#title' => t('Language'),
+    '#languages' => LANGUAGE_CONFIGURABLE | LANGUAGE_DEFAULT,
+    '#default_value' => variable_get('language_negotiation_selected_langcode', FALSE),
+  );
+
+  return system_settings_form($form);

Unfortunately it is not acceptable anymore to introduce new variables. We need this converted to CMI.

+++ b/core/modules/language/language.negotiation.incundefined
@@ -316,6 +321,24 @@ function language_from_url($languages, $request) {
 /**
+ * Identifies language from configuration.
+ *
+ * @param $languages
+ *   An array of valid language objects.
+ *
+ * @return
+ *   A valid language code on success, FALSE otherwise.
+ */
+function language_from_selected($languages) {
+  $langcode = variable_get('language_negotiation_selected_langcode', FALSE);
+  // Replace the site's default langcode by its real value.
+  if ($langcode == 'site_default') {
+    $langcode = language_from_default();
+  }
+  return isset($languages[$langcode]) ? $langcode : FALSE;
+}

This looks good. Why are you not removing the site default language item in favor of this new one? The existence of both look puzzling to me.

I'm reading through this, trying to see where the changes are and how to test it. (Let me know what else I should be looking at. I'll poke around to find places too.)

So far, with a clean install, I enable modules for content translation, language and locale. Added a language in the config language settings (admin/config/regional/language/add), then from the language config (admin/config/regional/language) picked the Detection and Selection tab to get to admin/config/regional/language/detection

Here is a comparison of that language Detection and Selection tab without the patch and with the patch from #11

Without patch

With patch

In the summary, c31ck says: Since changing the default language on a Drupal site can cause a variety of issues, it would be convenient if there was something like http://drupal.org/project/fallback_language_negotation in core. This allows the site to fallback to a language without actually changing the default language.

Please give me a specific example of one of the problems that changing the default language can cause. Then I can try and do the same thing with the features of this patch and see how the workflow is different and if the problem is avoided.

I dont think we want to hide the "Default language Use the default site language (Burmese). Enable default language language detection method Configure" row on the config page: admin/config/regional/language/detection It is a way to set the site default language from that page, and it says what the site default is...

Let me try removing that row and see what would happen...

The configure link for that row leads to a page that needs some work...

Suggestion:

For comparison, here is one of the other language detection config pages with some help text and more info.

This is me doing testing that lead to my comments in #16
http://blip.tv/cathytheys/improve-default-language-negotiation-patch-tes...

I'm posting the screencast because the first part (to about 7:20) shows me clearing out two sites and getting them ready to test the patch, and someone might have some feedback to tell me how I might have been able to do the setup faster, or maybe someone else wants to test a patch for this issue, and seeing me set it up, might help them. [Edit: Gabor gave some tips below, and moving the discussion to: http://drupal.org/node/1489010#comment-6470956 ]

The second half (starting at around 7:20) shows me configuring the site and trying to use the new stuff from this. I'm posting that because it shows the effect of this patch (the one from #11) and might be useful showing my confusion trying to sort out the usefulness of the patch.

(13:20-15:11) By setting the site default language to German, and the interface select language to Bermese, I could get on a article node create form, the interface in Bermese, and the language of the node being created to be German. That might be as designed.

I think we need the answer to the discusion in #15. A specific use case.

@YesCT: wow, wow, thanks for the very elaborate testing and the video proving it worked :)

As for use cases (question from #15), the general problem in Drupal 7 is that a lot of things don't have language selectors. When you go add a view or contact form or specify the site name, there is no language selector, so Drupal can only assume you create all of those in the site's default language. Then it often happens that people build sites out in a language and then want to **switch the default language** later, so that the fallback language for the site is not the same that was in development. That is a big no-no in Drupal 7 given that then all the data you entered earlier is now assumed to be in another language (Drupal will not swap out your config to translations and your translations to config). That is the problem that Fallback language negotiation module is supposed to solve by making the fallback language a configuration, so you don't need to change the site default language. In reality, until we have a language selector on all configuration and content so you can tell piece by piece what language is the data in, the site default language has this special role and changing it is dangerous. It is hard to tell at this point whether we'll get there 100% in Drupal 8, its more likely that we will not. So putting fallback language negotiation (configurable fallback language instead of a fixed default) seems like a good idea to help people not shoot themselves in the foot. Hope this helps explain the background :)

Now, let's summarise this in a short help text as you suggested in #16's suggested UI and make all the remaining changes (I agree with all your suggestions there on the screenshots for the UI, we should explain why is this useful, people don't know the above story until they get burned and we want to avoid them getting burned :).

Ps: as for testing speedup tips, my tricks are (a) I don't have 2 parallel sites, I test on the site first, then apply patch and test again (b) I don't blow away the site settings, so I don't need to enter them again on the UI, installation is much quicker (c) I use the MySQL command line and just drop database and create database (these are short and easy to type commands vs. dropping all tables individually that you needed a UI for) (d) I avoid local branches for testing, I apply the patch as needed and just keep it in the local index (git add but not git commit); then I can git stash and git stash clear the changes if needed or git reset. When I need to do interdiffs, I also just use the local index as a lightweight branch and diff against that instead of branching: http://hojtsy.hu/blog/2012-apr-13/quick-and-simple-interdiffs - I don't think we should do this discussion here, but since you posted a video and people might follow this discussion wondering, I posted some quick tips here; let's talk on IRC more if you have questions :)

+++ b/core/includes/language.incundefined
@@ -407,11 +407,14 @@ function language_negotiation_info() {
     // Add the default language negotiation method.
     $negotiation_info[LANGUAGE_NEGOTIATION_DEFAULT] = array(
-      'callbacks' => array('language' => 'language_from_default'),
-      'weight' => 10,
+      'callbacks' => array(
+        'language'    => 'language_from_default',
+        'negotiation' => 'language_from_default'
+      ),
+      'weight' => 12,
       'name' => t('Default language'),
       'description' => t('Use the default site language (@language_name).', array('@language_name' => language_default()->name)),
-      'config' => 'admin/config/regional/language',
+      'config' => 'admin/config/regional/language/detection/default',
     );

@@ -474,8 +477,13 @@ function language_negotiation_method_invoke($method_id, $method = NULL, $request
-function language_from_default() {
-  return language_default()->langcode;
+function language_from_default($languages) {
+  $langcode = (string) config('language.negotiation')->get('default_langcode');
+  // Replace the site's default langcode by its real value.
+  if ($langcode == 'site_default') {
+    $langcode = language_default()->language;
+  }
+  return isset($languages[$langcode]) ? $langcode : language_default()->langcode;
 }

I know it looks comfy to just reuse the existing default provider and totally change its behavior, but its not really doing "default language" anymore, depending on configuration, so this becomes pretty misleading. We should rename the provider / callbacks, which will unfortunately also require an upgrade path, but that should be easy to test (as part of the existing language upgrade tests).

+++ b/core/modules/language/config/language.detection.yamlundefined
@@ -0,0 +1 @@
+default_langcode: site_default
\ No newline at end of file

As the last line says.

From the failures it looks like LANGUAGE_NEGOTIATION_DEFAULT is used at a couple more places not yet accounted for.

Replaced instances of LANGUAGE_NEGOTIATION_DEFAULT with LANGUAGE_NEGOTIATION_SELECTED.

Here is the ui from #25 patch

detection tab, has the changes in the last row

the config link opens this (admin/config/regional/language/detection/selected)

There we see the place where the help text needs improving. Right now it says:
"Determine the language from a selected language or the site's default language. Selecting a different language here is preferred over -link-changing your site's default language directly-endlink-."

Something that bothers me is:
... if someone wants to change their language, they will go to config, then click on language, and this takes them first to:

It seems to me that someone wont see the help text we put on admin/config/regional/language/detection/selected even if we put something great there. So if we really want people to use that over changing the default, then we need to put something here that tells them not to change the default here.

We need to figure out the great help text and what we are going to say that explains why it's better to use the detect/select than change the default. Right now it states blatantly: "Selecting a different language here is preferred over changing your site's default language directly." That's a pretty strong statement, and without qualification. From reading through this issue, it seemed more like it would be preferable to select a language here under certain circumstances and that we would spell out here when to do that here, and when it would be preferable to really change the default. If we can do that, it will make more sense to have the link to changing the default be in that phrase which says when to do it, instead of now, where the link is in a sentence that says not to do it. It's giving a conflicting impression.

So, in summary, The ui is pretty good. But we need to get the words just right for the help text (and maybe put some of them right on the lang config page).

Here is super rough help text.

  case 'admin/config/regional/language/detection/selected':
      $output = '<p>' . t("Determine which language is used to display page elements (primarily text provided by Drupal and modules, such as field labels and help text), from a selected language or the site's default language.") . '</p>';
      $output = $output . '<p>' . t("Selecting a different language here is preferred over changing your site's default language directly. Changing the site's default language can cause undesired side effects. A lot of things don't have language selectors. When you go add a view or contact form or specify the site name, there is no language selector, so Drupal can only assume you create all of those in the site's default language. If the site default langague is then switched, all the data entered earlier is now assumed to be in another language. Selecting a language here can avoid those problems.") . '</p>';
      $output = $output . '<p>' . t("Alternatively, <a href='@default-lang-configuration'>change your site's default language directly</a> when you need the change to ripple down through everything, for example in content creation forms if a content type or vocabulary is set to default to the site default language.", array('@default-lang-configuration' => url('admin/config/regional/language'))) . '</p>';
      return $output; 

I think the first paragraph is superfluos, it just explains language negotiation in general.

Selecting a different language here is preferred over changing your site's default language directly. Changing the site's default language can cause undesired side effects. A lot of things don't have language selectors. When you go add a view or contact form or specify the site name, there is no language selector, so Drupal can only assume you create all of those in the site's default language. If the site default langague is then switched, all the data entered earlier is now assumed to be in another language. Selecting a language here can avoid those problems.

I'd try and shorten this significantly if possible :) No concrete suggestions yet, need to think a bit about this.

Maybe something simple like (in place of all three paragraphs you proposed):

Changing the selected language here (and leaving this option as the last among the detection and selection options) is the easiest way to change the fallback language for the website, if you need to change how your site works by default (eg. when using an empty path prefix or using the default domain). <a href="@admin-change-language">Changing the site's default language</a> itself might have other undesired side effects.

@YesCT: any opinion on the text? Looks like this is pretty close except some textual changes and a small update function and a little check in the upgrade tests to test for this rename happening.

+++ b/core/includes/language.inc
@@ -404,14 +404,20 @@ function language_negotiation_info() {
+        'language'    => 'language_from_default',

Wondering if this is the right callback to get the language because if the user didn't select the site's default language we won't get the right value.

Gonna give a shot to the upgrade path to check if it's working.

If the user did not select a default language, we should assume Drupal's built-in default.

I think this looks good, but I second Artusamak's wondering...

+++ b/core/includes/language.incundefined
@@ -404,14 +404,20 @@ function language_negotiation_info() {
-    $negotiation_info[LANGUAGE_NEGOTIATION_DEFAULT] = array(
-      'callbacks' => array('language' => 'language_from_default'),
-      'weight' => 10,
-      'name' => t('Default language'),
-      'description' => t('Use the default site language (@language_name).', array('@language_name' => language_default()->name)),
-      'config' => 'admin/config/regional/language',
+    $negotiation_info[LANGUAGE_NEGOTIATION_SELECTED] = array(
+      'callbacks' => array(
+        'language'    => 'language_from_default',
+        'negotiation' => 'language_from_selected',
+      ),
+      'weight' => 12,
+      'name' => t('Selected language'),
+      'description' => t($description, array('@language_name' => $selected_language->name)),

So I have the same question that Artusamak had above :) We are replacing the one element callbacks array with two elements, and we keep the 'language' item as-is. Why is that? That sounds like it would not be correct depending on settings, right?

If i quote locale_update_8004():

function locale_update_8004() {
  $types = update_variable_get('language_types', NULL);
  if (!empty($types)) {
    foreach ($types as $type => $configurable) {
      // Rename the negotiation and language switch callback keys.
      $negotiation = update_variable_get('language_negotiation_' . $type, NULL);
      if (!empty($negotiation)) {
        foreach ($negotiation as $method_id => &$method) {
          $method['callbacks']['negotiation'] = $method['callbacks']['language'];
          unset($method['callbacks']['language']);
          if (isset($method['callbacks']['switcher'])) {
            $method['callbacks']['language_switch'] = $method['callbacks']['switcher'];
            unset($method['callbacks']['switcher']);
          }
        }
        update_variable_set('language_negotiation_' . $type, $negotiation);
      }

      // Rename the language negotiation methods weight variable.
      $weight = update_variable_get('locale_language_providers_weight_' . $type , NULL);
      if ($weight !== NULL) {
        update_variable_set('language_negotiation_methods_weight_' . $type , $weight);
        update_variable_del('locale_language_providers_weight_' . $type);
      }
    }
  }

The 'language' callback is not used anymore, replaced by 'negociation', i can't figure out if this update function is going to be broken if we have two different keys in the callbacks array and i tend to believe that we should get rid of the 'language' key in this array.

So how did it work before since it did not have a "negotiation" callback, it only had a "language" one? It falled back on the default language callback (ironically?). Looks like we should be able to remove "language_from_default" altogether, no - including this buggy reference?

@Artusamak, @webflo, @c31ck: any plans to bring this through the finish line? It is pretty close :)

The patch in #31 added the constant LANGUAGE_DEFAULT. This contant LANGUAGE_DEFAULT is already defined and used in the entity system (see bootstrap.inc line ~230). Lets rename the new constant to LANGUAGE_SITE_DEFAULT.

All right, that resolves the remaining concerns, it took the UI suggestions from above, so all in all looks good to go! Great stuff.

I read the issue summary and started to look at the screenshots. I don't understand the issue summary, and I don't understand the difference between the 'default language' and the 'selected language'.

The description for 'Selected language' in the screenshot in #26 doesn't make sense to me either, nor does the help text on the selected language configuration page in #27.

I think it may be a terminology language. Should it be called the 'Default (content) input language' and 'Default (content) display language'?

Also, why would you configure those in two different places? It looks like they are in different tabs. Wouldn't it make more sense to have them in one place?

I ran out of time and can't continue to look at this patch right now, but I figured I'd share my confusion as it is likely to confuse other people as well. Maybe the issue summary can be clarified.

Hm. That sounds like a "needs work."

Added remaining tasks.

Updating the issue summary. I think this is just a matter of misunderstanding / not enough background provided in the issue summary.

I think it may be a terminology language. Should it be called the 'Default (content) input language' and 'Default (content) display language'

Language negotiation is used to determine interface display language, content display language, and depending on content type configuration possibly content creation language. Therefore we are not qualifying this setting with "content" or "input" or "display" because configuration in the respective places makes it behave one way or another. This is just a general service of language selection that other systems use.

Also, why would you configure those in two different places? It looks like they are in different tabs. Wouldn't it make more sense to have them in one place?

The site default language has very far reaching consequences. The reason we intend to separate that from the language used in negotiation is now better explained in the issue summary with examples.

Adding images to use in issue summary as well.

Updated summary

Assigning to Dries since he did the review and has potential complaints. I think these are resolved with the better explained rationale and up to date screenshots in the issue summary.

Hopefully, this patch can get in before feature freeze, and this follow-up can take care of the remaining concerns after Dec 1. #1803638: Improve default language change process (ui and help text)

updated steps to test:

get site setup with patch in your favorite way

501 git checkout 8.x
503 git reset --hard
505 git pull --rebase
510 curl -O http://drupal.org/files/language_fallback_1776166_39.patch
511 git checkout -b language_fallback_1776166_39
512 git apply language_fallback_1776166_39.patch
515 drush -y si --account-name=admin --account-pass=admin --site-name=d8-patch-language_fallback_1776166_39 --db-url="mysql://root:root@localhost/d8-patch"
518 drush -y en translation locale language

test the patch

1. clear cache at admin/config/development/performance or > drush cc all
2. add some languages at Configuration -> Languages admin/config/regional/language
3. add a couple languages and make one the default so it will start indexing strings to translate (I added spanish and german and made german the default)
4. translate the Home string so can see effect of changing site language by clicking on the 0% link in the interface translation column of admin/config/regional/language, type Home in the string contains field and click filter. I translated Home to HomeSpanish in Spanish, and HomeGerman in German.
5. uncheck the url method to simplify testing at Configuration -> Languages -> Detection and Selection /admin/config/regional/language/detection
6. observe the Home in the ui is HomeGerman since the language detection is using the site default and the site default is german http://drupal.org/files/dl-s01-2012-10-04_1344.png
7. edit the article content type and unhide the language selection at Structure -> Content types -> Article -> edit /admin/structure/types/manage/article in the Language settings vertical tab. Observe the Default language drop down is "Site's default language" and also uncheck Hide language selector and save
8. Add content -> Article /node/add/article and note the Language drop down has the default value German (the site's default language)
9. change the selected language at Configuration -> Languages -> Detection and Selection, click configure in the Selected language row /admin/config/regional/language/detection/selected http://drupal.org/files/dl-s02-configureselectedlanguage-2012-10-04_1358... change to spanish http://drupal.org/files/dl-s03-spanish-2012-10-04_1359.png
10. reload the node add form: Add content -> Article /node/add/article and see the ui has HomeSpanish as that is the selected language but the Language of the node to be created defaults to German (the site default langage) this is as expected in the situation where a working site needs to change it's user interface language, and does so by configuring the selected language in the detection and selection tab http://drupal.org/files/dl-s04-diffsitedefault-diffselectedlang-2012-10-...

From the screenshots, it still isn't clear what the difference is between default language and selected language. Maybe it is just me, and this patch is RTBC. Is this clear to others?

@Dries I think you were close in #41 with "Should it be called the 'Default (content) input language' and 'Default (content) display language'? " But I think there are some finer points that we can spell out in the follow up.

As I understand it, without this patch, in core, to change the default interface display language,
http://drupal.org/files/DefaultBefore.jpg (the before pic in the summary) the site default language needed to be changed. And that would change "too much" about "other stuff" like the translation process.

Now, with the patch, the interface can have a different default language (detected language), and it can be changed on a working site, without messing up the translation process.

Comments #27, #28, #29 have other ways of phrasing it.

And the text on the detection and selection tab also has words to explain what it will effect (that is different from the site default language). http://drupal.org/files/dl-s01-2012-10-04_1344.png It uses phrases like: "display page elements", and "user interface text".
The whole text on that page is:
"Define how to decide which language is used to display page elements (primarily text provided by Drupal and modules, such as field labels and help text). This decision is made by evaluating a series of detection methods for languages; the first detection method that gets a result will determine which language is used for that type of text. Define the order of evaluation of language detection methods on this page.
User interface text language detection
Order of language detection methods for user interface text. If a translation of user interface text is available in the detected language, it will be displayed." (copied here for easier cut and paste and accessibility to a wider audience, cause it's hard for some people to look in an image)

@Dries: I'm not 100% clear on your question:

1. The patch *removes* the default language negotation and adds in the *selected language* negotiation instead so "what's the difference between them" in this context will not come up since only the selected language negotiation will be available.

2. As for the selection of languages themselves, if you pick a concrete language, it will stay there, if you pick the "site default language", it will keep following any changes you make to the site default (that is it will be an indirection to use that setting as set at any time instead of being a concerete language). This makes the change backwards compatible and also easier to set up. When you add more languages and pick a default language on setup, you don't need to go around and make the change at multiple places.

3. A very similar setup is possible for content type language assignment per content type where the same concrete language + special languages combination exists with the 'site default language' being the default setup following the site default language the same way. Same rationale applies there, it is set to site default by default, so it follows any change in site default language, but it can be set to a concrete language as desired per content type.

Any suggestions to make this clearer? We are trying to use this as a pattern on content types (soon on vocabularies), the site language negotiation settings, etc. Since we are using this same pattern elsewhere, I think it looks pretty straightforward. Any suggestions for improvement?

More background: Gabor pointed out to me an example for the settings on the Detection and Selection effecting more than strictly just the interface language. Since during content creation, the language selector can pick up and use the current interface language as the language the content is being created in.

Also, distilling a conversation from irc: there are some things (like site name, maybe others like stuff to do with views or contact forms) that right now, dont have language selectors/cannot be translated. It would be good to try and get some improvement in those areas... before feature freeze. But, more to the point: since it's not known how much progress we can get in that and other areas of translation, it's not useful to describe exactly (in the help text) the current state since hopefully that will change between now and feature freeze. And thus, that should be a clean up task.

I regularly create multilingual sites so that Goba asked me on #drupal-i18n to go through on this issue. I don't know this issue before but the interface and the functionality is clear for me after the first read.

I have suffered the problem of changing the default language in a production multilingual site. IMHO this is a great improvement in #DX and the advice about the side effects when switching the default language is pretty clear to me.

#39: language_fallback_1776166_39.patch queued for re-testing.

So, coming into this fresh...

1) With the "Before" image in the issue summary, the problem this issue is trying to fix seems pretty clear to me. You want the flexibility to change the site's fallback language, after it's already been set up in a different language (it took YesCT and I a few minutes on IRC to come up with a valid use case, but we can imagine one is that you set the site up in your own native language but want to make it live now for your client, whose users are primarily $languageX). Currently it's not possible to configure these values independently, and changing the site default language is apparently a Really Big Deal.™

2) The solution outlined is two-fold: 1) to change the label on this negotiation method to "Selected language" instead and 2) to make that selected language default to "Site's default language," as other places in core (e.g. content types) do as well. So the end result is the same; the difference is now you could set this to French if your English company gets bought by a bunch of Québeçoises. :)

I didn't really have trouble understanding this interaction, myself. Though to back Dries up, I did find a couple of things odd:

- I agree that it's really strange for this setting and the site default language to be so far apart from one another; ideally we'd handle this in a similar way to how we do site theme vs. admin theme configuration; all in one place. (Dries said this too in #41.)
- I also find it really strange that while there is a cautionary boogeyman tale in the Selected Language screen about switching the default language causing baby kittens to cry (ok, ok, not that bad ;)), there is no such language at all on the screen where you actually can change the default language (depicted at http://drupal.org/files/config-lang-2012-09-14_2249.png)

YesCT advocated handling these in follow-up issues, however, since the help text and UI perfection could happen a lot better after feature freeze, when we know what all features we have to unify and document. That actually sounds pretty reasonable to me. But leaving RTBC and assigned to Dries to see what he says.

Updated issue summary.

added follow up issue explanation to summary

Updated the issue summary to include info about the follow up issue and why it's a follow up and not part of this patch, also added some words to clarify that the configure link in the before and after images went to different destinations.

@webchick: your observations are pretty good :) Let me react to a couple only:

I agree that it's really strange for this setting and the site default language to be so far apart from one another; ideally we'd handle this in a similar way to how we do site theme vs. admin theme configuration; all in one place. (Dries said this too in #41.)

The configuration for language selection affects how the interface language is picked, and depending on configuration might affect how new content is created or content is displayed. While part of language negotiation might be tied to the default language, content creation might be tied to the default language, etc. these are independent settings. Eg. if you look at #50, content creation has configuration to either take its value direct from the site default, or direct from the output of language negotiation or direct from the user setting or tie to a specific language.

So the overall site default is input to many things on the system. Some don't have specific settings. Such as when you enter the site name, its assumed to be in the site default. It is an optional input to the language negotiation system in that this patch makes it configurable to tie negotiation to another language. That is, this patch makes negotiation LESS tied to the default language, not more, so I don't think moving their settings closer together is a good idea. Language negotiation does not decide which language your site name is saved with, but the default language does. It has more far reaching consequences. That is why we want to make things independent of it, when possible, so changing/setting it is not an all or nothing operation. We want things to have independent knowledge of language as possible. So independent settings for them makes more sense.

I also find it really strange that while there is a cautionary boogeyman tale in the Selected Language screen about switching the default language causing baby kittens to cry (ok, ok, not that bad ;)), there is no such language at all on the screen where you actually can change the default language (depicted at http://drupal.org/files/config-lang-2012-09-14_2249.png)

Yes, I strongly agree we should do something about warning people that changing the default language might be dangerous. At this point, we don't really know how far we can get with introducing specific language information to pieces of the site. In an ideal world, you could enter language information with every piece of content/config (such as when entering the site name). It is unlikely that we reach to all content/config pieces, and when we have a better picture of how far we got we can re-asses the level of danger caused by changing the default language which would inform what kind of feedback should the user get when trying to change and/or how hidden should we make this setting to discourage people from touching it. I don't think we have good information now as everything is moving and we are introducing language information to various things at once.

I hope this makes things clearer and would help this patch being committed sooner than later.

OK, I went ahead and committed this patch. It seems like it is an important and everyone (but me) seem to understand how it works. If necessary, we can follow-up with UX improvements later.

Added a change notice at http://drupal.org/node/1808518