Wikipedia talk:Twinkle

"WT:TW" redirects here. For other uses, see Wikipedia talk:WikiProject Taiwan.

LLMPROD

Tracked in github.com
Issue #2362

Any chance the recently adopted WP:LLMPROD could be added as an option in Twinkle? InfernoHues (talk) 01:33, 16 May 2026 (UTC)

On it! Chaotic Enby (talk · contribs) 23:41, 17 May 2026 (UTC)

While you're at it, I think Template:Uw-llmblock and the associated block option might be a good add. (I'll add it to github when I get home though, I can't access GH from work) ASUKITE 17:25, 11 June 2026 (UTC)

Already wrote a PR for that one. Chaotic Enby (in solidarity · talk · contribs) 17:56, 11 June 2026 (UTC)

Kermit the Frog waving his arms and going "Wheee!"

Seriously, given the volume at which we're doing LLMPROD, this would be so helpful. Thank you! M kuhner (talk) 04:16, 26 June 2026 (UTC)

Loss of data when switching in AfD

Tracked in github.com
Issue #2382

Happened to me twice now, is annoying: Start nominating some article(s) at AfD, finish text, notice that the dropdown at the top says "deletion" but want instead "redirect", and poof, all text written below is gone. Why can't this just keep what is already there? Alternatively, remove that dropdown which doesn't do a lot otherwise. Fram (talk) 09:09, 12 June 2026 (UTC)

I fixed this in 2382. – SD0001 (talk) 19:46, 23 June 2026 (UTC)

Automated edit request to complete RfD nomination

I noticed yesterday that Twinkle generated an automated edit request on the talk page of a protected redirect that I nominated for RFD. This is super helpful! I think this may be a a new feature as this did not happen the last time I nominated an edit-protected redirect but I don't recall if I used Twinkle or used another tool or did it manually.

Could the edit request be amended to include instructions to leave an edit summary along the lines of Nominated for RFD at: [[Wikipedia:Redirects for discussion/Log/2026 June 14#Article merge]] per edit request when completing the request? I used the full location for my nomination but obviously this should be modified to fit the relevant nomination. I haven't used this for other nominations of protected pages via Twinkle but I assume the functionality is similar, and could be updated similarly. This is similar to the instructions at WP:RFDHOWTO.

This may seem like a minor point but editors who work on redirects and participate in WP:RFDs often rely on edit summaries in the history to identify past discussions that may inform their assessment. There are of course other ways to find this information. In my experience {{Old RfD}} and {{Old XfD multi}} are often missing or incomplete, especially for redirects that were nominated many years ago.

Thanks for considering. —Myceteae‍🌈 (talk) 17:30, 15 June 2026 (UTC)

Talk page watching defaults

Tracked in github.com
Issue #2386

Now that topic subscriptions are a thing, I don't think most Twinkle users are going to be interested in watching the user talk page of the initial contributor to a page beyond the notice of the XfD (which they will generally be automatically subscribed to). Could we change the default Twinkle settings to reflect this? Sdkb ^talk 01:33, 16 June 2026 (UTC)

I support this. Have you opened a GitHub ticket about it? FaviFake (talk) 16:18, 3 July 2026 (UTC)

Done! Sdkb ^talk 19:38, 3 July 2026 (UTC)

Feature request: option to suppress username in edit summary upon revert

Tracked in github.com
Issue #2381

I originally brought this up on GitHub where Novem Linguae (talk · contribs) had some really useful thoughts and advice, and directed me here for better discussion and seeing if there's a consensus to be had.

To compress what I wrote on GitHub: we have a number of high-speed vandals who register abusive usernames, often insulting specific editors, then go on a spree.

Twinkle is the fastest way of non-admins reverting them while we wait for action at AIV, but leaves an edit summary that reads Reverted 1 edit by [Abusive Username] (talk) to last revision by [Previous Editor] This is causing extra work for administrators who go back and suppress the edit summary in order to reduce disruption.

There is a workaround (manually undoing the abusive edits and replacing the default edit summary with RVV or the like) but this is far slower than using Twinkle directly — important when the vandal is a high-speed one editing high-traffic and highly visible pages.

A possibility might be in the tools presented in the diff view, by adding a fourth option:

[rollback (AGF)] || [rollback] || [vandalism] || [LTA]

The [LTA] button would generate a username-less edit summary: Reverted 1 edit to last revision by [Previous Editor]. If this is likely to be misused (I don't see how, but it's possible), having it in the Options so it has to be deliberately turned on rather than being present by default might mitigate that?

Novem points out [t]here's a lot of newbies that use Twinkle. You only need to be autoconfirmed. Some might mash the LTA button without knowing what LTA means.

A better name/label might be a solution, or moving that particular button to be less prominent perhaps. I'd be grateful for all input on this overall idea, even if it's only to tell me to slink away! • a frantic turtle 🐢 solidarity 16:44, 21 June 2026 (UTC)

Just to quote from the git:

I think the "An optional comment for the edit summary:" popup is implemented via JavaScript prompt(), which is extremely simple code but also completely un-customizable with check boxes. We would need to add a bunch more code to pop up a Morebits form that had a check box. Do-able, but not a simple change.

There's a check box for Prompt for reason for normal rollbacks in the TW prefs, and if I'm not mistaken it's ticked by default. If it's not, can we make it that way? seems like that would take care of it for the majority of users. Primefac (talk) 16:58, 21 June 2026 (UTC)

I believe the resulting edit summary would still be

Reverted 1 edit by [Abusive Username] (talk) to last revision by [Previous Editor]: [reason given in JS box]

and thus wouldn't solve the issue? • a frantic turtle 🐢 solidarity 17:04, 21 June 2026 (UTC)

Right, forgot it's an addendum not an overwrite. Primefac (talk) 17:08, 21 June 2026 (UTC)

From a sandbox test, the resulting edit summary suppresses the [Previous Editor] but not the [Abusive Username] part. Bum! • a frantic turtle 🐢 solidarity 17:10, 21 June 2026 (UTC)

Just to respond to the "is there consensus", as someone who is constantly hiding edit summaries because of this, I absolutely support it. Primefac (talk) 17:22, 21 June 2026 (UTC)

Is there a technical or policy reason why we name the account being reverted in the edit summary, in Twinkle or in native rollback, other than transparency and/or because we always have? • a frantic turtle 🐢 solidarity 17:33, 21 June 2026 (UTC)

No, just best practice to give as much useful information as possible (who, what, why, etc). Primefac (talk) 18:42, 21 June 2026 (UTC)

Got a preference on which solution should be implemented? –Novem Linguae (talk) 21:47, 21 June 2026 (UTC)

I like the idea of the "LTA" button, but I think the best option is just change the default edit summary to omit the username altogether (i.e. in all cases). Primefac (talk) 22:27, 21 June 2026 (UTC)

[t]here's a lot of newbies that use Twinkle. You only need to be autoconfirmed. Some might mash the LTA button without knowing what LTA means. An easy solution is to require extended confirmed to see the LTA button. Most people working to revert LTA usernames are already extended confirmed anyway. —⁠k6ka 🍁 (Talk · Contributions) 01:34, 30 June 2026 (UTC)

Survey: remove the vandal's username from the Twinkle rollback vandal edit summary

Thoughts? Credit to Primefac for the idea in the comment above this one. I am neutral, Primefac supports. –Novem Linguae (talk) 20:32, 22 June 2026 (UTC)

• Support. I hate making ongoing work for other people, but hitting [rollback] (native or Twinkle) when faced with the fifth variation of "Respected Editor Name is a commienazi" today is basically muscle memory and I will keep doing it without thinking. Primefac's idea reduces that work and I don't believe, personally, that it reduces transparency enough to matter. • a frantic turtle 🐢 solidarity 20:47, 22 June 2026 (UTC)
• Taking a deeper look at this, the regular MediaWiki rollback includes the username. Are we sure we want to get Twinkle out of alignment with regular MediaWiki rollback? –Novem Linguae (talk) 16:10, 30 June 2026 (UTC)

  I was thinking about this too and... yes? Getting native rollback changed is likely to be one hell of a hill to climb, but if we can point to a success from changing the most-used method of undoing edits, we'll have a bit more standing with the community to request a change to the second-most used. The period of asynchronicity would be a couple of months, I'd reckon — unless the change to native rollback didn't go through, in which case I think we should come back here and debate synchronising them again by reverting our changes to Twinkle. In the meantime, we'll have cut — but not eliminated — the work revdellers are having to do removing disruptive usernames from logs. • a frantic turtle 🐢 solidarity 16:18, 30 June 2026 (UTC)

• Hiding the username makes sense for editors who regularly revert LTA's, and a preference option to omit usernames from revert summaries is a really good idea. But it should be opt-in and hiding the username shouldn't be the default. The username in the edit summary is a record of exactly what action is being taken. If the default were changed to "reverting edits", or similar, it would be less obvious exactly whose edits were being undone, especially to other users viewing the page history who aren't familiar with Twinkle's behavior.
  I'm not super familiar with Twinkle's guts, but if it utilizes session storage, is it possible to just omit usernames of editors who have recently been reported to UAA (or editors who the Twinkle user has attempted to report to UAA)? That might be an elegant solution. As an aside, it would be really nice to have a checkbox to hide the username when reporting to AIV. If that were the case we could even modify {{vandal}} to include an argument to hide the username like at m:SRG. --tony 17:21, 30 June 2026 (UTC)

  My view is that even relatively new users (but not new new users, who will be confused anyway so 🤷) will be able to spot Reverted 1 edit to last revision by [Previous Editor] and pick up what's going on — the last edit was reverted. That's more informative than what's happening now in the cases of LTAs with editor-insulting usernames, where what they see is (edit summary removed) once revdellers have become available to remove the offending username from the edit summary.

  It's worth remembering that Twinkle users, rollbackers and even just 'undo' users should never revert an edit that requires explaining why it was reverted without supplying the reasoning for doing so. 'Blind' reverts of non-vandal edits are A Bad Thing if the reverted user is named or not. Repeatedly doing it after being told not to is a blockable offence.

  But suppressing (or having the option to suppress) the username in the edit summary when reporting to AIV or UAA? Yes please! • a frantic turtle 🐢 solidarity 17:40, 30 June 2026 (UTC)

  Your explanation makes a lot of sense, especially your edit summary removed comparison, and I'm not opposed to the idea anymore. The only edge case I can think of now is situations where a user has been hounding another editor to revert their edits. I ran into an example today (it's probably not appropriate to link) where a good 80% of their edits were unexplained reverts of a single user across many articles (the other user's contribs looked the same but reversed). I could easily tell this at a glance because the username is in the edit summary, but absent that it would look indistinguishable from someone doing RCP unless I had a reason to check each one. I don't think that's a dealbreaker but it's something this would impact. tony 23:54, 30 June 2026 (UTC)

Discussion at Module talk:Module wikitext § Template-protected edit request on 16 June 2026

 You are invited to join the discussion at Module talk:Module wikitext § Template-protected edit request on 16 June 2026. Est. 2021 (talk · contribs) 14:28, 22 June 2026 (UTC)

Use Rollback API if rollback perms

Reverts using the Twinkle rollback links would probably be much faster if the Rollback API was used rather than the undoafter API, by reducing unnecessary API calls. This would only affect rollbackers and administrators, other users would continue using the older API. Aasim (話す（はなす）) 17:01, 23 June 2026 (UTC)

Seconding this; pretty noncontroversial as it would not affect visible functionality. RedWarn does this already, although it's opt-in. The rollback edit summary now also supports displaying the number of edits being reverted, so Twinkle could still show this by sending Reverted {{PLURAL:$7|$7 edit|$7 edits}} by [[Special:Contribs/$2|$2]] ([[User talk:$2|talk]]) to last revision by $1 as the edit summary. —⁠k6ka 🍁 (Talk · Contributions) 01:43, 30 June 2026 (UTC)

Bug report for a non-English welcome template

Tracked in github.com
Issue #2363

Issuing {{welcomeen-ja}} to a user resulted in a duplicate header with nothing beneath it. [1] –LaundryPizza03 (dc̄) 21:58, 25 June 2026 (UTC)

Not seeing anything obvious in the template code that would do it. Primefac (talk) 22:33, 25 June 2026 (UTC)

Something seems to be very wrong with some welcome templates (specifically the cross-language welcome templates, like {{welcomeen-es}})

So I just started welcoming users that speak other languages a while ago. However, there is a bug in where the "Welcome!" header in English generates twice, like in here. I mostly use Twinkle for these welcome messages, so is it able to be fixed? Or is it just not related to Twinkle at all? @AzaToth @Novem Linguae @SD0001 (pinging them for absolutely zero reason but to see whether the problem is the "Welcome!" header in the wikitext of these welcomeen-language templates) – SimpleObjects-9ei 🏖️/☀️/🥵 (🌎 CentralAuth) 00:15, 30 June 2026 (UTC)

I was able to reproduce this problem. I went to my own talk page, clicked the TW menu, clicked Wel, choose Non-English welcomes, clicked the radio button next to welcomeen-he, and then clicked Submit. I got a doubled header. The doubled header also appears in Twinkle's in-dialog-box Preview. It looks like there is a pull request that might fix this problem, if someone has the ability to check and merge the code. – Jonesey95 (talk) 01:39, 30 June 2026 (UTC)

Another (worse) option would be to remove the header from each of the non-English welcome templates, but then they wouldn't work when substed. Better to fix the Twinkle code. – Jonesey95 (talk) 01:42, 30 June 2026 (UTC)

Merged and deployed. However, I'd note that several of these templates like {{welcomeen-ar}}, {{welcomeen-no}} {{welcomeen-it}}, and {{welcomeen-or}} are using a level-3 header which doesn't look right. – SD0001 (talk) 09:21, 30 June 2026 (UTC)

@Jonesey95, @SD0001, and @LaundryPizza03. Seems that the double header has been fixed, but now it generates two lines down like in right here. Still no idea what's causing "Welcome!" to drop like two lines down for no reason. – SimpleObjects-9ei 🏖️/☀️/🥵 (🌎 CentralAuth) 14:42, 1 July 2026 (UTC)

I think that I have fixed this and one other whitespace issue. I have tested it in my user sandbox, but any further testing you would like to do would be welcome. – Jonesey95 (talk) 16:33, 1 July 2026 (UTC)

Bug: can't type in user talk warning template selection drop-down on mobile Firefox

• Android 16, Firefox
• Open a diff page and revert it by tapping the vandalism button
• User talk page automatically opens and shows warning template selection dialog
• Tapping in the selection text input field to search for a template correctly brings up soft keyboard (with digit row) but keystrokes don't register
• Next, toggle the desktop mode in Firefox menu to bring up the user talk page in desktop mode
• Tapping in the selection dialog now correctly brings up soft keyboard (with digit row) and keystrokes work normally to filter the templates

This bug appeared maybe a month or two ago, and if I remember right it happened at the same time the digit row was added to the soft keyboard for this input field. If this description is confusing, I made a screen recording which demonstrates it and I'm happy to share on Discord. --tony 23:31, 25 June 2026 (UTC)

Change to PROD (proposed deletion) module

I want to suggest changing something on the PROD (proposed deletion) module. Is this the place? Magnolia677 (talk) 19:13, 1 July 2026 (UTC)

Yes. – SD0001 (talk) 03:52, 2 July 2026 (UTC)

Great. When I prod an article, there is the option "Notify page creator if possible". This should not be optional (it's not an option for an AFD). This option allows the proder to sneak a deletion in without the article's creator noticing. There's no reason not to notify the creator, who might offer a valid reason to keep the article. Magnolia677 (talk) 15:55, 2 July 2026 (UTC)

There are many reasons it might not be necessary or advisable to notify the creator, for example if the creator is blocked, it's a UPE creation, or they're long-term inactive. The box is ticked by default, which I feel is the right approach, but the option to untick it should remain in my opinion. HJ Mitchell | Penny for your thoughts? 16:19, 2 July 2026 (UTC)

Yes, agree with that. Keep the option, leave it checked by default. SarekOfVulcan (talk) 16:22, 2 July 2026 (UTC)

Just a minor note, the option to not notify the creator is available for AFD as well. Primefac (talk) 06:21, 3 July 2026 (UTC)

I have 28,000 articles on my watchlist, and might miss a prod if I don't receive notice, and I'm pretty sure some of my deleted articles were proded without my notice. It's a way to game the system. Moreover, what's wrong with a blocked editor receiving notices about their articles? The bad outweighs the good. Magnolia677 (talk) 11:03, 3 July 2026 (UTC)

it's not an option for an AFD
It is optional, actually. See WP:AFD3:

While not required, it is generally considered courteous to notify the good-faith creator and any main contributors of the articles that you are nominating.

Personally, I always disable the option to notify the creator, as that has never been a common practice in the previous merge proposal process. FaviFake (talk) 16:17, 3 July 2026 (UTC)

Nomination for merger of Template:Tfm notice and Template:Tfr notice

 Template:Tfm notice and Template:Tfr notice has been nominated for merging with Template:Tfd notice. You are invited to comment on the discussion at the template's entry on the Templates for discussion page. Thank you. FaviFake (talk) 16:13, 3 July 2026 (UTC)

Twinkle not recognizing existing tags

Resolved

Tracked in github.com
Issue #2387

When I select "Tag" in Twinkle, all of the templates in the list are unchecked, even if they're in the article. Is anyone else having this problem, or is it something on my end? Thebiguglyalien (talk) 00:38, 9 July 2026 (UTC)

I'm also having this problem. ARandomName123 (talk)^{Ping me!} 03:44, 11 July 2026 (UTC)

Same here, but I can't seem to reproduce it on testwiki. ~ rusty ^meow ~ 21:04, 11 July 2026 (UTC)

Should be fixed now. Thanks to HakanIST for the patch. – SD0001 (talk) 03:17, 12 July 2026 (UTC)

tag old news?

Would it be possible to add {{old news}} to the tag list here? --Joy (talk) 22:04, 13 July 2026 (UTC)

"Template:Welcome-uk" listed at Redirects for discussion

The redirect Template:Welcome-uk, which is used by Twinkle, has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Anyone, including you, is welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2026 July 15 § Template:Welcome-uk until a consensus is reached. In solidarity, Gommeh ^{(talk 🎮 sign)} 14:49, 15 July 2026 (UTC)

Template:welcome-belated seems to not be printing signature anymore

Hello and welcome again to a bug report. It seems that belated welcomes don't print the signature anymore (proof 1) (proof 2), and SineBot will even ignore it. The rest of the welcome templates actually print the signature, so what is going on here?

(Edit: I did actually edit Template:Welcome-belated but I still have no idea what prints the signature :/) – (In solidarity 🫡) SimpleObjects-9ei 🏖️/☀️/🥵 20:35, 15 July 2026 (UTC)

You edited the page after you left this message, has that fixed the issue? Primefac (talk) 09:22, 16 July 2026 (UTC)

@Primefac

...Yes. It did fix it. Adolphus79's move might have been bold, but unfortunately, we still have to find what prints the signature in the other welcome templates. In fact, we STILL have to find out how to remove "~~~~" without breaking signature printing. – (In solidarity 🫡) SimpleObjects-9ei 🏖️/☀️/🥵 18:47, 16 July 2026 (UTC)