Code never executes in language_initialize(), creates ambiguity regarding design choice of language logic

I don't understand the logic behind the implementation of the site-wide language negotiation setting vs. user-specified language preference setting. In my opinion, the help text seems to indicate that the user has some option of enforcing a language for the interface, but according to keith, the language is limited only to site e-mails.

I'm trying to clear the confusion by looking at the code.

This is the language_initialize() function taken from language.inc. I have broken it in smaller blocks and provided my interpretation of the code:

/**
 *  Choose a language for the page, based on language negotiation settings.
 */
function language_initialize() {
  global $user;

  // Configured presentation language mode.
  $mode = variable_get('language_negotiation', LANGUAGE_NEGOTIATION_NONE);

This retrieves the language negotiation mode, which should be an integer from 0 to 3 corresponding to the four choices defined in bootstrap.inc.

In case no setting for this value was found, the default value of LANGUAGE_NEGOTIATION_NONE is used. This is the usual path, since the variable language_negotiation doesn't exist on a fresh Drupal 6 install.

  // Get a list of enabled languages.
  $languages = language_list('enabled');
  $languages = $languages[1];
  
  switch ($mode) {
    case LANGUAGE_NEGOTIATION_NONE:
      return language_default();

This case statement ends the execution of the function and returns the default language specified for the site. I see this as a very deterministic phase: now we have the language, nothing to do here anymore, so let's exit and use this language. And this is the part that will be executed always, when no negotiation setting has been set. (I'm starting to repeat myself...)

In the case some other negotiation mode is selected, the appropriate processing will be done:

    case LANGUAGE_NEGOTIATION_DOMAIN:
      foreach ($languages as $language) {
        $parts = parse_url($language->domain);
        if (!empty($parts['host']) && ($_SERVER['SERVER_NAME'] == $parts['host'])) {
          return $language;
        }
      }
      return language_default();

    case LANGUAGE_NEGOTIATION_PATH_DEFAULT:
    case LANGUAGE_NEGOTIATION_PATH:
      // $_GET['q'] might not be available at this time, because
      // path initialization runs after the language bootstrap phase.
      $args = isset($_GET['q']) ? explode('/', $_GET['q']) : array();
      $prefix = array_shift($args);
      // Search prefix within enabled languages.
      foreach ($languages as $language) {
        if (!empty($language->prefix) && $language->prefix == $prefix) {
          // Rebuild $GET['q'] with the language removed.
          $_GET['q'] = implode('/', $args);
          return $language;
        }
      }
      if ($mode == LANGUAGE_NEGOTIATION_PATH_DEFAULT) {
        // If we did not found the language by prefix, choose the default.
        return language_default();
      }
      break;
  }

Lot's of "returns $languages;", as if all cases would be covered?

Actually, no.

If none of the above conditions (yes, there are more of them!) is met, the function still continues with these lines:

  // User language.
  if ($user->uid && isset($languages[$user->language])) {
    return $languages[$user->language];
  }

  // Browser accept-language parsing.
  if ($language = language_from_browser()) {
    return $language;
  }

  // Fall back on the default if everything else fails.
  return language_default();
}

This was the interesting part, since I don't see when the execution is supposed to get to this last part:

  if ($user->uid && isset($languages[$user->language])) {
    return $languages[$user->language];
  }

I would really like that Drupal just execute this block. Now the whole function seems to be coded as if this section is not meant to be executed at all. Or is it? I don't know. It's confusing -- exactly like the help text for the setting.

By looking at the code, it looks like I am supposed to cheat by inserting any value NOT listed in the case blocks:

UPDATE variable SET value = 's:2:"-1";' WHERE name = 'language_negotiation';

To make it cleaner, I would create a new constant:

define('LANGUAGE_NEGOTIATION_REALLY_NONE', -1);

.. and make a proper case block in language_initialize() to handle this.

In my opinion, this should be classified as a bug, not a user interface text issue. And definitively not something to be pushed to 7.0.