Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.This is so confusing and whilst I've seen the issue reported before I can no longer find it. Anyway I have a site where the default language is English and some of the pages get translated into French.
The multilingual option page is set to "Mixed current language"
So I have nodes with aliases like /section/my-page and these are also available via /fr/section/my-page.
The problem is that once I change the page as being in the English language as opposed to language neutral then the path /fr/section/my-page is no longer valid and gets a 404 error. What I want is to be able to retain the original alias so that it is still accessible via the /fr prefix.
How can I workaround the fact that the alias gets switched from "All" to "English" (which is the default language.
Comments
Comment #1
walwyn CreditAttribution: walwyn commentedComment #2
Dave ReidWhen you save a node as an 'English' node, it's URL alias gets saved as having the English language as well. When you browse your site in French, Drupal core only uses URL aliases that are language-neutral or French. No English URL aliases will work.
Comment #3
walwyn CreditAttribution: walwyn commentedThanks. The problem is that somewhere along the line the language-neutral alias is getting zapped to English. So if I start off with:
section/entomology/diptera-empididae node/200 All
and then change the language to English then hat I end up with:
section/entomology/diptera-empididae node/200 English
and the the All entry is gone. I wouldn't mind if the All entry was left and a new English entry added its the replacement that is the problem. The effect of this is any incoming links that were to /fr/section/entomology/diptera-empididae gets 404'd
Can anyone tell me how I can stop that from happening. I've just applied a patch to the path module in core
http://drupal.org/node/321848#comment-2669782
which seems to fix the problem, but doesn't seem the right thing to do.
Do I also need to apply the patch here?
http://drupal.org/node/321848#comment-2669782
it seems that the two are intertwined or maybe they are addressing different problems.
Comment #4
walwyn CreditAttribution: walwyn commentedSorry I just realized that you effectively closed this as 'by design'.
I can appreciate that if a new alias is created for English and the language-neutral alias is left then every would be fine. Unfortunately that isn't what is happening, the language-neutral alias is being zapped by the English alias. How do I stop this from happening.
Comment #5
roderikThis is not a problem in pathauto, but in Drupal core - specifically, it's path_set_alias() which will zap the neutral language alias.
This was by design. See flowcharts in http://drupal.org/node/154517#comment-625541. I don't know if that design decision is still necessary, but I guess it should be explicitly discussed.
Related issues:
#541802: Let path_nodeapi reuse the current path alias language on update - the latest take on this issue would also solve your problem. (I have no opinion on it)
#269877: path_set_alias() doesn't account for same alias in different languages - the patch in #218 would also solve your problem. Later patch #275 (by me) does not solve your problem because IMHO this is a functionality change, which should not be intertwined with the bug which issue #269877 is really about.
I'm not setting 'duplicate' yet because I'm not sure which this is a duplicate of. We will probably know when/if any of these issues gets resolved.
Comment #6
walwyn CreditAttribution: walwyn commentedThe issue with pathauto is now spread over a number of threads and it is difficult to workout exactly what is being said in each. It seems that symptoms are being addressed rather than a core design problem.
It seems to be that multi-languages have issues in DRUPAL. I have another problem with multi-languages in the relatedlinks module, where a page edit deletes any relatedlinks set on any of the other nodes in a translation group. To my naive probing it all seems to be down to the fact that when a page is updated all the nodes in a translation group get dragged through the system too and it is none obvious to any of the hook functions whether the update is due to a primary change or a synchronization.
Currently I've found that so long as I ensure that a all aliases generated for a language page are not the same as the all-language alias the problem is sidestepped. And so long as I have the patch in path.module in place, and the pathauto_persist module installed, and I set the canonical url in theHTML header,then any residual problems are manageable. Not ideal, but something I can live with in my installation.
That flowchart just seems wrong. The step at "Only neutral alias" cannot have considered the practical implication of discarding an URL simply because the language was changed from neutral to specific. Going from the stats on my site a new page is picked up by 20 webcrawlers within 10 minutes of posting. The last page I added was #3 on Google 30 minutes after posting, one simply can't 404 the URL just because I've added a French translation.
Comment #7
donquixote CreditAttribution: donquixote commentedI think the conceptual problem is in the unclear meaning of the language setting for a node.
1) In some cases, it means
"This content should only be visible for people browsing in language X".
-> typical with D6-style node translation.
-> Also typical if different language sections of the site are totally independent.
2) In other cases it means
"Text in this content is in language X, but anyone can view it".
3) And, with D7 entity translation / field translation:
"Text is available in multiple languages, but the 'master language' is X."
Only in (1) does it make sense to have a language-specific aliases.
For (2) and (3), it is probably much better to have all aliases language-neutral.