This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
Hi! When using Twinkle to report a sockpuppet to WP:SPI, duplicate listings are sometimes created; this has happened to me several times, most recently today. Is there some way that the tool could be set up to check whether the username being reported is already present in the SPI (or the archive thereof), and in that case warn the reporter? – somewhat as it already does when trying to add a user talk-page warning that's already been added. Many thanks, Justlettersandnumbers (talk) 15:55, 11 December 2023 (UTC)
Looks like we've already got a ticket here. Thanks for reporting though. It's good to see when issues are popular requests. Then hopefully we can prioritize them. –Novem Linguae (talk) 16:19, 11 December 2023 (UTC)
Sometimes, I have used Twinkle instead of Ultraviolet for anti-vandalism, and have noticed that Twinkle has substantially less built-in templates compared to Ultraviolet/RedWarn, including some important ones like ((uw-coi)). Can these be added? Rusty4321talkcontribs22:59, 18 October 2023 (UTC)
Please change “Blatant WP:NOTWEBHOST violations”
to “A non contributor violating WP:NOTWEBHOST”.
The hard criteria for U5 is that the user is not a genuine contributor to Wikipedia.
If the user is a contributor, it doesn’t matter how blatant the NOTWEBHOST violation, it has to go to MfD. SmokeyJoe (talk) 00:48, 18 January 2024 (UTC)
Thanks. Noting that I did that. It was a frequently recurring problem at MfD, and still occurs. This change has stuck for over a year, and I think it is a good thing. I was heavily involved in implementing U5. SmokeyJoe (talk) 01:19, 18 January 2024 (UTC)
It looks like there's currently no way to nominate pages in the Help or Wikipedia namespaces for merging, because the merge function is under the tag menu, which appears only for articles. That's unfortunate, given that there are plenty of projectspace pages that could use merging, so we want to make it easy to suggest doing so. ((u|Sdkb))talk01:57, 19 January 2024 (UTC)
It says "((WikiProject Women in Red Invite)): welcome for users with an intrest in writing about women" instead of "((WikiProject Women in Red Invite)): welcome for users with an interest in writing about women" when looking at WikiProject welcomes. - The Master of Hedgehogs(always up for a conversation!)18:27, 22 January 2024 (UTC)
Would it be possible to add another option to the 'Categories for discussion' action dropdown menu? Often, I come across a category that isn't a notable intersection, so I need to indicate both parent categories. The issue is that the current merge option only allows selecting one category. As a workaround, I've been using the split option to propose what are essentially dual merges, enabling me to identify both categories.Mason (talk) 23:42, 14 November 2023 (UTC)
@Smasongarrison. Can you provide a diff of what you'd like Twinkle to write? Is a second parent category supported by whatever templates are being used here? Is this proposal to add a "Target category 2 (optional)" box to the CFD form in Twinkle? Thanks. –Novem Linguae (talk) 06:55, 15 November 2023 (UTC)
Sure! The split option supports a 2nd category already. So the proposal is either to add an optional 2nd category to merge, or create a nearly identical copy of split, and call it dual merge. (I don't know which would be easier to implement on the backend). Here's a diff of my workaround: [1]. The only difference would be to change the ":* Propose splitting" to say ":* Propose dual merging". Here's an example of the solution [2]. (I became very lazy about changing the word to split, so I had to dig around for an example.) Mason (talk) 13:03, 15 November 2023 (UTC)
Hi Novem Linguae, I saw that the issue was marked as complete last week, but the warning isn't showing up in Twinkle for me. In the file changes at #1938 (where the change was implemented) the template name is misspelt as "uw-lonsd"; perhaps that's causing the issue? Liu1126 (talk) 00:16, 29 January 2024 (UTC)
Can't scroll through options in user welcome and tagging dialogs
I think this is new--I'm pretty sure I've been welcoming users and tagging articles from my phone all along. But today in both dialogs, in Chrome on Android (Samsung Galaxy S10) I was unable to scroll the issue list. Swiping just scrolled the article. I couldn't grab the scrollbar either, though as far as I know that's normal since I don't normally have any reason to do that. Largoplazo (talk) 18:00, 3 February 2024 (UTC)
Is there a way to add an option so that warnings added to user talk pages via Twinkle result in subscribing to the particular month level 2 heading that is created, in lieu of adding the talk page to one's watchlist? Thanks, voorts (talk/contributions) 17:22, 15 February 2024 (UTC)
Feature request: Do not display username in ES if "offensive username" is ticked
Recommend using a default string like "Adding [Redacted Offensive Username]" verbatim in ES. It just creates something that will need to be revdel'd after since there's no way to uncheck it after, OR give us a checkbox to optionally redact the username from the ES if offensive username is checked. DarmaniLink (talk) 05:25, 19 February 2024 (UTC)
Yes it's in twinklearv ::aivPage.setEditSummary() and ::uaaPage.setEditSummary(). I'd also like this, along with wider adoption of this practice, however, I should point out that the edit will still probably need to be rev-deleted due to its content. Still, it'll be one less redacted edit summary for the reporting user, and probably one less combination of tickboxes for the admin to deal with. -- zzuuzz(talk)16:12, 19 February 2024 (UTC)
Errant notifying IP addresses
I recently nominated a category for renaming, and Twinkle dutifully notified the category creator, which was an IP address...that created the category in 2005. The chance of that message reaching the actual creator is somewhere between negligible and negative. Accordingly, I'd propose that Twinkle disable notices to IP addresses when the relevant action was in the distant past. ((u|Sdkb))talk17:27, 7 February 2024 (UTC)
Probably, but for registered users no harm is done such as would justify the effort to modify the code to create this exception. It's different an IP article creator where the next person to arrive with that IP address won't know what it's about. For IPs, it isn't clear to me that a warning is usually worthwhile even a month later, though there are unregistered users with static IPs. Largoplazo (talk) 17:20, 8 February 2024 (UTC)
I think the current system of always notifying whoever created the first revision of a page, even if they did it decades ago, is acceptable. It's simple code, a simple workflow, maximizes the chances of notifying the creator, and minimizes complaints about not notifying the creator. –Novem Linguae (talk) 19:27, 19 February 2024 (UTC)
@Clayoquot. Any changes needed to Twinkle? Did you change any template names, parameter names, etc? If you just changed template prose, probably doesn't affect Twinkle :) –Novem Linguae (talk) 21:35, 23 February 2024 (UTC)
Are all categories soft redirects instead of regular redirects? (I seem to remember that they are, but I could be wrong.) If they are, can we just turn off the tag module completely for categories? –Novem Linguae (talk) 02:55, 26 February 2024 (UTC)
Yep, that's my understanding also, per WP:CATRED. The tag module already seems to be disabled for normal (non-redirected) categories, so - as far as I can see - I think it would be okay to disable it for category soft redirects as well. All the best, —a smart kitten[meow]03:04, 26 February 2024 (UTC)
CSD: Do not send notifications of speedy deletions to creators of user talk pages that are not the user in question
Recently, I CSD'd a talk page and a user who first templated the vandal in question got a template on their talk page. To avoid from needlessly spamming other peoples user pages and have the template blame them for the vandalism of bad actors on their own talk page, do as the title says. DarmaniLink (talk) 08:15, 26 February 2024 (UTC)
DarmaniLink nominated a user talk page for U5 deletion (which was an invalid action in the first place as it was a just a copyvio situation, but irrelevant to this post), so the creator of that user talk page got a notification. Technically TW is doing exactly what it should be doing, and I question whether it makes sense to change that. First, user talk pages are very rarely CSD candidates, and second if you are nominating a user talk page for deletion (under a valid CSD criteria) chances are good whoever created that page should know about it.
In other words, if User A creates the user talk page of User B with a vandal/copyright post that should be deleted, they should probably get a notice. If User C just happens to make a vandal/copyright post on their own talk page, I do agree the creator of that page shouldn't get a notice, but that page also shouldn't be nominated in the first place. Primefac (talk) 13:02, 26 February 2024 (UTC)
FWIW, i got a filter hit and saw he uploaded the entire script for the mario movie to his own userpage and assumed he was using it like a pastebin DarmaniLink (talk) 18:33, 26 February 2024 (UTC)
I recently came across this thread from 2021, which seemed to have support for the idea of a talk-page category (or similar) that would opt users out of receiving Twinkle notifications (e.g. for XfD discussions); which could be included within the ((Deceased Wikipedian)) & ((Not around)) templates. As the pull request linked from that thread was closed as stale, and I can't find a relevant issue on GitHub, I wondered if anyone had any information on the current status of such a feature.
One thing to consider is that sometimes people follow a deceased person's talk page to catch these types of notices. They then work to improve the content in that user's memory. I've found this with several different users when I've nominated old drafts for G13 deletion. Hey man im josh (talk) 03:28, 27 February 2024 (UTC)
@Hey man im josh: Fair point - thanks for mentioning that,/gen it hadn't occurred to me. I'm not so sure now that this would be a good feature. All the best, —a smart kitten[meow]03:44, 27 February 2024 (UTC)
Every so often, I'm having to revert a new user's (or IP user's) apparent good faith efforts that have lots of problems, but none of the "problem" Welcome templates that Twinkle provides cover this scenario sufficiently. So, I have to use ((Welcome-suboptimal)) or ((Welcome-anon-suboptimal)) manually outside of Twinkle. Could these be added to the Twinkle selection list? Stefen Towers among the rest!Gab • Gruntwerk19:54, 5 March 2024 (UTC)
The instructions said to notify Twinkle if there were "breaking changes" but there weren't so I didn't. But I notice that although direct transclusions of ((Translation request)) (ex-((Needtrans))) at WP:PNT are working, most transclusions are not, and I presume those come from Twinkle. The edit in question is rev. 1209066449. Note that there are a couple of edits following that one; they affect solely the presentation of the template page itself, generating the top-of-page example you see there.
P.S., Maybe that wording about "breaking changes" should be modified, because I know what that term means and would have notified Twinkle earlier had the change fit that category, but it does not: new functionality which is fully backward-compatible is not breaking. Unless the problem lies elsewhere, such as in the redirect? Thanks, Mathglot (talk) 03:12, 7 March 2024 (UTC)
@Mathglot. Thanks for the report. Would you be able to link a broken transclusion diff that Twinkle placed, and then also a diff of someone fixing it? That would help me figure out what code changes are needed here. Diffs from WP:PNT preferrably, rather than from Template:Translation request. Thank you very much. –Novem Linguae (talk) 06:14, 7 March 2024 (UTC)
Not broken, in the sense of producing nonsense, just producing the old, valid output that it always used to. Nothing wrong with it, and not harmful in any way, just lacking some useful, new functionality. And since it is (presumably) substed and doesn't leave a hidden text trace of who produced it, I can't be sure that it is even Twinkle at all responsible for it; I just assumed so, since some source continues to produce the old-format output, so what else could it be? (Could even be someone directly typing text onto the page that looks like template output; unlikely, but not impossible.) While looking around for an example for you just now, I realized that the new template version doesn't have proper subst-protection, so let me go fix the Template so you have clean output to compare with. But n the meantime here are a few links that I presume are Twinkle, in case you want to look at these: § Cerveza Cristal (Chile), § Heiligenhoven Castle. I'll get back to you soon when the template is ready. Mathglot (talk) 06:36, 7 March 2024 (UTC)
Hm, won't be quite as quick as I thought. Subst-protection in Template:Translation request actually seems to be okay as is, at least at first glance, so the problem likely lies in one of the newly invoked templates that was not used before. There are two such: ((ISO 639 name)), which appears to be properly subst-protected , and ((Sitelink)), which is not. So to get ((Translation request)) to work, I'll have to convert Sitelink to be substable, and it's not one I've worked on before. In principle it should be mechanical and mostly about making sure I don't break anything; but there are a lot options and there is no sandbox or testcases. I may have to ask for help with that one. I'll get back to you on this. Adding Ponor, who is familiar with ((Sitelink)) and may be able to convert it more easily and quickly than I could. Mathglot (talk) 06:58, 7 March 2024 (UTC)
Twinkle edits can be easily identified because it uses an edit tag. So Cerveza Cristal (Chile) was indeed placed by Twinkle (diff). OK, so now we have the first diff. Is there anything wrong with this diff that needs fixing? The code Twinkle is using to place that diff is
What I don't quite understand, is why Twinkle doesn't already produce the right output, as it appears to be just generating the code for a call to Needtrans, and since the new output you see above doesn't depend on any new parameters but is derived directly from existing params and Wikidata, I don't quite see why Twinkle would produce different output in that case. (Note that the first article appears to have been renamed to Cerveza Cristal at en-wiki.) This doesn't obviate the need to subst-protect ((Sitelink)), but it does raise a new question of why Twinkle isn't already picking up the new format. Or perhaps, the subst issue blocks it, somehow? Mathglot (talk) 08:19, 7 March 2024 (UTC)
Hmm. I'm still a bit unclear about what the bug is. A diff of the wrong Twinkle output, and a diff fixing it, would be helpful. –Novem Linguae (talk) 08:35, 7 March 2024 (UTC)
Can you induce Twinkle to add two examples below, one for |pg=Cerveza Cristal |language=Spanish |comments=Further remarks., and one for |pg=Heiligenhoven Castle |language=German ? Mathglot (talk) 08:57, 7 March 2024 (UTC)
Yes, that produced exactly the correct result—although unsubsted, for reasons previously discussed—but note that the rendered-page output is exactly like the collapsed examples above. So the mystery has shifted from the earlier, 'why isn't Twinkle picking up the latest changes?' (answer: it is picking them up), to: 'Why did the two examples cited end up without the new functionality of linked foreign page at WP:PNT when placed earlier by users using ((Needtrans))?' I don't know the answer to that new mystery, but we don't have to resolve that, because it appears to be working now.
As an aside: I just went back to WP:PNT and noticed that someone just added § Potato production in France using ((Dual fluency request)) (per the hidden comment you added only hours before—great timing; thanks for that!) and is tagged Twinkle in history, that isn't invoking the new functionality, either. That is understandable, as ((Duflu)) is its own template (formerly merged to needtrans then unmerged, for reasons which need not concern us here). ((Duflu)) should have similar functionality added as happened here, and once the subst issue is clarified, I'll add it, or leave a Talk message about it.
I apologize that this got into the weeds a bit and has been confusing and lengthier than I expected. The bottom line is this: we still need to make ((Sitelink)) substable to get ((Needtrans)) up to par (nothing to do with Twinkle) and I doubt you will have to change anything in Twinkle at all for this template, it will just work. Same thing for ((Duflu)) once it is updated to match. I think the right stance now for Twinkle folks regarding these two, is "watchful waiting". It bears monitoring, but I don't expect you'll have to do anything at all to be compatible and in sync. Mathglot (talk) 21:58, 7 March 2024 (UTC)
Looks like Ponor is not around, so I went ahead and added subst protection to ((Sitelink)). Now, substing ((Needtrans)) looks okay, via this brief live test in WP:PNT. This should complete this upgrade, and I don't expect any further changes will be required at Twinkle, but please watch with one eye for a little while. Thanks, Mathglot (talk) 02:34, 8 March 2024 (UTC)
Non-breaking changes have been made to ((Dual fluency request)) to parallel similar changes to ((Translation request)) as discussed above at § Template:Translation request. I understand "non-breaking" as meaning that nothing will go wrong if you make no changes at the Twinkle end; however, the new version is more powerful, as it retrieves the foreign-language article automatically via Wikidata linkage. Parameter |orig= was formerly required in order to provide a link to the foreign article, but now it is no longer required and its use is discouraged. The |orig= parameter is still available (not deprecated) and if used, will override the Wikidata page link with whatever the user provides as the param value, so it exists solely as an override and to maintain backwards compatibility. If automatic processes generate the transclusion, then probably all you have to do is drop the use of parameter |orig=; everything else can remain the same; however nothing will break if you leave everything as is. If you do make the change, the result will be improved output at WP:PNT. Mathglot (talk) 01:45, 23 March 2024 (UTC)
@Mathglot. Thanks for your work on this. According to the program code, Twinkle posts in the format ((subst:duflu|pg=' + Morebits.pageNameNorm + '|Language=' + (lang || 'uncertain') + '|Comments=' + reason.trim() + '))~~~~. So I think it only uses the pg, language, and comments parameters of the template, and doesn't ever use orig. So probably no changes needed on Twinkle's end. –Novem Linguae (talk) 02:15, 29 March 2024 (UTC)
That sounds right to me. We should watch as the next few Duflu's from Twinkle come through to WP:PNT. I think the last one was this one, which says, "The initial language of this article was de.". I noticed another one just above it which also uses a lang code instead of a language name; could this be something in the Twinkle doc, or does Twinkle just point to the template doc and users are misreading/not reading it? Another upgrade to Duflu could eliminate this problem by emulating another change at Needtrans, which interprets lang codes if the user uses one by mistake instead of fully spelling out the language. Mathglot (talk) 02:38, 29 March 2024 (UTC)
Another upgrade to Duflu could eliminate this problem by emulating another change at Needtrans, which interprets lang codes if the user uses one by mistake instead of fully spelling out the language. This sounds like the way to go if it isn't too time consuming. In an ideal world, there's no reason these two similar templates should have divergent behavior for the same collected parameters. –Novem Linguae (talk) 04:12, 29 March 2024 (UTC)
Twinkle placement of RFDs when header gets messed up.
@Steel1943. Hey there. Re this ping. Twinkle's current algorithm is to place entries directly below <!-- Add new entries directly below this line. -->. In the situation on that RFD page, a new user placed their entry above that comment, ignoring the instructions. My recommended fix is to move all entries below that comment. I am disinclined to change Twinkle's algorithm since it's simple and it usually works fine. Hope that makes sense. –Novem Linguae (talk) 02:01, 29 March 2024 (UTC)
@Novem Linguae: Of course (it makes sense). I was, more or less, suggesting that whatever XFDcloser does to determine the top of the page when relisting, somehow incorporate that into Twinkle with posting new RFDs since whatever XFDcloser does is not reliant on that hidden text whereas Twinkle is. Steel1943 (talk) 04:56, 29 March 2024 (UTC)
COI template
Documentation for ((COI)) says (formatting per original):
Like the other neutrality-related tags, if you place this tag, you should promptly start a discussion on the article's talk page to explain what is non-neutral about the article. If you do not start a discussion, any editor will be justified in removing the tag without warning.
[...]
Do not apply this tag simply because you suspect COI editing, or because there is or was a COI editor.
Can Twinkle be made to notify users of these terms, or at least to nudge them to comment on the talk page immediately after applying the template? There may be other templates with similar conditions, so a generic fix might be best. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits16:41, 15 March 2024 (UTC)
Often IP user's will add information that appears good faith, but could be problematic or suspected of lacking a neutral point of view. I would like to welcome these IP user rather than scare them off with a warning template. Could ((Template:Welcome-anon-unsourced)) added to the Twinkle selection list? It is a more friendly and instructive way of welcoming users rather than ((Template:Welcome-anon-unconstructive)). Apologies if this has been settled before. Classicwiki (talk) If you reply here, please ping me.19:12, 29 March 2024 (UTC)
I noticed that the Twinkle automated system for non-English welcomes does not support some languages for which we have a template, such as Italian and Hindi. Can this be fixed? Kind regards 14 novembre (talk) 🇮🇹 11:19, 3 April 2024 (UTC)
Sounds good. I created a ticket. Same advice as in the section above though. You can just add these to Twinkle via your Twinkle preferences. –Novem Linguae (talk) 14:40, 3 April 2024 (UTC)
It is in the speedy deletion procedure. Summaries for administrators are always "speedy deletion of <pagename>" while for all others (including me) it is "speedy deletion nomination of <pagename>" Why are summaries different for admins and others? Toadette(Let's talk together!)22:37, 3 April 2024 (UTC)
@ToadetteEdit: Admins have the option of directly deleting the page with Twinkle, rather than simply nominating it for deletion. When this happens, Twinkle will leave a different warning template on the user's talk page that's been rewritten to inform the user that the page had already been deleted. For example, see the difference between ((Db-vandalism-notice)) and ((Db-vandalism-deleted)). —k6ka🍁 (Talk · Contributions) 12:32, 4 April 2024 (UTC)
Good day, this is a courteous message to inform Twinkle’s maintainers and users that:
Implemented: Revision and improvement to the body text in the warning message for ((Uw-copyright-new)), a 'Single-issue warning' in Twinkle.
Not sure. This should only affect Twinkle, and its users, if the boldtext parameter is used. In such a case, string of text in |boldtext=string of text may no longer function as expected as the body text at ((Uw-copyright-new/body)) has changed. But it seems it would be used more by users who would add the template manually than via Twinkle.
Checked: Checked testcases and tried implementation with Twinkle in many ways as possible. Functioning as expected.
I have noticed that when users respond to a welcome message that I have left using twinkle, I don't seem to get notified. Is there a way for me to fix this? Gaismagorm (talk) 20:00, 7 April 2024 (UTC)
For file maintenance, I suggest adding both ((Nominated for deletion on Commons)) and ((Deleted on Commons)) among the Twinkle options, as useful notice tags that the Commons copies of local files were nominated for deletion or deleted.
This is helpful in conducting future undeletion of files, in which the Commons copy should be requested for undeletion instead of transferring the local copy to Commons, as the transfer action effectively overwrites the deleted Cpmmons copy of the same file name. JWilz12345(Talk|Contrib's.)03:04, 8 April 2024 (UTC)
@Novem Linguae thanks for opening the suggestion at GitHub. By the way, I also suggest the tags will be automatically placed above the information fields, like this. If the template is found at the lower part of the description page, some future file movers may not notice it and still conduct transfer of the said file even if there is an identical copy on Commons that can be simply requested for undeletion. JWilz12345(Talk|Contrib's.)10:19, 9 April 2024 (UTC)
@JWilz12345. Do you know if this is the "normal" spot to put the template? Is there an MOS:FILEORDER somewhere? Do we need to get consensus for placing these tags in an odd spot? –Novem Linguae (talk) 21:11, 12 April 2024 (UTC)
@Saqib. Is this for placing warnings on user talk pages? Something else? Do you have a diff you could provide of what Twinkle currently does, along with what you'd suggest changing the text to? –Novem Linguae (talk) 21:13, 12 April 2024 (UTC)
@Novem Linguae: I meant is there a way to customize the title when posting a warning message on a user talk page, instead of using the default title based on the current month. --—Saqib (talk | contribs) 17:26, 13 April 2024 (UTC)
Developers might be interested in this: I created a patch tonight to change Twinkle from its custom eslint rules, to use the plugin eslint-config-wikimedia. Eslint-config-wikimedia is the standard wikimedia set of linter rules. I think there's some good advantages to switching to the standard wikimedia linter (discussed in more detail in the ticket). I've turned off controversial rules such as requiring spaces in parentheses, and turned off limiting line lengths to 100 characters. If there's any concerns or objections, please let me know here or in the ticket. I think getting more rules turned on via this plugin is going to be an important step in modernizing the codebase.
Note that this patch also applies all the auto fixes, which includes a conversion from var to let/const. Wikimedia grade A support appears to be firmly at ES6 now, so it should be safe to make ES6 upgrades. This new linter also includes strict rules (stricter than previously) that warn if we try to use features over ES6, which is a nice feature for making sure we align with grade A support.
Sorry that the title might not mean what you thought it means. I’ve encountered a problem many times where Twinkle brings me to the talk page of “wiki/User talk:User name/IP” which is annoying. This happens when I do the following:
Revert vandalism from diffs in Recent Changes
Warn user/IP in their talk page
Right after warning, click TW and ARV
Because the page automatically refreshes after a few seconds after warning user through TW menu, it brings me to wiki/User talk:Username/IP (note that Username/IP is the username or IP address of the vandalizing editor).
Yes, and it brings me to "wiki/User talk:Username or IP address" which is an invalid page.
The ARV screen is useful right after warning a user because it auto fills all the important details about vandalizing, so it would be helpful if it doesn't refresh if you go to the ARV screen in time. Myrealnamm (💬talk · ✏️contribs) at 14:37, 26 April 2024 (UTC)
This might be a dumb comment, but maybe... wait until the page refreshes before trying to multi-tag with TW in one set? Primefac (talk) 15:10, 26 April 2024 (UTC)
I have just verified: when I reverted vandalism and warn the user, and go to the ARV menu, Twinkle brings me to /wiki/User talk:Username or IP. Myrealnamm (💬talk · ✏️contribs) at 20:41, 26 April 2024 (UTC)
OK, I was able to reproduce this. I had to click really fast to beat the refresh though, which I think is on a timer for only 3 or 5 seconds. Ticket created. I don't plan on working on this soon, so for now you may just want to get in the habit of hitting F5 (refresh) as soon as Twinkle's status says it has posted the warning. Then do ARV after that. –Novem Linguae (talk) 06:23, 28 April 2024 (UTC)
I tried to hold esc while hitting ARV, however, once I am in the ARV page and esc is pressed, it will "close" that dialogue and bring back to the warning page (which is already open) and show another "Warning complete. Reloading page in a few seconds" under the previous. After the few seconds, it will bring me to an even more non-sense page @Novem Linguae.
I mean long-press Esc right right after "Warning complete, reloading talk page in a few seconds" for a few seconds. Then open ARV. Nardog (talk) 04:41, 29 April 2024 (UTC)
Thanks for your reply. My point is that after going to a user or IPs talk page after reverting vandalism, Twinkle knows about what happened (from “Grabbing data of earlier revision) and auto fill ARV screen, Warn screen and more. However, I believe that if I refresh the page, the auto fill is removed/cleared. @Nardog I will try that. Myrealnamm (💬talk · ✏️contribs) at 18:02, 28 April 2024 (UTC)
Vector 2022 has not (for a long time) provided styles for tables of content. Twinkle-config.js currently constructs a table of contents by hand more-or-less matching what you would have found in old Vector and in the other skins but because Vector 2022 does not send styles, the rendering ends up being more or less "basic" (see Wikipedia:Twinkle/Preferences). I would guess most other skins this displays as a "normal" table of contents.
Not sure if the best solution is to pull in all the styles Twinkle might want here (noting that all the other skins send table of contents styles basically everywhere) or what (the rules could be prefaced with .skin-vector-2022 so that only Vector gets different skinning, etc). Izno (talk) 22:01, 29 April 2024 (UTC)
My 2 cents as the closer is that it would be most convenient to place this under the "redirects" header. Mach6101:13, 3 May 2024 (UTC)
Existing tags showing up twice
The Tag portlet shows existing tags at the top. Sometimes these are listed twice, even though they're only present once in the article. jlwoodwa (talk) 23:14, 24 May 2024 (UTC)
Actually thinking about it, I think the intent to welcome makes sense, just I think that the wording is a bit off with the "problem user welcome template" as it mainly talks about article policy. Fork99 (talk) 11:01, 3 May 2024 (UTC)
I am wondering what the Unlink tool should do on disambiguation pages. Edits like this aren't really helpful: manual removal of the entire entry is the correct action, not just unlinking of the term. Perhaps it would be best to just skip disambiguation pages and tell Twinkle users to deal with disambiguation pages by hand? Ping @Liz whose edits made me notice this issue. —Kusma (talk) 16:36, 9 May 2024 (UTC)
Two things. First, Liz doesn't answer pings, so if you want her to know about this discussion you'll need to drop a talk page note. Second, there's a checklist given when unlinking, so anything with (surname) or (disambiguation) should be unchecked by the user doing the unlinking.
That said, making it uncheck those pages automatically would prevent things like this from happening as often, so I can't say that I'm opposed to the idea. I don't know a ton about the backend of Twinkle so I don't know if it would be able to detect if a page is a dab, though. Primefac (talk) 16:40, 9 May 2024 (UTC)
A third possible option would be to have an option like with WP:XFDC in which the user could specify "delink or remove entirely", but I somehow think the devs are going to throw forks at me for even suggesting it. Primefac (talk) 16:42, 9 May 2024 (UTC)
Removing entirely is often the right action for dabs, even if they don't have (disambiguation) in the title. Theoretically there might be a WP:DABMENTION elsewhere, but I would hope AfDs for such cases replaced the article by a redirect rather than deleting. There may also be rare cases where the deleted link is not the main topic (*[[Joe Redlink]], a singer with [[Deleted Band]]) but we probably want to delete those entries too. (And if the devs throw forks at us, we can use choose either version!) Certes (talk) 17:21, 9 May 2024 (UTC)
Thanks. I have not done any deletions of widely linked pages for a while, so I am not too familiar with the current interface. Unchecking dabs and dab-like pages by default seems a good first step. I will let Liz know of this discussion. —Kusma (talk) 21:26, 9 May 2024 (UTC)
Thanks for letting me know about this discussion. Since many admins tend to "specialize" in different areas, it would help to know where this problem is arising, is it with CSD-tagged articles, PRODS or pages deleted through the XFD processes. If we could specify when the behavior you find problematic is occurring, and there is some kind of consensus that this problem exists, if it's not a change with Twinkle, then it could be a matter of advising a half dozen admins to process deletions differently. For example, I only know of 5 or 6 admins who regularly handle PRODS so this might be a matter of retraining.
My only hesitation when this issue has come up before is we have to find a way of dealing this that can scale. We're not talking about checking links on a dozen articles a day but on hundreds of pages that are deleted daily. The current system is probably too blunt but I deleted an article the other day that had 94 links to other articles. While it's not much effort to scan a list of links, checking each link individually is not feasible with each page deletion. I'm not saying the current system is perfect (it obviously isn't) we are doing what we can with a decreasing number of admins. An admin I work with took a week off and the drafts that needed to be reviewed immediately piled up and we didn't "catch up" for days. I'll check back and see what y'all have to say about this. LizRead!Talk!23:53, 9 May 2024 (UTC)
On the technical side, Twinkle uses the API query ?action=query&list=backlinks to generate the list. This does not support filtering out or indicating disambiguation pages. To write a patch that filters out or indicates disambiguation pages, at least one additional API query would be needed.
To write a patch that detects (disambiguation) at the end of a title would be much easier, but would miss a lot of disambiguation pages.
I think XFDCloser is the most common source of backlink removal, since that would handle backlink removal for AFD.
In the case above, Twinkle's backlink remover is being used to help with PROD.
I'm not entirely sure what to patch here or if it's worth it since it is probably used infrequently, but am open to further ideas if someone wants to propose something specific, such as adding an "untick disambiguation pages" link to the backlink list page. –Novem Linguae (talk) 06:26, 26 May 2024 (UTC)
Twinkle's XfD nomination toolset should have a feature where it checks if the page creator is blocked from editing, and if so, skip placing an XfD notice on the user's talk page. This is an issue that I've been seeing a lot on many blocked/banned users' talk pages, where other editors have to constantly come and clean up the notices that were placed there, a good majority of them from Twinkle. — AP 499D25(talk)00:44, 25 May 2024 (UTC)
I think this has come up before, and consensus was to err on the side of over-notification. I agree with an over-notification strategy. Blocked users may get unblocked, or may be indeffed and may still want to know what is happening to their articles. –Novem Linguae (talk) 02:10, 25 May 2024 (UTC)
If anything I don't see the reason why other editors have to constantly come and clean up the notices - they do no harm. Primefac (talk) 14:24, 25 May 2024 (UTC)
I think it's better to allow user-level optouts by placing a configurable template on the talk page. By default, blocked and and even deceased users want notifications when their articles are being considered for deletion. (Not the deceased user themself, but their talk page watchers.) – SD0001 (talk) 08:54, 26 May 2024 (UTC)
Allow adding deletion sorting categories to all XFD venues
"Twinkle Rollback" includes error with articles with "Map" feature
Hello,
On this certain article, Interstate 90 in New York, when I revert multiple vandalism by someone with the "Rollback" button in Twinkle by "comparing selected revisions", it gives me a dialogue to confirm that they have made 3 edits and I would like to revert them all. However, Twinkle keeps a "map" button that is most likely unintended.
Example:
From Wikipedia, the free encyclopedia
Notice: Stopping revert.
Map
Well, I can't get a screenshot anymore, but when I clicked "Rollback" (the blue button), all the content of the article disappears (which is normal) and shows the progress of the revert. Because there were 3 edits by the same user, Twinkle will ask "This user has made 3 edits in a row. Are you sure you want to revert them all" or something similar. However, in the "progress" of the revert, it shows:
Hi, I am grateful to have Twinkle aid my anti-vandalism and anti-spam efforts. I would like a new feature: I should be able to automatically watchlist the userpages of whoever I report to AIV, UAA, etc. to stay aware of further vandalism developments. Thank you for considering this feature. Air on White (talk) 22:55, 26 May 2024 (UTC)
Doesn't it already do this? I feel like every time I file an SPI they end up on my watchlist. Or is it just for blocking? Primefac (talk) 11:39, 27 May 2024 (UTC)
According to Twinkle settings, SPI is the only user-reporting page for which it adds the userpage to your watchlist. Air on White (talk) 21:54, 27 May 2024 (UTC)