Help:Ingenpedia: The Missing Manual/Building a stronger encyclopedia/Getting readers to the right article: Naming, redirects, and disambiguation

With more than million articles on the English Wikipedia, how do you get to the one you want? For example, when a reader types "mercury" into the search box, what article do they expect to be displayed? What if someone creates an article called "Mercury (Roman god)" when there already is one called "Mercury (mythology)"?

Wikipedia depends on editors to fix naming errors, to create pages (redirects) that automatically correct typing errors, and to set out guideposts to readers to help them find their way (disambiguation). The cumulative effort of millions of editors has created a web of articles and links that get virtually all readers to the right place within one click.

Naming and renaming
The best way to deal with an error is to not make it in the first place. That's why Wikipedia has a naming convention for just about any kind of new article. The more you and other editors follow these conventions, the less renaming you'll have to do. But with so many naming conventions (see Figure 16-1 for a sampling), new editors can get confused and name articles incorrectly.



Common naming mistakes
This book can't discuss every possible mistake in article names—if it did, you'd need a forklift to carry it. If you have a very specific question about what to name an article for a geographical location in Ireland, for example—whether to use the official Irish name or a former English name—you'll probably find an answer at the policy page Naming conventions (shortcut IN:NC), which links to dozens and dozens of naming convention pages. (You can find the whole list at Category:Wikipedia naming conventions, shortcut: CAT:WNC.) You can avoid the vast majority of errors, however, by keeping the following points in mind:


 * Capitalize only the first word of article titles and section titles. All other words in a title start with lowercase letters unless they're proper nouns and are capitalized anyway. If the title of the article is the title of a work like a book or a song, minor words like "in" are not capitalized, while the rest of the words in the title are: for example, "A Fool in Love".
 * Use the most common name. Don't use a person's formal first name ("Christopher" rather than "Chris") or add a middle initial to a name if that's not the most common usage. If you're not sure, use a search engine and compare the counts of results for each option.


 * When several people in Wikipedia articles share the same common name, like George Allen, some editors try to differentiate between them by using a less common version of the name. For example, the article for the politician George Allen was once named "George Felix Allen", then "George F. Allen". The problem with these less common names is that they give you no clue, when you see them in an index or wikilink, as to who the person is. So avoid this approach. Check the disambiguation page (see the section about disambiguation), if there is one, and follow the established pattern there. In this example, George F. Allen became "George Allen (politician)".


 * Organizational titles. Don't start an article title with "The". The correct form is "Council of Organizational Associations", rather than "The Council of Organizational Associations".

Renaming an article
Renaming an article is technically easy. The trouble comes when you do something that other editors consider controversial. If you're fixing a clear error, and don't have any particular interest in the topic of an article, then go ahead and rename the article. (That is, do what Wikipedia calls a page move, as described in the section about renaming pages.)

On the other hand, if you have any reason to think the rename (move) might be opposed, then don't make it until you've discussed it on the article talk page. Treat a potentially controversial page move just as you would a controversial rewrite of an article.



Discussing a rename
To reach consensus about renaming a page, start a discussion on the article talk page. Focus the discussion on which naming policy and appropriate naming conventions apply. Avoid arguing, for example, that you like a certain name better, or that you find a name insulting. Stick to citing or interpreting policy and naming conventions.

When debating the name of the page or discussing merging it with another page, always mention the current page name. Otherwise, references to "this page name" become ambiguous after the page is renamed.

If you and the other editors can't reach a rough consensus, or majority rule on the move, then you can move on to one of the methods for resolving content disputes (see Chapter 10: Resolving content disputes). In addition, you can list the proposed move at the page Requested moves (shortcut: IN:RM). That page lets you request wider community input on your move debate. But if more than just a couple of editors are involved in the discussion and consensus can't be reached, it's probably time for you to move on to other, more productive matters than changing an article title.

Renaming a page
If there's no controversy about a move, or if you've reached consensus with other interested editors, renaming a page is technically easy. The following steps rename the article Samuel E. Wyly to the common, and correct, "Sam Wyly."

To practice along with this tutorial, you need to be logged in (anonymous IP users can't rename pages), and you must have had an account for at least four days. Instead of the Sam Wyly article (or other real article), move a subpage in your user space. (To see how to create such a subpage, see the section about creating your personal sandbox.)

1. Starting at the page you want to move (rename), click the "move" tab near the top of the page (see Figure 16-3).


 * You arrive at the Move page page, shown in Figure 16-4. It contains a long list of instructions and warnings and, at bottom, a short form for typing the new article name and performing the move.

2. In the "To new title" box at the bottom of the Move page page, type a new name for the page. In the Reason box, explain why you're making the move.


 * Figure 16-5 shows the form filled in with new name and reason.

3. Click the "Move page" button.

4. You'll see a new page with "Move succeeded" in small print, at the top of the page (Figure 16-6). You're almost done.

5. Click the bolded "check" link to check for double redirects.


 * You'll see a page listing all the pages that link to the newly named page (see Figure 16-7). If you don't see any double redirects, as is the case here, you're done.

When administrator assistance is required
In general, if you want to rename page A to become page B, but page B already exists, you won't be able to do the renaming yourself. You must ask an administrator to make the move.

If you can't move a page, list the proposed move at Requested moves (shortcut: IN:RM), where administrators and other editors will review it. Requests are generally processed after a seven-day review period, although backlogs of a few days develop occasionally. If there's a clear consensus after this time, the request will be closed and acted upon. If not, an administrator may choose to relist the request to allow time for consensus to develop, or to close it as "no consensus," in which case the move isn't going to happen.

Alternatively, if a move is non-controversial, but an existing page at the new name is in the way, you can request a non-controversial move at Requested moves/Technical requests (shortcut: IN:RMTR). See that page for instructions. An administrator or page mover should then move the page – or decide the move is in fact controversial and start a seven-day discussion as described above – within a few hours.

For old names and bad spellers: Redirects
When you or another editor moves a page, the old page name doesn't go away. Instead, it becomes a redirect page (or simply a redirect). That's good—other pages in Wikipedia are probably linked to the old name, and the redirect means the links on those other pages still work. They take the reader to the page in its new location.

You need to understand how redirects work for two reasons. First, sometimes a page move causes a double redirect, which you need to fix. Second, if you want, you can create redirects that will catch common spelling mistakes and get the reader to the right page.

How redirects work (and where they come from)
To understand why redirects exist, and how they work, consider this generic situation: Article A has a direct wikilink to article B. Say you move article B, changing the title to C. When you do, Wikipedia places a notice to itself—a redirect—at page B, pointing to the new name of page C. A reader clicks the link on page A. The software goes to page B, which still exists, but is now a redirect. The software sees the redirect and takes the reader to page C, where the desired article is now located, and displays that.

Why didn't the Wikipedia software, when you renamed page B to page C, simply change the wikilink at page A, so it points directly to C? One reason—perhaps the most important—is that Wikipedia software never, ever changes a page. Only editors can change pages, and such changes are shown in a page history. Also, the link from A to B could exist in many, many older versions of article A (hundreds, even thousands of prior versions). If B no longer exists, the links on all the older versions of page A become broken. The software would have to change all those hundreds of older versions to point to C as well. Fixing those wikilinks could be a huge load on the Wikipedia hardware, from just a single page move.

Here's an example to illustrate how a redirect caused by a move works, using actual article names. Consider the move of the article about the venture capital firm Kleiner, Perkins, Caufield & Byers to a page with a new name: Kleiner Perkins Caufield & Byers (the change was the deletion of commas, which aren't in the firm's actual name). At the time of the move, the article Sand Hill Road had a link to the old, incorrect name. Figure 16-8 shows what happens when a reader clicks that link.



Adding a redirect
Redirects are useful for more than when you move a page. You can create redirects when there's an alternative term for a subject, when there's alternative capitalization and/or hyphenation, and when there's an alternative spelling (for example, British versus U.S.).

You can also use redirects to help readers get to the right page when they misspell a word or phrase, or enter incomplete information. For example, if you've just created a new article about a person, and you know that it's common to misspell the name of that person (Arnold Schwarzenegger, for example), you can create a redirect so that when a reader searches for the misspelled name (Schwartznegger), a redirect sends the reader to the article.

In fact, if you attempt to go to an article via the search box, and get "No page with that title exists" because you've misspelled a word, others will probably make exactly the same mistake. If so, you have an opportunity to create a redirect, so you'll be the last person ever to see that search results page rather than the desired article.

Creating a new redirect page


The following steps walk you through the process of creating a redirect. First, you need a common misspelling to redirect from. If you can't think of one off the top of your head, you can use, say, Microsoft Word's list of commonly misspelled words (see Figure 16-9).

1. Type a misspelled word into Wikipedia's search box, click Go (or press Enter), and see if you get a response of "No page with that title exists."


 * If so, you've got your example.

2. Put the correct word into the search box to see where that goes, which is where your redirect page should send the reader when they type the incorrect spelling into the search box.



3. Suppose, for the sake of example, that you type "lisence" into the search box and see a page titled Search with bolded words "No page with that title exists" (Figure 16-10.).

4. Leaving open the window shown in Figure 16-10, open another browser window, and, in Wikipedia's search box, type the correct spelling of the word or phrase.


 * Wikipedia takes you to the page with the article you wanted. It's "License" in this example, which is what you're going to redirect to. This step is important because you need to know the exact title of the page to redirect to (License, Licensing, or whatever).

5. Copy the correct name of the article (press Ctrl+C or ⌘-C). Close this second window when you've done this copying.


 * If you copy the name, you don't have to worry about misspelling the article name when you create a redirect, which could be embarrassing.

6. Back at the original window, click the bolded red "create this page" link.


 * You'll see a new page, titled Editing Lisense (for example), with a bunch of advice about creating an article. Since you're creating a redirect, not an article, ignore the advice and scroll down to the edit box.

7. In the edit box, paste the text of the correct name, highlight this text, and click the "#R" icon.


 * You see the text for the new redirect Figure 16-11. Your redirect is almost there.

8. Add an edit summary (Creating redirect works well), and do a quick preview.


 * The preview shows what your new link will look like, plus the wikitext (Figure 16-12).



9. Click the "Publish changes" button.


 * When you see a page with the misspelled title at the top and the correct link below (Figure 16-13), you're done!



10. For quality control purposes, click the link.


 * If that takes you to the wrong page, or even to a different page via a redirect, you need to fix the redirect so it points directly to the page it should. In your browser, click the Back button to get back to the redirect page. Click the "edit this page" tab, and fix the text within the double square brackets (see #4 in Figure 16-11). Then add an edit summary, preview, and 'publish changes' again.

Redirects are handy for more than misspellings. For example, suppose you want to create a redirect for a relatively unknown product, called, say, ObscureProductX. Wikipedia doesn't have an article for ObscureProductX, since it's not notable enough. But the product is manufactured by ObscurbaCorp, about which Wikipedia does have an article. You can create a page ObscureProductX, and on that page put  #REDIRECT ObscurbaCorp . Someone searching for information about that product will be redirected to the article where it's mentioned.

Enhanced redirects
You can create redirects that take the reader to a section of an article rather than to the top of the page. Continuing the previous example, suppose there's a section of the fictional ObscurbaCorp article called "Unusual health products," and that's the only section that mentions ObscureProductX. In this case, create the redirect wikitext like this:  #REDIRECT ObscurbaCorp . The "#" sign tells the Wikipedia software that what follows is the name of the section ("Unusual health products").

Redirecting to a section, which sends the reader to the middle of an article, has one disadvantage. For example, if the "Unusual health products" section mentions ObscureProductX just briefly near the bottom of a long section, the reader could get confused about why they were sent there. Redirecting to the top of the article, from which a search will find the product, might be better. By contrast, if the redirect in the example had been to a section called "ObscureProductX's evaporation problem," there'd be no confusion.

You can also add a template to a redirect that puts the redirect into a category (see the chapter about categorization)—for example, redirects that deal with misspellings. The guideline Redirect (shortcut: IN:R) lists a number of these, although most are likely to be useful only if Wikipedia begins using redirects as a database. You should use R with possibilities for redirects involving topics that might justifiably become an article at some later time. Adding that template puts the redirect page into the "Redirects with possibilities" category, which editors can use to find ideas for new articles. Simply put the template on a redirect page immediately after the ending double square brackets.

Fixing a bad redirect
Redirects don't often go bad, so it's rare that you have to change one (except for double redirects, as described in the next section). But sometimes, perhaps due to vandalism, when you click a link on page A, get redirected via page B, and end up on page C, it's clear that page B points to the wrong place. To fix it, you could change the link on page A to point directly to where you want it to go, but if there are other links that go via redirect B, those links are still going to be wrong. Redirect page B needs to be fixed.

The challenge here is that if you type "B" into the search box, the Wikipedia software takes you to page C (that's what redirects do). To edit page B, not C, look for small print near the top of the page that says "Redirected from," followed by a link (see Figure 16-8 for an example). Click that link to go to the redirect page (B) itself.

Once you're at the redirect page, fixing it is straightforward: Click the "edit this page" tab, change the text within the double square brackets (see #4 in Figure 16-11), add an edit summary, preview it (Figure 16-12), and publish the change.

Fixing double redirects
In the steps in the section about renaming a page, renaming the Samuel E. Wyly article didn't cause any problems with double redirects. As mentioned there, double redirects are when a link on page A goes to redirect page B, which goes to redirect page C, which points to page D. In such a case, when a reader clicks the link on page A, the Wikipedia software displays the redirect page C, which isn't what the reader needs. The link on page A or the redirect on page B needs to be changed.

Understanding double redirects
Before discussing how to fix a double redirect, consider why the software won't take the reader to page D, even though that's clearly the right place. Or, to be precise, why the software doesn't let two redirects function sequentially. Suppose an editor set up redirect page C so that it pointed back to redirect page B? The software would go in circles, processing the same instructions over and over, until a human intervenes or a mechanical failure occurs. (In computer speak, that's called an infinite loop.)

Sometimes you stumble upon double redirects, but the best time to find and fix them is when a page move creates them. Using the renaming of Kleiner Perkins Caufield & Byers (see the section about redirects) as an example again, suppose you had just done that page move and you're at the last step—checking for redirects. When you look at the "Pages that link to" page, in addition to the non-indented links (which point directly to the article as it's currently named) and single-indented links (which are linked by one redirect), you see some double indents. The double indents represent double redirects, like Brook Byers in Figure 16-14.

The clue to a double redirect is to look for the black text "(redirect page)" mixed in with the blue links (page names). The first "(redirect page)" you find is okay (that's a single redirect), but should you find a second redirect page that is indented under the first, then you've found a double redirect that needs to be fixed.



Fixing double redirects
A number of the links in Figure 16-14 won't work because of double redirects. You have two choices: Fix the links within articles, so they bypass redirects altogether, going directly to the new page name; or, change a redirect. In other words, if article A links to redirect B, which points to redirect C, which points to article D, then you can fix the redirect by changing redirect B so that it points directly to article D. B is now a single redirect, which is okay. Here's how to decide which to do:


 * Most of the time, fixing a redirect is better than changing the links to the redirect. In Figure 16-14, notice the large number of links to the redirect Kleiner Perkins. Fixing one redirect is faster than fixing a whole bunch of links.
 * When there's a spelling mistake or something else where the reader is being misinformed, it's best to fix both the links and the redirect. In the redirect Kleiner Perkins Caulfield & Byers, the word "Caulfield" is wrong (it should be "Caufield"). Since there are only two links to this redirect, that's an easy decision—fix the two links plus the one redirect.

Fixing a double redirect is easy. Here are the steps:

1. At the top of the "Pages that link to" page, copy (to the clipboard) the current name of the article.


 * Use Ctrl+C, ⌘-C, or whatever works best for you. Copying reduces the likelihood of a typing error.

2. Find a double redirect (for example, Tom Perkins in Figure 16-14), and open it in a new tab or window. Click the "edit this page" tab to get into editing mode.


 * In the edit box, the old page name is inside double square brackets.

3. Select (highlight) the text inside the square brackets, and then paste (Ctrl-V or ⌘-V) the new name of the article over it. Tab to the edit summary box and type a brief explanation.


 * Something like Fixing double redirect is a good edit summary. When you're done, click "Show preview."

4. Click "Publish changes".
 * You've fixed a double redirect. Close the page or tab you opened (step 2), which brings you back to the "Pages that link to" page, and do the same for all other double redirects.

Once you've fixed all the redirects that didn't point directly to the new name of the article, you can turn to any pages that have a link with a misspelling or other misinformation. Although these links now work, since the double redirects are gone, you may still need to correct other errors.

At the very end, check your work. Refresh the "Pages that link to" page (press Ctrl+R or ⌘-R) to make sure that everything you wanted to fix was fixed.

For multiple meanings: Disambiguation
Disambiguation is a fancy word for how Wikipedia handles a single term that's associated with more than one topic. If you type a word or name that pertains to more than one article—Jerry Lewis, for example—disambiguation helps you find the article you're looking for.

You see disambiguation in two places:


 * Disambiguation pages. These are separate pages where you can pick a link to go to the article you want. Such pages normally begin something like "Mercury may refer to," followed by a list of several article links to choose from.
 * Hatnotes. These are notes at the top of an article that say things like "For other uses of the word mercury, go to mercury (element)." In this case, the link may go directly to another article, or, if there are several alternative articles, to a disambiguation page—as in mercury (disambiguation).

Figure 16-15 shows both types of disambiguation.



Creating and updating disambiguation pages and hatnotes at the top of articles are important skills for an editor. This section also shows you how to find and fix links in the body of articles that incorrectly go to a disambiguation page instead of directly to a specific article.

Disambiguation in Wikipedia involves fairly specialized knowledge, so this section starts out by introducing disambiguation concepts and helpful tools for getting readers to the right page. Then, when you end up at a page that isn't where you thought it was going to be, you'll be able to fix the problem.

Disambiguation pages
Disambiguation pages, as shown at the bottom of Figure 16-15, are easy to use, but creating them involves a bit of complexity. Naming such pages effectively is crucial. It's also important to get the formatting right. A good disambiguation page has enough details so readers can find the article they're looking for, but not so much text that they get muddled.

Naming disambiguation pages
Wikipedia has tens of thousands of disambiguation pages, which fit into two groups—those that have (disambiguation) as part of their name, and those that don't. Going back to the Jerry Lewis example, since the comedian Jerry Lewis is more well known than, say, a politician named Jerry Lewis, when you type Jerry Lewis into the search box, you arrive at the article about the comedian, titled Jerry Lewis. The other (not quite as famous) person has an article titled Jerry Lewis (politician).

Now suppose the two Jerrys are equally well known. The previous arrangement wouldn't be fair. Or suppose there are several other famous Jerry Lewises as well. In such cases, the page titled Jerry Lewis should be a disambiguation page, listing individual articles called Jerry Lewis (politician), Jerry Lewis (comedian), and so on, exactly as shown in Figure 16-15. Figure 16-16 shows another example.



With disambiguation, Wikipedia aims for the principle of least astonishment—that is, to avoid surprising readers. So if there's a predominant article that most readers will expect—like an article about the comedian Jerry Lewis—searches for Jerry Lewis go directly to that article. That article has a disambiguation link going to a disambiguation page: Jerry Lewis (disambiguation). If there's no overwhelmingly popular answer, as is the case for Donald Davidson, then searches for Donald Davidson go to a disambiguation page of the same name.

Proper formatting and entries
Once a disambiguation page has a title, it needs two more elements—an introductory sentence and the entries. The guideline Manual of Style (disambiguation pages) (shortcut: MOS:DAB) goes into great detail about how to format these elements.

Disambiguation pages get one of three standard opening sentences. After the name of the topics comes "may refer to:," "is the name of:," or "may stand for:," as shown in Figure 16-17 (top). The exception to these three is for pages with (disambiguation) in the title, where there's a clear primary meaning. In such cases, a sentence defining that primary meaning, with a link to the article, is recommended.



After the brief opening sentence or sentences, the bulleted entries immediately follow. Make sure entries are in order of usage, with most-used meanings at the top. Here are some more tips:


 * The first word or phrase in each entry normally has one navigable (blue) link. These links shouldn't be piped; they should show exactly the name of the page that readers will go to when they click.


 * One exception is when an entry is only one section in an article. In that case, you can link to that section with a piped link, and the link doesn't have to be at the beginning of the entry (see Figure 16-18.)


 * Keep descriptions in entries minimal. In general, don't exceed a single line onscreen. For example, for people, include their birth and death years (when known), plus brief descriptive information to help the reader distinguish between different entries.
 * Don't bold or italicize entries. If part of an entry should be italicized (for example, the name of a song), then use a piped link—for example,  Flower (Liz Phair song) .

As for what entries should and shouldn't be included, keep in mind the following:


 * A disambiguation page isn't a list of all entries that include a given word or phrase, but rather a place for readers who can reasonably be expected to arrive at that page.
 * If there is a reasonable chance of reader confusion due to misspelling ("Kington" versus "Kingston"), put the misspellings in a separate "See also" section.
 * You should add links to a non-existent article ("redlink") only when you're confident that an encyclopedia article can be written on the subject. (Every entry should have a link, either blue or red; a disambiguation page isn't a directory to the Internet.)

Long disambiguation pages can be broken into sections ("Science," "Music," "Popular culture"). If there are four or more sections, put the template TOCright at the top of the page to float the table of contents to the upper-right corner of the page (see the section about floating the table of contents for details).



Finally, at the bottom of a page, there must be a disambiguation template telling readers what the page is and reminding them to fix improper links. It also puts the page into a proper category. Figure 16-19 lists the choices for such a template. For example, Geodis is for locations (towns, rivers, and so on) and Hndis for human names. If more than one specialized template would apply to the page, use the general template disambig.

Fixing incoming links to disambiguation pages
With the exception of clarifying links at the top of articles (see the section about Hatnotes), articles should never have a link to a disambiguation page. But editors do make mistakes. For example, a British editor might wikilink the word "lift," unaware that the page Lift is a disambiguation page. (The editor should have used the piped wikilink  lift , which would display "lift" to the reader while taking the reader, if they click that link, to the article Elevator.)



Finding and fixing wikilinks that link to disambiguation pages is easy: At a disambiguation page, in the "toolbox" links at the left side of the screen, click the first one, "What links here." Change the Namespace box to "(Main)," and click Go. You'll see a list of pages with links to the word "lift," as shown in Figure 16-20.

For each article that links to the disambiguation page but shouldn't, go to the article and edit the link so it's correct. For example, in the Jet airliner article, you would change  wing lift performance  to  wing lift performance , since the word "lift" should link to the article Lift (force).

These erroneous links accumulate over time, since editors rarely verify wikilinks when editing an article, and readers taken to disambiguation pages rarely see the note on the bottom of such pages about fixing incoming links. So, not surprisingly, there's a IngenProject (see Chapter 9: IngenProjects and other group efforts) for those interested in fixing disambiguation links: IngenProject Disambiguation. But you don't have to be a member of that IngenProject to fix problems.

Hatnotes


When a term is ambiguous, like, say, Ally McBeal, readers may not reach the article page they expected (the TV show instead of the character herself). In such cases, the article should contain, at the top, one or more links to alternative articles. You create these links using a hatnote template, not formatting them by hand. Figure 16-21 shows the simplest example, the for template, in action:

There are a large number of such templates. The notes at the top of pages created by these templates are often called hatnotes. You can find a fairly complete list of these templates at the guideline Hatnote (shortcut: IN:HAT). You only need to know the basic concepts, not memorize the list. (A more organized list is found at Otheruses templates (example usage), shortcut: IN:OTEU.)



Hatnotes come in a long form ("This article is about the concept X; for the concept Y, see link") and a short form ("For the concept Y, see link"). Don't argue with other editors about which to use—it's not worth the trouble. But if you're adding a hatnote yourself, generally use the short form. Figure 16-22 shows an extreme example of how awkward the long form of a hatnote can be.

As a rule, add disambiguation links only when there's a good chance that a confused reader has arrived at the wrong article. Thus, for an article like Tree (set theory), a hatnote pointing to the page Tree (disambiguation) isn't needed, because someone reading up on set theory isn't expecting to read about greenery. Don't use disambiguation template links that have nothing to do with disambiguation. So, for example, in the article Merck & Co., it's incorrect to put a note at the top of the article saying "For the controversy over the drug Vioxx, which was manufactured by Merck, see Rofecoxib."

In an article's wikitext, hatnote templates go below cleanup templates (also called article messages boxes, amboxes, and message templates) and should, in turn, be followed by images, navigational and infobox templates, and other article content.



For articles that can be confused with each other but aren't actually related (homonyms and homophones, for instance), use the distinguish template. Figure 16-23 shows an example, and the underlying wikicode.