Jump to content

Wikipedia talk:Redirects for discussion/Archive 12

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 5←Archive 10Archive 11Archive 12Archive 13Archive 14Archive 15

Maintenance bot

Would it help to have a bot that would automatically evaluate each discussion for WP:RFD#HARMFUL (notify of significant edit history whether by count or by bytes added, previous moves from that page, etc.)? I know it would save me a few clicks, and hopefully the same for everyone else who peruses these discussions. czar 04:55, 4 March 2017 (UTC)

What about Wikipedia:Bot requests? Someone may replace DUMBBot with another bot. Thoughts? --George Ho (talk) 01:10, 5 March 2017 (UTC)
Also see #"Current list" section. — JJMC89 (T·C) 02:28, 5 March 2017 (UTC)
It wouldn't hurt to have a bot give us useful information. If Czar or a bot-owner wants to do it, please go ahead! The "current list" discussion above isn't a problem anymore, because recent changes to {{rfd top}} has already prevented the problem of too many recursive transclusions onto Wikipedia:Redirects for discussion. Nevertheless, I think it's good practice for the bot to subst any template that it may use to present the automatically generated information. Deryck C. 00:21, 7 March 2017 (UTC)

DELETE 10 vs. R with possibilities

Is there a guideline written elsewhere that defines more specifically what "virtually no information" means in WP:RFD#DELETE item 10? That is, how much information does the target article need to have to justify the existence of a redirect with possibilities? Is a brief mention of the relation between the redirect title and target topic enough? (How brief?)

Should {{R with possibilities}} itself be clarified in any way? --SoledadKabocha (talk) 18:14, 8 March 2017 (UTC)

I think the only answer anyone can give is "it depends". Compare for example Bishop-elect and Ocean biomass. Currently I think both have at least an acceptable amount of information for a redirect even though that is vastly different. Thryduulf (talk) 00:35, 9 March 2017 (UTC)

RFD template for soft redirect

Is there a way to modify {{Rfd}} so that it skips the error message for soft redirects? I'm imagining adding a parameter that can be manually added to a page so that it skips the error message. Nyttend (talk) 18:51, 10 March 2017 (UTC)

I think that's the right thing to do. Deryck C. 21:36, 12 March 2017 (UTC)

Need a shortcut template for WP:RFDGO

I have created a redirect WP:RFDGO to enable people like myself to get straight to the current discussions. I would like to add a {{shortcut}} to it so people will know about it but I'm not sure how to do that. Siuenti (talk) 22:27, 18 March 2017 (UTC)

This page takes too long to load

Whenever loading this page, my browser (Microsoft Edge) would spend a few seconds longer to load this page. Because this page is so long, can lists for WP:RfD be put in a subpage? UpsandDowns1234 17:08, 20 March 2017 (UTC)

We've had discussions before about subpaging individual RfDs (like how AfD & MfD work) but there's been no consensus to date. But each individual day is on a subpage (i.e. Wikipedia:Redirects for discussion/Log/2017 March 20). Does that help you at all? Ivanvector (Talk/Edits) 17:32, 20 March 2017 (UTC)
@Ivanvector No, it does not help. Maybe have as many redirects as needed to prevent long loading. Either only today's redirects for discussion are shown and there are links to the rest or there is a link to load the page as plain HTML. — Preceding unsigned comment added by UpsandDowns1234 (talk • contribs) 00:52, 22 March 2017 (UTC)
One possibility would be to transclude the most recent 5 or 7 days on the main page, and have a prominent link to older days with open discussions transcluded to Wikipedia:Redirects for discussion/Older (or some better title). A Wikipedia:Redirects for discussion/All page transcluding all days with open discussions would maintain the current setup for those who prefer that and don't experience (and/or mind) issues about slowness. Some additional bot jobs would be required: When adding a new day's page, add it at /all as well (trivial to implement I expect); remove the 6th/8th day from the main list and transclude it at /Older when adding a new day's page (probably very easy to implement); if a page is untranscluded from /all or from /older, untranscluded it from the other (I guess not too difficult, but I don't really know. It would probably need some logic about when to do it to minimise edit conflicts à la signbot). There would need to be a note on /Older that it might be empty at times and bots would need to work with this. Thryduulf (talk) 01:47, 22 March 2017 (UTC)

New closure script

I'm in the process of adding support for RfD to my XFDcloser script (which already works with AfD, CfD, FfD, & TfD). I would be interested in any feature requests, questions, or other comments you may have, so I can make the script as useful as possible. - Evad37 [talk] 02:29, 9 March 2017 (UTC)

Note the new closure syntax "{{subst:rfd top|<result>}} <additional text> ~~~~". If possible:
  • It should give the option to add one or more redirect categorisation templates to a redirect that is kept or retargetted, whether or not tagging was explicitly part of the result.
  • Add the {{old rfd}} template to the talk pages of redirects that are not deleted (sometimes this involves unredirecting them)
  • List the Wikiprojects that the talk page of the target is tagged by and add those not unchecked to the top of the talk page of the redirect with class=redirect and no importance= parameter (see this edit for what I mean). Thryduulf (talk) 08:46, 9 March 2017 (UTC)

@Evad37: You're amazing! Thanks for offering to do a new RfD script. I've made User:Deryck Chan/closerfd.js a few months ago, whose functionality is appropriate for current RfD procedures so it might be a point of reference for you. One new functionality that I'd like to have is a relister script that uses the API to edit both days' log pages - a discussion is copied from one day's log page to another day's log page when relisted. Deryck C. 12:03, 9 March 2017 (UTC)

Thanks Thryduulf and Deryck...
  • Rcats: Should be possible... I'm thinking that for each nominated page, the existing rcats wikitext should be presented in a textbox popup for editing, so that it will also be possible to remove rcats. Or should "retarget" results remove all previous rcats, and require closers to explicitly specify all rcats that are wanted?
  • Add {{old rfd}} to talk pages: Yes, can do in general. I'm not so sure what should happen in cases where talkspace redirects are nominated though (e.g [1])? Also, re "sometimes this involves unredirecting them", can you clarify the sometimes? Would it be possible to detect when by script, or should there just be an option for closers to tick/untick?
  • Wikiprojects: working out which templates are wikiroject banners can be a bit tricky... but I can probably do it by finding all templates present in the top section, and filtering out common non-project template (e.g. those listed at WP:TPL).
  • Relists: The script already does relists for FfD and TfD like that so should be no problem to do the same here. - Evad37 [talk] 14:12, 9 March 2017 (UTC)
  • Rcats: I think something like a dropdown list of (common?) Rcats with checkboxes filled for those that are already present that if unchecked will be removed and if check will be left/added would be ideal. If not all of them are listed then an easy way to add a different one manually should be present. I don't know how possible any of this is though.
  • talk space redirects are uncommon, and what's best will differ in each case, so probably best to throw a prompt "talk page redirect. Add {{oldrfd}}?" defaulting to no is probably best.
  • project banners: most (all?) should be in Category:WikiProject banner templates, and everything inside a {{WikiProject Banner Shell}} template is guaranteed to be a WikiProject Banner.
    Thinking more, a pop-up asking which ones to add (with the default being yes to all those on the target) and a way to add others easily would be ideal, if not just copy them all and the sorting can be done manually (e.g. List of ports in England redirects to List of ports in England and Wales. The target is tagged for both the England and Wales projects but the redirect isn't relevant to the Wales project). Some project banners have multiple other parameters, e.g. for task forces, these should be copied unless they contain "importance", "review", or "needs" or are two characters in the form "A#", "B#" or "C#" (where # is a number), in which case they should be left out.
    Put banner templates inside a {{WikiProject Banner Shell}} if there are two or three banners and the target page uses it, or if there are four or more banners. If using a banner shell and the target uses the "collapsed=yes" parameter then this script should do so to, otherwise don't.
    If retargetting then should check any existing templates are still relevant. Banner templates should go at the top of the page. Order isn't massively important, but if you want to set one then alphabetical by project name.
  • oldrfd: If there are no other old XfD templates then this template should be the last thing before the first section of the page, or the first non-template content if that is before the first header.
    If there are one or more existing old XfD templates, in which case this should go after the last one of them, regardless of where they appear.
  • oldrfd (dates): The date parameter should be the date of the first timestamp in the discussion, this will be different to the page date if it has been relisted.
    The date format doesn't really matter unless there are existing old XfD templates, in which case it should use the same date format regardless of what that is. I default to d month year (9 March 2017) only because I'm British. If the target has a preference set for dates (e.g. {{Use dmy dates}}) then you might want to respect that if there is no existing template to copy, but it's no big deal if you don't.
  • Relists: we use a slightly different format to other XfDs, we leave the section header (and ideally any different <span id="..."></span>) and below that use {{subst:rfd-relisted|<nomination header name>}} and move the entire discussion (including header and spans) to the current date and add the {{relisted}} template (substituted) at the bottom.
Sorry to give you so much more to think about! Thryduulf (talk) 15:04, 9 March 2017 (UTC)

@Thryduulf and Deryck Chan: Basic support for Rfd is now available. Closing the discussion section and relisting can be done by script, but edits/actions to actually implement the close need to be done manually for the moment (still working on providing full support, including much of what's discussed above). - Evad37 [talk] 03:31, 15 March 2017 (UTC)

  • Just a side note: I'm not sure I see the point of project-tagging redirects. I have almost never seen that done, it's not needed for the article alerts (they're triggered by the project tags on the target) and the only use I can imagine is for the case when the redirect is subsequently turned into an article, but then the old tags might or might not be relevant and new tagging is nevertheless done by the new page patrol. – Uanfala (talk) 05:00, 15 March 2017 (UTC)
The choice to project-tag redirects at the discretion of the individual projects czar 05:24, 15 March 2017 (UTC)
On the other hand, tagging redirects isn't actually harmful, and as Czar alludes to, Wikiprojects get to decide for themselves what they do or don't want tagged per WP:PROJSCOPE. In any case, such discussion is probably better suited to WT:COUNCIL or village pump. - Evad37 [talk] 09:32, 15 March 2017 (UTC)
I agree with Uanfala that the RfD closer script shouldn't have built-in WikiProject tagging functionality for the redirect talk page. Deryck C. 12:04, 15 March 2017 (UTC)
I'll go along with whatever the consensus is. - Evad37 [talk] 03:48, 16 March 2017 (UTC)

@Evad37: Your new script is great. I've got two comments about its current functionality:

  1. When relisting, previous practice is that the entire discussion is stripped from the old log page and pasted onto the new log page. XFDCloser seems to leave the nomination in place but move the discussion.
  2. When closing from Wikipedia:Redirects for discussion rather than the daily log page, I recommend that the script should jump to the daily log page after saving, where the "Closure: keep / retarget / delete" buttons work. Deryck C. 13:59, 16 March 2017 (UTC)
1: The latest update should have fixed this, see User talk:Evad37/XFDcloser.js/Archive 1#RfD_relisting. 2: The plan is for the script to do those actions itself. - Evad37 [talk] 02:01, 17 March 2017 (UTC)
Automated implementation of RFD closes is now available. This includes removing nomination template (for keep closes), deleting pages and their talkpages (for delete closes), retargeting/soft redirecting (for those closes), and adding {{Old RfD}} to talkpages. If the talkpage is itself a redirect, the script will prompt for whether to overwrite it with {{Old RfD}} or skip it. Rcats can be specified for retarget closes: there is a box in the form to input Rcats (with full wikimarkup required); the script will put these in an {{rcat shell}}. At this stage, any existing rcats will not be kept (unless you type them into the form input). Having some way for all or some of the existing rcats to be retained is something I intend to work on, but the multiple possible Rcat formats – loose templates, or within {{This is a redirect}} (or one of its shortcuts), or within {{Redirect category shell}} (or one of its shortcuts) – makes it somewhat challenging. - Evad37 [talk] 03:47, 23 March 2017 (UTC)

Improvements to new discussion closure template

Orange box

@Deryck Chan: I just saw your code in action for the nomination of Wikipedia:FaoPFC. It almost looks like you utilized the code from {{Rfd relisted}} for the templates' appearance on Wikipedia:Redirects for discussion. However, since the codes look alike, I think it makes it difficult for those viewing that page to differentiate between relisted discussions and closed discussions at first glance. I wonder if it's possible to return the <div class> tags and formatting without breaking any recent improvements. Steel1943 (talk) 17:01, 21 February 2017 (UTC)

@Steel1943: I thought about this lack of contrast too. How about we replace the yellow arrow with a green arrow or a blue arrow ? Restoring the bright orange box is also possible, but takes more work, and a bright rectangular box signifies "click to uncollapse" which isn't the behaviour of the new template. Deryck C. 17:09, 21 February 2017 (UTC)
@Deryck Chan: Changing an icon is not what I mean. I mean something more like ... this. See Wikipedia:Redirects for discussion#Wikipedia:FaoPFC for reference. Steel1943 (talk) 17:33, 21 February 2017 (UTC)
(edit conflict) (So yeah, returning the box.) Steel1943 (talk) 17:48, 21 February 2017 (UTC)
@Steel1943: This would be fairly easy to do, though personally I prefer diversifying the look of the message and the icon without using a collapse box that doesn't locally expand, such as Thryduulf's proposal below. Deryck C. 18:05, 21 February 2017 (UTC)
@Deryck Chan: Right. As my diff shows, there is no expand option. I just encapsulated your code in divs. Steel1943 (talk) 19:03, 21 February 2017 (UTC)
@Steel1943: I've just noticed that it's exactly the same box as the discussion closure box... I've added the orange box to some of the testcases on User:Deryck Chan/sandbox. Actually the code can be simpler if it's the same orange box. Deryck C. 11:20, 23 February 2017 (UTC)
@Deryck Chan: Exactly. Same code, but it looks slightly different since it isn't slightly darkened by the additional code used by the collapse option. Steel1943 (talk) 17:52, 23 February 2017 (UTC)
@Deryck Chan: Any possibility to reinstate the orange boxes around the closed discussions? Steel1943 (talk) 21:57, 5 March 2017 (UTC)

Icon dependent on keyword detection

I agree about the lack of distinction with the arrow. I'm not keen on replacing it with something that looks the same. I haven't the foggiest if it would be easy to code or not, but something like the coloured boxes used at m:Steward requests/Permissions based on the outcome (perhaps "delete", "delete all" or "speedy delete" = red, "keep", "speedy keep" or "keep all" = green, "retarget", "speedy retarget" or "retarget all" = blue, anything else = yellow?) would be good. I think the square block would indicate that the discussion is closed with better contrast to the round arrow used to indicate a relisting. Thryduulf (talk) 17:44, 21 February 2017 (UTC)

@Thryduulf: This is possible with some digging, as I'm yet unfamiliar with Lua search strings. Essentially we can set up the Lua function to detect keywords in the template parameter. Let's say "keep" , "delete" , "retarget" or "disambiguate" , multiple matches or no keyword detected or (choose grey to be different from yellow?). How does that sound? Deryck C. 18:05, 21 February 2017 (UTC)
I'm not keen on ticks for deletion, maybe or , (but bluer) for retarget, (again bluer) for disambiguate (or dismabig) results. I think I prefer purple for multiple (maybe something with a tick and a cross?) and a black or grey solid box for none. Thryduulf (talk) 20:39, 21 February 2017 (UTC)
Let's say: for keep, but red for delete, (how much bluer? give me a colour code / example) for retarget, for disambiguate? I'd also suggest or or (but in purple or grey) for multiple matches and/or no matches. Deryck C. 22:56, 21 February 2017 (UTC)
For keep, either or the stronger green (008000). For delete I've created which uses cc0000 for the colour. For retarget I've uplaoded which uses 0033CC for the blue. I've uploaded (using CC00FF) for mulitple matches. For no matches, either or (808080). Thryduulf (talk) 14:18, 22 February 2017 (UTC)
Actually, thinking more about it I don't mind using for both multiple and no matches. Thryduulf (talk) 14:55, 22 February 2017 (UTC)
For disambiguation I've created two possibilities, (the original suggestion using the 0033CC blue) and (one arrow becoming two, again using 0033CC), of which I prefer the latter. Thryduulf (talk) 14:52, 22 February 2017 (UTC)
@Thryduulf and Steel1943: Please see test at User:Deryck Chan/sandbox, which transcludes User:Deryck Chan/sandbox3, which in turn invokes a modified script that's ready to be deployed. May I also be greedy and suggest a three-pronged arrow for "disambiguate"? Deryck C. 22:43, 22 February 2017 (UTC)
@Deryck Chan: That looks good, three-pronged version of the disambiguation icon: . Thryduulf (talk) 23:11, 22 February 2017 (UTC)
I wouldn't mind seeing how it looks with Steel1943's boxes though. Thryduulf (talk) 23:45, 22 February 2017 (UTC)
Done, see User:Deryck Chan/sandbox for a comparison. Deryck C. 11:20, 23 February 2017 (UTC)
I generally prefer the boxed version, and definitely would if the icon were vertically centred within the box. Thryduulf (talk) 01:01, 24 February 2017 (UTC)

Should we try to detect more keywords: "no consensus", "not " (spacebar important, for "not delete", "not keep" but not "hatnote"), "procedural"? These should probably go to the category alongside no result, but a bespoke result string that triggers no keywords should probably go to the "bespoke result" icon? Deryck C. 11:23, 23 February 2017 (UTC)

  • "No consensus" should possibly be a category of it's own - maybe a hyphen or an equals and not a strong colour? I don't have time to do icons for them now but will take suggestions for later. "not keep" should not be recognised as "keep" (etc) but I'm not sure if they should be purple or grey atm. "... and (add a) hatnote" should be the same category as "...". I'll comment on the boxes later Thryduulf (talk) 13:55, 23 February 2017 (UTC)
    • The counterargument would be that "no consensus" isn't an "outcome" in RfD because the actual outcome would be "default to keep" (or sometimes "default to delete") which falls into one of the previous categories. In a way, I think that grey should be a "category of no outcomes", whereas everything that doesn't neatly fall into a category should go to the purple "bespoke outcome". Deryck C. 16:12, 23 February 2017 (UTC)
      • The result is "no consensus", which I think is important to distinguish from other results. I think they should either be grey or white - . If you want to know if it defaulted to anything other than keep then you can read the discussion. Thryduulf (talk) 01:01, 24 February 2017 (UTC)
  • "Withdrawn" should also be recognised, probably using the same icon as keep. Thryduulf (talk) 11:45, 2 March 2017 (UTC)
  • At the least, I'd suggest one symbol for closed and one symbol for relisted. Those two things need differentiated even more than others. — Godsy (TALKCONT) 07:44, 5 March 2017 (UTC)

Hi everyone. I had been busy IRL for the last 10 days or so. I apologise for going silent on this matter. I've tested and installed a new version of {{subst:rfd top}} and {{subst:rfd bottom}} which wraps everything in an orange box (even in include/abridged mode) and has keyword-aware icons. You can see the logic of keyword detection in function match_result of Module:RfD close. Further suggestions welcome. Deryck C. 16:46, 6 March 2017 (UTC)

Pings to people who have helped develop this template: User:Thryduulf, User:Godsy, User:Steel1943, User:EurekaLott. Deryck C. 16:46, 6 March 2017 (UTC)
Thank you for your work on this Deryck. It could do with something for a "withdrawn" result though. Thryduulf (talk) 19:30, 6 March 2017 (UTC)
@Deryck Chan: Something is going wrong though! I've just looked at WP:RFD and all the closed discussions are shown with no box and the icon used for relisting, regardless of the result. Thryduulf (talk) 19:42, 6 March 2017 (UTC)
@Thryduulf: Were the discussions you refer to closed prior to Deryck C. making the changes? If so, I'm assuming that the boxes will only be used on discussions closed after the changes to the templates referenced above were made? Steel1943 (talk) 19:46, 6 March 2017 (UTC)
@Thryduulf: In fact, see Wikipedia:Redirects for discussion#Tau Booetis Ab. This nomination is closed with the box visible. Steel1943 (talk) 19:55, 6 March 2017 (UTC)
Indeed, but Wikipedia:Redirects for discussion#Morpheus (disambigaution) immediately below is showing the icon for a closed discussion which is exactly wrong. Thryduulf (talk) 20:23, 6 March 2017 (UTC)
Discussions closed before this change are not affected. The discussion you reference was closed on 21 February, long before this change. -- Tavix (talk) 20:37, 6 March 2017 (UTC)
However it wasn't showing that icon a couple of days ago (when I last looked). I suspect this means that the error is in choosing an icon when it doesn't get the input it expects. Thryduulf (talk) 21:01, 6 March 2017 (UTC)
@Thryduulf, Tavix, and Steel1943: Tavix is correct. One of the two purposes of all this template overhaul is to recursively subst everything to reduce server burden when the main Wikipedia:Redirects for discussion is loaded. So any changes to {{subst:rfd top}} will only affect discussion closures made after the change. Thryduulf: The discussion may have been missing an icon a few days ago because the page didn't load properly when you tried it back then. Deryck C. 00:05, 7 March 2017 (UTC)

I've added "withdraw" = "keep" to the logic. Also the template shouldn't display in any circumstances since 8 hours ago. If you see any new instances of discussion closures with the yellow arrow, give me a diff and I'll see what happened. It shouldn't Deryck C. 00:33, 7 March 2017 (UTC)

Keywords

I'm wondering if "redirect" and "Wiktionary" should be recognised as keywords that produces the same icon as "retarget" ()? I noticed as Wikipedia:Redirects for discussion/Log/2017 February 24#Nose to the grindstone was closed with the result "Wiktionary redirect" and gets a grey box on the main RfD page. When I close discussions with the same result I usually bold it as "soft redirect to Wiktionary" or "Retarget", and I've seen other people bold "soft redirect" or "retarget to Wiktionary". Those with the word "retarget" in will get the blue arrow, those without will currently get the grey square but I think they should get both. A complicating factor is that "soft redirect" can also be used to mean changing a hard redirect to a soft redirect (common for redirects out of userspace and to the special namespace), usually but not exclusively to the same title. I don't have a problem using the blue icon for both cases, even though keeping the same title but converting hard to soft is closer to keeping than retargetting. Thryduulf (talk) 14:10, 7 March 2017 (UTC)

"Refine" should be treated as a synonym for "Keep", generating the icon. Sometimes these are closed as "Keep and refine" othertimes just "Refine" but I think the icon should be the same for both. Thryduulf (talk) 14:10, 7 March 2017 (UTC)

I've added "refine" to the "keep" set, and "soft redirect" to the "retarget" set. I think we should avoid using "redirect" as a keyword as everything here is a "redirect". Your example makes me get my act together and split "bespoke decision" (the closer provided a result that didn't trip off any keywords) to purple icon, different from "no result provided".
I've also implemented "no consensus" for cases where it hasn't already tripped off a more specific keyword ("keep A, delete B, no consensus on C" should go to "bespoke/multiple decision", not "no consensus"; "no consensus, default to keep" is okay to be classified as "keep" because I can't think of a watertight logic to separate this from "no consensus on A, keep B"); it uses a separate bit of logic from "no outcome provided" so that you can implement an equal sign icon for "no consensus" when you get around to it. Deryck C. 00:25, 8 March 2017 (UTC)
Two options for a no-consensus equals sign: and . Other colours are available on request. Thryduulf (talk) 10:55, 8 March 2017 (UTC)
I went ahead, made a #808080 grey version of your equal sign, and installed it. Deryck C. 12:47, 8 March 2017 (UTC)

I've also created commons:Category:Rounded square discussion closure SVG icons to curate this set of icons. Deryck C. 21:55, 8 March 2017 (UTC)

A couple more small issues:

  • I closed Wikipedia:Redirects for discussion/Log/2017 March 4#Alive (story) as "Retarget to Alive (a disambiguation page)". This is showing on the RfD page with the purple multiple keywords icon rather than the blue retarget icon. In this case I don't know whether it's possible to correctly filter this (and it's not a significant issue if it isn't) but it's worth checking that a closure of "Retarget to Foo (disambiguation)" or "Retarget to Disambiguation" would be interpreted as retarget not multiple.
  • Wikipedia:Redirects for discussion/Log/2017 March 9#Acne was closed as "wrong forum". This is showing as the purple i for multiple/unknown keywords, but this is not a result so I think it best to have this go to either a separate icon (white square or white equals perhaps) or the grey square. "Moot" should probably be part of this set if a more specific keyword is not triggered first.
  • "Converted to a disambiguation page" will presumably trip the disambig set, but "article" (e.g. "converted to an article", "now an article") should probably be recognised as something, but what? Thryduulf (talk) 13:52, 13 March 2017 (UTC)
  • "No consensus to delete" should fit the "no consensus" set not the "delete" set, similarly "no consensus to keep". Thryduulf (talk) 16:22, 30 March 2017 (UTC)

"Click here"

A small request: can we change the wording for the collapsed link, since "click here" is discouraged for usability reasons? Perhaps something like Closed discussion; see [[insert link here|full discussion]]. might work better. - Eureka Lott 21:15, 21 February 2017 (UTC)

 Done. [2] --Deryck C. 22:47, 21 February 2017 (UTC)

Just as an FYI, Wikipedia users on RFD need to remember that there are multiple romanization systems for Japanese. While the Hepburn romanization is the most familiar, one may encounter spellings like "Mount Huzi" (for Mount Fuji) and "Zyunitiro Koizumi" (for Junichiro Koizumi). Those are spellings under the Kunrei-shiki romanization system, which is technically the Japanese government's standard romanization (but is not used that much in practice). Some Japanese people use Kunrei or a combination of Kunrei and Hepburn when typing names, and therefore it's useful to have Kunrei redirects. If possible Japan-related RFDs should be tagged so editors are reminded of the spelling variations possible. Nihon-shiki is like Kunrei except some "z" characters are written with "d".

With Mandarin you have Hanyu Pinyin, Tongyong Pinyin, Wade-Giles, and many other systems. WhisperToMe (talk) 17:41, 6 April 2017 (UTC)

Thorough scanning on Wikipedia:Redirects for discussion/Log

I thought about re-creating more deleted redirects as disambiguation pages as I have done, but the thorough scanning would be very time consuming. I wonder whether another volunteer would help out and re-create pages then. --George Ho (talk) 18:38, 12 April 2017 (UTC)

Why?!? Deleted redirects are deleted because there's consensus to do so. If there's consensus to disambiguate, that'd come about via the discussion. -- Tavix (talk) 18:53, 12 April 2017 (UTC)
I didn't create all actually. I created some as dabpages, like How You Been and Marou, making them exempt from WP:G4. I left the rest still deleted as there aren't any articles using the unlikely terms. I stopped at the end of October 2009 logs. --George Ho (talk) 19:04, 12 April 2017 (UTC)
Oh, I see what you're saying now. -- Tavix (talk) 19:41, 12 April 2017 (UTC)
Thanks, I forgive you. ;) George Ho (talk) 19:46, 12 April 2017 (UTC)

Barack obama

Resolved

Given that redirects such as barack obama are "clearly useful", would you support getting a bot to make them all automatically instead of them being created manually, as proposed in a recent discussion? Siuenti (씨유엔티) 02:49, 7 April 2017 (UTC)

I would not be opposed to that. There are shorthand forms of U.S. city names which would make great redirects and I'd like a bot to do that too WhisperToMe (talk) 06:27, 8 April 2017 (UTC)
OK you have said "Keep - A plausible error someone could make if he/she is typing the URL directly into the address bar". I don't think this is a currently a very plausible error. If you type URLs to change the article you will very quickly realize that it's better to capitalize properly, because a large proportion of these things don't have redirects. It's not worth the risk of getting a bad result to saving the effort of typing a capital letter. If a bot went and made redirects for all of them, the lazy capitalization way would then become the quickest way and a certain number of would avoid the trouble of typing capital letters. Siuenti (씨유엔티) 07:22, 8 April 2017 (UTC)
Editing the URL — does anyone really do that? Why? It's really annoying; you need fine motor control to highlight just the part you want to change (or else you have to use the backspace or delete keys a lot); you have to remember to use an underscore for a space; you have to get it exactly right. On the other hand, in the search box, you don't need to blank out anything; you can use spaces for spaces; it does completion for you. Seems to me like the search box wins every time. --Trovatore (talk) 07:26, 8 April 2017 (UTC)
Trovatore, I use the URL bar, not the search engine, simply out of habit. Specifically it comes in handy if I wish to edit a particular redirect, or I wish to check if a particular spelling/diacritic set (related to romanization of Japanese, Chinese, Arabic, and other languages) redirects or not. If I don't see a redirect from that combo, I make a redirect to cover the gap.
Admittedly I think the habit is there because I first edited Wikipedia in 2003, at a time when the search function wasn't so great.
WhisperToMe (talk) 22:33, 12 April 2017 (UTC)
I can get to the url by typing two letters, I don't know what to type to get to the search box. Siuenti (씨유엔티) 07:37, 8 April 2017 (UTC)
And I don't have to use underscore. Siuenti (씨유엔티) 07:40, 8 April 2017 (UTC)

Anyway I think I can just dev this problem out of existence. Siuenti (씨유엔티) 09:06, 8 April 2017 (UTC)

Thank you. I really appreciate it WhisperToMe (talk) 22:34, 12 April 2017 (UTC)

Relisting multiple-redirect discussions

What's the consensus on leaving pagelinks behind, when relisting discussions that involve multiple redirects? Leaving the pagelinks behind can reduce confusion (e.g. for anyone coming to the listing from the template on one of the nominated redirects). However, if there's a large number of redirects, or they are substantially the same (e.g. slight difference in punctuation, spelling, plural/singular form), it might not be desirable to leave the pagelinks behind, and there may be little or no benefit from doing so. Note that the WP:template limits for the main RfD page aren't affected if the pagelinks are put inside <noinclude>...</noinclude> tags, like this: [3].

This was originally requested by Thryduulf in § New closure script above, and has also been discussed on my script's talk page here and here. In terms of the script, the options I can implement are:

  • Leave pagelinks behind for all multi-redirect discussions (current setting)
  • Don't leave pagelinks behind for any discussion
  • Add a checkbox that can be ticked or unticked, so people can choose when to leave pagelinks behind

So what do yo all think? Pinging @Thryduulf, Deryck Chan, Uanfala, Czar, Tavix, and BDD: - Evad37 [talk] 03:38, 4 April 2017 (UTC)

  • I would prefer not to leave any, but I'm not sure I can articulate a better case besides "we've always done things that way". I could get used to something different, and generally try not to quibble too much with the fantastic editors who make our lives easier with templates. But if it's my call, I'd rather not leave the links behind. --BDD (talk) 03:47, 4 April 2017 (UTC)
I feel the exact same way! -- Tavix (talk) 18:13, 4 April 2017 (UTC)
  • I'm not sure I understand the question correctly, so not all of this necessarily relevant but I think it is important that a link be provided from the original nomination page to the page where it has been relisted as I routinely link direct to the log page when advising wikiprojects of relevant discussions, however this just requires there to be a section header on the original page with one link to the relisted discussion. There doesn't need to be any links to the redirects themselves from the original page. If the nomination concerns multiple redirects, each redirect gets an anchor link on the log page, and it would be useful if these are retained, however they do not need to be associated with any additional off-page links. Very time consuming for doing manually, but I guess not for a script, would be to just have a plain text list of the other nominated redirects, either associated with anchors or (if this is problematic) nothing. The latter will at least allow people to find the name of the redirect they are interested in on the page. Something perhaps like:
    ===<span id="Bar"></span><span id="Baz"></span>Foo===
    *Nominated redirects: Foo | Bar | Baz
    {{rfd-relisted|Foo}}
    I haven't a clue how easy this would be to do though, or what anyone else thinks of the idea. Thryduulf (talk) 11:54, 4 April 2017 (UTC)
  • I would support an anchor being left behind (e.g. {{anchor|Foo|Bar|Baz}}), but not something visible. This would aid those following links left from {{subst:RFDNote}}, a notice which is generally served to the creator of a redirect. Otherwise, the section header description is enough.— Godsy (TALKCONT) 13:17, 4 April 2017 (UTC)

After some days with no further comments, it seems that the script should leave non visible anchors behind, but there's not consensus for anything more. Does it particularly matter if the anchors are placed on the line after the heading (which would be easier), rather than within the heading? - Evad37 [talk] 00:40, 10 April 2017 (UTC)

@Evad37: Actually, I'm not sure there is consensus for non-visible anchors, it may or may not be uncontroversial if included in the script. The standard procedure for relisting discussions at redirects for discussion is outlined at Template:Rfd relisted which does not include leaving anchors behind. — Godsy (TALKCONT) 15:18, 10 April 2017 (UTC)
@BDD and Tavix: How do you feel about non-visible anchors? - Evad37 [talk] 01:56, 11 April 2017 (UTC)
I'm indifferent. I don't mind one way or the other. -- Tavix (talk) 02:00, 11 April 2017 (UTC)
Sounds like a good idea to me czar 04:05, 11 April 2017 (UTC)
I think so too. --BDD (talk) 13:51, 11 April 2017 (UTC)

@Evad37: Sorry for the late response - I'm travelling this month and haven't had time to respond to Wikipedia discussions. Initially I insisted that the closer script strip all redirect listings from the original log page because of two reasons to do with the main log page:

  1. Minimize the amount of content loaded on the main log-page to improve load-time
  2. Prevent clashes of HTML page anchors the main log-page

So I think it's crucial that any anchors or redirect listings must be dumped inside noinclude tags once the discussion is relisted. But I see much value in keeping an anchor on the original day-log page so that incoming link anchors (e.g. from user talk notices) continue to work. I think something like <noinclude>{{anchor|Foo|Bar|baz}}</noinclude> sounds like a good plan. Deryck C. 16:11, 14 April 2017 (UTC)

Here's an example diff from the latest version of the script: [4]. It's easier, and functionally equivalent, to keep the existing <span id="Foo"></span> anchors rather than to make new anchors using the template. - Evad37 [talk] 00:38, 16 April 2017 (UTC)

woohoo, some less

User:Champion/Eubot list 12 is now red! Si Trew (talk) 23:39, 20 April 2017 (UTC)

Relevant ANI thread

I have just had cause to start Wikipedia:Administrators' Noticeboard/Incidents#SiTrew at RfD regarding user:SimonTrew's conduct at RfD. Anyone with relevant opinions on the matter (regardless of what those opinions are) is invited to contribute there (please do not reply here). Thryduulf (talk) 10:54, 26 April 2017 (UTC)

The current status of this process

Besides the loading issue, there may be some other issues. The process is full of nominated redirect pages. Some nominations receive more attention than most others, which have very little amount of participants present, most of them regulars (no offense). Maybe it's to do with enthusiasm (or lack of it) toward redirects, including cheap ones. If not, why have there been very little participants? --George Ho (talk) 15:35, 30 April 2017 (UTC)

The simple fact is that most people simply don't care enough about redirects to make RfD anywhere near as busy as most other deletion processes. The flooding will also have put some people off I suspect, as it can be intimidating. I don't comment on every nomination, as sometimes I don't have a strong opinion either way or nothing useful to say. If I come to a redirect where there are two or three people commenting in favour of what I would recommend and no opposition to that then I don't bother commenting as it's not worth spending the time. I suspect other people are the same. Thryduulf (talk) 17:37, 30 April 2017 (UTC)
Recently, Thryduulf, the PROD has extended to files. Therefore, the WP:FFD has been cleaned up, and the backlogging has been tremendous reduced (a bit). If extending PROD to redirects is unnecessary, how else do we deal with this situation? I'm unsure whether another criterion for redirect is unnecessary, given that the WT:CSD explains how messy and complicated the CSD is. --George Ho (talk) 17:49, 30 April 2017 (UTC)
PROD only works with pages that are sufficiently visible that people can discover they have been nominated, which is not the case with redirects. Before proposing a new CSD criterion you rightly need to demonstrate that meets four key points - Objective, Uncontestable, Frequent, Nonredundant - and I'm not sure there is any group of redirects that appear here frequently, always get deleted (and never retargetted or disambiguated) and which are not already speedy deletable by an existing criterion. The Eubot ones are the only ones appearing with any real frequency, and only a small percentage are being nominated and only a fraction of those that are are deleted without being contested (and still some of them were subjective) so that clearly isn't suitable for a new criterion. I think we should wait to see what happens going forward without the flood of eubot nominations before making any radical changes, as I'm not convinced that, in most cases, more than 2-3 opinions on a redirect are necessary - especially when they are in agreement with the nominator. Thryduulf (talk) 18:45, 30 April 2017 (UTC)

Redirects to daily log pages

At User talk:Evad37/XFDcloser.js/Archive 1#Links in RfD closure edit summaries I have expressed a desire to include section links in the edit summaries. However, length is an issue. One way around this would be to create redirects to the daily log pages, e.g. WP:RFD/20170502 → Wikipedia:Redirects for discussion/Log/2017 May 2 (the bot that creates the daily log pages could presumably easily create these at the same time). Is this a good idea? Are there alternatives? Thryduulf (talk) 13:41, 2 May 2017 (UTC)

Notice of Request for comment

FYI

I have started a formal Request for comment that may affect Wikipedia:Redirects for discussion. It is at Wikipedia talk:Deletion process#RfC on holding RfCs within XfDs. --Redrose64 🌹 (talk) 22:53, 29 May 2017 (UTC)

Request to relist a discussion

Hello. I'd like to request that my nomination at 'Murica be relisted. I don't see a consensus and I hope we can reach a consensus for it soon. jd22292 (Jalen D. Folf) (talk) 23:53, 4 August 2017 (UTC)

Already done by Steel1943. jd22292 (Jalen D. Folf) (talk) 23:59, 6 August 2017 (UTC)

A proposal to automatically delete certain types of cross-namespace redirects

You're welcome to comment on the proposal at Wikipedia:Village pump (proposals)#Automatic R2, which amounts to automatically tagging for speedy deletion {{R from move}}s to certain namespaces. – Uanfala 22:02, 28 August 2017 (UTC)

RFD and NPP

Nominated redirects get picked up as "new articles" that need reviewing. There's really no need for that. I've just seen Bearcat placing such redirects individually in Category:Temporary maintenance holdings. Does this exempt them from registering as new articles? If it does, then maybe this category should automatically be placed by {{rfd}}. Any thoughts? – Uanfala 09:43, 14 October 2017 (UTC)

Well, this appears to have already been done [5]. I guess I'd misunderstood what problem is solved by this category: it's nominated redirects getting treated as uncategorised new articles. This appears to be a new thing. But is there any way to take them off the WP:NPP queue? – Uanfala 09:56, 14 October 2017 (UTC)
Yeah, I did that batch run because 200+ RFD-nominated redirects were showing up as uncategorized new articles in the categorization queue. But that's also a thing that never happened before, but suddenly started at pretty much the same time you noticed them showing up at NPP. And you're right, these things really shouldn't be happening at all — but they most likely both have the same root cause. Nyttend adding the temp crapcatcher category directly to the template should resolve the "uncategorized" problem, but I don't think it would do anything to fix the NPP clutter — has there been some kind of change recently to the RFD template that's causing these strange new things to happen, and is there any way to fix them? Bearcat (talk) 14:16, 14 October 2017 (UTC)
RfD nominated redirects have presumably been showing up in NPP for a while: my experience has been that most of the time I nominate a redirect, I will soon see in my watchlist an entry in the page curation log that this redirect has been marked as reviewed. It has been like that for months if not more. – Uanfala 15:08, 14 October 2017 (UTC)

Tagging for bulk RfDs

If someone nominates a large number of redirects (more than 10, let's say), are they still expected to tag each one for deletion and to notify each one's creation? Or may they simply list the redirects here? I see nothing in the guidelines suggesting that the tagging rule and notification norm do not apply in the case of bulk deletions, but I've seen two recent cases where someone didn't tag the redirects and it went unremarked-upon. — PinkAmpers&(Je vous invite à me parler) 02:19, 21 January 2018 (UTC)

Of course they have to. I guess an exception can be made if they're only bringing up the redirects for an informal discussion without the expectation that deletion might result, but even then it makes sense to tag and notify: after all, the creator and users of a redirect, naturally, are in a good position to provide meaningful input. – Uanfala (talk) 02:50, 21 January 2018 (UTC)

Proposition to move table of contents to the top of the page

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
I am going to place {{TOC limit|3}} on Wikipedia:Redirects for discussion/Header as mentioned below as it seems rather uncontroversial. I will also change the "Neutrality of redirects" header from a level 4 header to a level 3 header. Steel1943 (talk) 18:44, 1 February 2018 (UTC)

After dealing with the table of contents on this page being so low on the page for a few years, I think it is time for change. To put the table of contents above the first header on the page, the page Wikipedia:Redirects for discussion/Header will have to be edited by placing a __TOC__ immediately before the first section header on that page. However, doing so will result in a long table of contents listing each individual RfD nomination being listed in the table of contents as well; this can be averted by using {{TOC limit|3}} instead of __TOC__. Using {{TOC limit|3}} will only leave the daily headers displayed in the table of contents on Wikipedia:Redirects for discussion while hiding the headers for the individual nomination sections. (This will also hide the "Neutrality of redirects" section from the table of contents; this can be avoided by changing the header for that section from a "level 4" header to a "level 3" header.) Since the individual days' nomination pages themselves will still have a table of contents displaying the day's nominations if either __TOC__ or {{TOC limit|3}} is used on Wikipedia:Redirects for discussion/Header, my preference is to use {{TOC limit|3}}. We can keep what we got, use __TOC__, or use {{TOC limit|3}}. Any thoughts on this? Steel1943 (talk) 16:59, 31 January 2018 (UTC)

(@BDD, Tavix, Uanfala, Ivanvector, Deryck Chan, Killiondude, and Zxcvbnm: Pinging some editors and administrators who have been active at RfD recently.) Steel1943 (talk) 17:04, 31 January 2018 (UTC)
(Also, pinging AngusWOOF and CoffeeWithMarkets while trying to figure out how I overlooked/forgot them.) Steel1943 (talk) 18:42, 31 January 2018 (UTC)
  • Yeah, that makes sense to me. We don't need the ToC to list every single redirect being discussed, just the log pages that are open. I also agree to move the "neutrality of redirects" section up a level. It has been used to both keep and delete redirects, so it doesn't need to be "under" either section. -- Tavix (talk) 17:12, 31 January 2018 (UTC)
  • Seems sensible to me. A table of contents should precede the contents, and needn't be exhaustive. Ivanvector (Talk/Edits) 18:49, 31 January 2018 (UTC)
  • It makes sense to have the ToC higher up the page. However, I do find the inclusion in it of individual discussions helpful: it's mostly this overall table of contents that I use to browse RfD nominations and decide if there's anything I can comment on – that's easier than cycling through the individual logs or scrolling through the discussions themselves. Still, I do understand that such level of detail might be seen as excessive, so if it's removed I wouldn't object. – Uanfala (talk) 20:09, 31 January 2018 (UTC)
  • Your preferred direction seems good to me. I also dislike the current TOC location. The accompanying changes seem appropriate. Killiondude (talk) 20:57, 31 January 2018 (UTC)
  • ...Turns out that the ToC was moved where it is currently by Deryck Chan, and I didn't realize it until now. (diff) Per the edit summary in the diff, it makes sense, but I guess after a year and a half of it being this way, I suppose this thought to change it back (and shrink the ToC) came up in my head. (I'm not sure why I thought it had been that way for longer than that.) Steel1943 (talk) 22:10, 31 January 2018 (UTC)
  • Support TOC limit 3 towards top of page. TOC Thanks for pinging me back to this discussion. (I have taken a back seat in RfD since last autumn because the backlog shortened down and spent more time on Wikidata and Cantonese Wikipedia instead.) Back then I didn't really consider limiting the TOC to date-level only, so I thought a TOC that listed the title of every discussion would be best placed below all the top-matter immediately above the first live discussion. I stand by that comment and would oppose moving the TOC further up if it continues to take the same level of detail. However, if we do limit the TOC to date-level, it will indeed fit more happily towards the top of the page, and I would support such a change. Deryck C. 14:49, 1 February 2018 (UTC)
  • Oh God Yes Outside of ANI, RfD is possibly the most unappealing page to come to. ~ Amory (u • t • c) 15:35, 1 February 2018 (UTC)
The above discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

Fancruft alert: The Wheel of Time

I came across a bad, FANCRUFT-y redirect to The Wheel of Time (Fictional creatures: seanchan), only to find that there seem to be a lot of them. This is half a note to myself, half to some of the other sleuths of such redirects around here, to investigate further. --BDD (talk) 20:53, 23 February 2018 (UTC)

Monster Reborn

Think that redirect should be deleted, but unfortunately, it is protected so that only admins can edit it. My rationale is that the redirect refers to just one Yu-Gi-Oh! card that is not mentioned anywhere in the target article and is not a franchise trademark like the "Blue-Eyes White Dragon," "Dark Magician," and "Exodia." Even though it was used quite a lot in the anime and considered a must-have for anyone playing the card game, people will not likely search for individual cards here, they would do it on a Yu-Gi-Oh! wiki, the franchise's official website, places that sell cards, etc. If an admin can start a discussion on the redirect, it would be appreciated. 69.118.34.204 (talk) 00:58, 2 March 2018 (UTC)

 Done, see Wikipedia:Redirects for discussion/Log/2018 March 6#Monster Reborn. -- Tavix (talk) 16:21, 6 March 2018 (UTC)

COM:OVERWRITE

I came across this soft redirect COM:OVERWRITE to a Commons project page, in article space (it doesn’t work but the page does exist on Commons). It seems an odd thing to have in Wikipedia article space to me but I’m not well up on soft redirects to other projects. Is this a valid redirect? Thanks, --Malcolmxl5 (talk) 14:54, 6 March 2018 (UTC)

I fixed the link, but I'm not sure if we want to support the COM pseudo-namespace on Wikipedia. There's only one other page that uses it. You might want to nominate them for discussion and see what the consensus is. - Eureka Lott 15:25, 6 March 2018 (UTC)
@EurekaLott: COM:FR exists because of the reason given at Talk:COM:FR#Reasons for this soft redirect. Unless COM:OVERWRITE exists for the same reason, I'd suggest nominating it separately if desired due to the different circumstances surrounding each of the redirects. — Godsy (TALKCONT) 00:50, 13 March 2018 (UTC)
(edit conflict)I'm not opposed to them in theory (and they are certainly valid in some cases, this doesn't seem worth it to me. It was just created and has no incoming links (well, one from half a decade ago). I'd be curious to hear from Illegitimate Barrister as to why they created it, but personally I'd be in favor of sending it to RfD/R3. Link is now fixed (credit to Eureka Lott, who I've now conflicted with twice). ~ Amory (u • t • c) 15:26, 6 March 2018 (UTC)

Shortcuts

The shortcuts "WP:RFD#DELETE" and "WP:RFD#KEEP" on this page don't work for me, they just go to the redirect WP:RFD. I can't work out how to fix it because of the transclusions, but at Wikipedia:Redirect/Deletion reasons the shortcut shows up without the hashtag as "WP:RDELETE" but doesn't work either, stopping at the redirect Wikipedia:RDELETE. If this could be fixed – or, better, improved by a shortcut to each serial – this might encourage commenters on RFD to cite the documented deletion reasons. Shhhnotsoloud (talk) 12:22, 20 March 2018 (UTC)

  • I haven't attracted any help with this yet. I intend therefore to try and fix it myself, and give each reason to delete an individual shortcut WP:RFDDn, and reason to keep WP:RFDKn, in the manner of WP:A1. Any suggestions or comments? Shhhnotsoloud (talk) 05:34, 9 April 2018 (UTC)
    • Why do you think so many shortcuts are helpful?
    • Shortcuts involving the # character probably rarely work because most browsers interpret the # character as a marker to then search the page for the text that follows. WP:RFD#DELETE will tell your browser to take you to WP:RFD, the. Search for DELETE. —SmokeyJoe (talk) 07:54, 9 April 2018 (UTC)
@SmokeyJoe: Can you help me out here please. I don't really understand the transclusion mechanism and the use of #switch in the source code and I don't want to break it. I just want the redirects to work, which involves taking the "#" character out of the following shortcuts at WP:RFD: WP:RFD#HARMFUL, WP:RFD#DELETE, and WP:RFD#KEEP. The page WP:RFD seems to be constructed in such a way as to baffle regular editors! Shhhnotsoloud (talk) 07:39, 22 April 2018 (UTC)
Transclusion? There is no transclusion. Do not create redirects without a good reason. Most new shortcuts are just more jargon that increases the barrier for newcomers to understand what people are saying. —SmokeyJoe (talk) 07:48, 22 April 2018 (UTC)
@SmokeyJoe: Let's forget about any new shortcuts and just fix the ones that don't work. At Wikipedia:Redirects for discussion there are shortcuts listed (WP:RFD#HARMFUL, WP:RFD#DELETE, and WP:RFD#KEEP) which don't work. When I click Edit Source on that page there's nothing to edit. If I click Edit source on the Section "When should we delete a redirect?" there's nothing there either except "{{Wikipedia:Redirect/Deletion reasons}}" (which is a transclusion, yes?). When I go to Wikipedia:Redirect/Deletion reasons the shortcuts are listed in a different form (respectively WP:RHARMFUL, WP:RDELETE and WP:RDEL, WP:RKEEP and WP:RK). When I edit that page, the shortcuts are wrapped in a #switch command I don't understand. Shhhnotsoloud (talk) 09:35, 22 April 2018 (UTC)
Depending on the page a different shortcut is shown (seems unecessary..). Anyhow, the shortcuts do work - just the link in the shortcut box doesn't, because it is supposed to show the redirect. Click WP:RFD#DELETE here - does work. There are individual shortcuts too, in the form of WP:RFD#D1 Galobtter (pingó mió) 09:42, 22 April 2018 (UTC)
For technical reasons, The following characters cannot be used should never be used in titles (this includes shortcuts): # < > [ ] | { } _. The fact that the # sometimes functions as expected doesn’t change this. Shortcuts should not use the # character. A url can not include the # character. —SmokeyJoe (talk) 10:35, 22 April 2018 (UTC)
@Galobtter: Yes, it works from this Talk page but the shortcut on the WP:RFD page doesn't, and the individual redirects like WP:RFD#D1 aren't advertised and so might as well not be there. Now that we've established that # shouldn't be used, could you please help to actually fix the problem (which I can't for the reasons stated above)? Shhhnotsoloud (talk) 12:42, 22 April 2018 (UTC)
Well that is the way it is supposed to be - it isn't broken. The shortcut is only "broken" in the case when it is in the shortcut box - works fine everywhere else. Using # is fine personally. Galobtter (pingó mió) 12:59, 22 April 2018 (UTC)
A single '#' in URL#Syntax is valid and specifies an anchor on the page given before '#'. It doesn't make a search but relies on code for the anchor placed somewhere in the html of the page. MediaWiki automatically places anchors at section headings so section links like Wikipedia:Redirects for discussion#Reasons for deleting work. Additional anchors can be placed by editors. I'm not aware of any rule against using anchors in shortcuts. The shortcuts WP:RFD#DELETE, WP:RFD#KEEP, WP:RFD#HARMFUL all work fine when written as wikilinks. In the shortcut boxes on Wikipedia:Redirects for discussion they are not wikilinks but url's with redirect=no, e.g. https://wiki.riteme.site/w/index.php?title=Wikipedia:RFD&redirect=no#DELETE. They are transcluded from subpages like Wikipedia:Redirect/Deletion reasons where they are made with {{shortcut}}. At Template talk:Shortcut#Direct link it was decided that the box made by {{shortcut}} should link directly to redirects without following them to the target page. It was implemented in [6]. Summary: There is nothing wrong here and nothing to fix. If you want the box made by {{shortcut}} to make links which follow redirects then you can post a new suggestion at Template talk:Shortcut. PrimeHunter (talk) 13:27, 22 April 2018 (UTC)
Many thanks to the editors who have helped me understand why the thing that looks broken isn't broken! Shhhnotsoloud (talk) 11:36, 23 April 2018 (UTC)

Enter cryptozoologists

Some of you may notice an increase in traffic on this article with the introduction of a number of cryptozoology-related articles here. You may notice some of these users making aggressively pro-cryptozoology comments or complaining about Wikipedia's coverage of pseudoscience or policies like WP:UNDUE. For a little background, you'll probably find this thread of interest, and I recommend also reading this. :bloodofox: (talk) 23:43, 6 May 2018 (UTC)

For those confused by this, this appears to be in reference to a number of nominations at Wikipedia:Redirects for discussion/Log/2018 May 4. ~ Amory (u • t • c) 00:54, 7 May 2018 (UTC)

Dealing with old moves and page move vandalism

I just noticed the RFD for "Actor (mythology) will not speak out class" due to an addition to the deleted articles with freaky titles page by Raymond1922A, but I don't think any of the participants in the discussion realised that it was just a remnant of old page move vandalism. I'm also pinging the users who participated in the RFD: @Iazyges, LaundryPizza03, P Aculeius, CoffeeWithMarkets, and Ivanvector:

The page move of the redirect (which occurred in May 2005) was not logged in the modern way because the move log was created when MediaWiki was upgraded to version 1.5 in June 2005 – indeed, the first move log entries date from this time. By doing a search for wikipedia:"will not speak out class", I found this similar RFD in 2007, which led me to discover that Meelar had also dealt with this page move vandalism. Looking at their contributions at the time, I figured out that Nauseam (talk · contribs) was the vandal – which is obvious from their user page! I also speedy-deleted some other similar redirects I discovered along the way. A Google search for "will not speak out class" is rather depressing.

P.s. sorry about the double-pings: I had to repost this message *twice* because I mistyped some of them. Graham87 09:40, 8 May 2018 (UTC)

Those google results are astounding, couldn't think of a better example. Also worth noting that you can't see any evidence in the history of Actor (mythology). A good reminder that (very) old redirects should be weighed accordingly. ~ Amory (u • t • c) 10:18, 8 May 2018 (UTC)
Good to know about the move log, thanks. It seems this has all been dealt with, but will keep an eye out. As for external sites mass-harvesting Wikipedia content and republishing it for their own commercial gain, well, I don't feel bad that some of what they get is vandalism. Ivanvector (Talk/Edits) 12:20, 8 May 2018 (UTC)
Why did people at the time think it was made by User:Boothy443? Anyway, glad I helped solve this vandalism "cold case." Raymond1922 (talk) 23:40, 8 May 2018 (UTC)
@Raymond1922A: Because he moved it back to the proper title to undo the page move vandalism. Graham87 06:22, 9 May 2018 (UTC)

Redirects from software + version to software

A user currently creates a large amount of redirects for individual software versions of OpenOffice.org and StarOffice, e.g. OpenOffice.org 2.4 → OpenOffice.org. Are those redirects generally wanted? --Count Count (talk) 17:42, 31 May 2018 (UTC)

In probably most cases they're going to be harmless at worst and beneficial at best, particularly if there is content about that version at the target. If the software version doesn't exist and isn't confirmed as a future version, or if they're inaccurate in some (implausible) way then bring them for discussion. Thryduulf (talk) 23:23, 31 May 2018 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Wikipedia_talk:Redirects_for_discussion/Archive_12&oldid=865044543"