Wikipedia talk:Redirects for discussion/Archive 11

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

Redirects that should be synchronised

There are many sets of redirects that should always point to the same target, for example Parliament of Belgium, Belgian parliament and Belgian Parliament, so if one is updated all of them should be. To assist with this I propose a template, drafted at User:Thryduulf/Synchronise redirect (please someone with more template skills than me improve this!), which informs editors of which other redirects need to be updated if they are changing the target of this one. e.g.

This could additionally be fed to a bot that checks all the listed redirects do point to the same target and either keeps them up to date (e.g. if 1 has been retargeted, retarget the others; logging the action somewhere for human review) or posts them at RfD for human investigation and action. I do not have the skills though to write or operate a bot though so someone else would need to take on the task.

This would be entirely opt-in, so if it was decided that two redirects should not be synchronised (any more) then the template would just be removed from the redirect. There could to be a one-off project to tag many redirects initially, but this is not essential and I think it would be possible to get bot assistance with this (e.g. if two redirects that differ only in capitalisation point to the same target then tag both of them).

Pinging some RfD regulars and those that commented on a recent case: @SimonTrew, BrownHairedGirl, Champion, DeryckC, Tavix, Lenticel, WhisperToMe, and CoffeeWithMarkets: Thryduulf (talk) 11:38, 12 December 2016 (UTC)

Fixing ping to @Deryck Chan:. Thryduulf (talk) 11:38, 12 December 2016 (UTC)
People who were pinged above as regulars but I overlooked pinging (sorry): @BDD, Godsy, Patar knight, Ivanvector, Gorthian, Steel1943, AngusWOOF, and Uanfala:. Thryduulf (talk) 11:41, 12 December 2016 (UTC)
(responding to ping) Cheers, I probably would have seen this anyway. Looks like a good idea, I am a bit concerned about clutter though. Although readers don't usually "see" redirects anyway. Will evaluate better a bit later on when I'm not late for work :) Ivanvector (Talk/Edits) 11:56, 12 December 2016 (UTC)
Sounds like a good idea. @Paine Ellsworth: may have some idea about how to implement. older ≠ wiser 12:16, 12 December 2016 (UTC)
  • Great idea, in principle. I'm not sure how it could be implemented, but if it can be done, it would be a very useful thing. --BrownHairedGirl (talk) • (contribs) 12:28, 12 December 2016 (UTC)
  • Agreed, looks useful. I would suggest that anything tagged with {{R avoided double redirect}} already has such a relationship with its defined parameter, so similar to how {{R to anchor}} says to use {{R to section}} instead if applicable, {{R avoided double redirect}} should take precedence over this one. Although I suppose if the redirect in the parameter became its own article, we'd still want to define the relationship between the redirects that get retargeted there. I suppose I'm thinking out loud here... --BDD (talk) 14:19, 12 December 2016 (UTC)
  • I also agree that this is a great idea in principle. -- Notecardforfree (talk) 16:07, 12 December 2016 (UTC)
  • This looks like a net positive; it could cut down a little on the RfD nominations. — Gorthian (talk) 17:12, 12 December 2016 (UTC)
  • Sounds like a good idea, but I thinks cases need to be discussed before the template is used, okay, not for all. - CHAMPION (talk) (contributions) (logs) 20:31, 12 December 2016 (UTC)
    • @Champion: I don't understand your point here. This would only be used on sets of redirects that currently point to the same target, and should continue to point to the same target if it is changed. Obviously there would need to be discussion about which redirects (if any) this can be applied to by bot, but I don't see a need to discuss every case beforehand - e.g. I can see no reason why Belgian Parliament and Belgian parliament should ever point to different places. Thryduulf (talk) 22:02, 12 December 2016 (UTC)
      • @Thryduulf: I'm thinking of the situation of similarly named redirects that point to different targets. Also, I think that semi-protection for those redirects is something to be considered. - CHAMPION (talk) (contributions) (logs) 23:24, 12 December 2016 (UTC)
        • @Champion: Redirects that do and should point to different targets are completely outside the scope of this proposal. This proposal is only about redirects, whether similarly named or not, that should always point to the same target (regardless of what that target is or should be). Protection of any sort is also completely independent of this proposal so your comments seem completely irrelevant. Thryduulf (talk) 23:46, 12 December 2016 (UTC)
  • I agree with BrownHairedGirl that this is a good idea in principle, so I'd like to know more about it. Yes, there is the very useful {{R avoided double redirect}}, as raised by BDD, which actually recategorizes redirects if a "main" redirect is converted into an article. There are page movers and bots that take care of double redirects in follow-ups to page moves. One job a template like this might be truly helpful with would be the growing problem with unsynchronized talk page redirects if it also lists those along with subject page redirects. Wbm1058 and I have been trying to deal with that for some months now, and that editor knows more about bots than I will ever learn.  Paine Ellsworth  u/c 20:58, 12 December 2016 (UTC)
  • Y'all are aware of Wikipedia:Double redirects? Wikipedia:Requested moves/Closing instructions#Cleaning up after the move advises page movers to fix double redirects, but I think some get lazy about this because they know that bots will clean up after them. The template shouldn't be a substitute for checking "what links here" – that's always complete and up-to-date. Some pages have dozens of redirects to them. What's the specific issue that prompted this discussion? Problems occur when redirect targets are changed: i.e. x used to redirect to y but now it redirects to z. What do you do with the other redirects to y? The bots won't take care of this, since nothing was moved. This is an issue when WP:primary topics are changed, or a title which previously had a specific target becomes ambiguous. – wbm1058 (talk) 21:16, 12 December 2016 (UTC)
  • You may also be interested in: Inconsistent similar redirects
  • @Wbm1058 and Paine Ellsworth: the main use case for these templates is not page moves, where whatlinkshere is/should be used and double redirects created, but situations where a redirect is retargeted independently, for example if someone retargets Belgian parliament to National Congress of Belgium this template would alert them that they should also retarget Belgian Parliament and Parliament of Belgium. Different capitalisation redirects are fairly obvious, but there are many other sets where it wont be (e.g. different languages). Thryduulf (talk) 22:02, 12 December 2016 (UTC)
    • Thryduulf, The Belgian redirects have been stable since 2004... 12 years, so I don't see the point with that particular example. There are a lot like that, and seems like a lot of work to add templates on the chance that, for the first time in 12+ years, one of them might be retargeted. On the other hand, if we could patrol recent changes, to watch all redirects that have recently changed. I think a bot could do that. I haven't written a bot that did that kind of thing yet, though one that looked for recent links to misspellings is something that crossed my mind. I may be able to write a bot that does such stuff, given enough time to do it. wbm1058 (talk) 22:20, 12 December 2016 (UTC)
      • The Belgian redirects are just examples of redirects that should always be pointing at the same place, not examples of redirects that have been treated incorrectly in the past. There are two, independent, possible jobs for bots:
        1. Add this template to sets of redirects.
        2. Monitor redirects with this template and when a set gets unsynchronised synchronise it and/or report it.
      Bots are not essential to this process at all though, as it can always be done by humans - and even if task 1 is done by a bot, then there will always be instances that are clear to humans but not easily definable in advance. Thryduulf (talk) 22:39, 12 December 2016 (UTC)
      Human's time would probably most productively be spent working Inconsistent similar redirects for those so inclined. I've worked this before, but it hasn't been a high priority so I seldom get to it.
      Maybe we could just have a default edit notice on all redirects advising that if you change the target, please check "what links here" to the old target to check for others that should be changed too.
      I'm not against using this template on pages that you believe to be high risk for inconsistent retargeting, but I'm not sure how you would identify such pages in advance, unless they have a history of frequent retargeting. wbm1058 (talk) 23:18, 12 December 2016 (UTC)
    • Thank you, Thryduulf, for clarifying this for me. Is there any way to assess how big a challenge this is, presently? i.e., how many of this type of unsynchronized redirect are there that need fixing? Also, is there a guideline to cite (or that needs to be updated with this) that will inform editors as to what to do in these cases? (that will maybe help keep this from happening in the future)  Paine Ellsworth  u/c 10:29, 13 December 2016 (UTC)
  • Re clutter: could the template go on the redirect's talk page? -- Tavix (talk) 22:42, 12 December 2016 (UTC)
    Redirect pages are usually pretty simple, and who is going to bother to open up the talk page to look for this? Often a redirect's talk page is a red link, and I'd rather not create a page just for a template like this. wbm1058 (talk) 23:18, 12 December 2016 (UTC)
    My thought would be if it's a bot that handles it, an editor wouldn't need to see it. I agree with your assessment though. I do think it'd be a bit clunky and I don't think it'd be an optimal solution to apply a template to thousands of redirects. I think a better solution would be a database report that lists redirects with small details that go to different places (eg: capitalization). It's reactive instead of proactive, but I do think it'd be a better use of time. -- Tavix (talk) 23:28, 12 December 2016 (UTC)
  • I think this is a good idea, but I'm apprehensive about a bot managing it, and how this will be applied to each redirect. An example for the first concern: if it becomes appropriate to change the target of one redirect within a synchronized set of redirects, the editor changing it may not be familiar with the system and thereby fail to remove it from the synchronization template, potentially resulting in the theoretical bot unduly retargeting the others or the one that was changed being reverted. I think that making it more of a human endeavor would be appropriate. For example, if one redirect within a set of synchronized redirects falls out of synchronization, they are put into a category for other contributors to review. In regard to the second concern: if one redirect is to be removed from the set, and this template is "physically" present on all of the redirects in the set, they would all have to be altered. This could be fixed by having a separate page for the synchronized set listing, then transcluding it to all of the applicable redirects, but that would not be very contributor friendly.— Godsy (TALKCONT) 00:00, 13 December 2016 (UTC)
  • Support looks good. Perhaps we should do a run with human editors first before running it via bot? --Lenticel (talk) 01:01, 13 December 2016 (UTC)
  • @Tavix, Paine Ellsworth, Godsy, and Wbm1058: I don't know how big a task this is, but the main aim is to prevent redirects becoming unsynchronised rather than fixing them afterwards. A think a report (I'm not sure a category would work alone, but it might) by a bot is a good thing, and may be better than a bot autofixing it.
    regarding editors unfamiliar with system, the intent is for the template to explain what to do, which should be 1 of 2 things: Change all the other redirects if you change this one, or start a discussion (probably at RfD) if you think that the set should be split.
    If a set of two is intentionally split then the template is just removed from both members. If one member (A) is removed from a larger set (ABC) then the template is removed from A and the templates on B and C are edited to remove mention of A. Thryduulf (talk) 11:24, 13 December 2016 (UTC)
  • Sounds like a good idea to me. I'm not too fussed whether this goes onto the redirect page or the redirect talk page. Deryck C. 12:08, 13 December 2016 (UTC)
  • I've thought about this and have a lot to say about it (unfortunately for you all), but have not had time to condense it (fortunately...). In the meantime I note that Wikipedia_talk:Naming_conventions_(use_English)/Archive_8#Use_of_diacritics_in_biographical_article_titles has an interesting discussion about the use of diacritics in particular, i.e. whether they are considered misspellings or just alternative spellings. (I don't think the arguments presented there are specific to bios.) Si Trew (talk) 00:03, 14 December 2016 (UTC)
    • @SimonTrew: Did you mean to post this here? What titles articles should have, doesn't seem relevant to synchronising redirects? Thryduulf (talk) 12:52, 14 December 2016 (UTC)
Only really meant as a courtesy acknowledgement for being pinged, not to add any particular points right now (,I want to spend time to make a coherent case, including when we should kill one of the siamese twins for the benefit of the other). Si Trew (talk) 19:21, 14 December 2016 (UTC)
The template wording above says that if you think this is incorrect, nominate the set of redirects at RfD. If you want to delete one of the redirects then nothing about this proposal stops you nominating it at RfD - it will just alert you to the fact that it is part of a set so you will likely want to either nominate the other member(s) too or mention them in your RfD rationale. Thryduulf (talk) 20:02, 14 December 2016 (UTC)
  • Support. Many RfDs are where targets point at different things (e.g. "Belgian Parliament" and "Parliament of Belgium") when they shouldn't. This would free up a bit of work. ---- Patar knight - chat/contributions 15:02, 21 December 2016 (UTC)
  • Dissent. All this does is put work up-front on categorising redirects that should be done at the time a redirect is retargeted or a page is moved. There's no need to do loads of pre-emptive work that is both optional (i.e. it won't get done) and unnecessary (i.e. most redirects don't get moved around). Editors should check incoming links when moving or retargeting things (or proposing thus), it's as simple as that. There's no need formally or informally to tie all the redirects together. A much better solution, in a large number of cases, is simply to delete a load of redundant redirects and stop the maintenance headache once for all. Less is more. Si Trew (talk) 05:28, 26 December 2016 (UTC)
And there's no point suggesting that a bot could do it. If a bot could do it there'd be no need for it; and we've seen in the past (and right now) what happens when you let bots make decisions about creating or categorizing large numbers of redirects. i.e. it sometimes makes the wrong decisions that have to be fixed anyway, and fixing them involves going through its entire history to find out which ones were bodges. Si Trew (talk) 05:31, 26 December 2016 (UTC)
  • Nobody has mentioned how the sets would be identified on the individual redirects. Let's think that through. Presumably we need some kind of name: which would also have to be maintained. If it was just the name of the target, that would defeat the whole point of being able to maintain them if the target were moved and so on; similarly, it can't be the name of any redirect in the set itself, in case it's excluded from the set; so we need some other arbitrary unique name, that would have to be managed. If people just chose names of sets at random there could be a clash in the names of two unrelated sets (and they may not be aware of this) so we'd need a central register of names, and we'd need to think about disambiguating them... er, hang on... that starts looking very much like what we do with page titles. In which case we might as well create a holding page (in some pseudo namespace or something) and just list all the related redirects on it: in which case we wouldn't need the proposed rcat because each R in a set would have a link from the holding page, as well as... err... all being linked to the same article already. So the holding page would essentially be a manually maintained doppelganger for the redirect-only results of the "what links here" for the article they target. Because it would be manually maintained it would go out of date, but we could have a bot to run through to find mismatches, as proposed above. But we wouldn't need the bot if we didn't have the pages but just found out what redirects linkted to a target somehow... we could use What Links Here! Have wheel, will reinvent. Si Trew (talk) 05:44, 26 December 2016 (UTC)
  • @Simon Trew: you're reading far, far, far too much into this proposal. All it involves is:
    1. A human deciding that a given set of redirects should always point to the same target
    2. A template being placed on all articles in that set that (a) identifies it as a member of a set, (b) lists other members of the set, and (c) encourages anyone retargetting one redirect in the set to retarget them all, or to discuss it at RfD if they think they should have different targets.
    3. Optionally, a bot being used to identify if members of set have become pointed to different targets.
    There is no need for naming of sets (all the members of a set are simply listed on each member of the set), holding pages, specifying of targets, new R cats, or anything like that. There is no requirement for anybody to do any work upfront as it will just naturally grow if people find it useful.
    If you want to nominate any member of a set for deletion then there is absolutely nothing at all stopping you - the only difference is that you will know of other similar redirects that you may wish to include and/or mention with your nomination. Thryduulf (talk) 18:34, 27 December 2016 (UTC)

Modification in policy for RfD

We are finding too many redirects with small verb change, as well as foreign language terms. The discussion on these obvious deletes (non-controversial ) takes significant time and effort. The technical way to address the issue is to enhance the Wikipedia Search Engine to throw suggestions for similar sounding words and different spellings rather than creating redirect pages for them. Will it be better if we stop allowing foreign language redirects, differently spelled redirects all together as part of policy itself ? Open for discussion/suggestions. Devopam (talk) 06:52, 16 December 2016 (UTC)

  • This would involve some sort of mass deletion, I would need specific details about how this could be handled before making a support or oppose decision, I don't know anything about the internals of the search engine, so I'm remaining neutral for the time being. - CHAMPION (talk) (contributions) (logs)

(ping)@Thryduulf, BDD, Tavix, SimonTrew, Godsy, Thryduulf, Deryck Chan, Patar knight, Ivanvector, Gorthian, Steel1943, Pppery, Lenticel, AngusWOOF, CoffeeWithMarkets, and Uanfala:. - CHAMPION (talk) (contributions) (logs) 09:37, 16 December 2016 (UTC)

  • (responding to ping) I also don't really understand the proposal, but it sounds like you are proposing a theoretical change to the search engine, and a preemptive deletion of content without knowing if the theoretical change is even possible, let alone if it is working. Besides, redirects serve more of a function than just supplementing the search engine. If by "stop allowing ... differently spelled redirects" you're suggesting that WP:ENGVAR redirection should be handled by the search engine, that's just a bad, bad, BAD idea. This proposal needs to be a lot more verbose on the details. Ivanvector (Talk/Edits) 11:51, 16 December 2016 (UTC)
  • (edit conflict) oppose. The internal search engine is only one of many ways people search and browse Wikipedia and so changing that (which is a non-trivial task for developers) will not help everybody. For example, there are links from articles and other internal pages, links from external sites (including other WMF wikis), bookmarks, direct URL entry, URL bar shortcuts, external search engines (many and varied), etc. In any case, being taken to the correct article directly is always preferable to having to go via search results (which can never be completely predicted).
    Additionally it is not possible to treat all foreign language and no-diacritic redirects the same, as many are valid alternative names or likely search terms for other reasons as well. Yes it takes a lot of time and effort, but unless you are talking about very specific groups of redirects (e.g. where a bot has substituted "oe" for "ö" in the names of places in Hungary) then there is no alternative to manually considering them and even in those specific groups there is always going to be the possibility of exceptions. Thryduulf (talk) 11:55, 16 December 2016 (UTC)
Oppose. This is just too vague: what are "too many redirects with small verb change, as well as foreign language terms"? How many is too many? Is "Encrypt urls" a "small verb change" from URL encryption? Why doesn't "decrypt" mean "to remove some body from a crypt"? Are we supposed to end up playing Uxbridge English Dictionary? Some points, loosely expressed:
  1. We should weigh Wikipedia's own searching above that of external sources. We can't be beholden to how things are written outside of Wikipedia. While going to the "correct" article is preferable to going via search results, we're often in the position of not knowing which is the "correct" article, and we must have a healthy disregard for WP:External link rot or we would find that we could never change anything (e.g. that a printed or online work had referenced a Wikipedia page without a permalink meant that we could never change that page and never delete it). While we mustn't needlessly break external links, we mustn't be beholden to themeither. As for external search engines, I believe that any popular ones will also take account of transliterations, and for English speakers tending to drop diacritical marks on foreign words (let alone naturalised words), so there is no need for Wikipedia to keep every possible transliteration of a foreign word.
  2. It is not the end of the world if someone ends up at the search engine. Readers seem to manage perfectly well with external search engines presenting them with a list of pages. The internal search engine has got a lot better since things like {{R from title without diacritics}}, {{R from incorrect capitalisation}} and so on where encouraged.
  3. Incorrectly-titled redirects encourage harmful WP:Accidental linking. Editors seeing that their link "works" are unlikely to check whether it is tagged as being an incorrect form. This might propogate beyond WP, i.e. "it must be right, it was on Wikipedia".
  4. I don't believe that the search engine (or another tool) would accurately identify "small verb change". To take a simple example of a regular verb such as "colour": are we going to reject "colours" as a "small verb change" (or is it a plural noun?) What about "coloured", is it a verb or an adjective or a noun? (Do we have coloureds? What about "color" vs. "colour", is there a difference between coloured people and colored people? Should there be?)
  5. In the specific case of R's from titles without diacritics, as Thryduulf has noted, this rather depends on having someone who has a working knowledge of the language (as indeed WP:RFFL states). The Hungarian ones coming up on RfD are largely because I have a knowledge of Hungarian (not a great one) and I have an interest in RfD; Chinese ones come up similarly from two or three other regulars; on the other hand a user who is not a reg at RfD kindly informed us that the Germanic umlaut for "oe" is quite acceptable in Swedish. But for the most part, a foreign-language redirect won't even come up at RfD unless someone who knows that language happens to spot it (and is in the mood to list it).
I do see, however, that although we can't have tools making these decisions, we could make WP:X1, the "temporary relaxation of RfD criteria", permanent of itself but get consensus to add and delete current criteria to a list of what powers it currently had, and argue for inclusion or deletion from that list. The inclusion bar would have to be set quite high, but would not be quite as high as arguing for a new CSD criterion on itself: i.e. the general principle would be "from time to time we find large numbers of redirects for which consensus is to perform a deletion: right now, here are the criteria that meet such consensus". e.g. for redirects containing "oe" in place of an "ö" at the target, it might be that they were created by a bot, had no history, had no links from article space, had hits below some very low threshhold, that the target had an existing redirect tagged as {{R from title without diacritics}}, that the target title is not in a Germanic language, and that the redirect's title is identical to the target's except for the substitution of "oe" for "ö" and the straight removal of all other diacritical marks. Having such a temporary criterion listed under this permanent X1 would allow redirects to go to WP:CSD without the need for WP:RFD, but essentially would come down to the CSD admin asking "do I trust the person CSDing this?", let alone that the criteria would have to have significant consensus and be sufficiently tight, which might make it just as difficult as to get consensus for a new CSD from scratch. Of course I myself am always trustworthy and competent, but everyone else is suspicious and foolhardy... it is unfair to put a CSD admin in the position of having to make a judgment on something they know nothing about, so the criteria have to be so tight that it is purely an administrative affair and not an executive decision to delete it. That was essentially the case with the Neelix redirects, where the responsibility was left at the nominating editor's and the closing admin was merely a second check.
I've thoughts on other criteria such as profusion of redirects simply on number (when a target has more than about ten redirects then often some of them are of marginal utility: members of the nobility seem particularly prone to having every possible permutation of their style enumerated). My general take is that of WP:COSTLY, and that redirects should not be a substitute for the search engine. But that's enough for now. Si Trew (talk) 05:29, 17 December 2016 (UTC)
  • Alternative software perspective here. I'm a regular Wikimania attendee and a Wikitech-Ambassador, which means I get regular updates about updates Wikimedia software changes. Devopam proposed that instead of creating redirects, the search engine should throw out inflections and auto-corrections. But the search engine needs an input dataset to work with! What is the synonym of this? What are the correct inflections of this? What are plausible typos of this? By curating redirects, RfD is curating the dataset that is needed for Devopam's idea to work. Devopam's idea is a good suggestion for the Discovery team (which unfortunately has had more than its fair share of controversy over the past 2 years) but I see mass-deleting redirects as counter-productive to this goal. Deryck C. 14:48, 17 December 2016 (UTC)
Good point, User:Deryck Chan. However, I think it would need to rely on R's being categorized better, and that is not something many people do. (Sometimes I think I am the only one.) With many "change of morphology" redirects it is hard to know how to categorise them, considering that in English there is no noun that cannot be verbed, and that things often fall into several categories (is it useful to categoriye them thus? If a redirect is has flattened out the diacritics on a foreign-language redirect that has diacrtical marks, but its target doesn't, is that a {{R from title without diacritics}} or not?) Until people are more strongly encouraged to categorise R's, the dataset is not very well curated in the first place. Si Trew (talk) 08:15, 25 December 2016 (UTC)
    • @SimonTrew: I agree that redirects will be most useful as a dataset if we categorize them properly. But as a start, even the very act of keeping some redirects and deleting others has created a set whereby we drew the fine line that decides if something is "close enough or not", which is in itself quite useful. Deryck C. 00:22, 28 December 2016 (UTC)
  • Oppose for now due to the technical issues involved. Maybe the best thing that we can do for now is to generate enough data for the techie guys to work with --Lenticel (talk) 00:43, 19 December 2016 (UTC)
    I support this in theory, but in practice, it would probably be too difficult to do. Perhaps we should get some input per the above poster. Gamebuster19901 (Talk | Contributions) 15:17, 19 December 2016 (UTC)
  • Oppose. Redirects that consist of minor variations in spelling facilitate navigation, and Deryck C.'s comments are important to consider as well. Best, -- Notecardforfree (talk) 16:40, 19 December 2016 (UTC)
  • Oppose per Deryck C. Until the tech is there, we shouldn't change how we do things. ---- Patar knight - chat/contributions 02:44, 21 December 2016 (UTC)
  • Oppose - until we have a tried and true alternative to these type of redirects, they are necessary, and may in fact be a stepping stone for that per Deryck Chan.— Godsy (TALKCONT) 17:16, 26 December 2016 (UTC)

RfC on empty log pages

Consensus for option 2, undelete previously deleted pages. Request logged at WP:AN requesting undeletion. Any help amending the page links when undeleted will be appreciated. Amortias (T)(C) 19:35, 2 January 2017 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Should we allow daily log pages with no nominations in them apart from those within 3 days from today? Here are 2 options:

With Option 1, the redlinks in the header on the preceding and following log pages will have to be fixed to point to the next or last, respectively, available non-empty log page instead. With Option 2, the links in the header on the preceding and following log pages will have to be fixed so that undeleted or created log pages will no longer be skipped. GeoffreyT2000 (talk, contribs) 01:12, 3 December 2016 (UTC)

  • Option 2. I see no problem with the arguments in favor of keeping the log from that MfD - specifically, I think an empty log still serves the valid purpose of showing that nothing happened on a given day. Enterprisey (talk!) 20:08, 3 December 2016 (UTC)
  • Option 2 per the consensus at that MFD, it just WP:SURPRISEs users if they see a date missing and they would wonder what happened in that date when in fact nothing did. - CHAMPION (talk) (contributions) (logs) 03:49, 4 December 2016 (UTC)
  • Option 1. I am cleanup-minded. Best regards, Codename Lisa (talk) 20:43, 8 December 2016 (UTC)
  • Option 2 per the Champion. I agree that future users may be confused if they come across a missing day in the log. -- Notecardforfree (talk) 19:48, 11 December 2016 (UTC)
  • Option 2 because of page navigation. I often use the navigation links from one day to the next or previous day, and it would be much easier to just have an empty day than a red link and having to fumble around to find the next blue link. However, I would suggest that a simple boilerplate message be added to the empty pages to say something like "Nothing to see here—move along" "No redirects were nominated for deletion on this date". That would make it clear that the empty page isn't just a mistake of some sort. — Gorthian (talk) 17:25, 12 December 2016 (UTC)
  • Option 2 per arguments at MfD regarding being clear about the continuing record, and semiautomated page navigation. Ivanvector (Talk/Edits) 17:58, 12 December 2016 (UTC)
  • Option 2  Empty pages are useful, and what is not useful is to hide the information that the page is empty.  The detail in the workmanship of the proposal is evident.  Unscintillating (talk) 01:55, 13 December 2016 (UTC)
  • Option 2 Per Gorthian Gamebuster19901 (Talk | Contributions) 15:22, 19 December 2016 (UTC)
  • Option 2 since Option 1 breaks the navigation bar at the top of each page. Steel1943 (talk) 21:58, 20 December 2016 (UTC)
  • Option 1. I'm actually surprised to be here, but I don't see any use for empty log pages, but I do see some use for the redlinks. To address Champion's concern: if someone sees a deleted log page a) the deleting admin usually notes "no redirects were nominated that day" (eg: Thryduulf's example from 2014 October 27) and b) I can't imagine someone assuming some admin conspiracy to delete a log page that is anything but empty. Second, to address Gorthian's page navigation concern, that day is simply skipped in the page navigation, the fumbling around to find the next blue link simply doesn't happen. As an example, check out the logs for 2014 October 26 and 2014 October 28. The "next" day has been corrected on the 26th to advance directly to the 28th (and vice versa). Recreating the empty logs would require an extra click to go from the 26th to the 27th to the 28th, and that's completely unnecessary. Finally, a redlink is better because it clearly shows which dates are empty in the archive. The log uses {{Daily archive log}} to produce the list, and AFAICT, there's no way to unlink an individual date to show that it's empty, so it has to be done via a red link. -- Tavix (talk) 16:09, 24 December 2016 (UTC)
  • Option 1 per Tavix's sound reasoning is my preference, but as long as whatever system we use is consistent then I'm not going to complain. If previously deleted log pages are restored then please edit the log pages either side to restore the links to them as otherwise they'll be orphaned probably everywhere other than my user:Thryduulf/RfD watchlist. Thryduulf (talk) 20:02, 24 December 2016 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Putting a note about moves in the RfD group edit notice

There have been quite a few times recently I've speedily closed RfD discussions that belong at WP:RM, and a couple more occasions where I've not been quite sure enough of this to close the discussion but have still commented - this just wastes everybody's time and contributes to the too many templates thing discussed above. There are instructions at the very top of Wikipedia:Redirects for discussion that explicitly say that these don't belong here, but it's clear that not everybody is reading this. So, to supplement this I propose to add the following note to Template:Editnotices/Group/Wikipedia:Redirects for discussion:

The wording of the bullets is taken verbatim from Wikipedia:Redirects for discussion/Header, but I'm open to different if people want, but prefer to keep this short so it's more likely to be read. Suggestions for a better title more than welcome! If there are no objections or better suggestions I'll add this in a few days. Thryduulf (talk) 02:37, 8 February 2017 (UTC)

  • I've noticed a recent uptick in "wrong forum" nominations too, and I'd support anything to help prevent that. The editnotice you've created looks great to me, and I can't think of any improvements. Unfortunately, it won't catch those using Twinkle (like the most recent example). -- Tavix (talk) 03:17, 8 February 2017 (UTC)
  • Support. It's a minor fix and if it's stops anything that should be at RM, it'll save everyone time. ---- Patar knight - chat/contributions 15:33, 8 February 2017 (UTC)
  • Support - Hmm... Twinkle users would not be aware of this proposal overlook this banner, even when passed. However, having the notice at the top seems a nice change. The proposal needs some more attention from others. George Ho (talk) 18:08, 9 February 2017 (UTC); edited. 18:18, 9 February 2017 (UTC)
  • Support! Deryck C. 13:08, 10 February 2017 (UTC)
  • Support, but I do want to emphasize that an RfD can result in a move. Consensus is consensus—see also WP:NOTBURO. Of course, if the initial request is for a move, it shouldn't be started here. --BDD (talk) 17:43, 14 February 2017 (UTC)

 Done After a week with nothing but explicit support I've made the change. I've also left noincluded notes there and at Wikipedia:Redirects for discussion/Header asking for them to be kept in synch. [1][2]. Thryduulf (talk) 19:24, 15 February 2017 (UTC)

Does G7 apply to redirects left behind from a page move?

Thryduulf said "G7 is not applicable as you are not the only author of the page prior to the move", but my understanding is that G7 (or even G6) is applicable because an editor is essentially saying, "the software forced me to leave a redirect behind but I didn't mean to".

The requirement to leave a redirect behind before invoking G7 already creates accountability by making sure an admin and another editor agree before deleting. In the past when this kind of case arrived at RfD they almost always result in unopposed deletion. Deryck C. 11:13, 15 February 2017 (UTC)

  • Unopposed deletion and speedy deletion are very different things. If something does not meet the letter of a speedy deletion criterion then it is not eligible for speedy deletion. WP:CSD#G7 explicitly mentions redirects from page moves: For redirects created as a result of a page move, the mover must also have been the only substantive contributor to the pages prior to the move. with an explanatory footnote noting that there has been "a history of improper deletions of these redirects". If the page was originally created at an obviously incorrect title in error or obviously accidentally created in the wrong namespace, then the redirect may be deleted under criterion G6. In the linked case, G6 does not apply because the creator intended to create it at the title they created it at - if that is incorrect it may be a reason to delete the redirect, but it does not make it elligble for speedy deletion. Thryduulf (talk) 16:30, 15 February 2017 (UTC)
    • Okay, thanks. Deryck C. 17:49, 16 February 2017 (UTC)

"Current list" section

Seems to me that the "Current list" section is slowing down loading times for the RFD page. I thought about moving the section into the proposed subpage, {{Wikipedia:Redirects for discussion/current}}. I hope the subpage would improve the loading times, but I don't know how much it does. However, it makes the editing more efficient. Thoughts? --George Ho (talk) 20:46, 4 February 2017 (UTC)

That wouldn't help loading times as all discussions would still be transcluded, as they are now. If loading times are a concern, a solution could be to simply link to each log page instead of transcluding the logs, similarly to the way it's done at CfD (see: Wikipedia:Categories for discussion#Current discussions). -- Tavix (talk) 20:59, 4 February 2017 (UTC)
Actually, when I spoke "loading times", I should have said loading after saving the changes, including the one I made when the bot didn't add the latest log. Back to what you said, I think the consensus is needed for either proposal. --George Ho (talk) 21:40, 4 February 2017 (UTC)
Also, making changes would affect the bot that does transclusions (and probably backlogging?). George Ho (talk) 21:43, 4 February 2017 (UTC)
Yes, any of the proposed changes would effect the way DumbBOT clerks the page. This is actually a fairly big problem as the bot's operator is no longer active. -- Tavix (talk) 21:49, 4 February 2017 (UTC)
Shall we go to WP:VPT about this then and ask someone else to take over the bot? --George Ho (talk) 21:56, 4 February 2017 (UTC)
No, there should be consensus for a change first. -- Tavix (talk) 22:00, 4 February 2017 (UTC)
The size of the logs has become so great that not all of them can get transcluded on the main page now. As a temporary reprieve, I've excluded most of the closed discussions in the 16 January log from transcluding onto the main page [3]. I hope this doesn't break anything. – Uanfala (talk) 23:48, 4 February 2017 (UTC)
Ah, I didn't realize that was a problem. I definitely think we need to switch to listing the open log days instead of transcluding them. -- Tavix (talk) 00:26, 5 February 2017 (UTC)
Alright, I've went ahead and switched to a list. WP:CFD is plagued with large backlogs, so I've taken a page from their book and mirrored the way they list their backlogs. The loading times should drastically decrease now. I've also added {{bots}} to the page to deny DumbBOT from editing the page. Someone (I'm fine with doing so) will have to manually add whichever day falls into the backlog everyday until the backlog has decreased to a level we feel comfortable transcluding again. Anomie's bot clerks CfD so perhaps we can ask him to code his bot to clerk RfD if this becomes permanent. (Of course, I'm doing this WP:BOLDLY so feel free to revert.) -- Tavix (talk) 00:53, 5 February 2017 (UTC)
Nvm, I can't seem to deny DumbBOT for some reason. Anyway, check the history for what that would look like. We'd need to get DumbBOT on board for it to work though. -- Tavix (talk) 01:18, 5 February 2017 (UTC)
Anomie should be able to easily add Rfd clerking to his bot. I would email DumbBOT's operator to shut down this task. — JJMC89 (T·C) 03:43, 5 February 2017 (UTC)
Yes, that should be fairly easy. If it comes to that please ping me again with a description of what exactly the bot should do. BTW, glancing at some open discussions it seems the bot could probably detect the output of {{subst:rfd2}} to be able to close discussions when all redirects mentioned have been deleted, like it does at TFD (like this), if that's wanted here. Anomie⚔ 02:36, 7 February 2017 (UTC)

Time to change appearance of closing discussions to avoid technical issues on page?

All, the reason some of the nominations aren't appearing on the page (and probably the reason for the slow loading times) is due to WP:EXPENSIVE issues I seem to have caused when I updated {{Rfd top}} and {{Rfd bottom}}. I noticed this a few weeks ago when I was relisting some discussions, and I know that Uanfala had to relist a discussion for the same reason recently. And yes, I know I caused them since I know the solution. Long story short, I didn't think the backlog would grow so large that an improvement I made would actually be a hindrance. Anyways, long story short, a solution would be this: Instead of closed discussions appearing collapsed on only Wikipedia:Redirects for discussion and not its subpages, they would have to be collapsed on their subpages as well. Any objections to this? (@BDD, Tavix, Thryduulf, Deryck Chan, Champion, and George Ho: Pinging all of you for input on this as RFD participants and/or clerking admins.) Steel1943 (talk) 01:06, 6 February 2017 (UTC)

Forgot to ping Patar knight. Steel1943 (talk) 23:22, 6 February 2017 (UTC)
What, that doesn't make sense. First of all, page parses are cached, so slow wikicode wouldn't make the page load slowly, just save slowly after edits. Secondly, {{FULLPAGENAME}} isn't expensive at all. All that would do is make subpages load slower. Pppery 01:14, 6 February 2017 (UTC)
My impression was that the expensive parser functions here come from the {{no redirect}} template that is used to format the link to the redirect in every nomination. – Uanfala (talk) 01:22, 6 February 2017 (UTC)
Adding that afaik the reason why the other day some logs couldn't transclude onto the main page had to do with exceeding the post-expand include size – and that's simply due to the sheer size of the discussions on the open log pages, and this could be solved in individual cases by tricks like this. Agreeing however that some general solution is desirable. – Uanfala (talk) 01:26, 6 February 2017 (UTC)
@Pppery and Uanfala: Right. Technically, both {{No redirect}} and the templates I mentioned have the potential to create parser function issues due to how they are built. But yes, per Pppery, the function I implemented in the templates I edited, "{{FULLPAGENAME}}" isn't listed at WP:EXPENSIVE. But, I figure I'd suggest something that may help as I think the subpages not appearing has happened more often since I implemented the changes. Steel1943 (talk) 02:00, 6 February 2017 (UTC)
One solution I can think of would be to exclude closed discussions from displaying on the main page altogether (instead of having them displayed as collapsed). With the current state of the logs, I reckon that should reduce the loading times by about a half. – Uanfala (talk) 02:24, 6 February 2017 (UTC)
@Uanfala: Doing that while using daily subpages would require similar parser functions as are currently being used right now to collapse the discussions on Wikipedia:Redirects for discussion. As far as I know, the only real clean way to do that would be to give each redirect its own subpage, and as you know, you've suggested that before. Steel1943 (talk) 02:30, 6 February 2017 (UTC)
It will only require invoking {{FULLPAGENAME}} once twice for each closed discussion, and that would prevent from transcluding onto the main page both the text of the discussion and any parser functions that it contains (notably the expensive ones coming from the links in the nomination). – Uanfala (talk) 02:37, 6 February 2017 (UTC)
@Uanfala: Right, and using two instances of {{FULLPAGENAME}} is currently how the current setup of {{Rfd top}} and {{Rfd bottom}} functions. Making your proposed change would not change the amount of {{FULLPAGENAME}}s that are executed on Wikipedia:Redirects for discussion when a discussion is closed. Steel1943 (talk) 02:43, 6 February 2017 (UTC)
The crucial difference is that the current setup uses these instances of FULLPAGENAME in addition to everything else that is already used within the nomination and the discussion. – Uanfala (talk) 02:50, 6 February 2017 (UTC)
@Uanfala: Ah, I see what you mean now. Even though the amount of {{FULLPAGENAME}}s will not change, all of the other parser functions, such as the ones in {{No redirect}}, will never run since the page will not appear at all. The thing is that ... I actually don't know if that is how that works (I mean, in regards to the parser functions not running on text that is hidden before the parser functions can run.) Steel1943 (talk) 02:58, 6 February 2017 (UTC)
(edit conflict) I'm not qualified to talk about the technical issues, but if collapsing the discussions on the daily log pages solves them then I don't object to doing so. I would prefer them to remain uncollapsed though if technical issues are equal either way. If they are collapsed I'd prefer a less garish colour scheme though (the one WP:DRV uses for example would be OK in my book). Thryduulf (talk) 01:29, 6 February 2017 (UTC)
Collapsing the subpages? ...No, that would affect readers' abilities to read the subpages. I have to surf through archives to create newer redirects/pages of the same names, like Dumb bitch/Dumb Bitch, which is now a dabpage, unlike what it was previously before deletion. Even I created Greed Is Good (disambiguation) as a result of the discussion about greed is good, a catchphrase from Wall Street. CFD, AFD, FFD, and MFD subpages don't collapse those discussions. On the contrary, DRV and MRV collapse closed discussions, but they are just closure reviews. --George Ho (talk) 01:35, 6 February 2017 (UTC)
  • Oops... I said "collapsing the subpages" when I should have said "collapsing a closed discussion in the subpage". My mistake. Anyway, I read the old discussion you mentioned, and... I might switch to neutral (unofficially) until I decide again whether to favor or oppose the idea. BTW, the 30 Nov 2007 log and the 31 Jan 2016 are the pages to determine the historical value of those discussions uncollapsed. George Ho (talk) 03:16, 6 February 2017 (UTC)

Two suggestions from in-person discussions I've had at Wikimania last year on how to optimize discussion closure boxes:

  1. Subst templates completely. {{Rfd top collapse}} doesn't currently do this, even though the documentation appears to say it should.
  2. I wonder if the collapse box should wrap the actual discussion content into a <noinclude>, which would then make the collapse box a link to the discussion rather than a "show" button. Deryck C. 11:37, 6 February 2017 (UTC)
  • I'm not too knowledgable about the technical side of things, but my preference would be for any solution that doesn't prevent people from navigating using the TOC (I guess this means leaving a section header/anchor?). If noinclude tags can link to the RfD while meeting the above criterion, using those should be fine. ---- Patar knight - chat/contributions 19:50, 7 February 2017 (UTC)
  • "... if the collapse box [could] wrap the actual discussion content into a <noinclude>, which would then make the collapse box a link to the discussion rather than a "show" button." sounds like a good idea. — Godsy (TALKCONT) 20:19, 7 February 2017 (UTC)
  • Okay. I've done some playing around with code today and found that:
    • Currently we can't completely subst {{Rfd top collapse}} when {{subst:Rfd top}} is called, because {{Rfd top}} depends on an #if: statement which must be preserved (the bit that determines if you're on the main RfD page). That makes it impossible to invoke a table without calling {{!}}.
    • So, it might be a better idea to try to wrap the discussion in <noinclude> when the discussion is closed. We can even wrap a summary box in <includeonly>!
    • I've been having some success with Lua: this code {{subst:User:Deryck Chan/sandbox2|outside|inside}} (which subst's a sandbox template which in turn safesubst-invokes a sandbox Lua module) will literally dump a <noinclude> tag onto whatever page you've been editing.
I'll figure out the rest over the next week. I might also head over to DRV and see what exactly they do.DRV simply subst's a collapse box onto the page, so it's collapsed whichever way you access the discussion log page. Deryck C. 00:38, 10 February 2017 (UTC)
  • After long thought, collapsing a discussion in a subpage wouldn't make loading times easier. I don't know how our servers handle the code of collapsing. How much time can a server load a collapsing code if a content is collapsed by default? Back to the original issue, how is still the loading time used to save changes after combating vandalism? George Ho (talk) 18:21, 17 February 2017 (UTC)
    • George, see how you like the new template. There is a difference between collapsing and hiding it in "noinclude": Collapsing is done on client side, which means the entire discussion's content is delivered to the reader, but isn't shown until the reader clicks "show". In contrast, "noinclude" is done on server side, so that a browser viewing WP:RFD won't load any of the discussion content (except the result and the link); the link then sends the reader to the daily log, where the entire discussion is loaded and displayed. Deryck C. 23:44, 19 February 2017 (UTC)

Script is out for testing

Hi guys, please try 

{{subst:rfd top/sandbox|'''result'''.}} Further comment. ~~~~

Original discussion here.

{{subst:rfd bottom/sandbox}}

User:Deryck Chan/sandbox3 is one such "log page" that is the result of this draft template and Lua script Module:RfD close. sandbox3 is in turn transcluded onto User:Deryck Chan/sandbox where only the "Closed discussion" notice gets transcluded. Deryck C. 16:49, 10 February 2017 (UTC)

@BDD, Tavix, Thryduulf, Deryck Chan, Champion, George Ho, and Patar knight: Any thoughts about this proposed new template? Deryck C. 10:27, 13 February 2017 (UTC)
 Done - I've been live-testing this new template for over a week, using the sandbox version to close discussions, without noticing any problems. So I've deployed the new templates onto {{rfd top}} and {{rfd bottom}}. Deryck C. 23:32, 19 February 2017 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Redirects_for_discussion/Archive_11&oldid=776441357"