Tips for writing good bug reports and feature requests:
Include the affected article name and a diff.
Include a screenshot.
For bugs, include the exact steps to reproduce the bug. Bugs need to be reproducible.
We will use this information to create a ticket on GitHub, which is our todo list for volunteer developers. For most tickets, expect them to take a long time (months). They will need to attract the interest of a volunteer developer, then go through code review, then get merged to master, then get deployed.
Twinkle has detailed documentation located at WP:TW/DOC.
This page has archives. Topics inactive for 30 days are automatically archived 1 or more at a time by Lowercase sigmabot III if there are more than 30.
This might be a dumb question, but... why? BLAR just involves editing the page, Ctrl+A, then typing in #REDIRECT [target]. Doesn't seem like it would save all that much time and effort to use TW for this. Primefac (talk) 10:28, 19 January 2026 (UTC)[reply]
Because that way, it can also inform the top contributors of the page that a BLAR action is being made on the page. Manual BLAR-ers might skip that step. Kingsacrificer (talk) 18:50, 19 January 2026 (UTC)[reply]
I teach classes and tell my students to install Twinkle. Some of my students this semester cannot install it - it does not appear in their preferences. I confirmed it visually - for some it is not there (should be between gadet "revisionjumpe" and "Suppress display of all CentralNotices", but for some there is no Twinkle button to activate, and it also doesn't show up in their search). At this point I cannot identify a common cause for some of them not having it - is it supressed/hidden for new editors or such (an early guess)? Piotrus at Hanyang| reply here07:06, 3 April 2026 (UTC)[reply]
it would be great is we could use twinkle to put CT notice templates on user talk pages, especailly if ti would check whether they have aware templates or prior notices. (i think this functionality is in place for others, but i could be wrong). -- Aunva6talk - contribs20:40, 3 April 2026 (UTC)[reply]
@Voorts. Did you have any specific changes in mind for Twinkle? Will this affect the XFD -> Articles for Deletion page's options/layout? (That page is used to file AFDs.)
@Novem Linguae: I don't think XFDCLOSER will require any updates since it already supports merging. I think Twinkle's AfD layout will need to be changed to be similar to CfD so that editors can specify the outcome they're selecting. That will need to be paired with changes to the templates to indicate what is being proposed. voorts (talk/contributions) 15:50, 25 March 2026 (UTC)[reply]
Basically, Twinkle should now give editors an option to pick the type of action they're suggesting, and for merges/redirects, add the name of the target page. I think Twinkle should also tag the target page for merges with {{merge from AfD}}, linking to the AfD discussion. voorts (talk/contributions) 20:31, 3 April 2026 (UTC)[reply]
The template has been updated to support these four options: Deletion, Merging, Redirecting, Draftification. On github, the last one is missing. These are selected using the |outcome= parameter. See {{Article for deletion/dated/testcases}} for the 4 cases.
Yes, but there are other changes unrelated to the writing of the AfdD template on the page to nominate, such as to the talk page notice sent to the creator of the page. They will need to be adapted to what the user has picked. Note that the |target= parameter is optional, of course; editors oftentimes don't know right away where an article should be merged, for example.
For deletion, nothing changes.
For merging: {{subst:Afd notice|ARTICLENAME|outcome=merge|target=TARGETNAME}}
For redirection: {{subst:Afd notice|ARTICLENAME|outcome=redirect|target=TARGETNAME}}
For drafitication: {{subst:Afd notice|ARTICLENAME|outcome=draftify}} (it doesn't support |target=)
At WT:AFD we've decided to rely on the main {{Merge from}} template, since the other was just a copy with some longer and outdated text. So the parameters are:
Every parameter is optional except |1= and |date=, and the template supports 20 unnamed parameters, so a maximum of 20 source articles (to use for bundled AfD nominations). |section= should only be added if the proposed destination is a section and the template is placed at the top of that section.Here's how {{merge from}} should link to the AfD discussion:
We will continue supporting the old |talk= and |discuss= parameters until all old PAM merge proposals that use it are closed, and once the implementation is finished we can turn them into aliases of |afd=.
To clarify, I didn't add the target parameter for draftification as the name of the target is relatively immaterial, usually being Draft:ARTICLENAME or (if the latter is preoccupied) Draft:ARTICLENAME 2, which doesn't affect the discussion like a merge/redirect target would.The part after the "Wikipedia:Articles for deletion/" already exists as a parameter, name. Chaotic Enby (talk · contribs) 19:47, 4 April 2026 (UTC)[reply]
I edited the original post in the ticket. Please check it out when you get a chance and let me know if it needs further changes. Feel free to reply in the GitHub ticket to keep things centralized. –Novem Linguae (talk) 09:09, 5 April 2026 (UTC)[reply]
Thanks and sorry! That makes sense. I think a parameter like the one i suggested above could be used for this purpose, to avoid making the transition harder for users and bots FaviFake (talk) 19:30, 4 April 2026 (UTC)[reply]
Alright, I've finalised my proposed plan for the transition. What are we thinking, especially about the last paragraph? Is it doable to implement into Twinkle? (logging off for now, I'll respond tomorrow) FaviFake (talk) 21:40, 4 April 2026 (UTC)[reply]
We have a maintenance category in use to track the deprecated use: Category:AfD merge templates using unnamed parameters. Currently it is only populated with pages using {{afd-merged-from}} (which is not used by XFDcloser), as I have kept the other afd-merge templates updated with the named parameters via periodically checking a cross-cat search (+ all namespaces enabled), but current XFDcloser usage reintroduces population with the other templates.
Per the two recent edit summaries v4.0.16 at 72f6fa2 and v4.0.16 at 60a827b, seems like this was due to using generated outputs from the PR commits rather than their squashes into the repo, and 60a827b was not rebased to include 72f6fa2. ~ oklopfer (💬) 16:47, 10 April 2026 (UTC)[reply]
@Novem Linguae The most urgent change is to allow editors to add |outcome=merge to te AFD template when using the twinkle XFD popup. Anything else is less urgent (but still very much necessary!) FaviFake (talk) 15:54, 10 April 2026 (UTC)[reply]
Sure, but you don't need to implement the merging one all at once. For example you could just add a very simple check box that says "this is a merge proposal" and literally just adds the parameter |outcome=merge to the AFD template on that page alone, without doing anything else. That would already go a very long way towards helping editors nominate articles for mergers. The rest is less important. FaviFake (talk) 21:39, 10 April 2026 (UTC)[reply]
Diff. I wasn't able to reproduce this on testwiki. We're probably missing a step to reproduce. Maybe this involves following a redirect, or linking a deleted page, or something complicated like that. In general, Twinkle is pasting this on user talk pages for A10s: {{subst:db-a10-notice|NovemTest110|nowelcome=|article=Test|{{{key2}}}={{{value2}}}|{{{key3}}}={{{value3}}}}}<!-- Template:Db-csd-notice-custom -->~~~~ –Novem Linguae (talk) 08:57, 1 May 2026 (UTC)[reply]
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.
Proposed article merges now have to go through AfD, but the procedure is slightly different, because you also have to add {{Merge from}} to the target page and use {{subst:Mergenote}} to notify the page creator. It doesn't seem like Twinkle can do that currently, would be great to have that feature. 🍅 fx (talk) 09:26, 16 April 2026 (UTC)[reply]
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.
Someone submitted a patch for the block module adding an "LTA" preset, and I want to double check consensus. The details of it include 1) indef, 2) blocking user talk page access, 3) doesn't leave a template on user talk, and 4) block log reason of "Long-term abuse". Does this sound useful to add to Twinkle? –Novem Linguae (talk) 02:30, 18 April 2026 (UTC)[reply]
The text of uw-unsourced1 is: Hello, I'm [own username]. I noticed that you added or changed content in an article, [name of the article], but you didn't provide a reliable source. On Wikipedia, it's important that article content be verifiable. If you'd like to resubmit your change with a citation, your edit is archived in the page history. If you have any questions, you can leave me a message on my talk page.
Regarding the second last sentence: I want to warn users also in cases I didn't archive the edit in the page history. That second last sentence of the warning message should be removed.
Regarding the last sentence: Leave a message on one own's talk page? Why? The topic is added on the user's talk page so the discussion should be made there. WikiPate (talk) 14:24, 18 April 2026 (UTC)[reply]
The second to last sentence is a beginner-friendly way of saying "your edit's wikitext still exists as a diff and is still in the history tab if we ever decide to restore it". The last sentence is just a standard sentence included in many user warning templates. The advantage of moving the conversation to your user talk is that you may not be watching the user talk page or be subscribed to the section of every person you warn. –Novem Linguae (talk) 14:29, 18 April 2026 (UTC)[reply]
The second last sentence confuses the user if the edit has not been reverted. Is it consensus on Wikipedia that a discussion started on the talk page of user B by user A should be continued on the talk page of user A? WikiPate (talk) 14:34, 18 April 2026 (UTC)[reply]
If you're concerned enough about unsourced content to leave a Talk page notice for someone, then I'm confused as to why you wouldn't be concerned enough about it to revert it. I don't leave this notice for an editor unless I have reverted their edit because it added unsourced content.
There's no consensus of the nature you describe, and in fact it's probably a bit counterintuitive in general, but Novem already explicated why it might be helpful, especially with regard to newer users. DonIago (talk) 15:19, 18 April 2026 (UTC)[reply]
It's more friendly and cooperative to not revert something immediately, but to give the user 2 days to add a reliable reference. Especially for new users it's more easy to add a reference instead of also re-adding the deleted content.
Or sometimes I added a reference by myself but also want to make it clear to the user to do that by themselves in the future. WikiPate (talk) 18:09, 18 April 2026 (UTC)[reply]
Sounds like you have a non-standard workflow. The disadvantages of not reverting immediately are inefficiency, and leaving bad content in view of readers. The advantage as you mention is treating newcomers better (WP:BITE). –Novem Linguae (talk) 22:13, 18 April 2026 (UTC)[reply]
I'm unlikely to remember to revert unsourced content some arbitrary amount of time after I've first seen it. If I don't think it should be immediately removed I'll CN tag it, but then I also wouldn't leave a note for the editor who'd inserted it. DonIago (talk) 22:25, 18 April 2026 (UTC)[reply]
I always subscribe to the topics I started on a user's talk page. Is it possible that Twinkle automatically subscribes to a topic that was created on a user's talk page? Then the last sentence of the warning message is not needed anymore. Or is it possible to add a checkbox in Twinkle for not adding the second last and last sentence to that warning message? WikiPate (talk) 14:46, 18 April 2026 (UTC)[reply]
There's no requirement that people leaving user warnings subscribe to the Talk pages where they're leaving those warnings, and there are probably reasonable reasons why there shouldn't be such a requirement. If you don't like part of a warning template, you can always edit the message or even create a custom version of it for your own use. DonIago (talk) 15:21, 18 April 2026 (UTC)[reply]
just to clarify: not subscribing to the whole talk page, only subscribing to the created topic of a user's page.
"edit the message" means Twinkle posts the standard message and then I edit it afterwards with a second edit?
You can! You could for example store a version of a template on a subpage of your userspace (e.g., User:WikiPate/uw-sourcing) and add it as a custom warning in your Twinkle preferences. Make sure to clear your cache before you test it in the User talk:SandboxScrubbedFalcon (talk) 18:24, 18 April 2026 (UTC)[reply]
Is it possible that Twinkle automatically subscribes to a topic that was created on a user's talk page? A preference to auto subscribe a user to talk page sections is possible (I did it in another gadget I maintain, WP:AFCH), but I don't think has been done for Twinkle yet. I also recall the API query I was using not being designed specifically for this use case, so had some challenges.
Or is it possible to add a checkbox in Twinkle for not adding the second last and last sentence to that warning message? Changes like this would first need to be made to the template itself. And would need consensus since your workflow is non-standard. –Novem Linguae (talk) 22:18, 18 April 2026 (UTC)[reply]
Another thing is: When putting the link of "Difference between revisions" into the "linked page" input field of Twinkle, it looks like this:
The advantage is, that the user does not need to find the exact edit by themselves, especially when the user made several edits in a row. The user can more easily restore the deleted content and provide a reliable reference. WikiPate (talk) 07:18, 19 April 2026 (UTC)[reply]
I think that's a usage issue on your side. If you revert someone and, from the page with the revert, go to the Talk page of the editor for whom you wish to leave a warning, the appropriate link will automatically populate. If you don't do it this way or otherwise populate it yourself, then it's incumbent on you to enter the link in the format in which you wish it to appear. DonIago (talk) 08:12, 19 April 2026 (UTC)[reply]
i want this code to be added into Twinkle:
if the Twinkle user adds https://en.wikipedia.org/w/index.php?title=name of article&diff=prev&oldid=oldid into the "linked page" input field, then format it like this: [https://en.wikipedia.org/w/index.php?title=name of article&diff=prev&oldid=oldidname of article] WikiPate (talk) 08:31, 19 April 2026 (UTC)[reply]
Would need to be changed in the template first. But this is non standard usage. It might make more sense for you to just switch to the standard usage, which is putting the page title instead of a diff URL. That is, instead of trying to change Twinkle and templates for 50,000+ users, instead just change the approach for 1 person. –Novem Linguae (talk) 12:18, 19 April 2026 (UTC)[reply]
@Novem Linguae: How do I add merge tags to drafts? After not finding the merge tags under "Tag", and being lost for a long time, I found this discussion. Jay 💬14:06, 2 May 2026 (UTC)[reply]
Not NL, but I've been working on these issues also. The old merge tags are slated to become wrappers of {{AfD}}, so probably not useful for drafts. You could consider a WP:BOLDMERGE or sending the draft creator a message encouraging them to do the merge boldly? I've been working on a new {{Consider merging}} template that's more similar to {{Notability}} in that it suggests a merge for a particular reason without adding it to a backlog (per the PAM/AfD merge RfC). The usefulness of that last option is still being discussed elsewhere. ScrubbedFalcon (talk) 14:58, 2 May 2026 (UTC)[reply]
The new XfD module seems have a couple of relatively minor issues:
When editors set a redirect as the target the module doesn't place the {{merge from}} template on the proposed destination article (the redirect target) as intended. See for example this nomination which nominated the article for merging to this redirect. I've fixed the issue manually for now in this case. I see two possible solutions:
Adjust tagTargetPageWithMergeFromTag to follow hard redirects.
Forbid setting redirects as the target. Is there a redirect page object that twinkle already parses that would make creating this warning relatively easy?
The edit summary when twinkle places the merging version of the template still reads Nominated for deletion; see [[Wikipedia:Articles for deletion/...]]. I think this should be a relatively easy fix on line 1290 of the xfd module to pass the value of the outcome variable into the edit summary. So, something like pageobj.setEditSummary('Nominated for ' + params.outcome + ' ; see [[:' + params.discussionpage + ']].');
@Novem Linguae: I have edited WP:WARNING, see Wikipedia talk:Template index/User talk namespace#Regarding uw-login. The current editing while logged out policy reads If you have concerns that a temporary account is being inappropriately used by someone with a registered account, you can give the temporary account notice of this policy ({{subst:uw-login}} is available for this purpose) so if the template once was used to discourage logged-out edits overall, it no longer should be. If you feel a change to Twinkle to match this is warranted, and assuming my version remains stable, my contribution is "Making potentially controversial edits while logged out". Regards, CapnZapp (talk) 15:48, 8 May 2026 (UTC)[reply]
Thanks, but I'm not using Twinkle. Please consider that ticket yours. That's why I left the decision in your hands. I don't know how close tabs Twinkle keeps on the various policies and what not its source code phrases are based on, so I posted this talk section in anticipation of giving a heads-up something that appeared connected to Twinkle changed. Cheers CapnZapp (talk) 10:35, 9 May 2026 (UTC)[reply]
I find that reply a bit confusing. You're the one that wants the change, so it's up to you to tell me if I summarized your request correctly in that ticket or not. –Novem Linguae (talk) 15:15, 9 May 2026 (UTC)[reply]
I am informing you and everyone reading this talk of a change I made (that appears stable) to how a template is described by Template index/User talk namespace, User:Novem Linguae. If you feel it would be useful to reflect this in the Twinkle tool, you are welcome to make the change. I leave the details of how you accomplish this up to you and other Twinkle users. The new wording would be "Making potentially controversial edits while logged out". Best regards, CapnZapp (talk) 16:29, 9 May 2026 (UTC)[reply]
Feature request - open Welcome instead of Warn automatically
When you use Rollback on an edit, preferences can be configured to automatically open the editor's talk page and open the Warn dialogue box. Is it possible to enhance this feature, so that when the user talk page doesn't yet exist, Twinkle opens the Welcome menu instead of the Warn menu?
Personally, I would like the following (I know others may want it to work different, just providing an example of what I mean):
User talk page exists - open Warn menu
User talk page doesn't exist (registered editor) - open Welcome menu
User talk page doesn't exist (Temporary Account) - open Warn menu (perhaps configurable in preferences?)
I'm not sure this is a good idea. If you are rolling back someone's edits and then visiting their user talk, it is usually to warn them. We could create an option to both warn and welcome, but that's getting a bit complicated on the coding side, so may also not be a good idea. –Novem Linguae (talk) 11:53, 12 May 2026 (UTC)[reply]
Well yes - but if it’s a newly registered user, it’s generally good practice to leave the appropriate welcome template rather than a warning template… for example if the editor made an unsourced change, I’d be leaving {{welcome-unsourced}} instead of {{uw-unsourced1}}Danners430tweaks made11:56, 12 May 2026 (UTC)[reply]
I noticed that when admins block with this reason and with TPA revoked, the block template doesn't include the |notalk=yes parameter but it seems to do so for all other block templates. This probably needs to be fixed. Here is an example of this bug. --Prothe1st (leave me a message)-- 21:51, 9 May 2026 (UTC)[reply]
So I'm fighting vandalism. Sometimes. Or most of the time. And I mostly assume these edits are bad faith because of a bug: the button is not appearing. I checked my preferences and the button won't appear, even if I saw other users reverting edits starting with "Reverted good faith...". It's probably because I don't have rollback rights (manual reverting is still occasionally helpful), but what I'm seeing looks something like this:
To my knowledge, that's just simplified for logs (see how it also doesn't include an option to welcome). I don't have rollback either, and it lets me do both buttons. You just have to look at the diff itself to do AGF rollback. 🫀 Crash // Organhaver ( it / he | talk to me, maybe? ) 23:32, 10 May 2026 (UTC)[reply]
An editor has been offended, perfectly reasonably, by the edit summary of General note: Image-related vandalism in articles on [...] when I gave them a good faith {{uw-image1}} warning using Twinkle.
Although the wording of templates uw-image2 and uw-image4 both use the term "vandalism", the text of uw-image1 itself only says that an image appeared to be irrelevant to the article or violated the image use policy, and all level 1 templates assume good faith. (Even Twinkle's edit summary for uw-vand1 does not use the word "vandalism"!)
Looking at {{COI}}'s implementation, it seems like it forces the discussion to take place on the talk page, while {{AI-generated}} offers both options. How do you envision both to be set up? Two different text fields, or one text field with two options to post (in which case we'd have to make a choice between inline and free-form text field)? Chaotic Enby (talk · contribs) 23:40, 17 May 2026 (UTC)[reply]
The implementation of some templates like {{Expert needed}} give a choice between a reason and a talk page header, as two different fields. Presumably, giving the user a choice between reason and free-form talk page section would be the best here. Chaotic Enby (talk · contribs) 23:42, 17 May 2026 (UTC)[reply]
Yes, I imagined there being two optional text fields: one provides a short description of the issues (to fill in |reason=), and one provides a way of automatically starting a talk-page discussion (for lengthier explanations). So it might look like the {{Expert needed}} set-up, but works like the {{COI}} implementation and helps editors skip a step by starting the talk page discussion for them.
Thanks a lot, that's what I've been coding so great to hear. Well by "coding" I really mean copy-pasting and adapting something that's half made of JSON but hey! That counts! Chaotic Enby (talk · contribs) 23:54, 17 May 2026 (UTC)[reply]
There is very little that can be done mechanically to the template that will help me. What would help is getting people to not remove it without actually fixing the issues, and it would also be nice to not have to create ~4,500 more pointless talk page templates. It would also be even more nice to turn off the bot that keeps moving this under "Multiple issues," which makes the "reason" parameter go away, and I have been yelled at before for not including it. It would be nice to not have to play whack-a-mole with a bot. Gnomingstuff (talk) 00:48, 18 May 2026 (UTC)[reply]
So here's where I'm at right now. Functional, but the aesthetic aspect of having both text fields in different styles is a bit jarring. Although at the same time a free-form text field wouldn't work for a banner template parameter, so... I guess that's the best compromise? Chaotic Enby (talk · contribs) 00:02, 18 May 2026 (UTC)[reply]
I mainly participate in RfD and MfD, but recently wanted to speedy rename a category I created.
I literally have no clue where any of the things for that are in Twinkle. I'm pretty sure they exist, as I searched in archives, but I don't know where it would be in the menu. Also glanced at my Twinkle preferences, don't see anything I could've turned off. Yikes! Had to do it manually.
For blocks, stop redirecting to user talk page after? This has been proposed on GitHub and would like to make sure there's consensus. Thanks. –Novem Linguae (talk) 10:12, 18 May 2026 (UTC)[reply]
Seems sensible, though I usually start doing something else or reload the page before Twinkle has the chance to redirect me anywhere. Toadspike[Talk]15:04, 18 May 2026 (UTC)[reply]
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.
A Twinkle feature to automatically ignore a local list of users during notification has been repeatedly requested, with both support and opposition. Should such a feature be implemented, and how? –LaundryPizza03 (dc̄) 17:18, 19 May 2026 (UTC)[reply]
It is possible that there are more to uncover, including proposals not specific to deceased users. (The situation that led to my own proposal is unwanted CfD notifications to a user who is topic banned from categories.) –LaundryPizza03 (dc̄) 17:18, 19 May 2026 (UTC)[reply]
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.
i recently changed a template called 'db-gs-notice' and that's there in twinkle standard installation. Reason for change is in my edit summary ~2026-29967-83 (talk) 08:20, 21 May 2026 (UTC)[reply]