Hi All,
If I go to http://en.wikipedia.org/Tokyo (note the missing "/wiki"), I get a 404 page that contains a 5 second-client side refresh tag like so: <meta http-equiv="Refresh" content="5; URL=http://en.wikipedia.org/wiki/Tokyo">
Is there any chance we could follow the great example of the PHP folks, and immediately give the user what they really want (e.g. http://php.net/date , which instantly shows the user the content of the http://php.net/manual/en/function.date.php page) ?
In other words, use a server-side HTTP redirect/location header, rather than a client-side refresh?
This would be quicker for the user, friendlier, more forgiving, and just generally a nice touch.
All the best, Nick.
Nick Jenkins wrote:
If I go to http://en.wikipedia.org/Tokyo (note the missing "/wiki"), I get a 404 page that contains a 5 second-client side refresh tag like so: <meta http-equiv="Refresh" content="5; URL=http://en.wikipedia.org/wiki/Tokyo">
Is there any chance we could follow the great example of the PHP folks, and immediately give the user what they really want (e.g. http://php.net/date , which instantly shows the user the content of the http://php.net/manual/en/function.date.php page) ?
I nixed that because then you've got scary unstable URLs being linked to. The URL system may change, potentially dramatically so, and they'll no longer work. (But I'm a bit of a stickler about stable URLs on articles.)
The PHP manual example is particularly dangerous because they don't even issue an HTTP redirect, it just spits the content right back. Bad for caching and for linking.
-- brion vibber (brion @ pobox.com)
I nixed that because then you've got scary unstable URLs being linked to. The URL system may change, potentially dramatically so, and they'll no longer work. (But I'm a bit of a stickler about stable URLs on articles.)
Well if http://en.wikipedia.org/XYZ redirects to http://en.wikipedia.org/wiki/XYZ , and http://en.wikipedia.org/wiki/XYZ either is the real content (or a redirect to the real content in the future event of a URL system change, so as to maintain stable URLs), then wouldn't that be okay?
The PHP manual example is particularly dangerous because they don't even issue an HTTP redirect, it just spits the content right back. Bad for caching and for linking.
I agree (and I should have said as much in the original mail). Their implementation seems wrong (bad to echo content, should redirect instead), but the principle (IMHO) of doing something nice with the input is pretty sound. i.e. I was thinking more a HTTP 30x redirect header.
All the best, Nick.
On 8/11/06, Nick Jenkins nickpj@gmail.com wrote:
Well if http://en.wikipedia.org/XYZ redirects to http://en.wikipedia.org/wiki/XYZ , and http://en.wikipedia.org/wiki/XYZ either is the real content (or a redirect to the real content in the future event of a URL system change, so as to maintain stable URLs), then wouldn't that be okay?
No, because then people get used to entering it like that . . . and they happily go on entering it like that . . . and then one day, they're interested in looking up info about the Robot Exclusion Policy Protocol and type in http://en.wikipedia.org/robots.txt . . . and WTF? There's not really much mileage in encouraging people to continue using such links. Who knows what files and directories someone might want to put in the root directory of enwiki?
No, because then people get used to entering it like that . . . and they happily go on entering it like that . . . and then one day, they're interested in looking up info about the Robot Exclusion Policy Protocol and type in http://en.wikipedia.org/robots.txt . . . and WTF?
I knew someone would make that argument, but I really don't find it a very compelling reason to not do something.
Firstly, how do you know this isn't happening already? There's a meta redirect, so how do you know people aren't just using that? And how do you know that right now someone isn't looking at http://en.wikipedia.org/robots.txt and going "Huh? Where's my Wikipedia article?" ?
Secondly, if someone wants to read an article about the gory details of the robot exclusion policy, it seems a stretch to suggest that they will have no idea about HTTP redirects or that there's a file called robots.txt. (I.e. if the robot exclusion policy required us using a file called http://en.wikipedia.org/Cabbage_Patch_Doll then I agree, that would be a real problem, but "robots.txt"? Come on!)
Thirdly, of the one-point-something million article pages, there's a handful which have real content in the web root. It's like 10 files (equivalent to 0.001% of the article space), and some of them are like http://en.wikipedia.org/COPYING (i.e. they're not doing anything particularly useful).
Look, I'm not trying to be obtuse, but I sincerely think that a redirect is better, and pointing to corner-cases as a reason not to make things better in the general-case doesn't make much sense to me.
All the best, Nick.
On 8/11/06, Nick Jenkins nickpj@gmail.com wrote:
Look, I'm not trying to be obtuse, but I sincerely think that a redirect is better, and pointing to corner-cases as a reason not to make things better in the general-case doesn't make much sense to me.
It makes sense because there's practically no cost to the alternative that avoids such corner cases. People will rarely leave out the /wiki/ part, because they'll learn that it gets them the soft redirect, but if they don't leave it out there's no harm anyway, and so we don't have to worry about the corner cases.
This is especially important in the context of any kind of automated procedure — say if someone writes a Firefox extension that will give you the appropriate Wikipedia page for selected text from a context menu, and sees that the shorter URL works. Out of thousands of people looking up tons of stuff every day, somebody's going to become totally confused at some point — some things, like "wiki", aren't as minor as robots.txt.
Frankly, I think it makes pretty much no difference, but we may as well stay on the safe side.
Would this be an appropriate time for me to ask that if you go to a redirected article (say, George Walker Bush), then you would properly redirected to end up at http://en.wikipedia.org/wiki/George_W_Bush, rather than http://en.wikipedia.org/wiki/George_Walker_Bush with content from the George W Bush page (and the words "redirected from").
I'm sure I had a good reason for requesting this, but it escapes me at the moment. If anyone knows...:)
Steve
On 8/11/06, Brion Vibber brion@pobox.com wrote:
I nixed that because then you've got scary unstable URLs being linked to. The URL system may change, potentially dramatically so, and they'll no longer work. (But I'm a bit of a stickler about stable URLs on articles.)
The PHP manual example is particularly dangerous because they don't even issue an HTTP redirect, it just spits the content right back. Bad for caching and for linking.
-- brion vibber (brion @ pobox.com)
Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Steve Bennett wrote:
Would this be an appropriate time for me to ask that if you go to a redirected article (say, George Walker Bush), then you would properly redirected to end up at http://en.wikipedia.org/wiki/George_W_Bush, rather than http://en.wikipedia.org/wiki/George_Walker_Bush with content from the George W Bush page (and the words "redirected from").
I'm sure I had a good reason for requesting this, but it escapes me at the moment. If anyone knows...:)
We should have a FAQ for this. :)
/me digs up an old response
http://mail.wikipedia.org/pipermail/wikitech-l/2005-November/032619.html
-- brion vibber (brion @ pobox.com)
On Fri, Aug 11, 2006 at 08:33:19AM -0700, Brion Vibber wrote:
Steve Bennett wrote:
Would this be an appropriate time for me to ask that if you go to a redirected article (say, George Walker Bush), then you would properly redirected to end up at http://en.wikipedia.org/wiki/George_W_Bush, rather than http://en.wikipedia.org/wiki/George_Walker_Bush with content from the George W Bush page (and the words "redirected from").
I'm sure I had a good reason for requesting this, but it escapes me at the moment. If anyone knows...:)
We should have a FAQ for this. :)
/me digs up an old response
http://mail.wikipedia.org/pipermail/wikitech-l/2005-November/032619.html
I'm glad Steve did it. I was gonna do it, but -- and I thought you might actually be quoting me, til I looked -- I remembered already *having* done it once.
Steve, there's one in the archive where he explains it to me too, and (thanks, brion) in more detail than the one he links, IIRC. You might hunt that one down too... I wasn't entirely convinced, I don't think, but enough to shut me up at least. ;-)
Cheers, -- jra
On 8/11/06, Brion Vibber brion@pobox.com wrote:
We should have a FAQ for this. :)
/me digs up an old response
http://mail.wikipedia.org/pipermail/wikitech-l/2005-November/032619.html
Ok, that actually makes sense. Summarising: You have two options. Either:
a) It hard redirects you, and there's absolutely no link back to where you came from. Very bad for maintenance, working on the redirect itself etc. b) It redirects you, but leaves the link back to the original redirecting page. But the only way to make that work is to have a parameter on the URL, like http://en.wikipedia.org/wiki/George_W_Bush&redirectedfrom=George_Walker_..., which totally kills the point of the whole exercise (having a clean URL).
The one suggestion I might make would be adding a *forward* link as well as a backward link. So, when you get soft-redirected like that, you would end up with a link to the actual page (without the backwards redirect. Maybe that's what I'm missing. It'd just be convenient if there was a way to get to the actual page, in order to bookmark it or copy the URL or something. Currently I end up copy-pasting the title into the navigation box.
Steve
On 8/11/06, Steve Bennett stevage@gmail.com wrote:
The one suggestion I might make would be adding a *forward* link as well as a backward link. So, when you get soft-redirected like that, you would end up with a link to the actual page (without the backwards redirect. Maybe that's what I'm missing. It'd just be convenient if there was a way to get to the actual page, in order to bookmark it or copy the URL or something. Currently I end up copy-pasting the title into the navigation box.
Click the "article" tab.
Steve Bennett wrote:
On 8/11/06, Brion Vibber brion@pobox.com wrote:
We should have a FAQ for this. :)
/me digs up an old response
http://mail.wikipedia.org/pipermail/wikitech-l/2005-November/032619.html
Ok, that actually makes sense. Summarising: You have two options. Either:
a) It hard redirects you, and there's absolutely no link back to where you came from. Very bad for maintenance, working on the redirect itself etc. b) It redirects you, but leaves the link back to the original redirecting page.
or (c) It hard redirects you, and there's a link back to where you came from.
This is the false dilemma.
Timwi
On 8/14/06, Timwi timwi@gmx.net wrote:
a) It hard redirects you, and there's absolutely no link back to where you came from. Very bad for maintenance, working on the redirect itself etc. b) It redirects you, but leaves the link back to the original redirecting page.
or (c) It hard redirects you, and there's a link back to where you came from.
Ok, what do "hard direct" and "soft redirect" mean in this context exactly? Let's take some page A which redirects to page B. They're hosted directly at wiki.org.
Currently wiki.org/A shows the content of wiki.org/B, but with a link back to A. The URL shows wiki.org/A.
You're proposing that wiki.org/A force a (server-side?) redirect to wiki.org/B, display the content of B, with a link back to A, and yet the URL shows wiki.org/B? The question is, how does MediaWiki know to show the link back if the URL is only wiki.org/B, and not wiki.org/B&red=A or something?
Forgive my ignorance, I have absolutely no idea how server side redirects work.
Steve
On Mon, Aug 14, 2006 at 07:16:28PM +0200, Steve Bennett wrote:
On 8/14/06, Timwi timwi@gmx.net wrote:
a) It hard redirects you, and there's absolutely no link back to where you came from. Very bad for maintenance, working on the redirect itself etc. b) It redirects you, but leaves the link back to the original redirecting page.
or (c) It hard redirects you, and there's a link back to where you came from.
Ok, what do "hard direct" and "soft redirect" mean in this context exactly? Let's take some page A which redirects to page B. They're hosted directly at wiki.org.
Currently wiki.org/A shows the content of wiki.org/B, but with a link back to A. The URL shows wiki.org/A.
You're proposing that wiki.org/A force a (server-side?) redirect to wiki.org/B, display the content of B, with a link back to A, and yet the URL shows wiki.org/B? The question is, how does MediaWiki know to show the link back if the URL is only wiki.org/B, and not wiki.org/B&red=A or something?
The problem is that we want a "clean" URL when we land, and yet we also want a backlink on the page proper. There doesn't seem to be any good way to get both.
I, too, think it would be nice to make it as difficult as possible to bookmark a URL that's the *source* of a redirect (which I presume is what everyone's on about), but as brion says, there doesn't seem to be any clean way to do that and still have link back to the redirect -- without maintaining state in the server, which is entirely uncalled for here.
IMHO.
Timwi clearly thinks that one of our premises, or our conclusion, are incorrect, but doesn't seem to have provided details yet.
Cheers, -- jra
Jay Ashworth wrote:
I, too, think it would be nice to make it as difficult as possible to bookmark a URL that's the *source* of a redirect, but...
That's really true only if the "source" is "wrong". It turns out it's not always wrong, which is yet another reason I think the current setup is the right compromise. (That is, we'll just have to find other ways to stamp out the "bad" links that result when people bookmark or otherwise use a truly "wrong" URL that we're actively trying to deprecate.)
In many (perhaps most) of the current cases, redirects are used to create "aliases" for pages, and there really oughtn't be any stigma attached to linking to such an alias, if that makes more sense. For example, if I know that [[Los Angeles]] redirects to [[Los Angeles, California]], and if I'm writing in a context where it's unnecessary to remind my readers of the state, should I slavishly write [[Los Angeles, California|Los Angeles]], or should I rely on the redirect and just write [[Los Angeles]]? Truly, one of the reasons these "alias" redirects exist is to make it easier on people creating wikilinks in naturally-flowing prose without having to use pipelinks all the time, so why not make use of them when they're there?
I've recently come across two other cases in which I think it makes sense to deliberately link to a redirect.
1. Questionably-robust redirect partitioning. Suppose I need to link to the article about Vancouver, BC. It happens that, currently, plain [[Vancouver]] is about the Canadian city, and the U.S. city is at [[Vancouver, Washington]], and there's a disambiguation page at [[Vancouver (disambiguation)]], and [[Vancouver, BC]] redirects to [[Vancouver]]. So I could get away with just linking to [[Vancouver]].
But the Vancouver situation is (to me, at least) different from the Los Angeles one. There is and is only ever likely to be one Los Angeles, but the Vancouver situation feels much less absolute. I can imagine that, some ways down the line, someone might change plain [[Vancouver]] to be the disambiguation page. So I'd like to explicitly link to [[Vancouver, BC]], even if it means using the pipelink [[Vancouver, BC|Vancouver]], and even though it means linking to something which I know today to be a redirect. But, in this case, being explicit feels much more robust to me, doesn't leave me feel like I'm relying on today's coincidence (i.e. that plain [[Vancouver]] happens to be the one I want) to last forever.
2. Clarifying "antiredirects". Just this morning, I was reading up about countable versus uncountable nouns. I tried [[Countable]], which redirects to [[Countable set]]. It turns out we do have [[Countable noun]], which is a redirect to [[Count noun]], which is another term some people use for what I think of as a "countable noun". But to make it easier on the next reader who happened to be interested in linguistic as opposed to mathematical countability, I edited [[Countable set]] to add
"Countable" redirects here. For the linguistic concept, see Countable noun.
at the top. Almost immediately someone changed it to
...For the linguistic concept, see Count noun.
noting that [[Countable noun]] is a redirect. But I think showing the link as [[Countable noun]] was (mildly) preferable in this case, because it explicitly shows the same word which the searcher who got redirected from [[Countable]] is looking for. It doesn't make too much of a difference in this case, but if the terms were more different -- if the searcher looked for [[Abc]] and got redirected to [[Abc d]] and was told that there was also an article on [[Xyz]], he might not realize that the [[Xyz]] link was worth following if what he thought he was looking for was [[Abc q]].
(Actually, I don't need to use that hypothetical Abc/q example, because I've got a real one right in front of me: at the same time I was playing with [[Countable set]], I also edited [[Uncountable set]] to include the similar legend "'Uncountable' redirects here. For the linguistic concept, see Uncountable noun". Now, [[Uncountable noun]] is actually a redirect to [[Mass noun]], but if the same change were made here -- if the legend said "For the linguistic concept, see Mass noun" -- it might be confusing.)
The bottom line is if there's less reason to discourage linking to "wrong" titles (as I maintain), there's less reason to worry about showing the "wrong" URL in the address bar of a redirected-to page.
[P.S. Personally, I think it would be good if articles could have alternate titles or "aliases" as a formally-supported concept, so that we could do away with the hordes of manually-maintained explicit redirects which simulate them, but that would admittedly be much more complicated on the implementation side, if "more convenient" on the user side.]
[P.P.S. One way to tell if a redirect is really an "alias" is if the alias name shows up in bold face, preceded by the word "or" or "also", in the redirected-to article's lead sentence. See [[Mass noun]] for an example.]
On Mon, Aug 14, 2006 at 02:58:09PM -0400, Steve Summit wrote:
Jay Ashworth wrote:
I, too, think it would be nice to make it as difficult as possible to bookmark a URL that's the *source* of a redirect, but...
That's really true only if the "source" is "wrong". It turns out it's not always wrong, which is yet another reason I think the current setup is the right compromise. (That is, we'll just have to find other ways to stamp out the "bad" links that result when people bookmark or otherwise use a truly "wrong" URL that we're actively trying to deprecate.)
Redirects are much more malleable, in my perception, than pages, and that's why I feel that bookmarking them is Not The Best Idea.
In many (perhaps most) of the current cases, redirects are used to create "aliases" for pages, and there really oughtn't be any stigma attached to linking to such an alias, if that makes more sense. For example, if I know that [[Los Angeles]] redirects to [[Los Angeles, California]], and if I'm writing in a context where it's unnecessary to remind my readers of the state, should I slavishly write [[Los Angeles, California|Los Angeles]], or should I rely on the redirect and just write [[Los Angeles]]?
That's an excellent question. How 'reliable' do you want your writing to be. When you find a redlink for which there "really" is a page, what do you do? Do you fix the link, or create a redirect?
Truly, one of the reasons these "alias" redirects exist is to make it easier on people creating wikilinks in naturally-flowing prose without having to use pipelinks all the time, so why not make use of them when they're there?
There's an argument on both sides, certainly.
I've recently come across two other cases in which I think it makes sense to deliberately link to a redirect.
Questionably-robust redirect partitioning. Suppose I need to link to the article about Vancouver, BC. It happens that, currently, plain [[Vancouver]] is about the Canadian city, and the U.S. city is at [[Vancouver, Washington]], and there's a disambiguation page at [[Vancouver (disambiguation)]], and [[Vancouver, BC]] redirects to [[Vancouver]]. So I could get away with just linking to [[Vancouver]].
But the Vancouver situation is (to me, at least) different from the Los Angeles one. There is and is only ever likely to be one Los Angeles, but the Vancouver situation feels much less absolute. I can imagine that, some ways down the line, someone might change plain [[Vancouver]] to be the disambiguation page. So I'd like to explicitly link to [[Vancouver, BC]], even if it means using the pipelink [[Vancouver, BC|Vancouver]], and even though it means linking to something which I know today to be a redirect. But, in this case, being explicit feels much more robust to me, doesn't leave me feel like I'm relying on today's coincidence (i.e. that plain [[Vancouver]] happens to be the one I want) to last forever.
So our disagreement is a difference in degree, not of sorts. Got it.
Clarifying "antiredirects". Just this morning, I was reading up about countable versus uncountable nouns. I tried [[Countable]], which redirects to [[Countable set]]. It turns out we do have [[Countable noun]], which is a redirect to [[Count noun]], which is another term some people use for what I think of as a "countable noun". But to make it easier on the next reader who happened to be interested in linguistic as opposed to mathematical countability, I edited [[Countable set]] to add
"Countable" redirects here. For the linguistic concept, see Countable noun.
at the top. Almost immediately someone changed it to
...For the linguistic concept, see Count noun.
noting that [[Countable noun]] is a redirect. But I think showing the link as [[Countable noun]] was (mildly) preferable in this case, because it explicitly shows the same word which the searcher who got redirected from [[Countable]] is looking for. It doesn't make too much of a difference in this case, but if the terms were more different -- if the searcher looked for [[Abc]] and got redirected to [[Abc d]] and was told that there was also an article on [[Xyz]], he might not realize that the [[Xyz]] link was worth following if what he thought he was looking for was [[Abc q]].
Well, if those "blah redirects here" things are *manual*, then there's another good reason: they're *wrong* if you came in to a page with multiple redirects pointing to it.
(Actually, I don't need to use that hypothetical Abc/q example, because I've got a real one right in front of me: at the same time I was playing with [[Countable set]], I also edited [[Uncountable set]] to include the similar legend "'Uncountable' redirects here. For the linguistic concept, see Uncountable noun". Now, [[Uncountable noun]] is actually a redirect to [[Mass noun]], but if the same change were made here -- if the legend said "For the linguistic concept, see Mass noun" -- it might be confusing.)
Which I think is another way to say the same thing.
The bottom line is if there's less reason to discourage linking to "wrong" titles (as I maintain), there's less reason to worry about showing the "wrong" URL in the address bar of a redirected-to page.
My perception is that the writers on a page assume it's called what it's really called, and that assumption may color what they write, in the way you suggest, and possibly in other ways that aren't obvious, both on WP and on private wikis... and the results of those problems may confuse *readers*, which is a couple/three order of magnitude worse problem... right?
[P.S. Personally, I think it would be good if articles could have alternate titles or "aliases" as a formally-supported concept, so that we could do away with the hordes of manually-maintained explicit redirects which simulate them, but that would admittedly be much more complicated on the implementation side, if "more convenient" on the user side.]
By which you mean that the article "could tell" that it had such and such aliases, in a way that it can't now?
Cheers, -- jra
On 8/14/06, Steve Summit scs@eskimo.com wrote:
at the top. Almost immediately someone changed it to
...For the linguistic concept, see Count noun.noting that [[Countable noun]] is a redirect. But I think showing the link as [[Countable noun]] was (mildly) preferable in this case, because it explicitly shows the same word which the searcher who got redirected from [[Countable]] is looking for.
You were right - that's the entire reason why {{redirect}} exists.
[P.S. Personally, I think it would be good if articles could have alternate titles or "aliases" as a formally-supported concept, so that we could do away with the hordes of manually-maintained explicit redirects which simulate them, but that would admittedly be much more complicated on the implementation side, if "more convenient" on the user side.]
Is there any difference between an "alias" and a protected redirect?
Fwiw, I kind of asked for this a while ago, but from a different point of view. It'd be nice for any article if you could edit *on the article page* the list of redirects that point there. Redirects should be considered part of the article, not as random other articles that by sheer chance happen to point to it.
[P.P.S. One way to tell if a redirect is really an "alias" is if the alias name shows up in bold face, preceded by the word "or" or "also", in the redirected-to article's lead sentence.
Yes...but...no. It's a pretty complicated topic. I've thought a fair bit about that logic and it's complicated. Often for some topic A, you have redirects A', A'', B, B', B'' and C. In the text at A, A, B and C will be in bold. If you're lucky. Maybe D and E will be in bold too, but they won't be linked. Although they should be. Other times, F (which also redirects here) will be in bold, but in the 8th paragraph, because it's a minor topic, related to A, but that doesn't deserve its own article...
IMHO we should stop this tendency towards agglomerating all articles into one unless they stand a chance of becoming an FA....but that's a different debate.
Steve
"Steve Bennett" wrote:
You're proposing that wiki.org/A force a (server-side?) redirect to wiki.org/B, display the content of B, with a link back to A, and yet the URL shows wiki.org/B? The question is, how does MediaWiki know to show the link back if the URL is only wiki.org/B, and not wiki.org/B&red=A or something?
There is another option to have the link back that nobody said, and is using the Referer: header the user-agent gives. That would give enough information to make the link back while avoiding the ?ugly=url. The risk is not showing the back link to all the clients, as we're relying on the information they gave before, though most common browsers give it.
Steve Bennett wrote:
On 8/14/06, Timwi timwi@gmx.net wrote:
a) It hard redirects you, and there's absolutely no link back to where you came from. Very bad for maintenance, working on the redirect itself etc. b) It redirects you, but leaves the link back to the original redirecting page.
or (c) It hard redirects you, and there's a link back to where you came from.
Ok, what do "hard direct" and "soft redirect" mean in this context exactly? Let's take some page A which redirects to page B. They're hosted directly at wiki.org.
Currently wiki.org/A shows the content of wiki.org/B, but with a link back to A. The URL shows wiki.org/A.
You're proposing that wiki.org/A force a (server-side?) redirect to wiki.org/B, display the content of B, with a link back to A, and yet the URL shows wiki.org/B? The question is, how does MediaWiki know to show the link back if the URL is only wiki.org/B, and not wiki.org/B&red=A or something?
My personally preferred way is to simply redirect to B, and at the same time make it much easier than currently to get a list of "what redirects here" (and whatever other subsets of "what links here" you can imagine). Thus, the answer to your question is: You get the link to A because A redirects to B and you get the list of all titles that redirect to B.
Forgive my ignorance, I have absolutely no idea how server side redirects work.
The term "server-side" is a bit misleading here. Even the term "redirect" is confusing because what _MediaWiki_ calls a "redirect" is not actually a HTTP or HTML redirect at all.
The thing you get when you go to http://en.wikipedia.org/Article (i.e. with the /wiki missing) is an HTML redirect or "soft redirect", i.e. a <meta> tag that redirects after a set number of seconds.
The thing you get when you go to http://en.wikipedia.org/wiki/article (notice the lower-case "a") is an HTTP redirect or "hard redirect", i.e. an HTTP response with status code "301" and a Location header.
The thing you get when you go to a page title that is a MediaWiki redirect, is a pageview. ;-)
Timwi
On 8/15/06, Timwi timwi@gmx.net wrote:
My personally preferred way is to simply redirect to B, and at the same time make it much easier than currently to get a list of "what redirects here" (and whatever other subsets of "what links here" you can imagine). Thus, the answer to your question is: You get the link to A because A redirects to B and you get the list of all titles that redirect to B.
That sounds to me like the link from A would become quite hidden. I do agree with the point that the link has to be prominent to make it easy for people to understand why the hell they are where they are, and how to fix it if that's not the right place to be. It happens fairly frequently that someone (pipe)links to some [[A]], without expecting that to redirect to some other [[B]]. What does the average user do when they clicked on the word "C", only to find themselves at [[B]], which bears no relationship whatsoever? At least by having a link back to A, they can see that it's a redirect and start to see where it all went wrong...
(However, having a list of all articles that point to B would be great ;))
Steve
This thread has deviated quite significantly from the original question.
I don't believe anyone was suggesting that the internal redirects currently in use behave in any other manner than the currently do.
The issue was with redirecting from (e.g.)
en.wikipedia.org/USA
to
en.wikipedia.org/wiki/USA
The original poster was proposing that this is done with a 'silent' 301 (page moved permanently) so that from a visitors point of view, typing either of the above give the same result. The fact that the page they view will actually be 'United States', with a redirect note is not relevant to this discussion, and there is no need to display any 'redirect' notice unless the requested page is itself a redirect.
The advantages of this method is that the user doesn't get a 'page not found, you will be redirected' message and either have to wait 5 seconds or click a second link. Instead they are instantly taken to the article they want. A second advantage is that the 301 error will inform the browser/proxy to look for this page in the new location from now on (though I don't know how efficiently current browsers/proxies deal with this).
The argument against this was that if people start making it a habit of linking to en.wikipedia.org/USA and then the server structure changes, then these links will no longer work. A second argument was that certain pages will not be accessible in this manner (e.g. en.wikipedia.org/wiki).
I hope that summarises the actual question and story so far and gets this thread back on track. Normal redirects are not in danger!
- Mark Clements (HappyDog)
----- Original Message ----- From: "Steve Bennett" stevage@gmail.com
(However, having a list of all articles that point to B would be great ;))
I recently logged a bug for this: http://bugzilla.wikimedia.org/show_bug.cgi?id=6934
- Mark Clements (HappyDog)
On 8/14/06, Timwi timwi@gmx.net wrote:
or (c) It hard redirects you, and there's a link back to where you came from.
So . . . I go to http://en.wikipedia.org/wiki/HTTP_redirection. I get a 301 to go to http://en.wikipedia.org/wiki/URL_redirection? Then how does the server know to display the link back? All it knows is someone asked for one URL and got a 301 in return, then someone asked for another URL and needs to be returned a page. HTTP is stateless. So you'd have to redirect to http://en.wikipedia.org/wiki/URL_redirection?redirect=HTTP_redirection or something, which completely defeats the purpose.
Your only reply to that was that we didn't need the redirection link, we could just have a "pages redirecting to here" and that would be good enough. I haven't seen anyone else agree with that yet; I certainly don't. You're talking at least two clicks and a pageload plus hunting through a list, all instead of a single click. It would be quite annoying.
Brion Vibber wrote:
Steve Bennett wrote:
Would this be an appropriate time for me to ask that if you go to a redirected article (say, George Walker Bush), then you would properly redirected to end up at http://en.wikipedia.org/wiki/George_W_Bush, rather than http://en.wikipedia.org/wiki/George_Walker_Bush with content from the George W Bush page (and the words "redirected from").
I'm sure I had a good reason for requesting this, but it escapes me at the moment. If anyone knows...:)
We should have a FAQ for this. :)
/me digs up an old response
http://mail.wikipedia.org/pipermail/wikitech-l/2005-November/032619.html
How ironic that you link to the one where I replied and refuted your weak arguments. You have shown in that thread that you are stuck up with your false dilemma and are unable to understand (much less conceive) any alternatives.
Timwi
On Mon, Aug 14, 2006 at 05:32:11PM +0100, Timwi wrote:
Brion Vibber wrote:
We should have a FAQ for this. :)
/me digs up an old response
http://mail.wikipedia.org/pipermail/wikitech-l/2005-November/032619.html
How ironic that you link to the one where I replied and refuted your weak arguments. You have shown in that thread that you are stuck up with your false dilemma and are unable to understand (much less conceive) any alternatives.
Ooooh!
The Thrilla from Manila.
/me pops popcorn; grabs beer.
Cheers, -- jra
Brion Vibber wrote:
Nick Jenkins wrote:
If I go to http://en.wikipedia.org/Tokyo (note the missing "/wiki"), I get a 404 page that contains a 5 second-client side refresh tag like so: <meta http-equiv="Refresh" content="5; URL=http://en.wikipedia.org/wiki/Tokyo">
Is there any chance we could follow the great example of the PHP folks, and immediately give the user what they really want (e.g. http://php.net/date , which instantly shows the user the content of the http://php.net/manual/en/function.date.php page) ?
I nixed that because then you've got scary unstable URLs being linked to. The URL system may change, potentially dramatically so, and they'll no longer work. (But I'm a bit of a stickler about stable URLs on articles.)
I can't say I agree to this hand-wavy argumentation. There is no reason to believe that any substantial amount of people would create links to the redirecting URL. My guess is that 95% of people go to Wikipedia, use the search function to find the article, and then copy & paste the URL. Another 4% construct the URL manually and then copy & paste the URL it redirected to. The remaining 1% are the wackos who construct URLs without actually trying them, and neither a 301 header nor the current 5-second soft redirect helps against those. Therefore, the 301 redirect is clearly more beneficial.
The PHP manual example is particularly dangerous because they don't even issue an HTTP redirect, it just spits the content right back. Bad for caching and for linking.
That, I agree with -- unless they have made clever arrangements to prevent themselves from needing to use those URLs for other purposes in future.
Timwi
wikitech-l@lists.wikimedia.org