Wrong url-language negotiated when the user has an admin-language

Problem/Motivation

When the language is negotiated via a user-preference and url-prefix, and the user sets an administrative language, the LanguageInterface::TYPE_URL language-type seems to be negotiated to the sites default-language.

The most visible result is that when accessing the site via eg. /da/page1 (da being the url-prefix for Danish) - the main-menu on that page, is rendered with /en/ prefixes.

Steps to reproduce:

1. Install a english site with the standard profile
2. Enable the language module
3. Access /admin/config/regional/language and add a language (eg Danish)
4. Access /admin/config/regional/language/detection and enable "Account administration pages"
5. Configure the URL detection to use /en as prefix for english
6. Add an article and enable "Provide a menu link" so that a link is added to the Main Menu
7. Access /en and verify that the main-menu tabs on the front-page links to the article with a /en prefix
8. Access /da and verify that the main-menu tabs on the front-page links to the article with a /da prefix
9. Edit the users preferences, and set "Administration pages language" to any language (eg danish)
10. Access /en and /da and see that no matter what prefix is used, all menu-links are prefixed with /en (the default language)

In the last step I would have expected no change from the previous visits to the front-page as I have only changed a configuration relevant for the admin-interface. If the preference is set to "No preference" the prefixes behaves normally.

The following code in ConfigurableLanguageManager seems to be the culprit. The first time a language-type is requested, a initialization flag is set and the initialization is begun. As long this flag is set, the sites default language is returned - this seems like a sensible precaution in case the initialization itself requests a language. When the initialization is completed, the temporary value is replaced with negotiated value.

The problem is that this flag affects all language-types so that if another language-type is requested, a "temporary" value is again set - but as we then hit the initialization-flag, it is never overwritten, and is then made permanent.

  public function getCurrentLanguage($type = LanguageInterface::TYPE_INTERFACE) {
    if (!isset($this->negotiatedLanguages[$type])) {
      // Ensure we have a valid value for this language type.
      $this->negotiatedLanguages[$type] = $this->getDefaultLanguage();

      if ($this->negotiator && $this->isMultilingual()) {
        if (!$this->initializing) {
          $this->initializing = TRUE;
          $negotiation = $this->negotiator->initializeType($type);
          $this->negotiatedLanguages[$type] = reset($negotiation);
          $this->negotiatedMethods[$type] = key($negotiation);
          $this->initializing = FALSE;
        }
        // If the current interface language needs to be retrieved during
        // initialization we return the system language. This way string
        // translation calls happening during initialization will return the
        // original strings which can be translated by calling them again
        // afterwards. This can happen for instance while parsing negotiation
        // method definitions.
        elseif ($type == LanguageInterface::TYPE_INTERFACE) {
          return new Language(array('id' => LanguageInterface::LANGCODE_SYSTEM));
        }
      }
    }

    return $this->negotiatedLanguages[$type];
  }

Proposed resolution

A possible solution would be to maintain seperate flags for each language-type. Another would be to return the default-language during initialization straight away, without persisting it if we're initializing. The first approach seems the best.