Wikipedia:Tools/Navigation popups/About fixing redirects

{{Essay|interprets=inappropriate use of navigation popups and its {{code|popupFixRedirs}} feature}}

{{Nutshell|It is discouraged to use {{code|popupFixRedirs}} to 'fix' piped links that point to redirects by changing them to direct links as it anecdotally is more resource heavy on Wikimedia servers in the long-term. It is also discouraged by Wikipedia:Don't worry about performance.}}

Some users of Navigation popups are making inappropriate use of the {{code|popupFixRedirs}} feature. Editors believe using this feature reduces the workload on Wikipedia servers, but in reality, it actually increases the servers’ workload.

Say you come across a perfectly legitimate redirect link, for instance (morphosyntax redirects to Morphology (linguistics)):

class="wikitable"

! Wikitext !! Display

-

|Some languages treat unergative verbs distinctly from other intransitives in morphosyntactical terms.

|Some languages treat unergative verbs distinctly from other intransitives in morphosyntactical terms.

The popupFixRedirs feature allows you to hover over the morphosyntactical link, click Redirects, and change the text to:

class="wikitable"

! Wikitext !! Display

-

|Some languages treat unergative verbs distinctly from other intransitives in morphosyntactical terms.

|Some languages treat unergative verbs distinctly from other intransitives in morphosyntactical terms.

(Note: Please don't try it on this page. Popups fixes every case of a redirect where it finds it on a page, and so this essay will make no sense after you "fix" it.)

= Myth =

The new wikitext avoids the redirect and goes "straight" to the "right page", so it must be "better" on the Wikipedia servers, and you're performing a great service by "fixing" the "bad" link, right?

= Fact =

Unfortunately, probably not. Here's why:

  • When a reader clicks on a redirected link (say, morphosyntax), the MediaWiki software performs SQL queries to locate the destination page. That query includes a check as to whether the requested destination is a redirect (every page includes a database field called page.page_is_redirect), and if so, it returns the location of the redirected page. In other words, while it's technically true that it's more expensive to follow a redirect than a direct link, it's only the tiniest hair more expensive. (For those who care, the actual number on a 2006 version of MediaWiki was 44 SELECT statements to follow a direct link versus 48 to follow a redirect.)
  • The editor's action of using Popups to fix a single redirect has MediaWiki do more SQL queries than it takes to follow the redirect, but it also has to do several database transactions and writes. (To be exact, 8 transactions with 64 SELECTs, 10 UPDATEs, 4 INSERTs, and 2 DELETEs, on that same version of MediaWiki.)
  • Database updates – that is, write operations – are several orders of magnitude more expensive on the servers than database queries — that is, read operations. A benchmark ran in January 2006 showed that fixing a redirect is approximately ten thousand times more expensive for the server than following that redirect.

In other words, readers of Wikipedia would have to use a redirect link approximately 10,000 times before it would be worthwhile to replace that link with a direct link. In any case, Wikipedia:Don't worry about performance discourages Wikipedians from worrying about performance, so you shouldn't be trying to fix a redirect to reduce the load on the servers in the first place.

There is a final, perhaps more important, reason not to fix many redirects: The redirect page might be about another but related topic from the one redirected to, and someone might want to create the page in the future; such a page is a redirect with possibilities. When such a page is created, "fixed" redirects will point to an incorrect (or less precise) page.

See also