CZ:Proposals/Disambiguation mechanics: Difference between revisions

From Citizendium
Jump to navigation Jump to search
imported>J. Noel Chiappa
(Save draft before I screw up... :-()
imported>J. Noel Chiappa
(Save draft)
Line 9: Line 9:
* 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).
* 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.
* A redirect should should 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.


* All "foo" articles should be at pages of the form "{foo} (song)", "{foo} (automobile)", etc; i.e. disambiguated by a modifer enclosed in ()'s.
* 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 ===
=== 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 [[Special:Whatlinkshere/Tree|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 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 [[Special:Whatlinkshere/Tree|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 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]].
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. 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).
So even a disambig page can have legitimate links to it. So, 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)", 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.
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.

Revision as of 11:19, 13 May 2008

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. 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.
  • 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. So, 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)", 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):