CZ:Proposals/Disambiguation mechanics/Archive 1

From Citizendium
< CZ:Proposals‎ | Disambiguation mechanics
Revision as of 16:35, 19 July 2024 by Pat Palmer (talk | contribs) (Text replacement - "Ruby programming language" to "Ruby (programming language)")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

This is an Archive for CZ:Proposals/Disambiguation_mechanics (made on 9/29/2020)

Note: This proposal is not about when we should disambiguate, which names/articles should be disambiguated, what a disambiguation page should look like (e.g. how should it be organized, and what should it contain), etc. It's only about the low-level mechanics of how disambiguation should work.

Complete explanation

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

Article "A" is a redirect, any article that points to "A" has a term that needs to be pipelinked, although more often than not it will redirect to the "expected" term.
Article "B" is a redirect, any article that points to "B" has a term that needs to be pipelinked to the correct usage.
  • The disambiguation page (i.e. the page that provides links to the articles, for those meanings for which we have articles) should be at "{BaseName} (disambiguation)" (where {BaseName} is the name in question).
  • A redirect should always be placed at the base "{BaseName}" location (in diagrams "{BaseName}" is "A" and "B") ; i.e. with no article actually at "{BaseName}", not even the main meaning. That redirect will point at either the disambiguation page (see example B), or the most common meaning of the disambiguated term (see example A and read the discussion below for when we follow this strategy). 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; that way, discussion of any issues related to the redirect will all be in only one location.
  • All "BaseName" articles will always be at pagenames with an unambiguous name, which will usually consist of "{BaseName}" plus some disambiguation elements (Examples in diagram use "A of X", "A (y)" and "A (Z)"). This may be an extended name (e.g. Ruby (programming language)), but if no such obvious extended name exists, we will disambiguate with a modifier enclosed in ()'s, producing pagenames of the form "{BaseName} (song)", "{BaseName} (automobile)", etc.

Reasoning

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

If the disambiguation page is always at "{BaseName} (disambiguation)", and there is always a redirect at "{BaseName}", then all links to "{BaseName}" 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. With this scheme, there is no 'build up' of 'legitimate' entries in the 'What links here' to wade through, since there are no such 'legitimate' entries.


The reason why we don't want the main content at "{BaseName}" is that with a popular page like tree, it's impossibly painstaking to go click on every entry in its What links here, and look through all the text of 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 'base' name will often 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 will often point it to a particular meaning.

Where one meaning is much more common than others (e.g. dog), we can set the 'base' redirect to point directly to the article on the primary meaning. I.e. if we redirect from "dog" to "dog (animal)", writing [[dog]] in an article will get exactly the same result as under the old system.

In other words, we could, if desired, in all cases where we would previously have had one particular article at "{BaseName}", and all the others at "{BaseName} ({Disambiguator})", we would have the redirect at "{BaseName}" point to that article, and not to "{BaseName} (Disambiguation)"'.

Taken to the extreme, the effect of this would be that things will work exactly as they did before, i.e. someone could write an article with links to dog, ball, etc, and they would get exactly the same articles as they would before this proposal.

This will allow the work of creating articles to be exactly the same as the old system; people won't have to check to find out the proper article title to link to, they won't have to type any extra characters (e.g. [[dog (animal)|dog]], etc, etc. We hope most authors will take the extra effort (since everyone should always be checking all their links anyway, because what one person considers the 'obvious' choice for an ambiguous term, someone else might not), but it's not necessary that they do so.

Even were we to take this to the extreme, it 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 author-friendly (as above), and user-friendly. For the users, in the case of links to an ambiguous term, in most such cases, the extra click would not be needed.

The article at the 'base' name would contain a link to the disambiguation page at the top of the article (e.g. For other meanings, see tree (disambiguation)).

Someone else (likely aided by a bot, to make the work easy) can come along later and fix the link to go directly to the appropriate target, i.e. update those links to go directly to "dog (animal)", "tree (plant)", etc, and not via the redirect at "{BaseName}".


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' either disambig pages, or the article at the 'base' name of a term that has multiple meanings, 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 erroneous links, 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 ambiguously-named 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 such time as someone gets around to fixing them). That way, hopefully, new links to those articles will go to the new name, and won't need to be corrected later.

Implementation details

  • All the redirects to the disambiguation page will be tagged with a template, which adds them to a category, so it's easy to find them all to check them. (The reason it's via a template, as opposed to directly, is that that allows us to change what we do with these redirects without editing every last redirect.) The redirects will look like this:
#Redirect [[DisambiguatedName (disambiguation)]] {{dabredir}}
  • All pages which are the 'base' meanings, and have the redirect at the base term pointing to them, will have the template {{dambigbox}} at the head of them, which says:
This article is about Proposals/Disambiguation mechanics/Archive 1. For other uses of the term Proposals/Disambiguation mechanics/Archive 1, please see Proposals/Disambiguation mechanics/Archive 1 (disambiguation).
  • All such 'base' meaning redirects will be tagged with a similar template, {{mainredir}}, which tags them with a (different) category.
  • All disambiguation pages should be tagged with the {{disambig}} template, which in addition to a standard explanatory text header, tags them with a category.
  • References to the definition page of a disambiguated term are undesirable; authors should be encouraged to use the definition of the specific meaning they want. {{R}} now understands disambiguation, and if given "{DisambiguatedName}", and "{DisambiguatedName} (disambiguation)" exists, it pops up a nice little warning message. For those places where the disambiguation page does not yet exist, direct uses of the definition, etc, place {{dabdef|{DisambiguatedName}}} in "{DisambiguatedName}/Definition"; this produces the message:
Please do not use this term in your topic list, because there is no single article for it. Please substitute a more precise term from the disambiguation page.
Note: currently there is no disambiguation page for NoArticle, please create one.

Implementation issues

There aren't very many implementation issues.

  • What to call the category all the redirects to disambiguation pages are placed in? I would suggest "Disambiguation Redirects".
  • What to call the category all the redirects to main pages are placed in? I would suggest "Base Redirects", or something like that.
  • Is {{Dambigbox}} OK for the header template placed on such main articles? Should it go above, or below, the subpages navigation bar? Should it add the articles to a category, and if so, what should that be called? (This last decision can easily be changed later, simply by changing the template, so it's not super-urgent that it be decided, or decided correctly.)

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'? There is a spectrum of possible answers, but the important thing to realize is that from the point of view of this proposal, it really doesn't matter where on that spectrum we land; the benefits of this scheme (making it easy to find erroneous links) will remain, no matter what we do. The different options just transfer work from one group of people to others, is all. It is also worth noting that we could change our policy on which of these choices to adopt down the line, without changing the basic mechanism.
    • One possibility is to retain the current model, where when there is a meaning which is significantly more popular than the others, it always gets the redirect from the 'base' name; authors have to do the minimum amount of work, but the cleanup crew will likely have to do more.
    • The possibility at the other extreme is to simply say that the redirect at the base name always has to point to the disambiguation page.
    • The possibilities in the middle are all variants of the position 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 say that a Constable gets to make a decision which is binding, saving an appeal to e.g. the Editorial Council.
  • Do we want to bother having all the articles in a 'disambiguation group' have a header on them that says something of the form 'For other meanings of DisambiguatedName, see DisambiguatedName (disambiguation)'? I would say no, because people shouldn't be on such a page unless they deliberately went there, or were sent there, not as a result of confusion. However, I don't have a strong bias against doing so; if people want to do so, that would be fine with me. (If so, however, it should be via a different template, so we can separate out the 'main' meaning articles from the 'subsidiary' meaning ones.)
  • 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)".
  • When the 'base' redirect points to one particular meaning, should the talk: page for the disambiguation page will have a link to that meaning's talk page at the head, for ease of navigation? It will probably not be that useful, so perhaps not? People going to the 'base name', and then clicking on the "Discussion" link on the page they are given when they do so, will wind up on that article's talk page. The only way to land on the redirect at the base name (from whence clicking on the 'Discussion' link will wind them up on the disambiguation page's talk page) is to click on the Redirected from link, and most people won't do that.

Discussion

  • YES! I am coming out strongly in favor of this proposal. Despite the nuisance of having articles with names like "Tree (plant)", it is necessary to do something for topics which have important articles in completely different disciplines. "Tree" is a good example, because a "tree" is an important concept in computer science and mathematics. Without such a policy, there will inevitably be disagreements about which article gets top billing, i.e., sits at "Tree".Pat Palmer 15:23, 13 May 2008 (CDT)
    • Tree is also important in phylogenetics. We must learn from wikipedia and become better, this is a prime example. Chris Day 09:31, 15 May 2008 (CDT)
  • I too support this proposal. I especially agree with the redirect from {foo} to {foo} (disambig). It helps separate good links from "bad" links, which could help prevent confusion in many cases. My only question is this: Who decides (or rather, what will the standard be) on how to distinguish articles? I know this is a bad example, but would the article Victoria be changed to Victoria (Queen), Victoria (British queen), or Victoria (Royalty)? And why? I think there should be clear guidelines and standards to prevent confusion before this gets put into effect. John Dvorak 15:39, 14 May 2008 (CDT)
    • In the biology workgroup there was a long discussion on naming conventions. Each species has a scientific name and many have a common name too, some even have multiple common names. In summary, this has to be on a case by case basis. In that discussion we learned that it is hard to find one rule that fits all situations (at least, one rule that everyone is happy with). I would add, I think this is a tangential topic to the need being discussed here. Chris Day 09:37, 15 May 2008 (CDT)
    • That whole Victoria thing is a wholly separate issue; it's an issue of how we name articles (something we've had some long debates about, and tacitly put on the back burner while we get busy an create content). So, can we not dive down that rathole here? Thanks! J. Noel Chiappa 09:46, 15 May 2008 (CDT)
  • YES too! The {foo}/definition could exist but it is not critical. The {{R}} template could be coded such that if Foo (disambiguation) exists then the definition is automatically given as: "There are several meanings; see [[{{{1}}} (disambiguation)]]". This has the advantage of overiding any definition that might already exist at foo/definition as well as alerting the author of the specific related articles page to clarify the link that gives the correct definition in the context of that RA subpage. For example, {{R|Cell}} can be fixed to {{R|Cell (biology)|Cell}}, or <nowiki>{{R|Cell (electric)|Cell}}. Chris Day 09:52, 15 May 2008 (CDT)
I recoded the R template. Two examples would be:
{{R|Tux}} gives:
  • Tux [r]: The name of the penguin, official logo and cartoon mascot for the Linux computer operating system. [e]
and
{{R|Reel}} gives:
  • Reel [r]: Please do not use this term in your topic list, because there is no single article for it. Please substitute a more precise term. See Reel (disambiguation) for a list of available, more precise, topics. Please add a new usage if needed.
Note that the black hyperlink denotes that Reel is currently a redirect to the disambiguation page whereas the blue link for Tux indicates we actually have an article for that topic (An approved article, no less). Chris Day 13:15, 16 May 2008 (CDT)
  • I join in supporting this initiative and plead for a rather strict (but easy to navigate) implementation (along the lines of Chris' demonstration of {{R}}), as any discussion about priorities will result in the dissipation of much-needed energy, for generally very little gain. I expect a compulsory disambig to also increase interaction between the writers of the different Foo articles, especially if the disambig page provides some background as to the aspects in which the trees in mathematics, computer science, phylogenetics and elsewhere are related to the more ancient concept of the plant. And it makes tracking false links easier, too. -- Daniel Mietchen 10:32, 15 May 2008 (CDT)
  • No. I'm coming out against the proposal, logical though it is. I note that the first ones to weigh in are scientists, I think that's because it is well-reasoned, thoughtful and seems sensible. However, it is also counterintuitive, and I think that's the rub. It seems to me that the appeal to the scientific, as opposed to the artistic, mind is that it will ostensibly stop arguments, unify the format, and so ultimately save time and energy, things we waste entirely too much of, I'd be the first to agree.
Pat, I think you capture the essence of the problem I have with this, to wit, tree (plant) will be a nuisance. It will be more than a nuisance, it will be a major headache. Tree was a tree before it was a flowchart or a thing you stretched shoes on, and I suggest that most people's instinct is to conceive first of a tree, unless they were specifically thinking (writing) in some other context. To that end, we're going to have endless problems.
Ah, but, I hear you say--what about the constant arguments about which article name is the primary one? Well, look, so far we've gone with Standard English and Common Sense; I see no reason to abandon either. Who in their right mind is going to argue about the primacy of Tree? The difficulty arises, of course, if or when the matter is less clear. But in so many of these cases, there is a primary meaning, and when there isn't, we should of course use diambiguation.
You guys think differently. Or *people like me* think differently, as you prefer. For example, in a universal proposal you do not write article name or common noun, you write foo, and you're dealing with people who don't know what foo is. I'm learning, but it's a process.
What you're suggesting is that using universal disambiguation will make arguments go away. As far as I can tell, all that will happen here is that the place and level at which arguments take place will shift. The need to redirect will not change, what will change is where the redirects are to. In fact, it will likely make things even worse, because people will have to redirect common nouns all over the place. All the clusters. All the subpages. All the definitions. All because we're going to attempt to avoid defining a baker as someone who cooks things in the oven and a ball as a round spherical thing. Seems to me it'll be a lot easier in the long run to have ball and redirect the odd ball to "ball (dance)" when you run into a needed redirect than it will be to run around the wiki changing every blasted instance of ball to ball (round spherical thing)
I also note that the proposal already attempts to provide for exceptions. My point would be that there will be more exceptions that you have anticipated. Many nouns involved here. Many, many nouns. 26 letters of the alphabet. A gazillion plants and animals. The colours of the rainbow. Chris harked back to biology naming arguments; Noel doesn't want to go there, and I do agree, but I think that that argument helps illustrate how complicated matters can get.
People's brains do not instinctively disambiguate, and that's where the trouble is. People generally know what a primary use is. When I recently wrote the last great Moose--that's Moose, I placed the article at Moose (dog actor), not Moose, which is Rocky-n-Bullwinkle (and currently does not exist). It does not matter one wit that I am not a zoologist, a dog called Moose, no matter how famous, is not a Moose, and I know it. Now unless you can show me that it makes sense to have, instead of Moose, Moose (disambiguation): Moose (elk-like creature), Moose (dog actor), I cannot support the argument.
Having said this much, I think the *idea* is rooted in a good, solid premise, but some ammending is needed. Aleta Curry 19:23, 15 May 2008 (CDT)
  • The thing is that the old saying "There Ain't No Such Thing As A Free Lunch" applies here. Yes, typing "[[Tree (plant)]]" is a pain, but so is sorting through all the links to find the possibly erroneous ones. Your assertion that it will be "a lot easier in the long run to have [[ball]] and redirect the odd [[ball]] to [[ball (dance)]]" is not correct.
If you think it's not going to be a huge problem, trundle on over to Wikipedia and click on 'What-Links-Here' for "Tree", here, and go through that list and find (and fix) all the links to the wrong kind of tree. Hint: here is an incorrect one I found in a few seconds of looking - but how many others are in that list? How long will it take you to look through all the articles on that lengthy list and find all the mistakes? And how many new ones will have been added when you go back in 3 months, and have to look through the same long list?
Trust me, if we don't do this, we're going to have just what Wikipedia already has, which is a lot of articles that have links that link to the wrong thing (because what you're arguing for is basically the Wikipedia system, and we have evidence of what happens with that). I don't know about you, but that's not the quality level I'm hoping for from CZ.
And we won't have to "run around the wiki" changing anything; the redirects will keep things properly linked until someone changes things to link directly to the disambiguated article. The number of articles is still small enough that there isn't a giant backlog that will take forever to clear.
Also, this proposal is not in any way intended to get rid of arguments (I don't know where you got that from, because there's nothing suggesting that in the proposal, I thought - perhaps you could point it out?) But it won't make things any worse than it is now. If you have a name that has to be disambiguated, even without this proposal, you're still going to have the argument of 'which variant, if any, gets the 'base' page'. Been there, done that too, on Wikipedia (which, again, is basically the system you're arguing for).
Still, if you think it can be amended to be better, I'd more than willing to hear suggestions for improvements. Did you have any specific modifications to suggest? J. Noel Chiappa 20:36, 15 May 2008 (CDT)
  • Actually, now that I think about it, there might actually be less arguments with this system. As long as one meaning can 'claim' the title {DisambiguratedPage}, that increases the reward (i.e. incentive) for arguing over which one gets it. But when no article is going to get that article title, and the most one can hope for is to be the default link (which is only ever of temporary use anyway, since all links will be modified fairly quickly to not use it), there's a lot less incentive to drag it out.
On another topic, I expect eventually we might even have a human-assisted bot to fix those links to the 'base' name; it would e.g. pull up the text around the link, and look at the dab page to find the options, and then it could offer to link to the main meaning if one hits the space bar, or to pick one of the other ones, type a number, or something like that. J. Noel Chiappa 21:16, 15 May 2008 (CDT)
  • Thinking about the red herring a bit more. I can see that readers might be perplexed to find themselves on an esoterically named page, Aleta cites Tree (plant) as an example. But would this really be a problem? In the text this would be pipelinked so it would still be tree ([[Tree (plant)|tree]]). Do people even read the titles when they click onto a new page from a hyper link? For me, i tend to jump right to the content.
If it is just the title of the page that is a problem is there not a way to mask the page name with an alternative more user friendly version, possibly one coded in the metadata. This gets back to another proposal from Noel where he suggested there is no reason why the title at the top has to be exactly the same as the page name. Similarly the articles that have numbers in EB do have sensible titles for show (figure head titles?). Chris Day 10:58, 16 May 2008 (CDT)
To me this proposal is not about which name makes more sense or which name has priority, and both are valid discussions. This is about how can we be sure that a reader always finds the article they are looking for. In reality the names are not that important as long as the information is relevant. At worst a reader is surprised to find themselves following a link to a disambiguation page. This is a small price to pay, IMO, and may actually be educational. Chris Day 22:14, 15 May 2008 (CDT)
  • I think Aleta makes a good point in saying that tree (plant) looks weird. One looks at that and says, "Err...does that mean a tree, or doesn't it?" That conceded, I think the simplicity and general usefulness of the proposed policy outweigh such considerations. (Of course, I know, I'm just being logical.)
The way to address Aleta's concern is by giving it a different disambiguating word or phrase that makes sense. (I have sheer faith that there is such a word or phrase, so I am not entirely logical.)
One critical comment about the current wording of the proposal: "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..." This seems incorrect. Disambiguations do not and should not list all potential meanings, but only all potential articles that people might look for under this title. Disambiguation pages should not look like definitions. --Larry Sanger 10:41, 16 May 2008 (CDT)
  • I think Aleta was also concerned at the amount of extra typing in having to type [[tree (plant)|tree]], and also the time/energy/delay in having to go look, when you just wanted to link to "tree", to find out that the thing you actually need to link to is actually "tree (plant)".
To answer both of those, Aleta, if we redirect from "tree" to "tree (plant)", writing [[tree]] in an article will get you exactly the same thing as if you wrote that in the Wikipedia system - and someone else can come along later and fix the link to go directly. So I don't think that's an issue - feel free to link to "tree" (and "dog" :-) in everything you write! (I will update the proposal text to point this out.)
Now, about the "all the potential meanings ... those for which we have articles" stuff. The content of dab pages is still on my (lengthy :-) ToDo list... Whether dab pages should only contain entries for which we have articles, or other things too, is an interesting question, but one which I would prefer to defer (oooh, I love that euphony :-), to keep this focused on the mechanics issues, so I will reword that section to omit any mention. (That text came from a page on Wikipedia, which does list non-article meanings in dab pages, is all - nothing sinister! :-) J. Noel Chiappa 12:55, 16 May 2008 (CDT)
  • I have updated the proposal to point out that within this basic mechanism, we can, with the appropriate choice on our policy of 'whether to allocate the redirect at the {BaseName} to the principal meaning', produce almost exactly the existing behaviour (which is I think a lot of what Aleta was concerned about). I have also clarified the Open Issue bullet about this to list the range of policy options on this issue. I personally don't care that much which of them we pick; they all provide the basic goal (reduction of bad links) I am after with this proposal. J. Noel Chiappa 10:44, 17 May 2008 (CDT)
  • Two things; does this cover the "Soccer" versus "Football" debate; and second, can you please mention {{dambigbox}} that I made to beautify disambiguation text? --Robert W King 19:45, 16 May 2008 (CDT)
    • I'm not quite sure what the 'soccer'/'football' issue is, as a general concept (obviously, I can see the issues with that particular case). In general, as explained in the header, this proposal doesn't take any position at all on naming controversies, etc, it merely provides a mechanism to help us identify and get rid of erroneous links to ambiguous terms. As such, since "football" probably ought to be disambiguated, that disambigution would use this mechanism, but that's all. J. Noel Chiappa 10:56, 17 May 2008 (CDT)
      • This is a summary of the debate, and you can read this at the talk page I believe: "Football" means very different things depending on where you go. In the U.S., 'Football' means American Football (pigskin, with yards, tackles, and the blitz). Soccer means "football" to many europeans. How does this proposal affect this dilemma? --Robert W King 11:08, 17 May 2008 (CDT)
        • I still don't get it (and, as I said above, "I can see the issues with [this] particular case"). I mean, I understand that football means different things to different people. And I understand that that has caused a certain amount of confusion there. (At the moment the thing at Football seems to fall between two stools; it's neither a plain dab page, not a plain article on 'soccer'. In my opininion, it should be turned into one or the other.) But this proposal says right at the top "This proposal is not about when we should disambiguate, .. what a disambiguation page should look like (e.g. .. what should it contain)", so most of the issues raised on/by that page are outside the scope of this proposal. So what I don't get is how those issues, and whatever solutions is picked for them, relates to the contents of this proposal. Can you give me a better idea of how you think this proposal might be involved there? J. Noel Chiappa 13:06, 17 May 2008 (CDT)
          • Let me think about this for a while and make sure I'm not confusing the issue; I may be doing so. --Robert W King 13:15, 17 May 2008 (CDT)
I hadn't seen {{dambigbox}} before; that would obviously be the thing to use on all article where we wanted to link to the dab page (leaving aside the issue whether that should be done on all dab'd articles, or just the ones linked to from {BaseName}. I have only one thing about it that I would have done differently, which is that the entire text inside the box is provided as an argument. That means that different pages could provide different texts, and I believe such things should be absolutely uniform across the project. So, I would have moved the string "This article is about <arg1>. For other uses of the term "<arg2>", please see [<arg2> (disambiguation)]." text into the template. I see this template has already been deployed on a lot of pages; we could incrementally upgrade it, to operate in the way I suggest, by upgrading it to optionally take two new arguments. So, if "text" was specified, it would produce the old behaviour (meaning no need to rush around and change all the articles which use it), and if the new arguments were there, using the specified text. (We'd gave to give {BaseName} as an argument, since without the Strings: package we couldn't pick apart {BASEPAGENAME}.) What do you think? J. Noel Chiappa 10:56, 17 May 2008 (CDT)
  • I only am mostly concerned with apperance when it comes to templates; in this case I am not so worried about the text; that can change as needed and I am not phased by it. --Robert W King 11:08, 17 May 2008 (CDT)
  • Similarly, I am usually not very concernd with appearance, and only care about how it works! So it sounds like we can work that out. J. Noel Chiappa 13:06, 17 May 2008 (CDT)
  • WHOA! I just saw that "All "DisambiguatedName" articles" are supposed to use "Name (Subject)". I think this should be reworded to "an unambiguous name, such as 'Name (Subject)' or 'Name subject'. The reason is, that we have articles such as "Ruby programming language" and I do NOT want to rename them as "Ruby (programming language)" because, frankly, it's a terrible pain to get the links to parentheses correctly done, so why do it when we don't need to? So...surely this proposal does not want to force the use of parentheses if there is an alternative way to give an unambiguous name to an article? I am not against the basic idea of "Ruby" pointing to "Ruby (disambiguation)" but I think we should then allow the various articles about "Ruby" in various subjects to provide any reasonably type of unambiguous name that the workgroup chooses.Pat Palmer 12:38, 17 May 2008 (CDT)
    • Good point, that's fine, I'll change it. J. Noel Chiappa 12:43, 17 May 2008 (CDT)
      • It is foolish to give any kind of specialization or field "priority" or "tenure" when it comes to naming; as such we should note give Computer Science carte blanche on the word "Ruby"; this is absurd as Monster Cable Inc. suing other companies that happen to use "Monster" in any of their product lines or in their company name. I must disagree just because Pat thinks so and is 'slightly inconvenienced'. Surely you cannot declare yourself king of the naming mountain, Pat? --Robert W King 13:20, 17 May 2008 (CDT)
        • Err, I don't think Pat was saying he wanted any field to have dibs on any name (e.g. "Ruby"); I think all he was saying was he wanted to be able to name the article "Ruby programming language" as opposed to "Ruby (programming language)", the original wording did sort of imply that the latter form was mandatory (to which he understandably objected). Whether CS wants to name them all "<Foo> programming language" or "<Foo> (programming language)" should be up to them, is all he's saying - just as it should be up the linguistics people whether to name human language articles like French language, etc "<Foo> language" or "<Foo> (language)". J. Noel Chiappa 14:09, 17 May 2008 (CDT)
  • Wouldn't it be useful to always place a {{Dambigbox}} on top of a page listed on a disambiguation page? -- Daniel Mietchen 11:31, 26 May 2008 (CDT)
    • I think there are probably good arguments both ways (include/don't include). I don't have any problem with either choice, but would suggest only that if we do include a box at the head of all such articles, we use a different box for the head of articles which are disambiguated but which aren't ones which claim the 'base name'. (I see this is already listed as an open question.) J. Noel Chiappa 22:06, 21 October 2008 (UTC)
  • I like this proposal, but I think it needs to be implemented simultaneously with Noel's plan for the separation of pagenames and titles (mentioned in the description above). Titles like "Tree (plant)" really are unattractive at the top of an article. If we separate pagenames from titles, then we can have an article, [[Tree (plant)]] with the title "Tree" and the annoyance disappears. --Joe Quick 15:07, 9 June 2008 (CDT)
    • Don't expect me to disagree with this well-taken point! :-) J. Noel Chiappa 22:02, 21 October 2008 (UTC)

Why [i]tree(plant)[/i] and not [i]tree(biology)[/i]? If we go with [i]tree(biology)[/i] as the default we could write a bot that creates a new redirect from [i]tree(biology)[/i] to [i]tree[/i] when somebody creates a page called [i]tree[/i] in the workgroup biology.

Internal links could always be named [i]tree(biology)[/i] if you want to go to the normal tree. If someone creates a normal links to [i]tree[/i] in the biology workgroup and [i]tree(biology)[/i] exists, the bot changes [i]tree[/i] into [i]tree(biology)[/i]. If no article exists at biology [i]tree(biology)[/i] but an article exists at [i]tree(Disambiguation)[/i] the bot changes [i]tree[/i] with [i]tree(Disambiguation)[/i]. If neither of them exists the bot does nothing.

That system would allow someone who edits an article to see the target of a link. It would also provide people with a clear list where they can see all pages that link to [i]tree(Disambiguation)[/i] and go through that list and set them either to tree(biology) or to tree(computer science). At the same time the normal tree page can live on [i]tree[/i].Christian Kleineidam 23:22, 24 November 2008 (UTC)

Proposals System Navigation (advanced users only)

Proposal lists (some planned pages are still blank):

Retrieved from "https://citizendium.org/wiki/index.php?title=CZ:Proposals/Disambiguation_mechanics/Archive_1&oldid=964529"