This is the D7 backport initiative for #1294946: Language detection based on session doesn't work with URL aliases.
I wanted to give it it's own issue so that it doesn't clog up the d8 initiative that is currently going. Please see the other ticket for the specifics:

The following was copied and pasted from the original ticket.

Problem/Motivation

- Path module doesn't take into consideration the language when using session for detection, when using url prefix it works.
- Translation switch links in node's view doesn't output the alias of the translated nodes, it just print a plain url (e.g. node/3 instead of node/alias)

Steps to reproduce

Add a language, e.g. Spanish (es), detect the language using session.
Add a node, translate it, and set the translated node alias to something 'foo'
View the original node, the href of translated node link appears without the alias (e.g. node/2).
Try manually to go to 'foo', doesn't work.

Proposed resolution

- Allow Path module to detect the language from the global $language variable instead of $language_url
- Edit translation_language_switch_links_alter() to make it use url() instead of forming hard coded url.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

generalredneck’s picture

Issue summary: View changes
generalredneck’s picture

Issue summary: View changes
generalredneck’s picture

Here is my first wack at it with no tests. It's strictly based off of https://drupal.org/node/1294946#comment-5375646

Status: Needs review » Needs work

The last submitted patch, 3: d7-language_detection_based_on_session-2156113-3.patch, failed testing.

The last submitted patch, 3: d7-language_detection_based_on_session-2156113-3.patch, failed testing.

Hilari’s picture

You can create a module for custom language negotiation (for alias lang):

function mymodule_language_negotiation_info_alter(&$providers) {

$providers['locale-mymodule-custom']['callbacks']['language'] = 'mymodule_negotiation_custom';
$providers['locale-mymodule-custom']['file'] = drupal_get_path('module', 'mymodule') . '/mymodule.module';
$providers['locale-mymodule-custom']['name'] = "Alias negotiation";
$providers['locale-mymodule-custom']['description'] = "Custom Alias negotiation";
$providers['locale-mymodule-custom']['weight'] = -10;

}

function mymodule_negotiation_custom($languages) {

global $base_path;
$ruri = $_SERVER['REQUEST_URI'];
$ali = str_replace($base_path, "", $ruri);
$ali = urldecode($ali);
$lang = mymodule_language_getlangbyalias($ali);
if ($lang == false) $lang = "en"; // Default lang

return $lang;
}

function mymodule_language_getlangbyalias($alias)
{
$args = array(':alias' => $alias);
$result = db_query('SELECT language FROM {url_alias} WHERE alias = :alias',$args);
$lang = $result->fetchField();
return $lang;
}

coderintherye’s picture

Patch successfully allowed me to use the language session variable (via url ?language=) to provide the proper foreign language content at the same URL alias as the english language content.

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 3: d7-language_detection_based_on_session-2156113-3.patch, failed testing.

gambry’s picture

I confirm the patch works against 7.41.

However it works only if Session method is active on "User interface text language detection", with or without activating it on "Content Language detection" too.

othermachines’s picture

The patch in #3 seems to work as advertised, solving a large part of the problem. However paths provided on the content overview page at admin/content may still lead to a 404.

The following all works fine when language detection is set to URL (for both UI and content):

Languages: en (default), sv

1. View site in default language (en)
2. Create new node, setting language to Swedish (sv)
3. Go to admin/content
4. Click node title

You will be taken to the node view at sv/whatever-the-alias (language prefix is prepended)

However, if you do the same thing with language detection set to SESSION, you will be taken to whatever-the-alias (no language parameter appended) resulting in a 404.

Mind you, without this patch I also get a 404 when I'm viewing the site in Swedish, so this is a major improvement!

So it seems to me that a complete fix would also involve generating a language-appropriate URL when needed (as is done with URL-based detection), not just generating language-appropriate content based on the URL. If that makes any sense. This probably also applies to D8, although I haven't tested it there.

I'm not sure what the fix is, but my guess is this would require a change to locale_language_url_rewrite_session(). If I understood why URLs there are being appended with the language parameter only for anonymous users I might be more confident about suggesting a fix. At it stands I have no idea.

My workaround in the interim is to only generate language neutral aliases (not ideal).

I am using entity_translation and pathauto, if it matters.

Thanks!