So are you saying you want it to create [[Wikipedia:Articles_for_deletion/Queen_Street_Bus_Terminal (2nd nomination)]] instead? I understand your description of what it currently does, but I don't understand precisely what you want it to do instead.

In T169441#3426349, @Catrope wrote:

So are you saying you want it to create [[Wikipedia:Articles_for_deletion/Queen_Street_Bus_Terminal (2nd nomination)]] instead? I understand your description of what it currently does, but I don't understand precisely what you want it to do instead.

Correct. Wikipedia:Articles for deletion/Queen Street Bus Terminal already existed so it should have created Wikipedia:Articles for deletion/Queen Street Bus Terminal (2nd nomination), and so forth.

Relevant Twinkle code that may be of help:
https://github.com/azatoth/twinkle/blob/master/modules/twinklexfd.js#L525-L541

If the deletion discussion is still open, though, it should ideally reuse it (that likely means someone vandalized the page and removed {{Article for deletion}}.

I'm not sure if anybody's working on this, but it's still a problem. https://en.wikipedia.org/w/index.php?title=Wikipedia%3AArticles_for_deletion%2FWilliam_Herp&type=revision&diff=838375117&oldid=740513135

Still a problem... to the point that it is never advisable to use Page curation to nominate for AfD. Pretty sure most patrollers use Twinkle instead after they realise this bug exists.

@Insertcleverphrasehere, @Compassionate727, @GeoffreyT2000 - The way that English Wikipedia handles this situation seems overly complicated. Ideally we want every action that PageTriage takes to be configurable on-wiki (See https://www.mediawiki.org/wiki/Extension:PageTriage#On-wiki_configuration). Setting up support for creating additional pages and adding disambiguation strings would likely necessitate breaking the config model and resorting to custom code for English Wikipedia. The more we write custom code for English Wikipedia, the less configurable PageTriage becomes and the less likely that it will ever become available for other language wikis. Is there any possibility that English Wikipedia would be willing to simplify the AfD process and just list new nominations on the same page? This would also have the advantage of allowing people to easily refer to previous debates and would also simplify the nomination process (which right now is kind of a pain when there are previous nominations). I know this would be a big change, but I really don't understand why the current process is so complicated.

I have started an RfC for @kaldari's proposal above at Wikipedia talk:Articles for deletion#RfC: Stop creating separate AfD pages for renominations. If that proposal passes, then this task should be closed as declined.

@GeoffreyT2000 Explaining why you were proposing the change in the RfC lead probably would have helped, although I'm not surprised it's not going over well. This didn't seem like something that would.

The RFC currently has 10 responses at 80% Oppose. There's little chance it will turn the other way.

I understand why this would be more convenient on the programmer side to put a new AFD on the bottom of an existing page, but it would be bad for people working on EnWiki. We probably run into longer discussions and more cases of multiple re-nomination than somewhere like Commons. For example the deletion discussion for Covfefe was 136k long. That's probably a 1% case, but it's not unusual for discussions to run upwards of 50k. In an admittedly extreme case, Gay Nigger Association of America hit (22nd nomination). Five-to-nine nominations is more realistic for a really bad case recurring article. It's easier to use a clean page for the new work.

I know this goes way beyond the current task scope, but the inactive T103082 Workflow project would solve things like this. Each Wiki could configure the process locally.

@GeoffreyT2000 - Well, it's clear that RfC isn't going to result in consensus to change, so feel free to close it as [[WP:SNOW]]. Thanks for the effort though.

@MMiller_WMF - It looks like we'll need to fix this at some point.

Just to note that I now use User:Writ Keeper/Scripts/deletionFinder.js so I don't accidentally nominate a page at AfD a second time.

RFC closed as Snow Opposed.

For some reason, MediaWiki has never had to render ordinal numbers (1st, 2nd, 3rd, etc), so there's no facility in MW core to generate these that I know of. Thankfully enwiki does have a template that does this, so here's a suggested approach that doesn't depend on building (internationalized!) ordinal support into MW core:

• Create an i18n message that controls the name of the AfD subpage; pass it the page name (as $1) and the sequence number (as $2)
• Start with the sequence number set to 1, and check if the resulting page title exists. If it does, try sequence number 2, 3, etc, until you find a page title that doesn't exist. Use that title for the AfD nomination.
• In en.json, set the value of this message to something like $1 (nomination $2) or $1{{PLURAL:$2|1=| (nomination $2)}}. This is not compatible with enwiki's naming scheme, but it's a sensible default that doesn't require ordinals or anything else complicated.
• On enwiki, create a local override of the message with $1{{PLURAL:$2|1=| ({{ordinal|$2}} nomination)}}. (Note that [[https://en.wikipedia.org/wiki/Template:Ordinal|{{ordinal}}]] is a Lua-powered template that already exists on enwiki.)

(You could also use $1{{#ifeq:$2|1|| ({{ordinal|$2}} nomination)}}, that's equivalent to the PLURAL construct. However, we can't use {{#ifeq:}} in the software default without making PageTriage depend on the ParserFunctions extension, so we should definitely use PLURAL there.)

Note: For assorted reasons, there occasionally gaps in the (Nth nomination) sequence. If you look at Gay Nigger Association of America (22nd nomination), no pages exist at 3rd 4th 10th 11th 19th 20th or 21st. I'm not sure if Twinkle would create a new nomination at the first open slot (3rd), or if it's smart enough to create the new page at 23rd. Creating the new page at 23rd would definitely be preferable. It's probably worth checking the Twinkle code to see if it contains a solution for this, as well as checking whether it reveals any other corner cases or implementation details we've overlooked.

Spike outcome

This looks doable, if we're to discard the need to support more than one wiki (which is outside of scope of our current work anyway).

Generating page name: Roan has summed it up nicely in this comment. Note that due to PageTriage's WMF-centeredness, relying on ParserFunctions wouldn't be as big of a sin than in general, however looks like this message would need to be parsed on the client side, which would mean no ParserFunctions anyway. This message would have to always be in content language so you'll have to pass it as a JS config variable.

Finding the page: instead of checking for page existence one by one, you can batch it like this.

And are we aiming to find the next number in sequence, or just the first available one?

As @Alsee mentions above, there are somtimes gaps. It sounds like it'd be easier to retrieve the prefix list, count them (and add 1 for the 1st nomination?), and then start looping, checking for existence, and incrementing. Although, are there pages that already have parentheses in their titles that would break that approach?

Twinkle loops through the titles (it's actually parsing the DOM (!!!), probably because it predates API:Allpages which is what we use), parsing out the integer using regex, finding the maximum value, then adding 1: https://github.com/azatoth/twinkle/blob/master/modules/twinklexfd.js#L627-L655 I recommend using similar logic since this been battled-tested. I don't know how we would make it respect localization, etc.

Bear in mind the AfD system we support is pretty unique to English Wikipedia. Worse comes to worse, I think it's okay if we treat all of the AfD stuff as enwiki-only, and hard-code ordinal variations like Twinkle does.

I think it's fine in this case if our first go at this is focused on the existing EN-wiki only scope. It's not ideal and certainly not what we'd do if we had the chance to start from scratch. However, given the scope of a Wishlist item, I think holding to that for this work is acceptable.

I agree with @aezell regarding the focus on en-wiki only. Since this ticket was converted to a spike, I've created a separate ticket for the work itself: T231357

There's nothing left to review here I think. Work has started on T231357.

What happens to spike's after review? Straight to done?

Yes. Once we've created the tasks needed to do the work the spike recommends, we can close the spike task.