I have two languages setup, for example EN (English) and FR (French). The language switcher block is enabled with all languages and prefix only setting.
I create english frontpage content with URL alias path: content/welcome
The french content is set to Language = French and the URL alias path: content/bienvenue
I setup the translations for each node linking them together (ie. Translate tab for content/welcome and assign content/bienvenue node as it's translation and vice versa.)
The problem is now when viewing "content/welcome" node, the language switcher link for FR leads to path "node/98" instead of "fr/content/bienvenue" as it should? Anyone know what's wrong??
Thanks in advance!
Comments
Comment #1
skalfyfan commentedThis bug seems to be related to this new feature:
New feature: allow to select existing node as translation, #295682
When choosing an existing node as the translation the language switcher does not retrieve the existing nodes URL alias but uses it's node path "node/XX" instead resulting in no language code preceding the url etc etc.
Comment #2
micheMy experience was similar - but I have a couple more details to add.
node/34 = english = about/what-is
node/35 = french = about/what-is
English is my default language. I create node/34 as language neutral and translatable. I then switch it to English and am now able to create the French node where I assign the same url alias. After I create the French node, it redirects me to node/35. Thinking that the alias didn't get saved, I edit the node - but the alias IS there.
I click around and realize:
mysite.com/about/what-is = node/34
mysite.com/fr/about/what-is = node/35
However, I cannot look at node/35 while in the English language (since it is a French node) and see it with its URL alias.
Unless node/35 is findable from a search (site or google) and displayed in the default language rather than its correct one, only content administrators should see this bug.
NOTE: I am using 6.x.-1.0.
Comment #3
jose reyero commentedComment #4
amazingrandoSubscribing. I have the same problem. Is there a solution?
Comment #5
jose reyero commentedThese path alias are language dependendent, so check each alias has the right language assigned.
If using the same alias for two languages, like in #2, nope, you cannot look at the french node with the same alias while in English language.
So better think about how the system will tell which alias is which, check out your language settings (read carefully the language selection page) and don't try to mix duplicated aliases and languages because it will just not work.
And, in any case, this is Drupal core, not i18n module.
Comment #6
cubeinspire commentedAre you sure there is no bug at the internationalization module? If it's a core related bug shouldn't we move this bug to the core section?
I'm having exactly the same issue and I'm not in the case of #2.
I have internationalization module installed and the language switcher block activated.
The content type "basic page" is set as translatable and all options on user and content language detection are checked.
I have the following content:
node/54 => english => our-projects
node/44 => french => les-projets
There is no duplicated alias string as mentioned on #2 on my database.
When I'm at page "fr/les-projets" the language switcher link with the english flag is pointing to node/44 instead of our-projects.
When I click on translate the page les-projets it say that there is no english translation for it, but when I try to create a new translation and I save it there is a error message saying: "There is already a translation in this language." The exact same situation happens in the node our-projects the interface say it has no translation but when I try to save a new translation there is an error saying there is already a translation.
So there is a problem identifying the corresponding existing trasnlation for a certain node.
Sometimes it detects it (when trying to save the translation) sometimes not (when displaying the language switcher block or trying to display existing translations for that page at fr/node/44/translate but it gives an error when saving the create translation form at en/node/add/page?translation=44&target=en
How to replicate this bug?
Create a new instance of the content type Basic Page and set the language to the default one (French in my case).
Save the node and then click on the Translate link.
Save the English translation and visit the french page.
Navigate through the language switcher links and you will see that at the english translated page the links are wrong in the way explained before.
I solve this issue by deleting the nodes 54 and 44 then creating them again and clearing the cache, but the problem comes back again some nodes later... I hope I will find more details about the exact reason that triggers this bug.
----------------------------------
technical information
Drupal version: 7.23
Internationalization version: 7.x-1.10
Using clean install with profile: bear-7.x-1.x-dev-core
Comment #7
cubeinspire commentedchanging the status
Comment #8
cubeinspire commentedComment #9
jose reyero commented@cube inspire
You tell me, does it happen when enabling i18n module or does it happen without it?
Closing until you can provide an answer to that question.
Comment #10
stimalsina commentedNot directly related to this but I had a similar problem.
I have two languages, English (Default) and Spanish. I had some nodes that did not need translations, but translation was enabled for that content type. The nodes that I had were all marked English. So when I was in the node, the language switcher would show es/node/XX.
The problem was solved making the nodes Language Neutral.
TLDR; If your node does not have translation, better make it neutral to avoid node/xx problem.
Comment #11
joseph.olstadjust fyi, I noticed that the url aliases didn't work correctly when using an older version of php 5.6.x , I think it was between 5.6.17 and 5.6.22 , upgrading to the latest 5.6.x (I think as of today its 5.6.26)
that was on non threadsafe fastcgi version.
so ya upgrading our php from an older 5.6.22 (?) to the latest 5.6.26 (!) solved it for us.