Wikipedia:Village pump (proposals)/Archive 72

• Support - I think the vast majority cases of duplicate references are issues of editor didn't know how to group them or just didn't care - not that the editor consciously chose not to group for some stylistic reason. Nevertheless, adding a 1RR rule and templated exclusion option should cover all needed exceptions. (I don't think it makes sense to exclude GA and FA articles automatically; rather, I just don't think there will be much that the bot could do on those articles.) LadyofShalott 14:18, 21 March 2011 (UTC)
• The solution to getting a bot to do "controversial" edits shouldn't be to make editors add exclusion templates. It's a bad precedent, as it encourages this sort of workaround for future bot proposals. Generally, the standard approach has been to either restrict the bot task to avoid nearly all false positives, or (if the number of articles involved is "small") an editor makes the edits with script assistance. Gimmetoo (talk) 01:40, 26 March 2011 (UTC)
• Support 1RR which will take care of all the likely objections. The most frequent cases are that authors do not know, or don't want to bother (For an article with 10 refs of which 2 are dups, one might just copy & paste rather than think about it), or where an article starts off small with no duplicated refs and gets added to, and some of them duplicate without being noticed. I can't imagine why anyone would prefer not to. unless they were really accustomed to writing in the older style where one did number consenutively, and for the second time something was cited, say" Johns, A. B,. Ibid if immediately preceding or Jones, A. B. op.cit if not immediately preceding. (I have in fact seen this here, and its usually a clear sign of copypaste). I'd think that if anyone really wanted to write that way, they would not be using the ref formatting in the first place, but would hand code them. I can understand the objections as coming from the dear that other things in refefrences might get centrally formatted, but I don't think it's really a slippery slope here, and this particular change is obvious enough. DGG ( talk ) 05:30, 27 March 2011 (UTC)
• Support - you don't need to perma blacklist that site, just maybe a short period of time. Probably could add an automated edit note to notify of anything you believe is an error.陣内_Jinnai 23:24, 28 March 2011 (UTC)
• Support – This will take care of the objections. —mc10 (t/c) 02:17, 5 April 2011 (UTC)
• Strong Support - Making a bot that automatically cleans up references is a great idea. It should decrease the backlog significantly. Alpha Quadrant ^talk 03:26, 5 April 2011 (UTC)
• Strong oppose. Please don't force the abomination of "named references" in articles where they have been intentionally avoided. And please don't pretend that it is "clean up" to do so. --Hegvald (talk) 05:43, 5 April 2011 (UTC)

The proposal is to "Restrict the bot to working on articles that already use named references." This means it will not be adding grouped references to articles that do not have them already. Personally I think that the bot should fix all duplicate references, because otherwise they have to be fixed manually, or with RefLinks. As I frequently clean up references, it would be nice to have a bot that does the tedious work of fixing ungrouped references. @SW, will it be possible to run the bot on a single article, like citation bot does? Alpha Quadrant ^talk 14:14, 5 April 2011 (UTC)

My comment ended up under the wrong subsection. --Hegvald (talk) 19:42, 5 April 2011 (UTC)

• Support I would love a bot that did this. Would personally want the name of the ref group to be the Author last name and the date of publication. --
  talk · contribs · email
  ) 13:08, 6 April 2011 (UTC)
• Support Common sense, streamlines referencing, 1RR takes care of rare issues. --Cybercobra (talk) 23:38, 8 April 2011 (UTC)
• Support alternate proposals, 1RR/template/type exclusions sound entirely sensible and are my preference. --joe decker^{talk to me} 04:59, 11 April 2011 (UTC)
• General comment—I think that the # of articles containing duplicate references, 5,000, is small enough to tolerate without an automated fix. I would come down on the side of not bot-manipulating references in this manner in general. We have a quite difficult time getting people to add references, and if a bot makes a mistake in that area (potential, not a certainty - I trust bots in general), then that will be substantially offputting to those who are a) casual editors and b) been diligent enough to add references. In other words, I think the risk-benefit ratio is too high at the present time. --User:Ceyockey (talk to me) 13:44, 17 April 2011 (UTC)
• Support No-brainer. It'd tidy up pages, I too am perplexed at the ridiculous oppose !votes, ugliness of named refs? What the fuck? Seriously? —
  Talk • Contribs
  ) • 9:57pm • 11:57, 18 April 2011 (UTC)
  • There's no need to be offensive. I am almost provoked into opposing just on the strength of that comment - it shows a complete lack of understanding of those of us who actually write articles. Yes, they can be regarded as ugly, they increase code clutter in text view and more importantly, they affect the neat alignment of endnotes/footnotes with the multiple links. SpinningSpark 14:04, 25 April 2011 (UTC)
• Strong Support if exclusion template is implemented The ability to put a template on a page that tells the bot to not change it not only addresses all the steted objections, but also allows for creation of a example page that compares duplicate references with named references.
  talk
  ) 02:32, 20 April 2011 (UTC)
• STRONG, STRONG, STRONG OPPOSE—for the reasons discussed
  here. I have yet to read through all of the comments above, to evaluate others' opinions on this subject. But i already know how—absent some sort of thoughtful and creative implementation—this sort of proposal will (and does) affect my editing. Richard Myers (talk
  ) 18:07, 24 April 2011 (UTC)

Therefore, before i would support any alternative proposal, it must take into account the impact on real world editors who are diligently working on articles while they are working on those articles. The bot must explain itself more thoroughly, not just in edit summaries but also on the talk page (where "ambushed" editors may comment, discuss, and perhaps determine a response), and the bot must also not just allow, but actually encourage a non-controversial revert of its modifications in situations where it would impact process. A creative solution might be to provide editors with an option not just to revert, but to invite the bot to return to the article in (say) three months. Under such circumstances, i would change my strong, strong, strong oppose to (probably) a simple oppose. Richard Myers (talk) 19:13, 24 April 2011 (UTC)

Note: an article i've been working on, Anti-union violence, just now had duplicate references merged by someone using AWB. This time, i reverted. And i will continue to revert every instance that i encounter that interferes with my process.

Note that i am currently the author of more than 99 percent of the edits to this article (and of a high percentage of edits to the related article, Union violence). Please observe that my editing of these two articles has been an ongoing process, over the past several weeks. Why should i be brazenly interfered with in my editing of these two related articles by a process that is "preferable" and "standard" and "non-controversial", when i perceive it as an ambush that (absent a revert) dramatically and adversely impacts my ability to edit?

Yes, i am irritated. But i'm not trying to be hostile, i'm trying to convey that the impact of a process carried out with (in my view) near impunity is significant, immediate, increasingly pervasive, and VERY detrimental to at least a subset of longtime Wikipedia contributors. Richard Myers (talk) 20:24, 24 April 2011 (UTC)

I have posted a workaround for this article at the other thread. -- John of Reading (talk) 20:43, 24 April 2011 (UTC)

I have implemented the workaround on that article. The current generation of AWB/bots will not fiddle with the references on that article again. -- John of Reading (talk) 05:38, 25 April 2011 (UTC)

• Support, I find the arguments presented convincing, and the downsides only minor. I have one question, though, how does the bot derive a name for the reference? Having said that, I'd support it anyway. It makes a lot of things clearer in editing, etc. I'd like to see this trialed soon. Grandiose (me, talk, contribs) 18:16, 24 April 2011 (UTC)
• Conditional oppose - I oppose this unless some measures are taken to improve the quality. For one, using names like "ReferenceA" (which AWB seems to do if it can't come up with something better) is unacceptable. Named refs with unhelpful names are worse than repeated refs. The bot should also make an effort to not interrupt human editors (ideally almost every bot should do this). It should recognize tags like {{
  inuse}} and skip articles that have had recent edits (in the last 12-24 hours). Mr.Z-man
  14:43, 25 April 2011 (UTC)
• Support Per my support of the original proposal; if that does not succeed, then this is the best we can hope for.  Chzz  ►  15:23, 26 April 2011 (UTC)
• The opposition doesn't surprise me: Every time someone proposes something like this, there is always strong opposition from a minority of editors. For myself, I don't think that this proposal is either very helpful or the end of the world. However, if we're going to have such a thing, it would be appropriate to limit its use to articles that are already re-using named refs (not merely "one tag contains a name"). WhatamIdoing (talk) 23:35, 26 April 2011 (UTC)

Request for guidance on policy

I have carefully reviewed relevant policy/guideline pages

I have also explored Wikipedia:Citing sources, which states:

• How to write citations: Each article should use the same citation method throughout. If an article already has citations, adopt the method in use or seek consensus on the talk page before changing it.

To me, that language is very plain. It says, don't just jump into a random article and change the method, get consensus, or don't do it.

Now, this is my problem. In discussion here and elsewhere, i have been informed that named references are "preferable", "highly preferable", "standard", "non-controversial", "more efficient", "saves space", "improves readability", "logical", "beyond clear", a "no brainer", and a "good idea". But where does it say in Wikipedia guidelines or policy that the people who believe all of these things have the right to violate the very clear guideline above (and in my view, the ONLY stated guideline that gives weight to one method over another) which says simply, adopt the existing method, spend some effort to get consensus (or go away)?

In brief, until someone can offer a guideline or policy or a compelling reason which is not simply based upon their own personal opinion, it seems to me that this practice of merging duplicate references (longstanding though it may be) is in direct violation of the only relevant guideline or policy that expresses a preference one way or the other.

What, really, does the existing policy demand of those of you who have your minds made up? Even if you have this strong, strong consensus in your discussions, you are routinely violating a policy that protects many of us article editors! Please tell me where i am wrong. Richard Myers (talk) 23:24, 24 April 2011 (UTC)

I think the more important policies are

good faith, are trying to make an article better, just go ahead and do it. If people object, or disagree with your improvements, allow them to be undone and discuss. But we shouldn't walk on eggshells here... --Jayron32

03:10, 25 April 2011 (UTC)

This is total bullshit, based on your perception of what is "substandard. I often have to revert well-meaning, but utterly arrogant and against policy attempts to "improve" referencing on articles I've created or expanded. The problems come if you don't spot it in time, & can't be bothered to go back, revert & re-add a lot of changes. I've had to virtually abandon articles the cite-Nazis have got at. Johnbod (talk) 21:24, 25 April 2011 (UTC)

While I wouldn't put it that agressively, I also have a few articles I really wish I'd had the confidence to revert style changes and now find I'm really reluctant to return to even though I have more references that could go in. SpinningSpark 21:42, 25 April 2011 (UTC)

That makes at least three of us who have "abandoned" articles in one form or another because someone did something such as changing the notation scheme. Richard Myers (talk) 22:21, 25 April 2011 (UTC)

The

WP:BRD

is wrong for automated or semi-automated processes. Specifically,

6. The Wikipedia tenet "be bold" is not a justification for mass editing lacking demonstrable consensus.

I would anticipate this rule to be advisable (and perhaps in force?) with all bots, auto or semi-auto. Richard Myers (talk) 18:00, 25 April 2011 (UTC)

Out of curiosity, i did a superficial exploration of the edit histories of those who have supported merged duplicate references, just to see how many editors who do in depth editing of articles support, and how many are opposed, and vice versa. I went back 1,000 edits. Criteria is simple: is there, in the last thousand edits, a substantial string (more than ten or twelve) of edits on the content of a particular non-user page article? I didn't include anyone who didn't appear to state a preference for or against merged duplicate references.

This is by no means "scientific", but here's what i've found.

If i've erred in evaluating anyone's edit history, or if you'd prefer not to be listed, please let me know, i'll fix it. (Alternately, please feel free to edit the table as appropriate.)

Look at my edit history, you'll see many hundreds of edits each, on a comparitively small number of articles per thousand edits. I saw this type of editing history in the most recent thousand edits by just one individual who is here supporting merged duplicate references. In brief, it could be that some folks here are not concerned about routine merging of duplicate references because it doesn't affect their contributions to Wikipedia (at least not judging by the last thousand edits).

Pretty interesting. Richard Myers (talk) 05:09, 25 April 2011 (UTC)

My experience in finding this discussion on this page was pretty much by chance, somewhat roundabout, and only with the kind assistance of another editor. This, in spite of my active search for discussions on precisely this topic. Therefore i wonder if article editors are getting fair representation in this discussion.

I would like to see this discussion opened to more Wikipedians who are just typical editors impacted by the practice of routinely carpet bombing duplicate reference merges, rather than to Wikipedians who may be primarily interested in the technological aspects of bots and what bots do. Can anyone suggest a method of accomplishing this? Let us please try to get an overview of what editors who create in depth articles think. thanks, Richard Myers (talk) 02:17, 25 April 2011 (UTC) (this entry moved to consolidate logical discussion)

Is

iridescent

18:50, 25 April 2011 (UTC)

Hi, thanks. I'll explore options at those links. Richard Myers (talk) 19:13, 25 April 2011 (UTC)

I have put a brief notice here (Content Noticeboard) and here (Featured Article Candidates discussion). Richard Myers (talk) 20:18, 25 April 2011 (UTC)

comment on edit evaluation in table — this reflects as much style of editing as "depth". One edit can accomplish the work of twenty if the content revision is small in each individual edit of the twenty. Therefore, edit count alone cannot be used in this evaluation. It also depends upon the length of the article in question; a small number of edits can completely change a short article but barely dent a large article. What the table actually shows is "who did a lot of edits on a small number of articles" - not "who edits articles in depth" (by my interpretation). --User:Ceyockey (talk to me) 00:54, 27 April 2011 (UTC)

No disagreement with this. The method of analysis is imperfect. However, i feel the information is still useful, and (as you have done), anyone is welcome to change their entry to more accurately reflect their situation. thanks, Richard Myers (talk) 01:12, 27 April 2011 (UTC)

BTW, not trying to disagree with the above, but i learned the hard way some five years ago that a greater number of brief edits are greatly preferable to individual in depth edits, for the simple reason that a computer glitch (such as a browser crash) or a power outage could cause one to lose 30 or 45 or 60 minutes worth of editing effort. After it happened to me a couple of times, i changed my editing practices. I'd be surprised if some other experienced editors haven't learned the same painful lesson. Richard Myers (talk) 05:26, 27 April 2011 (UTC)

Quite right. I learned that as well, but approached it in a different way . . . I grab the wikitext and edit offline, making sure that there were no edits between when I captured the content and when I added back the revised content. I've only had to do that a couple of times in the past several years. --User:Ceyockey (talk to me) 01:14, 28 April 2011 (UTC)

Aspects of this discussion

This discussion about routine merging of duplicate references is, first and foremost, a discussion about a bot proposal. It has been conducted here, and at

• Does routine merging of duplicate references, as currently practiced, adversely impact a significant subset of editors?
• Should duplicate references be routinely merged:

• in articles which have reached some state of completion; and/or,
• in articles in general (including articles not yet in a state of completion)?
• And if so, under what guidelines?

• Is there benefit to consecutive numbering of references, and does that outweigh perceived advantages of merging with named refs?
• When duplicate references are merged, is it acceptable for named references to be auto-generated, or must they always use a real world tag (such as the author's name)?

I don't think this brief list is exhaustive, i'm just trying to keep track of some key discussion points. (Did i miss anything essential?)

But finally and most importantly (to me), has this discussion been carried on before, anywhere, in a forum where a significant cross-section of article editors have a chance to comment? Richard Myers (talk) 19:51, 25 April 2011 (UTC)

Frankly, I have never understood why one would not automatically merge duplicate references. I understand using Harvard style for multiple page refs in the same work, and I understand that there are editors who prefer Harvard vs. MLA vs. APA or whatever. These are stylistic choices in how the final reference appears on the page. But that is all they are - editorial, stylistic choices made by editors. That is what the guideline says to respect. The use of named references to eliminate duplication does not change the format or appearance of the citation itself. I see no benefit in the consecutive numbering because citations are linked. Readers can click the superscript indicator to see the ref, and then click on the matching ref number to returned to the spot where they were reading. Frankly, by refusing to merge references, we are making some author or work appear far more often than is necessary for the article itself. It is a pernicious form of

SEO to have the same work appear over and over again on the same page. Unless page numbers are necessary for citations, named refs should be the standard and duplication should be eliminated wherever possible. Jim Miller ^{See me | Touch me}

13:35, 26 April 2011 (UTC)

This. Duplicate ref merging doesn't substantively change the citation style, except insofar as the second-to-last point, which can be countered by the amount of potential References/Notes section bloat which would caused by the duplication necessary to force such consecutive numbering. The last point is a very legitimate concern; regarding AWB or similarly semi-automated tasks, this is where human eyes should be used. --Cybercobra (talk) 16:02, 26 April 2011 (UTC)

I have updated the table. As of now, five editors who have commented actually do in-depth editing of articles, by my cursory evaluation. Four of these five oppose having others jump in and auto-merge duped refs, at least during the article creation process. To me, that is the most significant statistic in this discussion. Richard Myers (talk) 18:05, 26 April 2011 (UTC)

Ad hominem fallacy. We should examine these editors' rationales for opposing. --Cybercobra (talk) 01:24, 27 April 2011 (UTC)

Happy to oblige. I create in-depth articles, including on historical topics.

I just skipped through four of the articles i've recently created. Respectively, they have 184 footnotes and 33 sections, 201 footnotes and 37 sections, 140 footnotes and 36 sections, and 102 footnotes with 12 sections.

Suppose i am working on a new section of one of these articles. I typically am working from the same source(s) with which i created the previous sections. For a given historical article, i may have ten or twenty books stacked on my desk at one time. The ability to quickly locate the correct reference string is vital to efficient article creation.

With my existing work process, i can often find the source(s) i need very easily, just one or two paragraphs above my edit point. I copy the ref string, and change the page number if necessary. Simple, quick, and easy.

If dup refs have been merged in the middle of my article creation process, suddenly it becomes necessary to search the entire article to find the reference string i need, and now there is only one such reference in the entire article to be found. I must leave the section i'm working on, interrupting workflow. Then i must find the edit point again, which i wouldn't have lost if i was working within just two or three paras.

It is much easier to find a given reference string in the section i'm working on, than to have to search thirty or so other sections, then find my way back to the work point. I estimate my productivity in lengthy articles with merged duplicate refs at maybe one-third of what i have routinely accomplished prior to merge.

The author of the bot proposal we're discussing has commented on another page that the disadvantage of having a reference string outside of the current edit window goes away if we edit entire articles, rather than sections of articles. That may be true, but it also takes away the very real advantages of section edits, including the ability to target precisely and easily the section being edited, and avoidance of many edit conflicts. The difference between editing a full article with 30 some sections, and editing one section or a subset of the full page, is very significant, and for several reasons.

I also like to maintain the flexibility to create complex footnotes, sometimes clarifying a particular quotation, adding the source used by the source, or even

bundling citations

. If i have only abbreviated named references to work from, that means that flexibility is impeded. Full reference strings are much better during the editing process, in my experience.

If i had a way to signal that i was satisfied a particular article was robust enough that major editing is no longer anticipated, and merging dup refs could henceforth be enabled, i would consider that an improvement over current practice. I'm not aware of a way to accomplish that currently, given existing policies/protocols. Richard Myers (talk) 03:14, 27 April 2011 (UTC)

As currently coded, the AWB general fixes do not merge duplicate references in an article where none of the references are named. See

this documentation. Currently the default behaviour for a new article with plain <ref> tags is precisely the behaviour you are asking for. To enable the merging, add a "name=" parameter to one of the references. -- John of Reading (talk

) 07:06, 27 April 2011 (UTC)

@Richard, thanks for explaining that. As someone who does an enormous number of small edits to a great number of articles, I'm left with idea that the vast, vast majority of the articles in WIkipedia are not constructed with the care you show yours. I'm all for figuring out how to prevent your article from being made harder to edit, but at the same time, for each article like that, I'd like to see a little less of [this] than I do. That's from a first-time editor, who has no idea that they could consolidate references. That probably explains why I see a 'bot with a 1RR permanent exclusion (e.g., someone reverts the 'bots changes to references once, it never gets hit again), any "fixes" the bot makes that are problematic would be easily fixed (and not repeatedly hammered) as a solution--it reflects the sort of material I spend a lot of my time on Wikipedia slogging through. But another way to signal it, and I'm absolutely sure that SnotBot could honor a particular exclusion comment if someone asked nicely, would work just as well. In any case, I really do appreciate you explaining why the referencing consolidation gets in your way the way it does. --joe decker^{talk to me} 01:34, 5 May 2011 (UTC)

Yes, i understand this. (And i'm very appreciative of the help related to this situation.) It seems that in the past, articles i have been editing have occasionally had a named reference which i wasn't aware of. I'm now more aware of this circumstance, and will be more watchful in the future. But i'm really more concerned about other editors, who may be at the knowledge level i've had the past few years, that is, the situation of not knowing, and not understanding why the article they may have spent a lot of effort on was suddenly converted to merged references. I'm inclined to believe that the article threshold should be much higher than just having one or two or five named references. best wishes, Richard Myers (talk) 09:42, 27 April 2011 (UTC)

Suggestion for sensible reference names

Regarding autogenerated names for duplicate references: I may be repeating something discussed elsewhere, and am not expert on Wikipedia bots, but a discussion linked above about problems with autogenerated names has merit, although I'm in favour of consolidating references. A name like "AutogeneratedD", or one created automatically from some meaningless text derived from the reference is confusing for future editing. It would be useful when autogenerating reference names to allow bot user input, so that the user can override the bot-suggested name with a meaningful one (like smith_contractlaw2009) before editing the article. Additionally, some way to automatically globally change an existing name to a user-designed sensible one would be handy.

By the way, is everyone familiar with the Template:rp? This allows a single reference to a book, with references to other pages in the same book identified by superscripts. I have tried changing references to use this format, but have met great objections. Pol098 (talk) 17:11, 16 June 2011 (UTC)

At the discussion about MediaWiki:Previewnote someone remarked "There must be some way we can show this to only new users". Assuming there isn't, would it be a good idea to have a way to do this? Perhaps a sort of newusers.css which would allow edit instructions to be highlighted much more boldly? Rd232 ^talk 22:20, 2 May 2011 (UTC)

As of r82285, stylesheets MediaWiki:Group-autoconfirmed.css, MediaWiki:Group-sysop.js, etc, will be loaded automatically if they have content. There are deliberately no stylesheets for the '*' and 'user' groups, mainly for performance reasons, but you can (and should anyway) show the content by default and hide it for autoconfirmed users in Autoconfirmed.css. When the software is next updated to support it, of course. Until then, it might be worth loading those pages with JS to get the functionality immediately, if desired. Happy‑melon 22:55, 2 May 2011 (UTC)

That's rather excellent; well done! I guess we can wait, since we need time to figure out how to use it anyway and kick around some drafts. Suggestions what we could do with this new technology, people? Rd232 ^talk 02:42, 3 May 2011 (UTC)

actualy by abusing the living daylights of of the Uselang function it's just about possible in theory to show things to very new users.©Geni 04:11, 5 May 2011 (UTC)

Due to the continuous argument over use of hyphens vs. en-dash in articles, I have made a proposal to update the Manual of Style to curb the debate. Please see Wikipedia talk:Manual of Style#Hyphen vs. en dash moratorium proposal. — The Hand That Feeds You:^Bite 18:28, 4 May 2011 (UTC)

When a page is tagged for speedy deletion, the speedy deletion template contains a message explaining to the creator that of they wish to contest the deletion they should place the tag {{hang on}} on the page and then edit the talk page, explaining why the page should not be speedy deleted. Two recent discussions have taken place regarding getting rid of this hangon tag process:

• One at the talk page the CSD; and
• Another higher up on this page.

Some of the issues that have been raised for scrapping the process are:

• Despite the seeming simplicity of the instructions, hangon tags are very often misplaced, and misunderstood: They are placed on the user's talk page; they are placed on the article's talk page; they are placed correctly in the article but not in the correct place, and commonly they are placed in place of the speedy deletion template. A check of 16 articles with hangons was noted in the discussion at WT:CSD and only three were placed properly (this implies that an unknown number of users may have tried to contest a speedy deletion but never managed to place the hangon tag at all);
• Many new article creators do not appear to understand that the act of placing the hangon tag itself has no ability to avoid speedy deletion, but that it is just a prelude to writing a talk page rationale. In that way, the hangon tag may actually hinder them from doing what is necessary to avoid deletion by giving them a false impression that the tag itself has some power;
• They are essentially redundant. All administrators are supposed to check talk pages before speedy deleting, and the placement of the hangon tag appears to have little or no affect on whether a page will be deleted or on the timing of that deletion; only a talk page post that addresses the deletion directly does. In other words, one of the ostensible purposes of placing hangons—to inform admins that a protest is going to happen—is ineffective and just forces creators into a two-step process. What matters is whether a sufficient reason has been given not to act on the speedy deletion tag on the talk page, and that talk page post should be seen by the reviewing admin regardless of whether a hangon tag has been placed.

The issue then, if we decide to get rid of them, is what alternative mechanism to put in place? What has been worked on is a direct link in the speedy deletion templates that takes the user to the talk page with a preformatted area to post their reason for contesting the tagging. Give it a try: . Note that the button detects what namespace the tagged page resides in and will say article/page/template etc. in its preformatted headline, depending on what is up for speedy deletion. Meanwhile, the template detects whether the talk page has been created or not. If it remains a red link it displays the following message:

. If, on the other hand, the talk page does exist, the template will display instead the following message:

The draft of this template incorporating these features is at {{db-meta/sandbox2}}. If consensus can be reached, this would replace the current template that all of the db- templates use, located at {{db-meta}}. You can test the template using {{a7-test}}, created for this purpose (it would be best to use the preview button only when doing so). One note: unless some brilliant soul can find a workaround, this will not work with Category:Contested candidates for speedy deletion, so we would lose that category. What say you?

--Fuhghettaboutit (talk) 19:45, 11 April 2011 (UTC)

--Yoenit (talk) 19:45, 11 April 2011 (UTC)

• Excellent proposal. Unless someone finds a very good reason against it, I support it. Hans Adler 20:04, 11 April 2011 (UTC)
• Strongly support this. I can't see any negatives at all. The only thing I'd say is, preserve a non-button method as well for the small but still significant minority who access Wikipedia via a text interface. (Thanks to Amazon's unusual approach to user-friendliness when designing the Kindle, this minority is larger than you might think.) – 
  iridescent
  20:08, 11 April 2011 (UTC)
  • Perhaps we could change the wording above the button somewhat so it is more clear that posting on the talkpage directly is a valid alternative. The red text is quite clear, but will not always show up. Yoenit (talk) 20:26, 11 April 2011 (UTC)
• Support the concept, but should the warning when a hold on request has been made be more visible? And is there a way to distinguish wiki project inclusion tags on the talk page from hold on requests? My concern would be that the project tags go into the forum, then a CSD tag gets placed, and it no longer provides instruction to the creator because the talk page exists from the project tags. Monty₈₄₅ 20:20, 11 April 2011 (UTC)
  • nope, unfortunately not. Only the red warning will disappear when a talkpage exists though, the template and button itself will still tell you to post on the talkapge. Yoenit (talk) 20:26, 11 April 2011 (UTC)

Regarding the above two issues, I have added this text to the template "You can also visit the talk page directly and tailor your own message or to see if you have received a response to your message and continue that discussion."--Fuhghettaboutit (talk) 20:47, 11 April 2011 (UTC)

• I like this idea a lot. The only concern I have is time-lag. A user can add a {{hang on}} tag in a very few seconds, then take his/her time composing the full reasons why the CSD criterion does not apply. A good admin will check the timestamps and should grant a few minutes, maybe even an hour or so for the comments to show up on the Talk page.
  With this process, users have a bias toward making their case in that very first post. While a longer, slower and more detailed message is better for the discussion, it's going to be counter-productive if the page gets deleted in the meantime because no one knew that you were working on your explanation.
  Can a button perform two functions - first to add some small flag that a comment is coming (maybe by posting the section header) then a second to open the edit pane? Or is there some other way to solve the time lag? Rossami (talk) 20:56, 11 April 2011 (UTC)
  • There is no way to make the pressing of the button itself cause a message to be place in the article, or at least I was told it was essentially impossible when I asked one of our best template programmers how to do this. My impression from experience is that the placement of hangon tags themselves rarely delays deletion, though I have no empirical study on this (and of course you may always do this and be an exception). But if that's a sticking point, and there is no workaround, then it comes down to a balancing test. Do the problems with hangon that are solved by this outweigh what we lose?--Fuhghettaboutit (talk) 21:11, 11 April 2011 (UTC)
    • I do see the hangon tags getting some deference, at least for articles that look like they're being started in good-faith. The speedy-tag is being used almost as a "please fix this immediately" tag rather than for it's original purpose.
      You're right about the balancing test. If there's no other way around it, this is still an improvement. Maybe two related tags instead? A first button click that creates the section header on the Talk page and transcludes a second "click here to explain your reasons" button which opens the section and allows the overwriting of the "click here" line? I'm hoping that's not as complicated as it sounds.
      By the way, if this process is adopted, we will have to update the user-notice tag as well. Do we have a draft of that one yet? Thanks again for taking the initiative to work on the problem. Rossami (talk) 21:31, 11 April 2011 (UTC)
      • The two clicks is a really interesting idea! Let me think about that. I'll work on the user tags directly.--Fuhghettaboutit (talk) 22:15, 11 April 2011 (UTC)
      • I just played around with how to do this but I'm afraid it's beyond my coding skills. I thought maybe I could use a preload template containing hangon and created {{Hangon click preload}} for this, but as far as I can tell there's no way to get a preload url to work to place text on an existing page and in a specific spot on that existing page.--Fuhghettaboutit (talk) 23:15, 11 April 2011 (UTC)
        • Regarding a draft for user warnings, I've just put one up at {{Nn-warn/sandbox}}. Obviously this will need to be tweaked for other warnings, but the gist is there.--Fuhghettaboutit (talk) 22:33, 11 April 2011 (UTC)
        • If we write (or have someone else write) a javascript that does it, we can add it to the link using "&withJS=<js location>". Cheers. lifebaka++ 04:11, 12 April 2011 (UTC)
• Support - Wording of the statement opened by clicking the button is a bit long, with all the who-ha about tildes and such, but the idea is a five-star winner. Simplification is good. Carrite (talk) 22:26, 11 April 2011 (UTC)
• Support - Agreed about the inefficacy of the existing '{hangon}' process. Quarl ^(talk) 01:40, 12 April 2011 (UTC)
• Support Sensible proposal that is worth a try. Goodvac (talk) 01:49, 12 April 2011 (UTC)
• Support. This seems like a well-designed solution to an obvious problem. I agree with Carrite about dropping the tilde reminder; it's just one more thing for an article creator to stress over and it's really no big deal if they don't sign their plea on the talk page, since the admin can easily figure out who wrote it. 28bytes (talk) 02:06, 12 April 2011 (UTC)
• Support, but prefer an easy javascript solution. See below. /ƒETCHCOMMS/ 03:04, 12 April 2011 (UTC)
  • • Per opinions above I have shortened the talk page preload by removing the signature instructions. Being unsigned is no barrier for us, whereas the instructions may be a complicating barrier for some users.--Fuhghettaboutit (talk) 11:15, 12 April 2011 (UTC)
• Support This is a good proposal. ~~EBE123~~ ^talk_Contribs 19:12, 12 April 2011 (UTC)
• Yes Newbies screw up hang-on tags more often than not. It's not reasonable to expect them to get it right. Gigs (talk) 20:00, 12 April 2011 (UTC)
• Support Lets
  be bold and implement this right away. Lugnuts (talk
  ) 07:00, 13 April 2011 (UTC)
  • The only thing we would need to wait on is making the (many) user notices we will need including those that Twinkle uses. The form is at {{nn-warn/sandbox}} and I'll get the equivalents for the others done tonight.--Fuhghettaboutit (talk) 12:50, 13 April 2011 (UTC)
• Support, though this could make opposing speedy deletion without understanding of CSD much easier. I'd also support Fetchcomms's idea, if implementable. Guoguo12--Talk--  20:20, 13 April 2011 (UTC)
  • We're up and running. I have changed numerous templates to conform with the new process and am looking for those I missed now.--Fuhghettaboutit (talk) 00:12, 14 April 2011 (UTC)
    • I think I;ve got them all, I've also requested full and indefinite protection for the button image on Commons and will go protect the templates the new db-meta transcludes.--Fuhghettaboutit (talk) 01:35, 14 April 2011 (UTC)

• Neutral — the button itself looks dreadful, and sits awkwardly in the centre of the template. It'd be much more preferable to replace it with a similar line of text. Mephistophelian (talk) 16:14, 14 April 2011 (UTC)
• Support: Out of my time patrolling new pages, most of the article creators have failed to correctly place the {{
  ☭msg_☭contribs
  21:44, 14 April 2011 (UTC)
• Support. Pure genius. Implement it now. Herostratus (talk) 00:18, 15 April 2011 (UTC)
• Support A little on the ugly side, but a definite improvement in usability. Kudos! --JaGa^talk 17:58, 18 April 2011 (UTC)
• Support Newbie friendly and easy to use, exactly what we should be trying to do as often as possible. oknazevad (talk) 17:57, 21 April 2011 (UTC)

New category

As noted, one thing we have lost is the category for contested candidates for speedy deletion. Even though it wouldn't be as targeted, what does everyone think about having a category for speedy delete candidates with existing talk pages? (I'm not sure of the title to use). This would be added to {{Hang on/notice3}}.--Fuhghettaboutit (talk) 13:27, 14 April 2011 (UTC)

I have implemented the new category:

CAT:CSD as Possibly contested (2), and is named that way since it cannot detect whether pages actually have protests but only whether the talk page exists so not all pages inside it will always have protests.--Fuhghettaboutit (talk

) 23:25, 15 April 2011 (UTC)

Go to Wikinews and pick out an article in the "In development, undisputed" section. Notice how the blue message box has a button that says "change", which, if clicked (if you click it, be sure to revert yourself), removes that template and adds a different one. We implement the same javascript on enwiki, put it in the CSD templates, and if a user clicks the button, the js automagically inserts a hangon tag. All we really need to do to make this perfect is for a js popup to prompt for why the page should not be CSD'd, and put that as a parameter in the hangon tag. This would let the reviewing admin look at the reasoning directly on the article (like a prod), instead of opening the talk page as well. Can a techy person look and see if this is feasible? /ƒETCHCOMMS/ 03:04, 12 April 2011 (UTC)

Interesting possibility. It couldn't work just by replacing the CSD template with the current form of hangon tag, or we would be forced to go to history and to the prior version each time to see what the article was tagged with, plus we would lose the ability to have the deletion dialogue preload the deletion summary from the db templates. So I suppose this would need to be coded to detect which speedy template was used and include that with the hangon? I imagine if so we would need either a different version of hangon for each speedy deletion template, and which one would automagically replace the CSD template would be detected by what species of db tag was placed (though multiple tags might be a problem), or alternatively, the new form of hangon would have some kind of multi-parser that would draw from a pages with text for each db-rationale. Anyway, we would need someone very technically proficient and interested enough to help.--Fuhghettaboutit (talk) 11:51, 12 April 2011 (UTC)

I think the code could be tweaked just to add the hangon without removing the original CSD, or to have a parameter in the hangon that says which CSD tag was originally on. (I don't think the technical part is very hard; just wanted to see if anyone thought this would be a more newbie-friendly solution than preloading text/bringing them to a whole other page and possibly confusing them in the process.) I'll ask around to see if this could be done; if it can, do you think it would work or be easier than the original proposal? /ƒETCHCOMMS/ 21:48, 12 April 2011 (UTC)

You know it's hard to say until you see it in a test form, which may reveal options we can't think of now as well as limitations resulting from the mechanics. However, if it can be tweaked so that clicking the button places the hangon tag on the page automatically but still functions the same way to take the user to the talk page with the preload, that would certainly be an improvement, would require changing nothing in this proposal, and is what I ideally wanted to do from the get-go but was told was technically impossible. That would also save the contested CSD category. However, unless we see someone willing to take on the full task very soon, I think we should go ahead and implement this. I will happily do the heavy lifting, such as creating forms for all warning notices that refer to hangon.--Fuhghettaboutit (talk)

• Very strong support' on multiple levels. Not only would this be great for allowing new users to get familiar with how Wikipedia works, and allow the page to not have two massive templates that makes it unreadable, but it would also promote discussion and not just arbitrary decision. Full support. Ajraddatz (Talk) 01:44, 15 April 2011 (UTC)
• OK, with the help of Bawolff (talk · contribs), I have an example up at User talk:Fetchcomms/Sandbox 5. It will require this code in your user js:

addOnloadHook(function () {
    var changeCSDToHangon = document.getElementById('hangonbutton');
    if (changeCSDToHangon) {
        try {
            importScriptURI('https://secure.wikimedia.org/wikinews/en/w/index.php?title=user:Bawolff/mwapilib2.js&action=raw&ctype=text/javascript');
            var button = document.createElement('button');
            button.type = 'button';
            button.appendChild(changeCSDToHangon .firstChild.firstChild);
            changeCSDToHangon .replaceChild(button, changeCSDToHangon .firstChild);
            button.onclick = function () {
                var hangonReason = prompt("Why should this article not be deleted yet?", "");
                if(!hangonReason) return alert("You must provide a reason for why this page should not be deleted!");
                if (this && this.firstChild && this.firstChild.data) this.firstChild.data = "Loading ...";
                api(wgPageName).getPage().
                    setDefaultSummary("Please do not delete this article yet").
                    replace(/^/, "\{\{hangon|" + hangonReason +"}}\n").
                    savePage().
                    lift(function () {
                        alert("Tagging successful!");
                        location.reload();
                    }).
                    exec();
            }
        }
        catch (e) {}
    }
});

• Can a few people try this? I'm still trying too see how to get it to prompt for a reason for the hangon, however. /ƒETCHCOMMS/ 23:48, 15 April 2011 (UTC)
  • I now have it where a prompt appears and passes that as the reason param in the hangon tag. Please try the updated code in the above collapse box and see if it works. /ƒETCHCOMMS/ 20:11, 16 April 2011 (UTC)

It works great! This is much better than the current proposal, IMO. However, make sure to give some more space for the rationale in the prompt, both to allow more text to be written without the beginning of it sliding out of sight, and to encourage better thought-through rationales. --

talk

00:47, 17 April 2011 (UTC)

This is very interesting. It shows there is a possibility to place the hangons back in an effective way. However, I think it should work in a quite a different way. What I would imagine would be ideal would be as follows. When a person clicks the button they are transported to the talk page just as they are now, where they can write their rationale with the preload instructions in place. Meanwhile, the clicking of the button would also place the hangon on the article to show that the button had been pressed. providing the normal hangon alert (which would also get back the full functionality of the contested category). The way it operates now is not ideal for a number of reasons. (to lurkers, none of this will make sense unless you try out the code to see what it does).

• First, people need to be able to read the text they write as a unified whole; to go back over it; to compose a complete response possibly over a few paragraphs; to be able to preview it and so on. Writing text in a small text field is incredibly hampering (this format also pretty much guarantees that posts will never be signed by new users).
• The protest needs to be placed at a discussion format, i.e., a talk page. The way this is set up, after the initial post appears in the hangon, there's effectively no way to respond but to click edit this page on the article, then figure out that the text posted is the parameter in the hangon tag ({{Hang on|creator's protest text}}), then use relatively advanced markup right next to the text, such as using <p> to offset a response, and then saving. This will not format well, but it would work somewhat as a response but many users will not know how to post a response at all, and very few creators will know how to respond thereafter. There are often talk page backs and forth on contested deletions and this simply will not allow that or make it so unwieldy to do so that it might as well be seen as a complete bar.
• I don't think the protest should be in the article at all. As someone who has reviewed thousands of db-tags, I can tell you that sometimes we get "FUCK YOU ASSHOLE!" and much worse, such as BLP violations, as the talk page response; now they will be on public view in the article.
• We occasionally see a reason to keep talk pages of CSD discussions even when the article is deleted, but now the discussion is part of the page, so if we delete it, perforce, we delete the discussion. And if we keep the article, the normally behind-the-scenes deletion discussion is permanently part of the page history barring revdeletion. Would we want that?--Fuhghettaboutit (talk) 06:03, 17 April 2011 (UTC)

I like the {{hangon}} + talk page combination, if that can be made to work. We shouldn't rely on editors having JavaScript turned on. With JS off, at least they'd get their message onto the talk page. -- John of Reading (talk) 06:40, 17 April 2011 (UTC)

• OK, so I've created User:Fetchcomms/hangon.js, which creates the button, adds the hangon when clicked, and then redirects to the talk page editing screen with current preload text. Instead of adding all the code to your js page, just add importScript('User:Fetchcomms/hangon.js'); to it and try this at User:Fetchcomms/test (because my previous test page was on a talk page already). Thanks for the feedback, /ƒETCHCOMMS/ 20:01, 17 April 2011 (UTC)
  • Actually, I'll need to tweak the code to work on non-mainspace pages, so don't try that just yet! /ƒETCHCOMMS/ 20:03, 17 April 2011 (UTC)

You were too slow with your second post, and I had already tried it. The button changed to "Loading..." and nothing else happened. I didn't manage to add a "hangon" tag to your test page. -- John of Reading (talk) 20:12, 17 April 2011 (UTC)

Hm, can you try purging and trying again? I fixed the code and it's now working for me. If it still doesn't work, wait for a bit and see if it's just the js being slow; otherwise, I'm not sure what's going on. /ƒETCHCOMMS/ 20:52, 17 April 2011 (UTC)

Two messages on the Firefox error console when I press the button: (1) Empty string passed to getElementById (2) api(wgPageName).getPage is not a function - is there some other stript I have to load before hangon.js will work? -- John of Reading (talk) 21:15, 17 April 2011 (UTC)

Looks nice :) Two things:

1. Change the wording of the message "you're not done until, etc." to something maybe like "A hang-on notice has been added to the page. You must now add your reasons in the edit box that will show up next, otherwise the request to stop the deletion process will be denied."
2. Use the editintro url parameter to provide further instructions, guidelines, links, etc. It could link to an empty page right now, which can later be filled with relevant content. --
   talk
   22:56, 17 April 2011 (UTC)

John, the script utilizes wikinews:user:Bawolff/mwapilib2.js, but that's for creating the button (I think that's the main thing it does), so I'm not sure what's causing your errors—I'm asking someone with a background in javascript to take a look. /ƒETCHCOMMS/ 01:56, 18 April 2011 (UTC)

• Support Much more newbie-friendly and easy, it'd save NPPers, admins and CSD patrolling users a lot of hassle. —
  Talk • Contribs
  ) • 9:39pm • 11:39, 18 April 2011 (UTC)

What a great combination! Works great. Thanks for working on this Fetchcomms. I suppose the next step is to talk to developers about adding this to the sitewide js file (no idea what it's called)? Have you spoken with anyone yet? User:Tim Starling might be the right person to talk to, though I'm not sure. I would change the text a little bit. Right now it tells the user, in part, "If you do not explain why, your request to prevent deletion will be denied", which implies that if the person adds a reason to the talk page, the page will not be deleted, regardless of the reason provided. The text also assumes it's an "article" and it doesn't tell the person what the purpose of the hang on tag is, as the prior text in db-meta did when it decribed placing the hang on tag. Also, I think hang on should be in quotes here. I would suggest changing it to just: A "hang on" notice has been added to the page. This will alert administrators that you intend to dispute this speedy deletion by explaining why you believe this template should not be deleted on the next page.--Fuhghettaboutit (talk) 01:00, 19 April 2011 (UTC)

Well, any admin can add it in now to Mediawiki:Common.js. However (after I tweak the message as you said), there are two concerns I have that I'd need someone who knows js well to look over: 1) It will work for users with js disabled (just need to change the link in my actual sandbox/test page to the preload one), but I'm not sure about overall accessibility. I'd like some wider testing, at least, first—can you ask a few NPPers or something to check out this thread and test out the js? 2) Bawolff, who was the original author of the base button code, told me that, because this uses a custom javascript library (the Wikinews thing I linked to above), it's slightly hacky and not perfect—good enough for us, yes, but probably not for all users, registered and anonymous. As a result, he suggested the button-creating code be rewritten in jQuery; however, I only know enough to tweak existing code, not devise something from scratch. I'll ask a few javascript wizards to see if they have time to do this, because the current code probably shouldn't be in Mediawiki:Common.js at this point. Thanks for testing the code! /ƒETCHCOMMS/ 02:37, 19 April 2011 (UTC)

I was asked to comment on this, and I'll reply in more detail later - probably over the 4 day weekend! A few brief initial comments. 1) If supporting non JS users is trivial, lets do it, otherwise I wouldn't worry about it. Every remotely modern browser (even IE 6) supports Javascript, and if users choose to deliberately disable it they'll be techies and expect that stuff won't just work™ when they are using the internet. 2) Redoing in JQuery sounds like a good idea, as JQuery works in every browser including IE 6 whereas specific normal Javascript may not work, I can take a look at this over the weekend probably.

Finally someone needs to QA the script in IE 6 on Windows XP before the code goes live, we do need to support those users. -- Eraserhead1 <talk> 20:48, 19 April 2011 (UTC)

Obviously, once this change is made, db-meta will need to be tweaked contemporaneously. {{Db-meta/sandbox2}} now contains the text I would propose to be added upon the change.--Fuhghettaboutit (talk) 21:31, 19 April 2011 (UTC)

Instead of adding an additional template {{hangon}} to the page, could you just add a new parameter (e.g. |hangon=yes) to the CSD template? By making a small change to {{db-meta}} we could create the same appearance but it may be neater and allow for additional functionality and flexibility. — Martin (MSGJ · talk) 11:45, 20 April 2011 (UTC)

That makes sense to me, although I'm not sure exactly how to change the script to add a parameter instead of a whole template. It's not a terribly big deal right now, but combining the two templates would be reasonable in the long run. /ƒETCHCOMMS/ 04:12, 21 April 2011 (UTC)

addOnloadHook(function () {
    try {
		var thisOuter = this;
        $('#hangonbutton').click(function () {
                var hangonReason = prompt("Why should this article not be deleted yet?", "");
                if(!hangonReason) return alert("You must provide a reason for why this page should not be deleted!");
                if (thisOuter && thisOuter.firstChild && thisOuter.firstChild.data) thisOuter.firstChild.data = "Loading ...";
                api(wgPageName).getPage().
                    setDefaultSummary("Please do not delete this article yet").
                    replace(/^/, "\{\{hangon|" + hangonReason +"}}\n").
                    savePage().
                    lift(function () {
                        alert("Tagging successful!");
                        location.reload();
                    }).
                    exec();
            });
        }
        catch (e) {}
});

OK, the above uses JQuery and should work - I haven't tested it though. -- Eraserhead1 <talk> 08:56, 22 April 2011 (UTC)

Hm, it doesn't do anything for me—also, is it still reliant on wikinews:User:Bawolff/mwapilib2.js, or does it stand on its own? I think Bawolff was saying that this custom library shouldn't be used for sitewide js. /ƒETCHCOMMS/ 22:59, 22 April 2011 (UTC)

It should be standalone. Where's the test page? -- Eraserhead1 <talk> 18:36, 23 April 2011 (UTC)

User:Fetchcomms/test (might have to change it to work in userspace?). /ƒETCHCOMMS/ 05:04, 24 April 2011 (UTC)

I've made some progress with displaying the message with User:Eraserhead1/hangon.js and that creates and styles (with JQuery rather than straight CSS unfortunately) a "button" and a dialog is shown. Unfortunately I'm having an issue with Firebug claiming that it cannot find the variable 'api' and its not working 100% yet. -- Eraserhead1 <talk> 20:51, 25 April 2011 (UTC)

I get the same issue with the other button as well. I don't think its a JQuery issue. -- Eraserhead1 <talk> 16:38, 29 April 2011 (UTC)

A problem

The recently implement changes direct editors (who don't carefully read every word of the db warning) to place their hangon rationale at File_talk:Speedy_delete_contest_button.png. One has already and I expect more to come. The button should probably be unlinked from the user talk page notice, but I can't do that myself unless the license is changed from CC-BY-SA to PD. Suffusion of Yellow (talk) 00:48, 14 April 2011 (UTC)

Damn, I'm sure it's something from one of the talk page notices, not the db-tags. Let me start testing them.

--Fuhghettaboutit (talk) 00:52, 14 April 2011 (UTC)

Yes, I meant the talk page notices. I haven't noticed any problems with the article tags. Suffusion of Yellow (talk) 00:56, 14 April 2011 (UTC)

Okay, I know what's going on. Some of the talk page notices actually provide the button with the same capability as the button in the db tags (where the template always has the article name as a parameter so that that can be passed through to {{{1}}}) and some of them say instead "If you do not believe the article deserves to be deleted, then you may contest the deletion by clicking on the button that looks like this: which appears inside of the speedy deletion... Of course some percentage of users aren't going to read and will click on the button, if it's clickable, so I need to go make it unclickable where it's used like this.--Fuhghettaboutit (talk) 01:01, 14 April 2011 (UTC)

All fixed—the image links in the notice templates are now unclickable. Thanks for looking out!--Fuhghettaboutit (talk) 01:18, 14 April 2011 (UTC)

• • Looking at how it is now being used, all editors , not just the author, are likely to use the button, instead of doing what they are actually directed to do, which is to simply remove the db template and say why on the talk p. or the edit summary. A rewording (and drastic shortening) of the template might help, and I'm going to try one. DGG ( talk ) 04:16, 15 April 2011 (UTC)

Preload content

Thanks, Fuhghettaboutit. The new button is nice. Now that it's been implemented do you mind moving the discussion to Template talk:Db-meta? One issue I've noticed is that hangers-on, who are 99% newbies, don't understand Wiki markup or HTML. So they write their don't-delete rationale inside <-- --> comments, which may be missed by the admin. I suggest we replace the comment characters with language that makes it obvious the template language needs to be replaced. Quarl ^(talk) 04:32, 14 April 2011 (UTC)

Now that you raised it, it's pretty obvious that this would be happening. It's also no burden on us if the preload text is left in place sometimes. I'll remove the comment out tags now. So, do you think we should just copy the entirety of this discussion to the template talk page?--Fuhghettaboutit (talk) 10:08, 14 April 2011 (UTC)

On the talk pages of articles I look through for speedy deletions, I still see the default message up, which doesn't get replaced:

=== This article should not be speedy deleted because... ===

Replace this text with your reason for contesting the speedy deletion and then click "save page" below. ~~~~

And then they type their message immediately afterwards or even copypaste what is displayed above. I don't know if there is a way hide this instruction (i.e. via commenting out or something else) without getting in the way of those who are a bit on the slow side? Commons uses various user scripts, many of which are fairly clean and newcomer-friendly, to handle many deletion requests over there; we could implement something like that with this, if site-wide scripts are desired. –MuZemike 09:21, 15 April 2011 (UTC)

It was originally commented out, but this was replaced by the current message because of fear users would break it and end up commenting out their entire post. I can think of two possible alternatives:

1. Use an editnotice to convey the information
2. Change the text to something like this:

=== Contested Deletion ===

This page should not be speedily deleted because...

The first option would removed the text completely, while in the second scenario the user hopefully understands he can continue the sentence with his rationale. Yoenit (talk) 10:29, 15 April 2011 (UTC)

I think the second is likely to work much better than the current and can be changed immediately. Let's try it. Not sure about a editnotice. AFAIK that require a separate page to be created each time in the form Template:Editnotices/Page/Talk:NAME. So every speedy deletion protest will create a new page that would only be applicable to the creator and each one would have to be separately deleted when the speedy deletion is done.--Fuhghettaboutit (talk) 11:45, 15 April 2011 (UTC)

The <inputbox> syntax allows for a parameter "editintro=PAGENAME" which makes PAGENAME act as an edit notice. -- John of Reading (talk) 22:41, 15 April 2011 (UTC)

Neat. So I created an editintro for the preload, {{Hangon preload editintro}}, but I don't know if we should use it, or at least use it for the purpose of telling them to leave the tildes in place. You can view what it looks like in the preload at this URL. What seems silly to me is that following the editintro text, quite redundantly at least in part, the sitewide talk page notice already says "This is a talk page. Please respect the talk page guidelines, and remember to sign your posts by typing four tildes (~~~~)". Please do edit this editintro template, possibly removing the stuff about tildes entirely with a different relevant message.--Fuhghettaboutit (talk) 08:37, 16 April 2011 (UTC)

You're right, the signature isn't that important. With a bit more effort, there could be one editintro for each speedy deletion criterion: "To contest an A7 you need to show..." -- John of Reading (talk) 08:57, 16 April 2011 (UTC)

Pretty sure your are referring to an editnotice— an editintro is a bit different. See

WP:EDITINTRO. ---— Gadget850 (Ed) ^talk

22:44, 18 April 2011 (UTC)

Ah— inputbox uses the term for something different. ---— Gadget850 (Ed) ^talk 12:04, 19 April 2011 (UTC)

I think the signature should be dropped from the edit form presented when clicking the button - I haven't seen a single case yet where a new user hasn't placed their actual reasoning after the signature, which looks weird and might discourage new users, while having no signature hardly matters. Zakhalesh (talk) 18:22, 20 April 2011 (UTC)

Timestamp to prevent Miszabot's auto-archival mistake.

Meh, more ranks might start creating the impression of wiki-elites and such. =p The situation on things like Osama will eventually calm down though. Sir William Matthew Flinders Petrie Say Shalom! 19:22, 3 May 2011 (UTC)

I'm not sure I follow you. If an article is semi-protected (as

Death of Osama bin Laden currently is), very very new accounts can't edit it anyway. 28bytes (talk

) 19:27, 3 May 2011 (UTC)

Very very new accounts that have passed autoconfirmed (which IMO is too low). 10 days+100 edits (can be anywhere even his talk/user page!) --

edit

at a time!  19:34, 3 May 2011 (UTC)

Do you mean protection level? If so, a new user group would need to be created or the right would have to be added to older user groups like rollbacker, reviewer and autopatrolled, as well as sysop so they could edit.  Hazard-SJ  ±  00:56, 4 May 2011 (UTC)

There is already a protection level that does this, one of the pending changes levels only allows those with the reviewer flag to edit or approve changes. Extremely controversial even when it gets set to only enforce pending on editors who are not auto-confirmed, I can only imagine the hue and cry if someone set that on a hot article like the death... Monty₈₄₅ 01:10, 4 May 2011 (UTC)

The issue is that semi-protection / full protection are very "hammer," when sometimes you need something a bit more flexible. You should be able to easily configure any page to have arbitrary restrictions. For example, some pages should require over 100 edits, while others should require a certain amount of time editing, or require that editors be in certain user groups, etc. Something like this is vaguely possible with the AbuseFilter currently, but it's clunky as shit and not very efficient. A native solution that kills the current rigid page protection setup is what you're after, I imagine. A random new "rank" isn't a real solution. --MZMcBride (talk) 05:18, 5 May 2011 (UTC)

Since this is a proposal for a usergroup permission higher thatn autoconfirmed this is in relation to editing through full protection. Full protection is very sparingly used. When it is used it's because there has been a consistent demonstration of disruption on the page from multiple editors that are already confirmed. The only people we let edit through a full portection are administrators, bureaucrats, and

• Oppose This new rank isn't well defined, and there dosen't seem to be a consensus that any new userright or usergruop is needed.
  Wha?
  08:54, 6 May 2011 (UTC)
• Strong Oppose : Wikipedia is already rather bureaucratic, let's not make it worse. Plus, we'll have tons of those rights-hungry people trying to attain the new right (When filemover was introduced, lot's of unrelated people joined..and have done nothing...). ManishEarth^{Talk • Stalk} 16:06, 6 May 2011 (UTC)
• Oppose, as there seems no real need with Pending Changes and normal protection already in use.  Hazard-SJ  ±  20:42, 6 May 2011 (UTC)

At

You have misunderstood the outcome of the AFD. Nobody has said that the works are inherently notable, or that they inherit notability from their author. What the editors said is this: If you are unable to find sources about the major works written by the winner of a Nobel prize for literature, it is only because you did not search effectively for them.

Note, please, that it is the existence of the sources, not the naming of the sources in the article, that matters for these things.

If I have not too badly misunderstood the German-language sources, then ISBN 9783860997765 gives the title as an example of her concise and densely meaningful writing style on page 14, and ISBN 9783906759982 says that the work addresses the psychological pain of waiting for arrivals and departures on page 76. Another appears to deal with the issue of paradox (a loose translation of the title might be "We have arrived, but we are not there"). There are certainly more sources where these came from. It would be silly to delete an article simply because one editor was unable to find sources for it. WhatamIdoing (talk) 03:47, 5 May 2011 (UTC)

Then the articles should at least be tagged with a cleanup template requiring more citations or something similar. And there were arguments like It's a very safe bet that literary works by Nobel laureates in literature will have received the coverage required to establish notability. Instead of annoying other editors with such a nonsense, sources should have been brought up at the AfD. Only because a book was written by a Nobel laureate doesn't automatically mean this work has received coverage by third-party sources. Yes, I believe it is in fact possible for a Nobel laureate to write a non-notable book that shouldn't have an article on Wikipedia. The only exceptions are books by authors who are considered so significant that each of that authors works will be notable. I don't see that

WP:NBOOK#Criteria. Otherwise I fail to see where these books established their notability. Toshio Yamaguchi (talk

) 18:42, 5 May 2011 (UTC)

The very concept of "inherent notability" is controversial. Note that the link for the term in your proposed template goes to an essay, not a policy or guideline. AFD may decide that an article should be kept, but such decisions don't typically declare a subject to be "inherently" notable. If moved into template space, an article tag making such claims would probably be deleted on "misrepresentation of policy" grounds. --RL0919 (talk) 15:03, 6 May 2011 (UTC)

Toshio, I agree that in the best of all worlds, the folks at AFD would have found the sources I did and told you about them, so there could be no doubt left in your mind. But in the best of all possible worlds, you would never have nominated it for deletion, because you would have found the sources I did. Sadly, we do not live in the best of all possible worlds, and we are thus left with this confusion and frustration. It is not their fault that you did not find these sources, just like it is not your fault that they failed to tell you about them. The important thing is that the sources do exist, and the article was correctly kept. We can therefore all move on to more important things.

You should feel free to leave a note on the article's talk page about these sources; there's no need for the next person to wonder whether any sources exist.

(And, yes, you should expect that template to be deleted. I suggest tagging it with {{

db-author}}.) WhatamIdoing (talk

) 02:45, 7 May 2011 (UTC)

I'm almost certainly in the wrong place, but I can't read most of the language names on the left side of the page where the links to each article in other languages are found. If I somehow end up in another language's Wikipedia (I'm not saying how I would, but if I did), how could someone reading English figure out what language it was? Surely there is already a way to do this. I thought of the idea for labeling each page and then realized it would have to be done for every language, which is impossible. But English speakers developed it so maybe the language could be identified for English speakers, and then too bad for everyone else.Vchimpanzee · talk · contributions · 22:23, 4 May 2011 (UTC)

List of Wikipedias tells you what each of the prefixes mean. When you hover over (for example) the "العربية" link on the left side of this page, you'll see the page it links to starts with "http://ar.wikipedia.org/". From the List of Wikipedias, you can see that "ar" means it's the Arabic Wikipedia. (It's possible I'm misunderstanding your question, of course.) 28bytes (talk) 22:28, 4 May 2011 (UTC)

I don't think it's really that big a deal. Someone can easily look up the two letter language code (is it ISO?) in front of wikipedia.org to see what language they were reading. BurtAlert (talk) 22:30, 4 May 2011 (UTC)

I'm inclined to agree with you; I don't think this is a big deal. EVula // talk // ☯ // 05:37, 5 May 2011 (UTC)

Okay, I get that I can see the two-letter code in the URL, but is there a list of these in alphabetical order somewhere? Actually, the reader of English who has somehow ended up in another language's article still doesn't know this or where the codes are without asking someone.Vchimpanzee · talk · contributions · 17:53, 5 May 2011 (UTC)

Fill your boots. A hypothetical reader who ended up on another language Wikipedia could always click the link that says "English" at the side of the page. – 

iridescent

17:58, 5 May 2011 (UTC)

But I'm thinking the reader might want to see what language that is where he or she is. Okay, I have all I need to know, so thanks.Vchimpanzee · talk · contributions ·

Yes but not someone stumbling upon the Wikipedia due to queries on the IRC's etc. By knowing what language the Wikipedia is written in, appriopriate help can be asked quickly. This can be used in deciding who is best suted to fix/solve the problem ie asking a French Wikipedian to help with technical aspect of the French Wikipedia, German Wikipedian with German Wikipedia, etc. Perhaps we can add a small word saying "English" at the bottom of the globe figure? --

reputations

00:49, 6 May 2011 (UTC)

So there should be a small block of English on every single language edition of Wikipedia? What about Korean readers; they might not know the difference between the Spanish and French editions, and an English tag wouldn't help them... do you see my point? Why would we favor English in this, especially if it's not really a problem? (if someone is jumping on IRC to ask a support question, I think it's reasonable to assume that they're technologically savvy enough to figure out what the ISO codes are) EVula // talk // ☯ // 05:52, 6 May 2011 (UTC)

It would be nice if appending "?uselang=en" while viewing a foreign Wikipedia would not only translate the user interface to English, but additionally give you an indication of the language's English name. —Кузьма^討論 08:07, 6 May 2011 (UTC)

Regarding the question "What about Korean readers", I did make the point when I first asked the question, although I didn't make it in such a way that it was obvious.Vchimpanzee · talk · contributions · 18:52, 6 May 2011 (UTC)

I don't remember where, but I think I saw a gadget that translated them. In any case, couldn't one be created here and made available for use?  Hazard-SJ  ±  20:40, 6 May 2011 (UTC)

The gadget you might want is this one. Actually, it's an extension of User:Tra/sidebartranslate.js (which for some reason has gone bye-bye). Tra's script translates the sidebar into English. My script does the same and also adds a tiny link to google translate for the page. ManishEarth^{Talk • Stalk} 04:23, 7 May 2011 (UTC)

You could try using this

javascript:var%20t=((window.getSelection&&window.getSelection())||(document.getSelection&&document.getSelection())||(document.selection&&document.selection.createRange&&document.selection.createRange().text));var%20e=(document.charset||document.characterSet);if(t!=''){location.href='http://translate.google.com/translate_t?text='+t+'&hl=en&langpair=auto|en&tbb=1&ie='+e;}else{location.href='http://translate.google.com/translate?u='+escape(location.href)+'&hl=en&langpair=auto|en&tbb=1&ie='+e;};)

in a toolbar bookmark. – Allen4names 02:26, 7 May 2011 (UTC)

When you are reverting, and intending to write an edit summary go to the slot provided you are presented with a slot full of text. This information comprises details of the edit you are reverting. Would it not be possible for the slot to be presented blank? I ask because when I started editing here it was a while before I worked out that you are supposed to move your cursor to the end of the text and add your edit summary. I think that some people would either not understand that this is what you do or, once they find that you have to do this, cannot be bothered to do it. I think we are losing edit summaries this way. Britmax (talk) 09:43, 8 May 2011 (UTC)

I've wondered in the past if we shouldn't expose a bit more of Wikipedia's innards on the Main Page (a section of it for highlighting backlogs, for instance). And I've just noticed that the section "Other areas of Wikipedia" only covers half the page. Why not use the other half to show the

I don't think the Signpost should be for the general public. However, I agree that a bit more of the inner workings of Wikipedia (as opposed to a finished-looking project) should be visible from the Main Page. Most other Wikipedias (ok, I just checked German, French, Spanish, and Polish) have much more visible content about the project or suggesting contribution than we do. Even just making the "Other areas of Wikipedia" stand out more (it has no images, and is low on a page full with images and information) might help draw people to the Community Portal, where the Signpost is included. I guess the next redesign of the Main Page should focus more on "free" and "anyone can edit" than "encyclopedia". —Кузьма^討論 11:09, 2 May 2011 (UTC)

Linking the Signpost on the Main Page has been suggested before, see here, here and here. Regards, HaeB (talk) 12:25, 5 May 2011 (UTC)

The advantage of the Signpost is that there's something ready to slot into an otherwise unused space. Anything else will take vast amounts of time and effort to agree on, and could easily take years. Of the three links you provide, only one (the last) is a substantive discussion, from nearly a year ago, and the arguments are unconvincing. The "main page is for readers" as an argument against is founded on a fundamentally unwiki divide between editors and readers. I also can't see that the Signpost will actively confuse anyone; and even for readers who wish to remain readers, a sense of the inner workings would be helpful. Rd232 ^talk 20:03, 5 May 2011 (UTC)

Strongly oppose this. I agree with every word of this IP's comments the last-but-one time someone suggested this; the main page is supposed to be useful to the 99% of our readers who have no interest in how Wikipedia operates, not an ego boost for the couple of dozen people involved in the Signpost. – 

iridescent

21:15, 5 May 2011 (UTC)

Most of the Main Page (everything except In the News) is an ego boost for a handful of editors. So adding the Signpost wouldn't change that. —Кузьма^討論 21:26, 5 May 2011 (UTC)

Um, what? I'm not proposing it from the point of view of "recognition" of Signpost contributors (and for the record I'm not involved myself). As I said initially, I think it would be valuable in giving people more of a sense of the Wikipedia community. People complain constantly about editor decline, but the biggest single obstacle to really tackling it seems to be admitting that there is a community. Wikipedia is not just a bunch of servers and a MediaWiki installation. For exactly the same reason, my metric for success on a trial of requiring autoconfirmed status in order to create articles (without assistance) is an increase in the number of editors who are reasonably interested in really contributing to the project, rather than self-promotion (measured tentatively as, say, 100+ edits to >3 articles and >5 talkpage posts). Rd232 ^talk 21:50, 5 May 2011 (UTC)

Your belief that the section "only covers half the page" and that the proposed addition would fill "otherwise unused space" is based upon your personal display settings. Under my configuration, the longest item spans more than 4/5 of the page's width. For others, the full width is used (possibly with some of the text wrapping to a second line). —

David Levy

22:40, 5 May 2011 (UTC)

OK, that's true. But at the end of the day, at present it's effectively one column, compared to the top two sections (Featured Article and In the News) occupying two. So even if adding a column would make the existing text wrap on smaller displays, it won't wrap any more than those two sections already do. Rd232 ^talk 23:43, 5 May 2011 (UTC)

Agreed. I don't mean to suggest that the idea isn't technically feasible. However, I don't personally regard such content as appropriate for the main page (though the addition of a Signpost link might be an acceptable compromise). —

David Levy

00:54, 6 May 2011 (UTC)

For what it's worth, I think putting a link to the Signpost on the Mainpage would be a good idea. People often come to the Wikipedia main page because they're curious about Wikipedia, and while about Wikipedia would be the natural link for that, some people main be curious with what's going on with Wikipedia now. As a general rule, whenever I go to a website main page I always like to checkout what's new with the site, if just for my own curiosity. Jztinfinity (talk) 18:01, 7 May 2011 (UTC)

Can't we just put a collaspable section of the transcluded sign post? --

IIRC, the problem has been that WebCite has had uptime/throughput issues, so there's a continually growing backlog. There was talk of having the WMF sponsor WebCite, having the WMF brew its own archival tool, or using

Archive.org's service, but I don't recall any action being taken. Perhaps someone can locate the past discussion in question? --Cybercobra (talk)

00:05, 3 May 2011 (UTC)

I used to relatively frequently archive material via WebCite, until it became clear that a reasonable large fraction of complex sites (such as almost all modern news sites associated with paper newspapers) archive in a mangled or poorly rendered manner. Though we would like for everything to be available online, the reality is that we must support the use of citations which are not available online, which includes, for instance, microfilmed newspapers in public libraries and physical books which have not been scanned for free online reading. Linkrot is not the primary problem; lack of supporting citations is. --User:Ceyockey (talk to me) 02:22, 3 May 2011 (UTC)

I agree linkrot isnt as bad as a lack of supporting citations in the first place. And of course it has long been established that physical books, magazines, newspapers that are not available at all online are perfectly fine and on equal footing with online sources. The loss of a link to a newspaper site doesn't invalidate the citation because a physical copy of the newspaper exists in some form somewhere and that is all that is needed, removal of the url from the citation keeps the citation valid because "someone, somewhere CAN" check the source themselves. Linkrot becomes a problem when the link is to something ONLY online, and I've personally come across links that I put in that later die and I can NOT find the same information ANYWHERE online. Even though I know it to be correct information it becomes either cited to a deadlink or it becomes uncited, which it then can be removed at will by any jerk. What is the recourse then?Camelbinky (talk) 02:31, 3 May 2011 (UTC)

The solution depends in part on what the nature of the source is. If it is something governmental which can also be considered public domain, putting the content into Wikisource could be a solution. WebCite remains a valid tool, with a few technical and performance bumps. If something disappeared recently (??how much time??) then it might still exist in a Google Cache form which could be captured via WebCite; this is true of other search engines as well, that there might be fading copies extant (I'm not sure which search engines retain cached copies in addition to Google). Another option is to quote (using quote parameter in a citation template) the salient passage from a potential transient web site; that at least would preserve the snippet, albeit in an unverifiable form. It would be useful to collate a set of source type which fall into the 'unrecoverable' class to use in considering additional options. --User:Ceyockey (talk to me) 03:00, 3 May 2011 (UTC)

I just want to clarify that there are no problems with WebCite. They have submissions throttled to reduce spam and have specifically said that anybody from Wikipedia can be whitelisted for full speed submissions. - Hydroxonium (T•C•V) 16:47, 8 May 2011 (UTC)

As I recall though, there were load problems when WebCiteBot was running. Not massive ones, but intermittent problems throughout (EDIT: as noted by CC above). - Jarry1250 ^{[Weasel? Discuss.]} 16:53, 8 May 2011 (UTC)

There are some technical problems related to website formatting. For instance, a news outlet that I use frequently, The News Journal (a Gannett property), has their DelawareOnline website configured in a manner that a) only the first of a multi-page web article can be archived effectively and b) it is not possible to archive a full article via the print function (some websites assign a recoverable url to ready-for-print articles; not so in this case). I'm not sure how widespread such is among other reliable source sites. --User:Ceyockey (talk to me) 17:02, 8 May 2011 (UTC)

I fail to see how a solution that has some issues is any worse than no solution at all. WebCite might not be ideal to archive everything, but there is a lot of stuff it can handle. For the stuff it can't handle, other solutions would need to be found, but until this happens we should have a solution that already works today (with some issues). Toshio Yamaguchi (talk) 17:47, 8 May 2011 (UTC)

Did I say anything about "avoid WebCitation.org"? No. Please be more circumspect in your critiques. --User:Ceyockey (talk to me) 18:25, 8 May 2011 (UTC)

Accepted and I apologize for my misinterpretation and misrepresentation of your comment. And I agree that Wikipedia should not entirely rely on online available sources. All I say is if it were possible to integrate something like Δ's script into the Wikipedia interface (for example into the toolbox), this possibility should be taken into a more serious consideration. Toshio Yamaguchi (talk) 18:59, 8 May 2011 (UTC)