Neil Harris wrote:

A possible point in favour: using rel="alternate" together with the hreflang attribute in <link> elements (as per http://www.w3.org/TR/REC-html40/struct/links.html#h-12.3, section 12.3.3) might help search engines make smarter decisions about indexing Wikipedia content, thus increasing the relevance and availability of Wikipedia content in Web searches made by the general public.

That's an interesting statement. What evidence do you have to support it? Can you name any search engines that actually look at this information?

Lars Aronsson wrote:

Neil Harris wrote:

...

A possible point in favour: using rel="alternate" together with the hreflang attribute in <link> elements (as per http://www.w3.org/TR/REC-html40/struct/links.html#h-12.3, section 12.3.3) might help search engines make smarter decisions about indexing Wikipedia content, thus increasing the relevance and availability of Wikipedia content in Web searches made by the general public.

That's an interesting statement. What evidence do you have to support it? Can you name any search engines that actually look at this information?

I think it's a chicken-and-egg problem, a case of "if you build it, they will come."

Although I do not know of any search engine that uses this information, on the other hand, it's hard to prove a negative. Google, in particular, are highly ingenious in using every scrap of information they can glean from analyzing web pages, and feeding it to their machine-learning pattern-matching engines. Certainly, unless that information is present, they will certainly not be able to use it, even in theory.

I think that encoding the metadata statement "this other page is an alternative to this page, in the following language" in a standardized machine-readable form is quite likely to be useful, possibly in unanticipated ways.

Indeed, the application of this link tag to Wikipedia is a clear case where both of the normal objections voiced to the hreflang attribute (no control of linked-to content, what about Accept-Lang) clearly do not apply.

It's simple to implement, clearly cannot do any harm to Wikipedia's content, and it might do some good; whether it is worth the additional load on Wikipedia's bandwidth and servers is another matter.

-- Neil

On Mon, 2005-14-11 at 08:32 -0800, Evan Martin wrote:

What problem is this change trying to fix?

It's not trying to solve any problem. There's a standard mechanism in HTML for specifying an alternate version of a document in another language; theoretically using this standard mechanism would help some MediaWiki-ignorant bots and spiders to find alternate language versions and "understand" the relationship between them.

I'm not sure I see the pros outweighing the cons...

I can see that. The pros are theoretical; the cons are more concrete. I'm of the opinion that if you follow Web standards, Good Things Happen (TM), but I don't have any proof that that's the case in this instance.

~Evan

On Mon, 2005-14-11 at 20:09 +0100, Ashar Voultoiz wrote:

...

    Specify language variants of this document

            If you have prepared translations of this document into
            other languages, you should use the LINK element to
            reference these.

Would be good if articles on the different projects were translations. Most of the time, although they are about the same subject, the articles are differents.

Yes, that's true. It's not clear how literal a translation an alternate document in another language has to be, though. Is the article about George Bush on Wikipedia fr: an "alternate in another language" to the one on Wikipedia en:? I'd say it's about as close as possible without being a translation.

~ESP

Would be good if articles on the different projects were translations. Most of the time, although they are about the same subject, the articles are differents.

Not all inter-wiki links link to an article that is about the same subject. They sometimes link to a more general topic. My pet peeve example is the German Wikipedians insisting that [[en:Vulcan (Star Trek)]], [[en:Romulan]], [[en:Ferengi]] etc. don't deserve German equivalents, so they *all* link to [[de:Völker im Star-Trek-Universum]], which of course contains less than half of the information, but instead a huge patronising banner warning not to be so stupid as to think these fictitious things could have anything to do with the real world, much less that they could be welcome on Wikipedia.

Timwi

On Fri, 2005-11-18 at 19:09 +0000, Timwi wrote:

...

I think it'd be useful for most multilingual MediaWiki installations that use interlanguage links to have such hidden <link> elements.

Speaking of which - this reminds me of an idea I had a while ago and I was wondering if anyone would be interested to hear this. Currently many Wikipedia pages in Google search results are redirects (for example, Google for "nonogram" and look at the seventh search result). I was wondering if there is a <link> element one could use to say that another URL is the "real" page? Then the page returned for a redirect's URL would tell search engines the URL of the page it's redirecting to.

I'm not aware of any <link> syntax, but one way to do it would be for MediaWiki to issue an HTTP 301 status (permanent redirect) to the new page, rather than returning 200 and giving the content. That probably introduces an unacceptably large performance penalty, though (extra round trip per request).

The "Content-Location" HTTP header is a potential longshot. I don't think Google documents their use/non-use of this header, but it's one of those "can't hurt" kind of things.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.14

It appears it can be tacked on using a meta http-equiv tag in the HTML head.

Rob

On Sun, 2005-11-20 at 18:39 -0800, Brion Vibber wrote:

Rob Lanphier wrote:

...

On Fri, 2005-11-18 at 19:09 +0000, Timwi wrote:

...

Speaking of which - this reminds me of an idea I had a while ago and I was wondering if anyone would be interested to hear this. Currently many Wikipedia pages in Google search results are redirects (for example, Google for "nonogram" and look at the seventh search result). I was wondering if there is a <link> element one could use to say that another URL is the "real" page? Then the page returned for a redirect's URL would tell search engines the URL of the page it's redirecting to.

I'm not aware of any <link> syntax, but one way to do it would be for MediaWiki to issue an HTTP 301 status (permanent redirect) to the new page, rather than returning 200 and giving the content. That probably introduces an unacceptably large performance penalty, though (extra round trip per request).

It's not a performance issue at all, and round-trips for 301s are often cheap compared to rendering.

...except for the fact that you are adding a round-trip in addition to subsequent rendering. I'll take your word for it that it's not a big deal in the larger scheme of things, but relative to a single header or tag, it seems pretty expensive (492 bytes inbound + 778 bytes outbound in the test I just ran with Firefox <=> standard config Apache).

It just makes it a lot harder to deal with such pages: if you HTTP-redirect straight to the target page you're missing the link back to the redirect page. (And that is *crucial* for editing work and vandalism cleanup. It is non-negotiable.)

If you redirect to an alternate URL which includes the linkback address, then a) it's an uglier URL and b) you don't get the alleged benefits of going to the single target URL in the first place.

We've actually discussed this many times before; please search the list archives if you wish to comment further. :)

I looked through the archives, and found the old "301's are evil" discussion from July 2003, which looks more like a misunderstanding than a productive conversation.

I'd like to point out that there's a third way, which is to set a cookie, rather than put the original request info in the URL. I'll admit that's probably got other problems, but I'm throwing that out there as a solution.

...

The "Content-Location" HTTP header is a potential longshot. I don't think Google documents their use/non-use of this header, but it's one of those "can't hurt" kind of things.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.14

The spec is sufficiently vague and mysterious that I'd recommend against using it for any purpose.

Typical use is in content negotiation, allowing the server to advertise the direct URL to the content that was ultimately served as a result of the negotiation.

Since the destination page would not return the same HTML as the redirect page, it would likely be incorrect and might cause problems if anything does use it.

I suppose you're right. More importantly, there's little reason to believe that it'd actually solve the problem at hand. Now that I think about it, the search engines probably shouldn't imply that the content location header contains the better URL to use to access the content in question. Since they shouldn't, that means it's a bad thing to count on.

Rob

Timwi wrote:

...

It just makes it a lot harder to deal with such pages: if you HTTP-redirect straight to the target page you're missing the link back to the redirect page. (And that is *crucial* for editing work and vandalism cleanup. It is non-negotiable.)

I feel I should point out an implicit fallacy in this. It is non-negotiable that we need a link to the redirect page. It is *not* non-negotiable that we can't return a 301 HTTP redirection.

The only fallacy is yours, you invented some claim that I said 301s can't be used. This is false; if you had read my message you'd have seen that my point was using a 301 would require sending additional parameters to avoid making redirect cleanup work hugely annoying, and this would destroy any benefit that would allegedly come from using an HTTP redirect to the direct target URL (since you can't do it, you'd have to use a different URL).

-- brion vibber (brion @ pobox.com)

Magnus Manske wrote:

We're already using two different URLs to display REDIRECT pages.

Using the redirect : .../wiki/The_Redirect shows the page The_Redirect redirects to.

Showing the redirect: .../w/index.php?title=The_Redirect&redirect=no shows the page containing the redirect.

Not that I have a strong opinion about using 301s, but couldn't we just turn the former link "style" into 301 and the latter not?

No, because then you have no idea how you got to that page, and have to dig through stuff to find out.

-- brion vibber (brion @ pobox.com)

Timwi wrote:

No, it wouldn't. _My_ point was that if we placed a link to the page you came from _somewhere else_ than a "redirected from" line (e.g. a list of "pages that redirect to here" on the Edit page), you would *not* need to send additional parameters. You could get back to the page a different way than you do currently.

If you have to jump through a bunch of extra hoops to get to it, then we've already lost the ability to easily get back where we came from. A 'pages that redirect here' would be only slightly more helpful than Whatlinkshere, as it doesn't tell you which one you actually came through.

Of course, there's also someone else's suggestion of using the session variables to remember where you came from and still display a "redirected from" line. As far as I can see, you haven't replied to that idea.

That would be a) extremely unreliable, b) harmful to caching.

-- brion vibber (brion @ pobox.com)

[Moving responses to what seems to be a new thread - though it may just be a new subject line, GMail's broken at telling the difference.]

On 27/11/05, Jamie Bliss astronouth7303@gmail.com wrote:

Does that line provide the inexperianced/ignorant user with any information of value? (ignorant == "unaware of how MW works in this regard")

A casual reader will not care if they are redirected between pages. An inexperianced editor _may_ wonder why they link to [[Foo]] and end up at [[Bar]]; some help entries can help on this if they don't already exist.

Actually, I would disagree with this rather strongly - a casual reader (or newbie editor, which we encourage to be the same thing) will generally be *very* surprised if they end up at a different page from the one they expected, precisely because they *don't* know what a redirect is. They may well not care that they're redirected between pages, but if they're not told that that's the case, *they will be confused*.

The chances of them finding a help page explaining this also seem rather slim - what would they search for? "Help:Pages which aren't called what you expect"?

IMHO, the information is rarely of value. Situations in which it is almost always involves editing and maintenance. I consider it unlikely of an anonymous and/or inexperianced editor wondering about this. (The true test is the various support channels.)

Well, you've hit the nail on the head there - the reason I am so confident in how new users will react is that I've seen their questions on the en.Wikipedia Help desk, things like "Whenever I try and look at page X, I end up at page Y instead! What am I doing wrong!?"

Indeed, this suggests that even our current label isn't doing its job well enough; for one thing - IMHO - Monobook makes it far too small and faint, as though we're ashamed of it and want to hide it among the "mechanics" of the UI.

On 26/11/05, Timwi timwi@gmx.net wrote:

I'm not convinced that you need to know which one you actually came through, especially if you have a list of all of them.

Well, I think it's important firstly to let users know that they *have* been redirected. Otherwise the wiki appears to be doing "magic" with links and page names, rather than being really straight-forward and easy to understand (even a piped link has the exact name of the target page written into it).

And secondly, the combination of piped links and redirects may mean you don't know *exactly* what page you *should* have ended up at, and it might not jump out of the list at you. So on a page with lots of redirects, you'd have to: 1) go "back" a page and find the link you clicked, hovering over it to discover the actual target in the tooltip 2) go "forward" (or click it again) 3) click "what links here" (or "edit this page", though I don't see why it would belong there) and possibly an extra button to get the "what redirects here" display 4) find the link back to the title discovered at step 1 to get at the redirect to edit/view comments in history/etc...

Or, of course, you could manually create a "redirect=no" URL after step 1, but that's hardly a user friendly interface. Maybe I'm making a meal of this, but it seems to me that's not all that unlikely a situation.

If you follow a link in an article and are redirected to a place you didn't expect to be redirected to, then looking at a list of "articles that redirect here" is doubly useful because you can fix other inappropriate redirects as well, not just the one you stumbled upon.

This is a good argument for power users, who understand how redirects work, and may even spot a redirect without any "redirected from" message - though I think even I would be slightly confused if the redirect was instant and invisible. But I'm not sure these are the only users who benefit from the current message, as explained above.

The whatlinkshere page could do with some improvement, though, and perhaps being able to separate the redirects from the "normal" links would be a useful feature to add to it.

-- Rowan Collins BSc [IMSoP]

On 28/11/05, Timwi timwi@gmx.net wrote:

I think you're basing this on the helpdesk questions you've seen. Myself, I haven't ever seen such a question from a confused user, but then again, I don't monitor the various helpdesks we have regularly.

Well, yes, I said I was; but I'm also basing it on the fact that those seemed very logical and reasonable confusions.

I can't really imagine that particularly many people would be surprised at redirects. Almost all redirects make sense. It makes sense for a misspelling to redirect to the correct spelling. It makes sense for synonyms to redirect to each other. And it makes sense for too specific a topic (e.g. a minor fictional character) to redirect to a general article (clearly titled "list of minor characters", in this example).

It's not just a case of redirects "making sense" - when people want to reverse a decision to redirect, it should be as easy as other edits. So if someone decides that two terms *aren't* synonyms, or that a character isn't really that minor at all, they should be able to edit the pages appropriately - I know this argument's much abused, but this does seem rather central to being "an encyclopedia that anyone can edit". And the first step in changing the redirect is to know that the redirect exists in the first place - I'm not convinced people would even find a "what redirects here" list if they were unaware of what a redirect was (though, I guess that's why you suggested putting it on the edit page - so that there was a higher chance of them discovering it "by accident". Still, seems a poor substitute for just announcing the redirection clearly in the first place.)

I think the only people who are "surprised" are those who are actually trying to figure out how things work; those who wonder how Wikipedians told the system that a link to X should redirect the user to Y, as there's no obvious way of doing that.

I guess the users I'm thinking of are those who are just about getting used to the basic principles of the wiki, and understand that [[foo]] should link to an article called "foo" - "how remarkably simple", they think... Then when they are presented with an article called "Meta-syntactic variable" instead, they are surprised - suddenly, the wiki is doing some kind of voodoo and interpretting what they say, rather than obeying it. They may not think of it as "a link to X redirecting the user to Y" at all - they'll just think they've misunderstood the basic "link by typing the title of the target page" philosophy.

So yeah, I guess they're the ones trying to figure out "how things work" - but only in as much as they're trying to participate, as they've been constantly invited to do since they first visitted the site.

Maybe, though, I'm over-compensating for my own system-logical mind (and experience with MediaWiki), and most new users *would* actually come to the correct conclusion with no clues other than consistently arriving at the "wrong" page; I'm not convinced, though.

In passing, I would also challenge your view that "we encourage casual readers and newbie editors to be the same thing" -- although we encourage everyone to join Wikipedia, it is still a product aimed at end-users who generally don't want to participate, so it makes sense to distinguish between the two.

Well, I sort of see your point, though I'd point out that you don't have to "join" anything in order to edit Wikipedia, you just click "edit this page", so the transition from reader to editor is a very subtle one in some senses. But yeah, I'll accept that "redirected from" notices aren't that important to readers - assuming editors are clever enough with their introductions that the redirects *do* make sense - but as soon as you turn editor, you absolutely need to know what's going on.

At this point I was going to make a new suggestion, namely to have a textbox with "titles that redirect to here" on the edit page, rather than a list of links. Redirects would then be edited at the target title, not the redirect's title.

There was a discussion along those lines a while ago (either on this list or mediawiki-l, I forget which), which got rather confusing, to the extent that I'm still not sure if there might be a feasible middle way on this...

-- Rowan Collins BSc [IMSoP]

Jamie Bliss wrote:

...

No, it wouldn't. _My_ point was that if we placed a link to the page you came from _somewhere else_ than a "redirected from" line (e.g. a list of "pages that redirect to here" on the Edit page), you would *not* need to send additional parameters. You could get back to the page a different way than you do currently.

Caching.

The browser can cache anything based on the URL and the headers given in Vary. (Within the bounds defined by the cache headers.)

If you were to use HTTP redirects in this manner (and not add a CGI paramater), then Referer would have to be added to Vary, causing the browser to cache a seperate (but generally identical) version of the page _for every page it is linked from._

How many more times do I have to state that my suggestion does away with the "Redirected from" line? Everyone keeps assuming that.

Jamie Bliss wrote:

I'd say (although I am not on the dev team) write the code and make it a user option.

Making it a user option is a good suggestion, however I hope everyone realises that the new behaviour would have to be default for the change to actually fulfill its intended purpose (improve search engine ranking).

On Sun, 2005-11-27 at 15:05 -0500, Jamie Bliss wrote:

Timwi wrote:

...

Jamie Bliss wrote: Making it a user option is a good suggestion, however I hope everyone realises that the new behaviour would have to be default for the change to actually fulfill its intended purpose (improve search engine ranking).

[...]

My request is that the status "301 Moved Permanently" not be used, and instead use "302 Found", "303 See Other", or "307 Temporary Redirect". (Only 302 is compatible with HTTP/1.0 agents.)

302 doesn't achieve anything with respect to search engines, or at least Google: http://www.google.com/intl/en/webmasters/3.html

It /shouldn't/ work for the others either. If it does, it's because those search engines are broken. 302 is a temporary redirect.

301 was part of HTTP/1.0: http://www.w3.org/Protocols/rfc1945/rfc1945

Rob

Ævar Arnfjörð Bjarmason wrote:

On 11/18/05, Timwi timwi@gmx.net wrote:

...

...

I think it'd be useful for most multilingual MediaWiki installations that use interlanguage links to have such hidden <link> elements.

Speaking of which - this reminds me of an idea I had a while ago and I was wondering if anyone would be interested to hear this. Currently many Wikipedia pages in Google search results are redirects [snip]

I've never understood why people think this is a problem.

It's a problem at least at Google because it means the Google rankings of several articles are split across various URLs that "contain" the same article. If these rankings were funnelled to a single canonical URL, article ratings would be much higher, and Google search results would be more relevant.

If I search for a term in a search engine I think it increases the value of the search if I get a redirect under the title I searched for rather than a synonym for the term which I may or may not be familiar with.

But you *won't* get a search result under the title you searched for (at least not in Google). Google for "nonogram". The window title (and hence the Google search result) displays "Paint by numbers" because that is the title of the article. Except in the URL and in the article's first paragraph, you don't see the word "nonogram".

Timwi

Ævar Arnfjörð Bjarmason wrote:

Could this thread please be kept on topic?

You're (probably) assuming that if people hadn't changed the topic, more traffic would be generated on your original topic. I sincerely doubt this is true. I don't think anyone is discouraged from replying to your original topic by the mere presence of a diverging thread.

The new topic is perfectly on-topic on this mailing list, so you're unlikely to succeed in prohibiting it. But even if it was off-topic, you would merely force it to be moved to another list, but you would still not encourage increased discussion of your original topic.

Timwi