Last modified: 2014-11-18 18:07:33 UTC
A while ago, there was a topic on Wikitech-l that discussed "Redirect to Anchor". Noting that this is technically impossible, but also concerned without redirects such as: Blood Agar --> Agar Plate where the relevant information is tucked away very far down in the article, the following feature is requested: Current behavior of Redirects totally masks any text that comes after the #REDIRECT [[]] declaration. Feature would modify behavior, where now this extra text (provided there is text at all), is placed at the top of the article people are redirected to, perhaps, in some way, reformatted to be prominent. The earlier example cited could be rectified in this manner: ---- #REDIRECT [[Agar plate]] '''Blood agar''' is a special type of agar plate. See [[Agar plate#Types_of_agar_plates]] ---- The following text would be inserted at the top of the article, so: ---- :<i>'''Blood agar''' is a special type of agar plate. See [[Agar plate#Types_of_agar_plates]]</i> An '''agar plate''' is a sterile [[Petri dish]] that... (continue main content) ---- IMHO, I think this is an elegant way of solving the "Irrelevant Redirect" problem. I also do not think that it would be very difficult to implement (although I'm no programmer for Mediawiki, so I can't really make any statements on this).
Since it is currently possible to add text after the redirect, and people are already using this possibility for adding metadata (typically, categories) which do not refer to the target page, I suggest a change of this proposal: use the text *before* the redirect for that; such text currently makes the redirect non-functional.
*** Bug 7091 has been marked as a duplicate of this bug. ***
(In reply to comment #1) > Since it is currently possible to add text after the redirect, and people are > already using this possibility for adding metadata (typically, categories) > which do not refer to the target page, I suggest a change of this proposal: use > the text *before* the redirect for that; such text currently makes the redirect non-functional. How is the parser supposed to know it's a redirect? Should the string "#REDIRECT" followed by a wikilink be banned in the first line (unless you want it to become a redirect)? Probably that wouldn't break much, granted . . .
I guess the string "#REDIRECT" followed by a wikilink is already banned from the first line unless you want it to become a redirect, isnt'it? I think the best would be to insert the additional text in some tags like the example of Edward Z. Yang up here, so the parser could know what to additionaly show in the target page, e.g.: :<description>'''Blood agar''' is a special type of agar plate. See [[Agar plate#Types_of_agar_plates]]</description>
*** Bug 7178 has been marked as a duplicate of this bug. ***
Connel MacKenzie suggested the perfect syntax at bug 7178: just [[Page|what to display]]. Quite intuitive, once you're used to wikimarkup, and fully reverse-compatible.
It is a good syntax if, and only if, you can still put any text in it; included wikilinks or even templates.
I'm closing this as WONTFIX, because we now can redirect to sections of pages using #REDIRECT [[Pagename#Section]]. If someone still wants the feature, feel free to reopen.
I'm reopening this bug because the possibility of redirecting to section only solves one part of the problem, that of having the relevant text down in the article. At least in the way I interpreted this bug, the text would also explain why the redirect points there. This could be "Blood agar is a special type of agar plate", but could also be something less obvious like "pivot_root is a Linux command sometimes used in the initrd initialization script". In this second case, the redirect name is not the title of a section, and the reader would otherwise be forced to first search for the point where "pivot_root" is mentioned, and then re-construct what "pivot_root" is from the surrouding text.
*** Bug 10990 has been marked as a duplicate of this bug. ***
*** Bug 8888 has been marked as a duplicate of this bug. ***
*** Bug 13595 has been marked as a duplicate of this bug. ***
