Wiktionary talk:Page deletion guidelines

Latest comment: 9 years ago by Renard Migrant in topic Arguments to avoid

Question edit

What I'm looking for on this page, but can't find:-

  • I've renamed/moved a page, and deleted the content of the resulting Redirect page. What do I then have to do to get that now useless ex-redirect page deleted. Orr will it be automatically deleted some time in the future, it having no content ?--Richardb 11:34, 8 Dec 2004 (UTC)

You put it on {{rfd}} for immediate deletion. Otherwise it will remain forever. Polyglot 12:24, 8 Dec 2004 (UTC)

Ammendment to Wiktionary:Page_deletion_guidelines#What_to_delete_and_what_to_keep #3 edit

I would like to add to Wiktionary:Page_deletion_guidelines#What_to_delete_and_what_to_keep item #3 the curcumstance where a page is likely linked-to from external sources. In particular, Transwiki: redirect pages should be kept by merit of such a rule. Additionally, almost all redirects (except as a result of blatant vandalism) should be kept. Comments please. --Connel MacKenzie 08:37, 15 May 2005 (UTC)Reply

Deletion of broken redirects edit

Do broken redirects qualify for speedy deletions? If not, what should we do? As I am an administrator here for less than two weeks, I would like to know more. I just saw at least 1000 broken redirects, mostly capitalized common words varied from their base forms.--Jusjih 16:50, 14 May 2006 (UTC)Reply

utilities vs Index to Internals edit

It currently says

but Wiktionary:Index to Internals says it has been deprecated in favor of utilities. Which way is it going? RJFJR 19:49, 17 October 2006 (UTC)Reply

Proposal: mandatory notification edit

I propose that talk page notification be mandatory for all imminent and executed deletions, including requests for verification, requests for deletion, and sysop deletion. This procedure enjoys existing community support, has longstanding support on multiple WMF projects, and can be easily managed with templates and existing automation tools.   — C M B J   08:39, 5 June 2013 (UTC)Reply

Watchlists are pretty much useless. I have ~ 55k pages on mine, and if you're absent for a few days it's easy to miss a {rfd,rfv} template addition. If you're absent for a longer period, it's impossible to spot it since it won't show up in the list at all. On Wikipedia, which has much lower article-per-user ratio, the person proposing the deletion always notifies the article creator. This should be trivially automatable, opt-out, and low-traffic. --Ivan Štambuk (talk) 12:45, 5 June 2013 (UTC)Reply
Watchlist WT:RFD then. Why have a centralised deletion request page if we’re not going to take advantage of the fact it is centralised? All this will do is discourage people from RFDing stuff because they will have to examine a ton of diffs to find out who added and who changed a definition. — Ungoliant (Falai) 13:17, 5 June 2013 (UTC)Reply
Ivan, perhaps your watchlist is useless because you have 55 000 pages on it! Mine has about 50 on it! Mglovesfun (talk) 17:53, 5 June 2013 (UTC)Reply
Or perhaps the reason why you don't have at least 10 times as much pages in your watchlist is due to the fact that watchlist is too primitive and useless in the first place - there is no way to subscribe only to language-specific, section-specific (e.g. only etymologies), type-specific (e.g. only unpatrolled) or content-specific (e.g. those that satisfy certain regex or a user-provided conditional) edits. Which is in turn just another argument that the whole watchlist mechanism is broken and no substitute for a talkpage message informing the user of the ongoing Rf{D,V} discussion... --Ivan Štambuk (talk) 18:40, 5 June 2013 (UTC)Reply
Ungoliant highlights the problem with what otherwise seems like a good (and automatable) idea: if the definition one wishes to RFV or RFD wasn't recently added, it may be quite hard to dig through the page's entire history to learn when it was added, and having a bot update everyone who ever edited the page would be overkill. However, I could support notifying the creators of brand new pages when their pages were RFDed/RFVed, especially if that notification could be automated. (If we could automate the addition of the entry to WT:RFV/WT:RFD, so no more entries were 'tagged but not listed', that'd be swell, too.) - -sche (discuss) 18:26, 5 June 2013 (UTC)Reply
Only active editors (e.g. in the last year or so) should be notified. Unless the editor simultaneously completely rewrote several definition lines, it should be relatively straightforward to reconstruct each of the definition's edit history simply through diffs and a fuzzy match. However, it appears that most of the entries/definitions that become tagged usually have few edits and distinct editors. A simplification could be made that only the last and the previous editor of the tagged definition are notified, indicating a potentially controversial change worthy of a wider discussion. Additionally, editors could be notified manually in case a bot somehow mismatches them. --Ivan Štambuk (talk) 18:57, 5 June 2013 (UTC)Reply
I really have no intention of participating in RfD/RfV discussions other than in those affecting entries I'm contributing to, or have a particular interest in. The article WT:RFD itself is subject to the same problem I've outlined above - once the watchlist grows significantly large, it becomes inconvenient to keep track of many entries at once. All of the modifications to the WT:RFD page (both new listings and discussions of existing proposals) will either get drowned among other edits, and those appearing chronologically before the threshold determined by the whatever obscure algorithms MediaWiki utilizes to cap watchlist's length to a few hundred items will not show up at all.
Listing the entry/meaning for verification/deletion should be a prioritized notification that a user is unambiguously informed of. Unless or until it is solved by means of automated technical assistance of the aforementioned notification gadget active on Wikipedia, or some other similar device, the least that can be done to pay due respect the editors that have spend time creating the entry is to inform them by leaving a message on their talkpage. --Ivan Štambuk (talk) 18:37, 5 June 2013 (UTC)Reply
I want to make clear that watchlists do not and technically can not serve this function. If you loathe the idea of being nagged, then we can implement customization as per DCDuring.   — C M B J   08:28, 6 June 2013 (UTC)Reply
That should be easy and I can think of at least two solutions right away.   — C M B J   08:28, 6 June 2013 (UTC)Reply
A few thoughts:
  1. I came across a link to this discussion from the bottom of a BP discussion on another topic. If you (proposer) want this to be noticed generally, create a BP section linking to this discussion.
  2. The proposal above… isn't one, really. It proposes "that talk page notification be mandatory for all imminent and executed deletions" without indicating what talk pages it refers to. The entry's? Its creator's? Its editors'? (All? All non-bot? All non-minor? All that add a sense?) On another note, what about deletion (removal) of a ==section==? of a sense? That said,
  3. IMO, w:WP:NOTYOURS applies here: that someone contributed an entry/sense/non-ns:0 page doesn't mean he needs to be informed of its deletion. (If he, especially, uses it — e.g. if it's an {{rfd}}ed template a user is known to use — then sure, he should be informed. But creation of a page doesn't afford that right IMO.) However, I think an exception should be made, and an entry/sense/page creator informed of impending or speedy deletion, if the nomination or deletion is soon after creation (say, within a week) and if one can AGF. This, so he's not left wondering what happened to his entry or whether it's worthwhile editing here (or it) again. I've used {{asdfg}} for this, myself.
​—msh210 (talk) 07:03, 16 June 2013 (UTC)Reply
"Be mandatory" doesn't say who should do it, either. As long as I don't have to do any notifying I don't really give a toss if someone else does it. Mglovesfun (talk) 21:25, 31 July 2013 (UTC)Reply

fuortrinbultsje edit

Discussion moved to WT:RFV.

Arguments to avoid edit

This page should probably include arguments to avoid. Here are three really bad ones that I think need to be codified as things to avoid:

  1. Other stuff exists arguments: Arguments that say that keeping this would mean creating other entries, and deleting this would mean deleting other entries. No, it wouldn't! RfDs are generally done individually or in very small groups, and the outcome of one usually doesn't preordain the outcome of another. This is because the laundry lists that are trotted out as arguments are usually completely unrelated to the entry at RfD.
  2. "Keeping this would mean a lot of work." First off, it wouldn't, because RfDs are distinct; something being kept doesn't mean changes at another page. Secondly, RfDs are decided on policy, not on the amount of work it means.
  3. Derogatory statements at the article creator or participants in the RfD. A meta policy is to comment on content, not on contributors

Purplebackpack89 (Notes Taken) (Locker) 19:56, 30 May 2014 (UTC)Reply

Thus spake the master of RFD arguing. — Ungoliant (falai) 00:22, 1 January 2015 (UTC)Reply
The current intro is "The following are guidelines on what to delete and what not to. It covers both speedy deletion and deletion by consensus." So no they should go on a separate page. Renard Migrant (talk) 00:23, 1 January 2015 (UTC)Reply

Tag: removal-of-deletion-or-rfv-template edit

Haha I replaced <nowiki>{{rfd}}</nowiki> with {{temp|rfd}} and that set off the filter. Renard Migrant (talk) 00:19, 1 January 2015 (UTC)Reply

Return to the project page "Page deletion guidelines".