On 8/11/06, Nick Jenkins <nickpj(a)gmail.com> wrote: 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?

On 8/11/06, Nick Jenkins <nickpj(a)gmail.com> wrote: 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.

Steve Bennett 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 -- brion vibber (brion @ pobox.com)

On 8/11/06, Brion Vibber <brion(a)pobox.com> wrote: 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…Bush, 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, Simetrical <Simetrical+wikitech(a)gmail.com> wrote: Ta. Steve

On 8/14/06, Timwi <timwi(a)gmx.net> wrote: 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

Jay Ashworth wrote: 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 8/14/06, Steve Summit <scs(a)eskimo.com> wrote: You were right - that's the entire reason why {{redirect}} exists. 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. 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: 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. 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

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)

On 8/14/06, Timwi &lt;timwi(a)gmx.net&gt; wrote: 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.

On Mon, Aug 14, 2006 at 05:32:11PM +0100, Timwi wrote: Ooooh! The Thrilla from Manila. /me pops popcorn; grabs beer. Cheers, -- jra -- Jay R. Ashworth jra(a)baylink.com Designer Baylink RFC 2100 Ashworth & Associates The Things I Think '87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 The Internet: We paved paradise, and put up a snarking lot.