Hello,
On a multilingual site I see that the local tabs menu fragment link looks like authcache.php?a=&r=frag/menu-local-tabs&o[q]=node/552&v=yz4h13 and that makes the menu to be always served in the same language.
Since the cache granularity is Per user, Per page I was expecting the link to be something like authcache.php?a=&r=frag/menu-local-tabs&o[q]=[current-node-language]/node/552&v=yz4h13
Am I doing something wrong or this is the default behavior?
Thanks!
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | add_language_prefix_to-2754707-5.patch | 1.04 KB | znerol |
| #3 | Screenshot from 2016-06-27 00-00-24.png | 154.26 KB | gge |
Comments
Comment #2
znerol commentedWhat mechanism do you use to determine the users language?
Comment #3
gge commentedSorry for the late reply
I'm using entity translation and the screenshot attached show the "Detection and selection" settings. The local tabs always show English language.
Thanks!
Comment #4
znerol commentedI am able to reproduce. This looks a bit like a regression since I remember that this was working at some point: #1967694: ajax block in multilingual site.
Comment #5
znerol commentedI did assume that
$_GETis left unchanged, and thus it is possible to collect the original request parameters from there. Regrettably that it is not the case. E.g., the language prefix is stripped from$_GET['q']in locale_language_from_url. Therefore it is necessary to add back that prefix when generating URLs for fragments.@gge: Would you mind testing the attached patch and report back whether it resolves your particular problem?
Comment #6
gge commentedTested it and problem solved.
Now the local tab language switches according to the node language and the cached fragment url does contain the language (
authcache.php?a=&r=frag/menu-local-tabs&o[q]=[current-node-language]/node/...)In my opinion the patch should be committed. Thank you very much for your help!
Comment #7
znerol commentedComment #9
znerol commented