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.
Remaining tasks
Write a test to show how it failed to request a path alias for translated node when using session to detect the language, and to show how translated links are not using aliases.
User interface changes
None.
API changes
None.
Original report by [username]
Vapes
Comments
Comment #1
walkah CreditAttribution: walkah commentedJust a quick note that I'm seeing this as well. It seems to be an issue with content translation other pages (views, etc) switch languages just fine.
URL detection (both path and subdomain) seem to work.
Comment #2
Countzero CreditAttribution: Countzero commentedJust filled a bug in the Entity Translation queue about this : http://drupal.org/node/1345716
Not sure if I should have filled it here instead, so cross linking.
Comment #3
Countzero CreditAttribution: Countzero commentedI can confirm this bug is still present in 7.10, and is not related to ET.
Steps to reproduce :
- Enable Entity and Entity Translation
- Set the detection method to Session
- Create a node and give it an alias
- Translate it and give the translation an alias
No version of the node is accessible via its alias, not even the one in the original language.
I could try to investigate this if I had a hint about the code involved, which I'm trying to find by myself at this very moment.
Comment #4
plachThe process starts at:
http://api.drupal.org/api/drupal/includes--bootstrap.inc/function/drupal...
Session language is detected at:
http://api.drupal.org/api/drupal/includes--locale.inc/function/locale_la....
Hope this helps :)
Comment #5
good_man CreditAttribution: good_man commentedI wrote a patch that solve this, but first I want to write a test that detect this bug, otherwise the patch won't be committed :) Any one can confirm it on D8?
Comment #6
plachThe D8 language negotiation code is almost identical to the D7 one so this bug should be present in D8 too.
Comment #6.0
good_man CreditAttribution: good_man commentedPut the details into template.
Comment #7
Countzero CreditAttribution: Countzero commentedgoodman, I'd be more than happy to give your patch a try.
Besides, I hereby withdraw from the hunt on this bug, as work seems to already be done.
Comment #8
good_man CreditAttribution: good_man commentedI think this is related #269877: path_set_alias() doesn't account for same alias in different languages although I didn't read it fully yet.
Comment #9
good_man CreditAttribution: good_man commentedA patch passing the test case.
Comment #11
good_man CreditAttribution: good_man commentedPatch in #8 meant to be failed, but in #9 not. So it needs a new patch for the failed test in path module.
Comment #12
Countzero CreditAttribution: Countzero commentedI tried to apply the changes manually to 7.10 and it doesn't seem to work : still got the 404 on every version of the node, including original.
Comment #13
good_man CreditAttribution: good_man commentedfrom path.test:
hmm not sure why path module has to determine the language based only on $language_url. In this case (user preference) and the issue's case (session), they both write the language to $language (so does the url detection). So why not using $language instead of $language_url? In this case we need to edit this comment and path test case.
Comment #14
good_man CreditAttribution: good_man commented@Countzero: are the steps you did the same of this issue? take a look into url aliases (if you enable path module go to URL Aliases page) check the alias(es) you have for this node, make sure they have the right language/path, then try again with the patch.
Comment #15
Countzero CreditAttribution: Countzero commentedYes, the languages and aliases are OK, as they were before applying the modifications.
Please see attachment to check.
Comment #16
plachURL aliases are not tied to the interface language, their language is determined only by their prefix, i.e. what the URL method looks for.
If your UI language is french, you are visiting a URL like
http://example.org/it/contenuto
, and french is used to look up an alias you will get a 404, since no french alias exists for the path'/contenuto'
.Session and URL methods are mutually exclusive wrt URL rewriting, so using Session language for aliases only makes sense when there is no prefix or domain information, e.g.:
http://example.org/contenuto?language=it
The responsible for initializing URL language in this case is http://api.drupal.org/api/drupal/includes--locale.inc/function/locale_la....
Comment #17
Countzero CreditAttribution: Countzero commentedMy bad : the aliases definitely work, but I had to add the session variable to the URL.
My apologies for the crappy testing feedback.
So, good_man's patch above works, in a way.
But I understand that as of now, there's no way to access an aliased translation with session based negociation. So there's work left on the issue, right ?
Comment #18
good_man CreditAttribution: good_man commentedYou can click either on the translated link shown at the bottom of the original node, or enable the language switcher block (from blocks page) and click on different links on it when viewing a node, so for example if you are viewing an English node, and you click French, Drupal will redirect to the French version of this node. Hope this help answers your question.
@plach: What do you think about the question I raised in #13? should we rely on $language variable everywhere? as it holds the current language in different scenarios better than $language_url.
Comment #19
Countzero CreditAttribution: Countzero commentedWell, in fact, no, it doesn't answer my question.
I don't want to spam this issue, but to make it short, my use case doesn't fit with these functionalities : I need the nodes to be accessible via their legacy URL, which lead to static files before the site was ported to Drupal. I think it's one major reason for using the session based negociation : keeping URLs as they are, and being able to access any page directly in any language.
Besides, I think it was (at least one of) the point(s) raised by the OP. Whatever the implementation is as of now, as soon as the translations are aliasable, one expects to be able to access them directly via their alias, without messing with other stuff.
But perhaps it's more of a feature request than a bug report, this I leave to your judgment.
Comment #20
plach#16 was exactly an answer to #13: we cannot use $language for the reasons explained there, what if also $language_content is configurable (i.e. it may differ from $language)? Should we use content or UI language to lookup URLs? There is no right answer, probably it depends on the use cases.
What we can do is fixing $language_url in case no prefix or domain is present: currently in this case the default language is returned, this is correct only when the URL language method is enabled (which is the check we are missing in locale_language_url_fallback), otherwise $language is a sensible fallback.
Yes, I was not arguing against this, see the last example in #16.
Edit: fixed typos all around.
Comment #21
Countzero CreditAttribution: Countzero commentedYes, I know, I was answering good_man.
The function you point in #16 doesn't know about the entity concerned. It just checks the environment variables.
For the functionality we're talking about, the entity translation language trying to be accessed via the current path has to be checked in a way or another.
Here's the result of my poor tries.
I added the folowing code in locale_language_url_rewrite_session :
Requesting the page with the alias only (in the form "www.thesite.com/index-EN.html) correctly outputs the formatted URL in the messages area, but doesn't change the actual page URL, for a reason I didn't understood yet.
Am I on the right track ?
Comment #22
plachThis one might work, let's ask the bot.
Comment #23
plachComment #25
Countzero CreditAttribution: Countzero commentedFor people like me who don't really understand the insides of core path management, here is a probably very bad workaround which I'll use on a demo site :
It's probably a very bad thing to do, but it works so far. Mean : it retrieves the node with the alias entered in the address bar and appends the session language variable with the correct value from the real node's translation.
So, if http://thesite.com/my-alias-to-russian-node is the page requested, and given the corresponding node's translation alias is the russian version, the redirect will lead to http://thesite.com/my-alias-to-russian-node?language=ru.
Hope it can help some until this issue is solved.
Comment #26
timofey CreditAttribution: timofey commentedHere's another very, very important related issue.
An aliased URL with a language prefix does not return content.
If you translate body & title fields of a node, using Entity Translation module, both languages will be sharing the same NID. So if I created content in 'en', and translated into 'ru', 'de', 'es'.... I will not be able to access content through ru.example.com/aliaseduri/abc, de.example.com/aliaseduri/abc, es.example.com/aliaseduri/abc... but en.example.com/aliaseduri/abc works. That is because drupal_path_initialize() grabs aliased url by uri and language.
As a temporary fix, I insert this
$path_language == 'ru' ? $path_language = 'en' : '';
into include/path.inc right under
$path_language = $path_language ? $path_language : $language->language;
But it only fixes the problem if the node was originally created in 'en'...
I hope I made sense!
Comment #27
Gábor HojtsyTagging for base language system.
Comment #28
Gábor HojtsyTagging for language negotiation too.
Comment #29
fenda CreditAttribution: fenda commentedAny progress with this?
Comment #30
cweagansFixing tags per http://drupal.org/node/1517250
Comment #31
Gábor HojtsyPut on the sprint as an interesting and well located bug :)
Comment #32
ygerasimov CreditAttribution: ygerasimov commentedHere is rerolled patch with test only
Comment #33
sxnc CreditAttribution: sxnc commentedComment #35
Kristen PolI assume the "1" in "t1est" is a typo?
Same... I assume the "1" in "t1est" is a typo?
One more... I assume the "1" in "t1est" is a typo?
Nothing else is jumping out at me ;)
Comment #36
ygerasimov CreditAttribution: ygerasimov commentedYes, sorry guys. Adding 1 in the name of functions was just way to run only one test case. This should be removed.
Comment #37
vasi1186 CreditAttribution: vasi1186 commentedAttached a patch that just removed the 1's in the previous one.
Comment #39
Kristen PolI didn't notice this before, but to be nit-picky, "english" should be capitalized.
I went through all the comments and code and it seems pretty understandable although I don't know much about simpletest.
Comment #40
webflo CreditAttribution: webflo commentedFixed the typo from 39 and rerolled 22.
Comment #42
Kristen PolThis looks good to me. It needs more people reviewing though.
Comment #43
marcusx CreditAttribution: marcusx commentedAs far as I can tell #22 won't fix it.
Patch with test, typo from #39 fixed and a new fix.
-> triggering bot
Comment #45
marcusx CreditAttribution: marcusx commented#43: core-fix_aliased_lang_switcher_links_with_session_negotiation-1294946-43.patch queued for re-testing.
Comment #46
marcusx CreditAttribution: marcusx commentedStarted tests that were ended with "Fatal Error" locally with no problems.
Trying to retest.
Comment #48
lazysoundsystem CreditAttribution: lazysoundsystem commented#40 was working except for the 'translated node switch' test.
Turns out this was looking for the link to 'Español', but the test doesn't install the .po file, so the link text remains 'Spanish'.
With this change tests are passing (locally, at least).
Comment #49
lazysoundsystem CreditAttribution: lazysoundsystem commentedComment #51
lazysoundsystem CreditAttribution: lazysoundsystem commented#48 fixed the Translation test, but it's still failing the Path and Locale tests. I'm checking those now.
Comment #52
marcusx CreditAttribution: marcusx commentedSo here is a new patch from todays work at the #D8MI Sprint. We couldn't finish it as people had to leave but we are on a good way.
The language tests are woking now. And we have the desired behaviour. But now two other tests are broken - we need to look into this a little more.
Comment #53
marcusx CreditAttribution: marcusx commentedLets check if the testbot brings the same results than we got locally.
Comment #55
marcusx CreditAttribution: marcusx commenteddamm it, on my local installation only the comment tests where broken. I don't get it. :-(
Comment #56
Gábor HojtsyThis is a regular bug that is not subject to new feature development as far as we found so far, so I don't think I should keep pointing people to this vs. other things that are feature freeze blockers. Therefore removing from sprint.
Comment #57
jair CreditAttribution: jair commentedNeeds reroll
Comment #57.0
jair CreditAttribution: jair commentedes == Spanish.
Comment #58
generalredneckI've started the d7 backport initiative for this problem over in #2156113: D7: Language detection based on session doesn't work with URL aliases so that there won't be version switching in this issue.
Comment #59
alansaviolobo CreditAttribution: alansaviolobo commentedre-rolled the patch.
Comment #60
alansaviolobo CreditAttribution: alansaviolobo commentedComment #62
sdelbosc CreditAttribution: sdelbosc commentedSorry if I introduce some confusion here but I wonder if there is any good reason to not have a simpler language_url_fallback() function.
I was thinking of something like this:
Any thoughts?
Comment #63
mgiffordThis still a concern in D8? Unassigned issue too.
Comment #64
kostyashupenkoRe-rolled language_detection-1294946-59.patch for v-8.0.x-dev
Comment #70
donquixote CreditAttribution: donquixote commentedComment #73
casivaagustin CreditAttribution: casivaagustin commentedTo implement a workaround in this issue I have implemented a link_alter hook, if there is a language option in the link variable I move the option to the query string so the session change the language and the editor will work.
Attached is a demo of the functionality working.
Comment #74
david.qdoscc CreditAttribution: david.qdoscc commentedI am still experiencing this issue in Drupal 8.8.1
Comment #76
catchMarking duplicate of #1125428: Language-specific aliases only work with url-based language negotiation.
Comment #77
octopus1 CreditAttribution: octopus1 as a volunteer commented#74 I tested with drupal 8.8.4 and I think there is still a prob:
this is what i tested:
Having URL(prefixes) language detection and negociation method, I create a node with the default site language (en), when trying to acces the translated node in frensh (prefix fr-FR) I got an URL with no prefix, and it shows the default site language's node content. Is there a fiw to this prob ?