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 should be placed at the main "{foo}" location; i.e. with no article actually at "{foo}", not even the main meaning.
- 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
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'.
The reason why we shouldn't have the disambiguation at "{foo}" is because this enables us to quickly check for articles which have linked to "{foo}", without the writer of those pages having checked to make sure they have linked to the correct meaning of "{foo}".
The thing 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. So, if we had the disambig page at {foo}, when you looked at "What links here", you'd still have 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)", with a redirect to "{foo} (disambiguation)" at "{foo}", then all links to "{foo}" are automatically bogus, and the rest (to "{foo} (disambiguation)") are automatically good - and it will be totally trivial to find the ones that need to be fixed.
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 . Some of those with Wikipedia experience regularly 'clean' disambig pages they created, and I do other ones all the time.
I just spent a couple of hours, a while back, fixing all the link to Cracker, and more recently did all the ones that linked to hack. I'm about to do links to protocol - and check out What links here for that!
The annoying thing is that you go fix them all - and you go back some months later and they are more, and you have to go check them all, all over again, because you probably don't remember any more which ones were legitimate, and which ones are not. And there's no history on "What links here" you can use, to call out only the ones that have been added since the last time you checked!
Yes, I know a jillion pages already use the old way, but that's no reason to keep making more of them - my primary concern at the moment is to stop things from getting any worse.
As to what to do with the existing ones, yeah, that's a big problem. I'm still pondering what to do about the existing ones.
Implementation
Discussion
Implementation Issues
| Proposals System Navigation (advanced users only) | |
|
Proposal lists (some planned pages are still blank):
|