Tim Starling wrote:
An extra feature has been added to MediaWiki allowing "diagonal" linking, with the help of redirects. A link reading [[wikt:fi:kukkala]] on the German Wikipedia will link to http://de.wiktionary.org/fi:Kukkala, which will redirect to http://fi.wiktionary.org/Kukkala .
I'm not sure that is such a good idea, performance-wise... ideally, it should go straight to the correct URL. People would otherwise constantly use "Copy link to clipboard" on these links and fill the web with nonsense links like http://de.wiktionary.org/fi:Kukkala, and we would forever have to keep the redirects working. They are starting to become a little difficult to keep track of, and I'm afraid it's only a matter of time until we will inadvertantly create an infinite loop of redirects somewhere.
In general, redirecting mechanisms should probably be revised to redirect straight to the correct place.
What is the longest chain of redirects we have so far?... http://wikipedia.com/wiki/de:a 302 -> http://en.wikipedia.org/wiki/de:a 302 -> http://de.wikipedia.org/wiki/a 301 -> http://de.wikipedia.org/wiki/A
So there are three things I see that are wrong here:
1. Those redirects should all be 301s, not 302 2. All of those URLs should 301 directly to http://de.wikipedia.org/wiki/A 3. Nothing should link to http://en.wikipedia.org/wiki/de:a (but a [[Wikipedia:de:a]] link on en.wiktionary.org would, according to what you said, causing two unnecessary redirects for every visitor that clicks on the link).
For those who don't already know what's so bad about redirects: (1) Even just one redirect doubles(!) the server's response time. That is extremely noticeable when the servers are slow, which they are almost always. (2) They cost Wikimedia an extra bit of bandwidth. I know this is pretty miniscule, but at the rate that we seem to be creating new redirects, it's going to make quite a difference pretty soon. (3) I'm not sure about this one, but I would imagine that they are detrimental to the Google ranking of the linked-to page.
Greetings, Timwi
Timwi wrote:
I'm not sure that is such a good idea, performance-wise... ideally, it should go straight to the correct URL. People would otherwise constantly use "Copy link to clipboard" on these links and fill the web with nonsense links like http://de.wiktionary.org/fi:Kukkala, and we would forever have to keep the redirects working. They are starting to become a little difficult to keep track of, and I'm afraid it's only a matter of time until we will inadvertantly create an infinite loop of redirects somewhere.
One chief reason for making these links available is to allow interwiki linking from *non-wikimedia* wikis as well. By using a single established prefix (WikiPedia:) you can link to any of our languages without begging third party site admins to add three hundred prefixes to their interwiki maps.
It would be nice to use the "real" URLs directly on our own wikis, of course, for the reasons you mention.
In general, redirecting mechanisms should probably be revised to redirect straight to the correct place.
Timwi makes several good points I agree with about cleaning up the functioning of the redirects to be cleaner and cacheable.
For those who don't already know what's so bad about redirects: (1) Even just one redirect doubles(!) the server's response time.
That's not exactly true; the redirect bounce doesn't require rendering, and if appropriately set up can be cached at the squid level. However, the _best case_ time is doubled, where the best case time is a 301 redirect response followed by a 304 not modified, all based on caching, with no content needing to be rendered or transferred or anything looked up in a database. That should be pretty fast anyway. ;)
-- brion vibber (brion @ pobox.com)
Brion Vibber wrote:
Timwi wrote:
I'm not sure that is such a good idea, performance-wise... ideally, it should go straight to the correct URL. People would otherwise constantly use "Copy link to clipboard" on these links and fill the web with nonsense links like http://de.wiktionary.org/fi:Kukkala, and we would forever have to keep the redirects working. They are starting to become a little difficult to keep track of, and I'm afraid it's only a matter of time until we will inadvertantly create an infinite loop of redirects somewhere.
One chief reason for making these links available is to allow interwiki linking from *non-wikimedia* wikis as well. By using a single established prefix (WikiPedia:) you can link to any of our languages without begging third party site admins to add three hundred prefixes to their interwiki maps.
This is a fair point, but nonetheless an implementation that I'm not entirely comfortable with. (Admittedly, I can't think of a better one other than to encourage the entire wiki community to go entirely multi-lingual and have all wikis standardise on a [[<sitename>:<langcode>:<pagename>]] syntax for links to other wiki sites...)
Another major disadvantage I thought of just now is that it poisons our namespace. Suppose some silly company makes some sort of product and (to be cool) calls it "fr:ea:ky". How would we name our article on it? It's only a matter of time until this will be an actual problem.
For those who don't already know what's so bad about redirects: (1) Even just one redirect doubles(!) the server's response time.
That's not exactly true; the redirect bounce doesn't require rendering, and if appropriately set up can be cached at the squid level.
At the time I wrote the previous message, my experiments with Telnet showed that the server took several seconds to reply with the redirects, but returned an actual article quite quickly. (Both are pretty quick now; maybe load has gone down since?) This leads me to believe that these redirects are not currently handled by the squids, and furthermore, that the load on the server is slowing them down significantly even though, as you say, they do not require rendering.
I'm assuming by "rendering" you are referring to turning Wiki-markup into HTML. While such a redirect doesn't need rendering, it still needs processing of an HTTP request. I'm wondering what proportion of the CPU power spent on a single HTTP request (including TCP handling, HTTP request decoding, PHP parsing and execution, and generating the HTTP response) goes to rendering. If CPU usage is the current performance bottleneck, then determining that a link to [[a]] should actually go to [[A]] might be quite as noticeable as a page rendering, as it is overheaded by the entire HTTP request handling and PHP stuff.
These kinds of redirects, admittedly, do not require access to the DB. This point is only significant if DB access is the current performance bottleneck.
Greetings, Timwi
Timwi wrote:
Another major disadvantage I thought of just now is that it poisons our namespace. Suppose some silly company makes some sort of product and (to be cool) calls it "fr:ea:ky". How would we name our article on it? It's only a matter of time until this will be an actual problem.
This is a non-starter; you can't link to such titles within the wiki, because they are interwiki links. A manually constructed URL used to just give an 'Illegal title' error, except where we had a special-case on www.wikipedia.org to do outgoing redirects.
-- brion vibber (brion @ pobox.com)
Brion Vibber wrote:
Timwi wrote:
Another major disadvantage I thought of just now is that it poisons our namespace. Suppose some silly company makes some sort of product and (to be cool) calls it "fr:ea:ky". How would we name our article on it? It's only a matter of time until this will be an actual problem.
This is a non-starter; you can't link to such titles within the wiki, because they are interwiki links.
Ah, yes. I haven't thought of that. Thanks.
Timwi wrote:
This is a fair point, but nonetheless an implementation that I'm not entirely comfortable with. (Admittedly, I can't think of a better one other than to encourage the entire wiki community to go entirely multi-lingual and have all wikis standardise on a [[<sitename>:<langcode>:<pagename>]] syntax for links to other wiki sites...)
I very much agree with this, but I would make it even simpler. It needs to be uniform and easily understood by non technical users. It should also be usable in the same way from any project. I would promote the format [[wwLLL:pagename]] where the ws represent the project, and the Ls (not necessarily capitalized) represent the language. The language part may be reduced to two letters, as would be the case with most major languages. All top level projects would have a w code. (There should be enough to go around unless we outdo ourseves in the development of entirely new projects.) Default situations can be easily defined, and allowances can be made for intrawiki namespaces.
Another major disadvantage I thought of just now is that it poisons our namespace. Suppose some silly company makes some sort of product and (to be cool) calls it "fr:ea:ky". How would we name our article on it? It's only a matter of time until this will be an actual problem.
It's a losing battle to try to accomodate every "fre:aky" broadband troll; they're always ready to throw another spammer in the machinery. :-)
Ec
Brion Vibber wrote:
Timwi wrote:
I'm not sure that is such a good idea, performance-wise... ideally, it should go straight to the correct URL. People would otherwise constantly use "Copy link to clipboard" on these links and fill the web with nonsense links like http://de.wiktionary.org/fi:Kukkala, and we would forever have to keep the redirects working. They are starting to become a little difficult to keep track of, and I'm afraid it's only a matter of time until we will inadvertantly create an infinite loop of redirects somewhere.
One chief reason for making these links available is to allow interwiki linking from *non-wikimedia* wikis as well. By using a single established prefix (WikiPedia:) you can link to any of our languages without begging third party site admins to add three hundred prefixes to their interwiki maps.
It would be nice to use the "real" URLs directly on our own wikis, of course, for the reasons you mention.
Brion is exactly right. The redirect mechanism was necessary for supporting external wikis. In time we may code a more efficient solution for local wikis. However there are glaring inefficiencies in MediaWiki which may be addressed first.
Note that this redirect feature was previously implemented in the apache configuration files using rewrite rules. There were no rewrite rules for Wiktionary, so instead of adding more, I generalised the mechanism by moving it to MediaWiki, taking advantage of the existing interwiki table to obtain URLs. Thus, it will now work on any wiki farm regardless of apache configuration. It will even work on wiki farms where the prefixes correspond to different directories under the same hostname.
-- Tim Starling
Brion Vibber wrote:
One chief reason for making these links available is to allow interwiki linking from *non-wikimedia* wikis as well. By using a single established prefix (WikiPedia:) you can link to any of our languages without begging third party site admins to add three hundred prefixes to their interwiki maps.
This is a very benevolent approach. :-) Still, the priority should be to make things work within the Wikimedia family. Making it easier for outside should never be more than an incidental byproduct arising out of making things easier for ourselves.
It would be nice to use the "real" URLs directly on our own wikis, of course, for the reasons you mention.
We already have noticeable opposition to using any kind of HTML; I don't see that these people would be made any happier by the need to write out full URLs. :-)
Ec
Ray Saintonge wrote:
Brion Vibber wrote:
One chief reason for making these links available is to allow interwiki linking from *non-wikimedia* wikis as well. By using a single established prefix (WikiPedia:) you can link to any of our languages without begging third party site admins to add three hundred prefixes to their interwiki maps.
This is a very benevolent approach. :-) Still, the priority should be to make things work within the Wikimedia family. Making it easier for outside should never be more than an incidental byproduct arising out of making things easier for ourselves.
Hardly benevolent; begging other site admins to get something I want is a pain in the ass for me when *I* want to link things. If it helps other people, great too. ;)
Anyway, it *already works right now* within the Wikimedia family. If you'd like to go to extra effort to make it slightly prettier or "more efficient", well, I expect to see your patches on wikitech-l.
-- brion vibber (brion @ pobox.com)
Ray Saintonge wrote:
It would be nice to use the "real" URLs directly on our own wikis, of course, for the reasons you mention.
We already have noticeable opposition to using any kind of HTML;
All websites use HTML.
I don't see that these people would be made any happier by the need to write out full URLs. :-)
Why would such a need arise?
wikipedia-l@lists.wikimedia.org