It would appear there is a use-case where the function locale_language_url_rewrite_url() produces an improper URL.
When working with domain specific (LOCALE_LANGUAGE_NEGOTIATION_URL_DOMAIN) URLs for language negotiation which are nested in subdirectories, so for instance, if we have drupal rendering behind something like this:
we run into a problem if the locale modules setting for USER INTERFACE TEXT LANGUAGE DETECTION method is enabled for URL.
Due to a hardcoding of the base url within the function locale_language_url_rewrite_url(), these lines...
$host = 'http://' . str_replace(array('http://', 'https://'), '', $options['language']->domain);
$host = parse_url($host, PHP_URL_HOST);
// Apply the appropriate protocol to the URL.
$options['base_url'] = $url_scheme . $host;
...which dictate what the new base_url shall be, are overwriting the URL path. Should the site be using the global setting $base_url, the value is ignored, the paths are forced to render incorrectly and the rest of the site will generate HREF from the base HOST url and send the user in the wrong direction when navigating links.
The following edit to locale.inc corrects this and ensures the global value is used:
// Let's check the $base_url and add it to the path if it exists.
global $base_url;
if (isset($base_url)) {
$base_path = parse_url($base_url, PHP_URL_PATH);
if ($base_path) {
$options['base_url'] .= $base_path;
}
}
I've included a patch file in case this can make it upstream.
Hopefully you find this useful and compelling to help solve a fringe use-case.