Nice error if the nominated page is already a redirect when applying …#150
Nice error if the nominated page is already a redirect when applying …#150Trialpearswiki wants to merge 3 commits into
Conversation
|
Noting that I've updated the original point in #135 to add that the Talk page of the source should also be checked, along with a second diff of what happens currently. Not sure if this is already handled by this patch? I can't think of any other page that it would make sense to check. |
This is not handled but I'm also not sure how to handle it. At RfD the user is asked if the redirect should be replaced with Old RfD (or that's the intention it's bugged and not working with a pull request waiting to fix it). At MfD it "edit[s] the redirect's target page, using the altpage parameter" (copied from code comment) and at other venues except AfD it appends the Old XfD template to the redirect. I think appending probably makes sense but warning like you suggest is also fine by me but then it would need a different warning message like "Nominated article's talk page ${makeLink(title)} is currently a redirect. Old XfD template not placed." I can easily implement any of the above solutions I just gotta know which to use. |
|
@Trialpearswiki @NovemLinguae Wait, I just realised that the article can become a redirect in two cases:
So, if the article was moved and the {{Afd-merge to}} template was not placed on the article because it's a redirect, the article will not be added to the backlog. We would still have the {{Being merged from}} template on the destination article, which is tracked as well, but maybe it's worth checking if there's something we can do to add the template somewhere. Since moving or merging an article is supposed to always leave a redirect category, what do y'all think about this flow instead? Edit: The new flow has been moved to the main issue |
|
No opinion from me. I'm trying to let you do the product manager type decisions and I'll just focus on code. |
|
Sure! Then, if this newer proposal isn't too hard to code, I think it's a much more solid way to handle this specific edge case. Sorry for not thinking about it earlier, I hope I didn't waste too much of Trialpear's time! |
|
I have to admit that's quite an elegant solution. Should be doable to implement but will take some time. (I am slow and inexperienced) Am currently focusing on getting the merge template cleanup functions done. |
|
Yes please! Definitely focus on that task first, if you can. This is just a rare edge case, and the merge templates still have to be updated manually for every merge closure. The sooner you manage to get that one working, the better. Thanks for helping improve XFDcloser! |

Not much to say. Deals with one of the boxes at #135
