The negotiated method_id does not need to be sorted on the Language or ConfigurableLanguage object.

It a howler when you see it. Simple to fix.

Actually there is no need to set method id on the language and in fact we probably should not since languages are what is negotiated and the method is what is use to do the negotiation - it's not really a property of the language at all. It's a state of the languageNegotiator - i.e. what method have been used to negotiate which languages.

Patch attached removes the method_id property from both Language and ConfigurableLanguage and adds a method to LanguageNegotiator to retrieve the current state.

+++ b/core/modules/language/src/HttpKernel/PathProcessorLanguage.php
@@ -110,7 +110,6 @@ public function processOutbound($path, &$options = array(), Request $request = N
     if ($this->multilingual) {
-      $this->negotiator->reset();
       $scope = 'outbound';

I'm not 100% certain about this change - obviously we don't have test coverage for it since the patch is green but the patch attached moves stuff around so you can get the negotiation method from the ConfigurableLanuageManager. This feels correct since it is responsible for integrating all the language subsystems. This means that the negotiator remains resettable.

I agree with the goals, the language indeed does not have anything to do with how it got to be born :) AKA the negotiator. But we need it for at least testing that it works right and possible for other reasons in the future. I have concern with the implementation though.

+++ b/core/modules/language/src/ConfigurableLanguageManager.php
@@ -204,7 +204,7 @@ public function saveLanguageTypesConfiguration(array $values) {
-      $this->negotiatedLanguages[$type] = $this->getDefaultLanguage();
+      $this->negotiatedLanguages[$type][LanguageNegotiatorInterface::METHOD_ID] = $this->getDefaultLanguage();

@@ -224,7 +224,7 @@ public function getCurrentLanguage($type = LanguageInterface::TYPE_INTERFACE) {
-    return $this->negotiatedLanguages[$type];
+    return reset($this->negotiatedLanguages[$type]);

@@ -453,4 +453,15 @@ public function getStandardLanguageListWithoutConfigured() {
+  public function getNegotiatedLanguageMethod($type = LanguageInterface::TYPE_INTERFACE) {
+    if (isset($this->negotiatedLanguages[$type])) {
+      reset($this->negotiatedLanguages[$type]);
+      return key($this->negotiatedLanguages[$type]);
+    }
+  }

While it is a neat trick to store the method ID on an array element, this array will only ever contain one element, so the array nesting is used to store metainfo on how the negotiation got the value. Why not store it in another property of the configurable language manager for each type? Sounds less nifty tricks but maybe easier to understand?

How about something like this. I'm keen to keep LanguageNegotiatorInterface::initializeType($type) returning an array since this means the typehint works. And anything else that uses it can get the method id just as easily.

That looks better, thanks. As for your concern on the change in #4, you are not making that change anymore in recent patches? I am not sure why it was added/removed? :)

In the changes from #3 to #4 I moved stuff to the LanguageManager from LanguageNegotiator so yep no longer a concern.

All good with me then, thanks!

I can see a minor snafu by running this patch through a lint checker...

Method 'getNegotiatedLanguageMethod' not found in class

from this code in language_test.module

drupal_set_message(t('Language negotiation method: @name', array('@name' => \Drupal::languageManager()->getNegotiatedLanguageMethod())));

From the annotations in Drupal.php the return from \Drupal::languageManager() is a \Drupal\Core\Language\LanguageManagerInterface object
and not \Drupal\language\ConfigurableLanguageManagerInterface

@martin107 that's not really a snafu - the ConfigurableLanguageManger implements LanguageManagerInterface as well as ConfigurableLanguageManagerInterface but \Drupal can only be sure that it returns a object that implements LanguageManagerInterface. There is no way of changing \Drupal return types if a module is enabled that replaces a service that is returned by \Drupal and extends the original interface. That is exactly what the language module does.

@alexpott thanks for the update

Should still be rtbc.

I agree :)

And thanks @YesCT - I didn't know about that update to the standard.

Committed/pushed to 8.0.x, thanks!