CZ:Proposals/Disambiguation mechanics

This proposal has not yet been assigned to any decisionmaking group or decisionmaker(s).
The Proposals Manager will do so soon if and when the proposal or issue is "well formed" (including having a driver).
For now, the proposal record can be found in the new proposals queue.

Driver: J. Noel Chiappa

Complete explanation

All articles/names which have multiple potential meanings (i.e. need disambiguation) will be handled as follows:

• The disambiguation page (i.e. the page that lists all the potential meanings, and provides links to the articles, for those for which we have articles) should be at "{foo} (disambiguation)" (where {foo} is the name in question).

• A redirect should always be placed at the main "{foo}" location; i.e. with no article actually at "{foo}", not even the main meaning. That redirect will normally point at the disambiguation page (see discussion below for possible exceptions). It will also be placed in a category, to allow all such disambiguation redirects to be easily found.
  • The talk page of the redirect should always be redirected to the talk page of the disambiguation page, for discussion of any issues related to the redirect in only one location.

• All "foo" articles should be at pages of the form "{foo} (song)", "{foo} (automobile)", etc; i.e. disambiguated by a modifer enclosed in ()'s.

Reasoning

Always having a redirect at "{foo}" enables us to quickly check for pages which have linked to "{foo}" without the writer of those pages having checked to make sure they have linked to the correct page for whichever meaning of "{foo}" they wanted.

If the disambiguation page is always at "{foo} (disambiguation)", and there is always a redirect at "{foo}", then all links to "{foo}" are automatically 'wrong' (although they might accidentally wind up at the right page - see below), therefore making it totally trivial to find the pages that need to be fixed.

On a periodic basis, the 'What links here' of all such redirects should be checked, and all articles linking to it updated to link to the correct page; this way, there is no 'build up' of 'legitimate' entries in the 'What links here', since there are no such 'legitimate' entries.

The reason why we don't want the main content at "{foo}" is that with a popular page like tree, it's impossibly painstaking to go click on every entry in What links here, and look through each page in that list to find all the references to tree, to make sure they are all to the arboreal "tree", as opposed to someone who wanted, say, a 'tree data structure'.

Even worse, even were such a painstaking sweep performed, after some time had passed, the list might again contain erroneous links - with no way to sort them out from the mass of previously checked links (since there is no 'History' for 'What links here').

Although the redirect at the 'main' name (e.g. tree) would generally point to the disambiguation page (so that for readers of articles which link to the ambiguous title, they are at most one click away from the article they want), we might make some exceptions. In some cases, such as tree, where one meaning is much more common than others, we could set that redirect to point directly to the article on the primary meaning; that article would contain the usual link at the top of the article (for other meanings, see tree (disambiguation)). This would still provide most of the benefits of this proposal (i.e. making it very easy to find articles which have linked to ambiguous article titles), but be a little more user-friendly, in that in most cases of ambiguous links, the extra click would not be needed.

The reason why we shouldn't have the disambiguation at "{foo}" is that for many disambiguation pages, there are some meanings of "{foo}" which don't have articles, and linking to the disambig page is the right thing (since the meaning is defined there). E.g. for "hack", some of the meanings don't have pages (e.g. party hack), and so some pages might legitimately link to hack (disambiguation), e.g. an article on Soviet art.

So even a disambig page can have legitimate links to it, and if we had the disambig page at "{foo}", when 'What links here' for the page was examined, there would still be a mix of legitimate links, and bogus ones (where someone was lazy, and linked to "{foo}", without checking to see what they got).

However, if the disambiguation page is always at "{foo} (disambiguation)", then all links to "{foo} (disambiguation)" are automatically good.

Background

This proposal is based on a great deal of practical experience (principally at Wikipedia), and was originally proposed there some time ago; time has not changed those conclusions.

So many instances of the kind of problems with the Wikipedia style of disambiguation pages have been seen that it's amazing that Wikipedia still uses their existing system.

Some of those with Wikipedia experience have either regularly 'cleaned' disambig pages they created, or tried to clean up other ones, and it's always a fair amount of work. The most annoying thing is that one can go fix them all - and go back some months later and they are more, and one has to go check them all, all over again, because one usually doesn't remember any more which ones were legitimate, and which ones are not. And there's no history on "What links here" one can use, to call out only the ones that have been added since the last time it was checked!

Implementation

Unlike Wikipedia, where a jillion pages already use the old way, we still have a manageable problem on our hands. Since this is not a technical change, merely a change to usage, there is no need to have a 'flag day' where we fix all the old pages. People can fix them as they run across them, and have the time and energy to do so.

There is, however, no reason to keep making more of them, so if we adopt this, we should spread the word about the new policy, to prevent making unnecessary work for us (by creating things we will later have to fix up).

Using the same reasoning ('don't make the hole any deeper'), we should try and fairly quickly move all article pages to their new, disambiguated names (that's all that's absolutely needed - the redirect will maintain all the existing links to that name until someone gets around to fixing them). That way, new links to those articles go to the new name, and won't need to be corrected.

Implementation issues

There aren't very many implementation issues.

• What to call the category all the redirects are placed in? I would suggest "Disambiguation redirects".

Open issues

There aren't really very many open issues in this.

• Probably the biggest one is 'when do we grant an exception to allow the redirect to point to the main meaning, instead of the disambiguation page'? I would suggest that this is probably something to be decided on a case-by-case basis (the issue to be discussed, and settled, on the talk page of the disambiguation page), with the general guideline that one particular meaning should be preferred only when it is overwhelmingly the most popular meaning. Or is this likely to lead to too many interminable debates? If so, we could simply say that it always has to point to the disambiguation page, or say that a Constable gets to make a decision which is binding, saving an appeal to e.g. the Editorial Council.

• Some people will no doubt be offended at having to title the article on trees at "Tree (plant)". I had proposed on the Forums that we separate page-names from article titles, but a few people strongly disliked this idea. If we had that technical capability, we could of course avoid this issue entirely. Without it, however, we are forced to chose one of either i) ugly article titles, or ii) widespread links to the wrong page (as on Wikipedia), and to me the former is the lesser of two evils - especially as we are already living with that evil in article titles like "Charles I (Spain)".

• Should we add all the disamguation pages to a Category? If so, how should this be done - with a standard template which all such pages should include, as in Wikipedia?

Discussion

Proposals System Navigation (advanced users only)

Help/policy New proposals List of all proposals Driverless proposals: proposals that lack a champion Discarded proposals: poorly formed proposals Templates: {{Proposal}} | {{Proposal assignment}} | {{Proposals navigation}}

Proposal lists (some planned pages are still blank): Editorial Council: Active | Finished | Declined Approval and Feedback: Active | Finished | Declined Eduzendium: Active | Finished | Declined Recruitment: Active | Finished | Declined Constabulary: Active | Finished | Declined Executive: Active | Finished | Declined Technical: Active | Finished | Declined PR: Active | Finished | Declined Ad hoc management: Active | Finished | Declined