Archives

Index Archive 1 Archive 2 Archive 3 Archive 4 Archive 5 Archive 6 Archive 7 Archive 8 Archive 9 Archive 10 Archive 11 Archive 12 Archive 13 Archive 14 Archive 15 Archive 16 Archive 17 Archive 18 Archive 19 Archive 20 Archive 21 Archive 22 Archive 23 Archive 24

This page has archives. Topics inactive for 28 days are automatically archived 1 or more at a time by Lowercase sigmabot III if there are more than 12.

Just upgraded to 3.4.13, but even before with 3.4.12, no edits seem to appear in the queue, even with the all edits option. I managed to revert an edit by entering the page in the page input field, but the queue seems dead, with any of the providers XmlRcs, IRC and Wiki. Is something broken, or I have missed something? - DVdm (talk) 15:45, 29 January 2025 (UTC)[reply]

More information:

1. Using Win 10 pro.
2. The logfile says: "Wed Jan 29 23:21:02 2025: ERROR: The webserver of enwiki requires that SSL is to be enabled. Please turn SSL on and try again. If you can't enable SSL (option is grayed out) you may need to install OpenSSL libraries to your system."
3. TLS 1.2 is active
4. Turned the firewall off, no effect (!)
5. Turned firewall on again, now the Wiki and IRC providers work. XmlRcs not.
6. Have set the preferred provider to Wiki in the feed options, but after close and re-open, the provider is IRC. Config file huggle.yaml.js lists preferred-provider: 0, which I manually set to 1, now it stays Wiki.

DVdm (talk) 23:13, 29 January 2025 (UTC)[reply]

I'm having the exact same issue. I came here hoping for a fix.--Mojo Hand (talk) 15:07, 2 February 2025 (UTC)[reply]

The question is: which is the best provider? Wiki and IRC work fine, but is XmlRcs —if it works— better? - DVdm (talk) 15:41, 2 February 2025 (UTC)[reply]

Weird that XmlRcs is the default provider.--Mojo Hand (talk) 16:18, 2 February 2025 (UTC)[reply]

Having this exact same issue. --Patient Zero^talk 00:36, 6 February 2025 (UTC)[reply]

It started working again for me when I changed provider on the system tab from XmlRcs to Wiki, but it seems slower to me.--Mojo Hand (talk) 00:41, 6 February 2025 (UTC)[reply]

Done that as well Mojo Hand, and completely agree that it is now slower...! Patient Zero^talk 01:28, 6 February 2025 (UTC)[reply]

I made improvements to XmlRcs server running on wmfcloud that should make it more resilient to similar outages. Petrb (talk) 17:15, 27 July 2025 (UTC)[reply]

So I can learn more about the architecture, may I ask what kind of improvements you made? Is there a GitHub repo for this server somewhere? –Novem Linguae (talk) 13:52, 28 July 2025 (UTC)[reply]

Yes, there is a github repo here - https://github.com/huggle/XMLRCS the architecture is described here - https://wikitech.wikimedia.org/wiki/XmlRcs the changes I made are major refactoring of es2r daemon (event stream to redis) which is now more resilient to crashes. On top of that there is a new service file for systemd which restarts the service on crash Petrb (talk) 19:50, 4 August 2025 (UTC)[reply]

I've rather given up on Huggle. Are there setting that I can adjust to fix any of these?

• Report user not not open popup window, either by Icon on tool bar, User->Report user, nor Ctrl+R
• Before the problem with the popup window issue
  • "check if reported" would not work
  • Huggle would generate a duplicate AIV report for already reported vandals
• UNAA does not work
• RFPP: additions are made near the top, not at the bottom per instructions on page.
• Warnings are often put in the wrong / previous section. If there is a "March 2025" and a "May 2025" (the current month) section, Huggle will put the warning in the March 2025 section.
• On startup, one must change the provider. It would be nice if the setting was persistent.

I uninstalled and reinstalled Huggle 3.4.12 (accidently). The AIV functions seemed to work OK. The AIV window problem returned after reinstalling 3.4.13
Adakiko (talk) 01:19, 23 May 2025 (UTC)[reply]

I feel you. Huggle really needs a quality-of-life update. —⁠k6ka 🍁 (Talk · Contributions) 01:47, 23 May 2025 (UTC)[reply]

+1. I've noticed I am encountering a few of the issues here, namely that Huggle keeps generating duplicate AIV reports, and putting my warnings under the wrong headers. There is a fix for the provider issue by changing the default one in the settings (see above "Nothing in queue"), but it would be great if it just worked from the get-go. I'm also currently having issues with starting the application in the first place - details of which are on Phabricator if anyone's interested, but it involves the "you logged out" popup... Patient Zero^talk 01:56, 23 May 2025 (UTC)[reply]

I don't see any posts by the Huggle maintainers on this talk page. I'll go ahead and give them a ping: @Petrb. @Addshore. Both have some recent edits to enwiki, and Petrb has some recent commits to the GitHub repo, so that's a good sign. –Novem Linguae (talk) 17:56, 23 May 2025 (UTC)[reply]

+1 Frost 08:20, 9 June 2025 (UTC)[reply]

• Restored from archive. Would like to see some action. Adakiko (talk) 20:30, 14 July 2025 (UTC)[reply]

Hello, I feel you guys, I am not very active these days, addshore is probably in similar situation. We are no longer those young guys with loads of free time :), having a family and a full time job, there is very little time for hobbies like similar open source projects. I do start Huggle from time to time to check if it's at least working to eventually fix some critical issues, and last time I did it was working fine, but I admit these advanced features like AIV / UNAA, RFPP etc. may be broken. They relied on parsing respective pages and adding sections to them using various template black magic and this logic breaks every single time there is a major update to the layout of these pages, which is probably what happened this time too. I will have a look hopefully through the summer. Petrb (talk) 20:48, 23 July 2025 (UTC)[reply]

I fixed the RFPP bugs, but it needs an extra fix in the config page as well, but my privileges to edit it were revoked. So whoever has admin rights: we need to update the rfpp related parts, most notably these two:

rfpp-verify: '.*$title\}\}.*'
rfpp-section: 0

That will fix it. Petrb (talk) 17:12, 27 July 2025 (UTC)[reply]

@Petrb. Can you please provide a wikilink to the page needing editing? Also, in the future, you can post on that page's talk page with the {{Sudo}} template, and this will put your edit request in a queue and get the attention of the correct type of admin. –Novem Linguae (talk) 13:49, 28 July 2025 (UTC)[reply]

It's Wikipedia:Huggle/Config.yaml Petrb (talk) 19:53, 4 August 2025 (UTC)[reply]

3.4.14 was just released, it fixes most of the issues mentioned on this feedback page. Petrb (talk) 22:08, 12 November 2025 (UTC)[reply]

Thank you for all your hard work @Petrb! Cloned & compiled and will poke around more later. Nubzor [T][C] 23:59, 12 November 2025 (UTC)[reply]

Wow! Thank you @Petrb! I wasn't expecting this. Much appreciated. Adakiko (talk) 11:46, 13 November 2025 (UTC)[reply]

As I wrote in WP:VPT#Compatibility of gadgets, scripts, bots, and edit filters with temp accounts, I wanted to ask you to check if AntiVandal is compatible. Here's our documentation for developers; in particular, see the section How should I update my code?. Thank you! SGrabarczuk (WMF) (talk) 08:53, 1 September 2025 (UTC)[reply]

Hello support for this feature is already integrated and will be available in next release. Petrb (talk) 18:34, 11 November 2025 (UTC)[reply]

@Petrb Quick question for you--Is there a setting to disable the "Shared IP" notice that gets automatically added to warnings? Or is that something perhaps that can be removed in a future release due to the move to temp accounts? Like here Special:Diff/1321843589. Again, thank you for all your work on this project still. Nubzor [T][C] 00:16, 13 November 2025 (UTC)[reply]

Yes, this is taken from the configuration that Huggle uses, it's just necessary to remove last 2 lines in the config file:

shared-ip-template-tag: '<!-- Template:Shared IP advice -->'
shared-ip-template: '{{subst:Shared IP advice}}'

I already requested template editor permissions so that I can fix this kind of stuff myself - https://en.wikipedia.org/w/index.php?title=Wikipedia:Requests_for_permissions/Template_editor&oldid=1321764358 Petrb (talk) 08:54, 13 November 2025 (UTC)[reply]

Given that temp accounts are technically IP accounts and it's no longer possible to use true IP account I think that this entire template could be also just modified accordingly, but not showing it at all is probably also fine. Petrb (talk) 08:55, 13 November 2025 (UTC)[reply]

@Petrb Thank you for already working to fix it. Looks like they did just grant you those permissions, so congrats also! :) Nubzor [T][C] 15:48, 15 November 2025 (UTC)[reply]

Great, now I can finally edit the page I created again :) I will fix it right now. Petrb (talk) 23:03, 15 November 2025 (UTC)[reply]

I'm currently working with Arcrev1 and helping to answer their questions regarding Huggle and setting certain options in order to filter the queue to only show edits given certain scoring thresholds and in the manner that Arcrev1 would like. I have questions regarding the "minimum score" and "maximum score" settings and a few things that I observed, and wanted to get some input regarding what I'm correct (and very likely incorrect) about regarding them.

The discussion between Arcrev1 and I can be read by navigating here. To summarize: I don't set any minimum or maximum score thresholds in my Huggle settings when use it. When I messed around with the minimum and maximum score options in order to try and assist Arcrev1 with their questions and request for advice, I noticed that setting a minimum score threshold (I just left the value at "0") reduced the number of edits that would appear in my queue by at least 80% compared to when I had the option turned off. That seemed completely fine to me; realistically, I revert anywhere from 5% of the edits that appear in my queue to 15% of them depending on the time of day, peak usage hours on Wikipedia (typically high during the day in the US and low during the evening in the US), and if schools in the US are in session or not (lol) - which leaves 85% to 95% of edits that I don't revert being added to the queue.

However, when I turned the minimum score option off and instead used the maximum score option (again, the value was just left at "0"), I saw the exact same result: a significant drop in the number of edits that would be added to the queue in the first place and by at least 80%. I would expect that the number of edits being added would remain at about ~80% compared to when the option is turned off, since setting the minimum score dropped the number of edits by about that amount. On top of this, after allowing a few moments for the changes to the settings to "propagate" (if that's even necessary) and after clearing the queue, I'd notice that some edits with ORES scores in the negative would be added to the queue despite having a minimum score threshold set to "0". I also noticed the same thing in the other direction when using the maximum score threshold.

What gives? Am I looking at the wrong "ORES score" with each of the edits that are in the queue? With an edit that has Meta information - ORES Score: -50 ORES Goodfaith: 216 Tags: wikieditor, I'm looking at that -50 score and with the assumption that this is what Huggle uses, and that the lower the ORES score, the less likely that the edit is problematic or disruptive, and vice versa for the other direction (positive ORES scores). Is this correct? Am I doing something wrong or looking at the incorrect information? Is there any input or assistance that anyone can offer in regards to these settings and why the results are so drastic regardless of which option I'm using?

Thanks to anyone and everyone in advance for reading through this discussion and for any input or information that can be provided. :-) Best - ~Oshwah~^{(talk) (contribs)} 12:21, 6 September 2025 (UTC)[reply]

Update: I managed to take a bit more time and mess around with these settings again in Huggle. After I expanded the threshold to be much wider away from being simply "0", I'm beginning to see better results now. I think that starting at "0", and then moving "the needle" by only 50 "points" each time was what caused my confusion. The ORES scoring is much more widespread between its maximum and minimum values. If I recall correctly, it ranges from -1000 to +1000; the higher the score, the higher probability that the edit is problematic. I think that by spending more time with these settings, I should be able to gain a better understanding of the score range dynamics. However, if anyone has any input or information to share, please do so. Anything will be helpful. :-D ~Oshwah~^{(talk) (contribs)} 17:37, 6 September 2025 (UTC)[reply]

@Oshwah glad you brought this up! This was one of my initial struggles when I started to tinker around with Huggle. I too am not certain what value(s) it's using when you set a min/max score in settings. After doing some testing, while likely incorrect, I was under the assumption the "global min/max score" referred to by those settings was the sum of the "ORES Score" and "ORES Goodfaith" numbers. So using your example above, that would come out to 166 (-50+216).

Either way, I ended up only enabling a global min score and have settled on -200 for the value and am satisfied with the number and the quality of edits that come through. I would agree that enabling a min score at 0 is a great starting place for anti-vandal RC patrol at least. Not enabling a min score gives way too many good edits. Though I found min 0 to not quite give enough edits for my liking, so I dropped it further negative. Nubzor [T][C] 00:50, 7 September 2025 (UTC)[reply]

Nubzor - Thanks for responding and for the information! I managed to figure out my bearings here when it comes to setting a minimum or maximum score values in Huggle. I'm actually using the minimum score, and I believe that I have the value set to "-150" at the moment. If yours is set to "-200", it's basically as if you're frequently pressing Control + Alt + D within Huggle to have it remove edits from the queue with scores of -200 or more. I use that queue option all the time on Huggle, and figuring out a good minimum score to set really does save the work of having to go through minor and non-problematic edits... :-D ~Oshwah~^{(talk) (contribs)} 00:56, 7 September 2025 (UTC)[reply]

Oshwah Oh wow, I wasn't even aware of that shortcut! That's neat. I felt -200 seemed decent after some tinkering. So if you're happy with -150, then I feel reassured we're in the right "area"! Nubzor [T][C] 01:30, 7 September 2025 (UTC)[reply]

Nubzor - I know a lot of keyboard shortcuts on Huggle by heart, and I'm here all day! If you want more, just let me know! ;-) Well, I believe that the range for ORES scores is +1000 to -1000. As the ORES score for an edit increases, the likelihood of the edit being problematic increases. The opposite applies for edits that are likely good changes. If you set a minimum score on Huggle, edits that are scored lower than the value you enter will not be added to the queue. As you increase the minimum score value to be higher and higher, you'll begin filtering out edits that were scored a bit higher on ORES but were otherwise okay. If you set the value too high, you'll begin to filter out edits that are problematic, but don't have an insanely high ORES score. You'll just start seeing a lower number of problematic edits that didn't score insanely high when evaluated by ORES. I'm working to keep shifting this value around a bit until I find a perfect medium; where good edits don't show up in my queue, and where bad ones do. It'll just be a matter of finding the threshold value that dials everything in just right, and where acceptable numbers of false positive and negative hits won't bother me. I'll keep messing around, and I'll let you know if I find a good value for you to try out. I'd be interested to see what others think, and hear some feedback about what a good threshold value is. :-D ~Oshwah~^{(talk) (contribs)} 02:48, 7 September 2025 (UTC)[reply]

Oshwah Appreciate your insight. Lo and behold Ctrl+Alt+D is right there in the 'Queue" menu. Completely overlooked that. I'm not sure the range, but you're definitely right that the lower score the "better" the edit and the higher the more problematic. Every now and then there will be a notification of a user getting whitelisted for hitting -2000 in the system log, which is how I remember negative is good, lol. But I think the "ORES Goodfaith" score is the opposite--the higher the score, the better? Which makes me question how the "global score" we set in the settings is calculated and why I assumed it was the two added together. Nubzor [T][C] 03:07, 7 September 2025 (UTC)[reply]

Nubzor - If you review the documentation and technical pages for ORES, you'll actually find that ORES adds a few different scores to each edit made. One is for edit quality (which is what Huggle pulls uses), and another is for the article quality. I also believe that the "goodfaith" value that you see is another such score that ORES assigns to each edit. The scoring system that ORES uses isn't just a "yay or nay" kind of deal regarding an edit and if it's bad or good. It takes a few different things into account. I wouldn't get too involved with learning everything about how ORES works, because - if you take a look here it's actually being deprecated! The WMF is working to transition us off of ORES and over to a new machine learning service called LiftWing. Once that happens, the WMF will likely sunset the ORES service and retire it. I'm hoping that LiftWing will be easy to learn and understand, but I haven't taken any time to review its documentation yet. Questions are already being asked on this page regarding Huggle and being transitioned over to use LiftWing. Eventually, we'll all have to update Huggle versions to a certain release in order to continue using it (so if there are any users who are stubborn and are still using Huggle v2, you're eventually gonna be outta luck).

In the meantime, here's some more shortcuts! The [ and ] keys will navigate you backward and forward in the queue, the space bar skips to the next edit in the queue, the Q reverts the edit and warns the user for vandalism all in one key press. Pressing the U key allows you to enter a custom edit summary and revert an edit with that as the reason, and the Y key does the same thing, but adds a note that the revert was for a good faith edit. Also, you should go into the shortcut tabs in your options and assign Control + [Number] to different "trigger Nth item in revert and warn menu" actions. I have Control + [Numbers 0-9] each assigned to different actions, and they make reverting and leaving correct warnings for users a breeze! :-) ~Oshwah~^{(talk) (contribs)} 03:47, 7 September 2025 (UTC)[reply]

Putting my programmer hat on, are there any changes that need to be made to Huggle to make understanding this easier? Should we update one of Huggle's wiki pages? Should we add explanatory text in the program somewhere? Should we change a default value? If any changes to the program are needed, please file a Phab ticket so that the idea has a chance of getting a patch written :) –Novem Linguae (talk) 09:38, 7 September 2025 (UTC)[reply]

For me, I would think adding some clarification to the manual or one of the wiki pages would be more than enough, since hopefully everyone is reading those :) Setting up a program like this is half the fun too! For example, I had no clue the difference in the feeds, and after someone brought that up above, your edit here is perfect and I'm sure will help others down the road. Nubzor [T][C] 14:17, 7 September 2025 (UTC)[reply]

Novem Linguae - I added a task to my "to-do list" to add a new page or section into the Huggle Manual, and explain and detail the "Feed" settings and what the "minimum score" and "maximum score" options do (if you'll have me, of course). I'll get started on writing a draft sometime this week. I think that it would help users to not fall into the same confusion that I did when testing these settings if the default value for the "maximum score" and "minimum score" was set to +200 and -200, respectively. I'll file a relevant phab ticket to ask that these default values be adjusted, and I'll brainstorm some additional ideas and let you know once I come up with anything that will help make these settings easier to understand. ;-) ~Oshwah~^{(talk) (contribs)} 17:00, 10 September 2025 (UTC)[reply]

Hello, I didn't read the whole section, but to give you some clarity: Huggle's internal scoring mechanism predates ORES, which was founded much later. Huggle internally uses integer based scoring system that is very trivial - the score is just a number that edits are ordered by in the queue - smaller the number, less likely the edit is considered "problematic". Higher the score - higher vandalism potential. The score is calculated based on many factors that can be influenced by various sources, there are some trivial algorithms that can be adjusted on the config page WP:HGC in prediction section (each wiki has own), then the score can be also affected by extension hooks (both JS and C++) and data from Huggle Antivandalism Network (HAN: that IRC chat Huggle users connect to).

Now, let's get back to the history and ORES. Before ORES, Huggle was mostly taking the "AI" scores from ClueBot, which was sharing them via HAN, however later on when ORES was invented, the score sourcing shifted to that via the scoring extension - https://github.com/huggle/extension-scoring

ORES is providing the scores as a set of probabilities that range from -1 to 1 (a float). This number can't be just "simply added" to Huggle's score, because it's too small to really have any visible effect. For that reason it's amplified using trivial math, there is an amplification constant (by default 200, configured per wiki using ores-amplifier key) which inflates this number. So with default constant of 200, it ranges from -200 to 200. Then this amplified score is added to Huggle's edit score and that is the final number you would see in the queue, that the edit would be sorted by and that the lower and upper limits are applied to. The reason for amplification constant being configurable is that in the early days of ORES we didn't know how reliable it is going to be, so we wanted to have a simple way to adjust the "weight" it has on the final score.

You will also see ORES score info separately in metadata, but that is mostly for debugging purposes, to see what score ORES estimated and how it affected the final score, but the edits in queue are ordered by Huggle's score, which is a sum of all individual scores calculated by all scoring algorithms and extensions.

I hope it's more clear now, let me know if there are more questions, just keep in mind I invented all this some 10 years ago, so I don't remember everything. Petrb (talk) 20:11, 22 September 2025 (UTC)[reply]

I am more confident than not I am using this talk page correctly to describe a problem I've recently noticed on user talk pages today.

On one of the user talk pages I've just warned someone about misbehavior of an article, I then noticed a misplaced Huggle message above an earlier edit ClueBotNG made. A few examples: User talk:209.137.220.113, User talk:137.52.208.53 and User talk:Dorathedestroyer. Seems like the tool places the warnings correctly if older warnings were made by other users however. Iggy (Swan) (Contribs) 15:56, 10 September 2025 (UTC)[reply]

Iggy the Swan reached out to me on my user talk page about this issue and linked me to this discussion. I've also been noticing that Huggle warnings have occasionally been left at the top of some user talk pages instead of adding them to the end of previous warnings that are under the section header for the current month and year, and of those - Huggle is sometimes also not adding the correct warning level (such as a level 3 warning when the user already has a level 2 warning under the section header for the current month and year). It seems to me like something, somewhere, has changed and is occasionally causing Huggle to either not see that prior warnings have been left on a user's talk page at all, or is causing other issues that is resulting in these occasional issues with warning levels and the location in which they're left. ~Oshwah~^{(talk) (contribs)} 17:08, 10 September 2025 (UTC)[reply]

The wrong warning levels being given is a perennial issue, see phab:T110818. I don't think there's a ticket about the warnings being misplaced, though. Perryprog (talk) 20:39, 10 September 2025 (UTC)[reply]

I've also had and seen this problem while using AntiVandal on rare occasions, so I don't think it's exclusive to an issue with Huggle. Nubzor [T][C] 15:02, 13 September 2025 (UTC)[reply]

Unless AntiVandal and Huggle share some of the same code, they are likely independent bugs. Deciding what warning to give is probably an algorithm in each tool that reads the page's wikitext, then determines what level to give. And there's probably a bug in the algorithm. There could be different heading formats, different template formats, etc. so it might be hard to cover all of them. –Novem Linguae (talk) 21:41, 13 September 2025 (UTC)[reply]

Yeah, I'm not particularly worried about it because it's so infrequent and seems like it'd be a nightmare to try and fix with all the variables. I had this example from earlier today where Huggle put a level 1 warning after a level 4. Maybe because it was from 6 days ago? But still September 2025. Then ClueBot put a level 2 after that. But I do check my reverts and caught it anyway. Not a big deal. :) Nubzor [T][C] 22:32, 13 September 2025 (UTC)[reply]

Shouldn't be that hard to fix with diffs. Wikicode in wikicode out, with a failing test case, is an easy programming problem to solve. However this project isn't actively maintained, so 🤷‍♂️. The best we can do is probably comment in a phab ticket with that diff. –Novem Linguae (talk) 22:51, 13 September 2025 (UTC)[reply]

Hello, please note that by default Huggle ignores all messages on talk pages that are older than 30 days. So if there is warning level 2 template that is 2 months old, Huggle would just issue level 1 template. This can be changed in wiki config, using key "template-age" (it's meant to be negative, default is -30), see https://en.wikipedia.org/wiki/Wikipedia:Huggle/Config.yaml for details. Petrb (talk) 20:23, 22 September 2025 (UTC)[reply]

Ohhhh very good to know @Petrb. In checking the linked config, template-age is currently -3. Would that mean 3 days, not 30? Nubzor [T][C] 20:53, 22 September 2025 (UTC)[reply]

Yes, that is correct, it seems it was set long time ago here - https://en.wikipedia.org/w/index.php?title=Wikipedia:Huggle/Config.yaml&diff=prev&oldid=918980316 I don't think that value is correct, 3 days is really short. Maybe up for a further discussion, but this is most definitely the root cause why Huggle seems to ignore most of warning templates. It doesn't see anything older than 3 days. Petrb (talk) 19:34, 23 September 2025 (UTC)[reply]

That clears up my issue at least. Thanks for sharing :) Nubzor [T][C] 19:36, 23 September 2025 (UTC)[reply]

cc ToBeFree. Looks like your diff https://en.wikipedia.org/w/index.php?title=Wikipedia:Huggle/Config.yaml&diff=prev&oldid=918980316 may have caused a couple of the sub-tickets at phab:T110818. Perhaps we should ponder if this 3 day limit can be raised a bit without re-introducing whatever AIV thing you were trying to fix. –Novem Linguae (talk) 03:26, 24 September 2025 (UTC)[reply]

Hmmmmmmmmmmm.

Thanks for the ping. The setting worked before my change and then for almost 6 years ... and we probably don't want an AIV report to be made when someone using an IP address 29 days ago had received a final warning back then. This setting also doesn't necessarily technically have to cause the issues described by Iggy the Swan initially here. That's caused by how Huggle implements the setting. My comment back then, When deciding whether to warn or report, ignore templates older than "-x" days, describes my intention. What Huggle appears to do instead is When parsing the page, completely ignore the existence of templates older than "-x" days, which is overkill. That should be changed. Users can still manually report anyone, just the (semi)automated reports of users whose warning was too long ago was the issue 2019. ~ ToBeFree (talk) 11:27, 24 September 2025 (UTC)[reply]

It's very hard to distinguish these 2 situations from the algorithm point of view - in fact it's pretty much the same. If you want to "ignore" the warnings when "warning or reporting" you pretty much want Huggle to completely ignore those old templates - those 2 situations you describe are the same. If you only wanted to consider the templates when reporting (not sending any subsequent warning) then the situation would be still only mildly different - let's say user has 3th level warning 2 months old. Huggle doesn't ignore all such templates as you expect - so it issues a 4th level warning. Then on next rollback is sees the user already received 4th level warning - so what should it do next? The logic say - report the user. But then you say: "ignore everything older than 3 days". The 4th level warning is not older than 3 days, but all previous warnings are. What should it do? I think Huggle behaves exactly as specified and required by the current configuration. I think the configuration should be fixed. There are multiple issues right now caused by misconfiguration on project config page. I already mentioned how to fix it elsewhere on this talk page. I can't fix it myself, because my extended global permissions already expired. Petrb (talk) 16:05, 27 September 2025 (UTC)[reply]

If you want to write a patch on the talk page and tag it {{IAER}}, someone will be along to implement it. –Novem Linguae (talk) 00:32, 28 September 2025 (UTC)[reply]

So as a compromise I raised the limit from 3 days to 15. I understand 30 is probably too much for English Wikipedia, but 15 should be fine. If there is a problem with that, we can adjust it. Petrb (talk) 23:09, 15 November 2025 (UTC)[reply]

Hi Team! I'm back in order to discuss another Huggle setting that needs some clarity and a batter way for users to choose between the two options available to them, as well as to request an enhancement that would save me time and (many times) annoyance when launching Huggle. On the Huggle Options window, if you click on the "Interface" tab and take a look at the list of checkbox items that you can enable or disable, the item that's listed at the very top and labeled, "Make the columns of lists either dynamic (will resize based on size of items) or manual (user can change their size)" is what I'm discussing today.

First and foremost, the description of this option is completely confusing to Huggle's users. Sooo... does enabling this option set the columns to be dynamic? Does disabling this option make it so you can change the widths manually? Vice versa? The way that this setting is labeled is akin to being asked to choose between a red or a green apple, but only being given a checkbox to select your choice. This option should be re-labeled to instead say, "Automatically adjust column widths", "Dynamically adjust column widths automatically", or maybe "lock setting column widths" - and where ticking the checkbox would "lock the columns" and have them dynamically adjust their width, and unticking the checkbox would allow you to adjust each column widths manually to your preferred size.

Speaking of "manually adjusting column widths", this leads me to the other issue that I want to discuss: I'm quite picky with how the different Huggle windows are arranged and where they're displayed, as well as how much room on the screen each one is sized to and how wide each list column is. However, each time that I exit out of Huggle and then launch it again later, the column widths and window sizes I manually adjusted are reset and completely back to the way that they're set by default. Each and every time I launch Huggle, I have to spend up to five minutes of time setting everything back up again... adjusting the size of the windows listed on the left, bottom, and right side and how much room on Huggle that they take up, and positioning the different windows and column widths back to the way that allows me to perform patrolling tasks both quickly and thoroughly. Can there please be an enhancement or an update made to the source code that implements a persistence for these customizations and saves them between Huggle sessions? ...PLEASE?!! :-) ~Oshwah~^{(talk) (contribs)} 20:16, 11 September 2025 (UTC)[reply]

A persistence exists; mine likely just got corrupted. ~Oshwah~^{(talk) (contribs)} 22:28, 13 September 2025 (UTC)[reply]

Woah Oshwah, relax, easy there, easy. Today I will be more than glad to help you out with the issue you are having. Unfortunately, I have been watching this page for sometime and was hesitant about participating to help out.

From my view, it appears to be, your offline configuration files have been corrupted by either an unexpected BSOD or an unknown transfer error in your computer data, and demand an immediate reset.

Huggle stores these config files in — (Main User)/AppData/Roaming/Wikimedia —

Now make sure you have completely closed the Huggle application.

1. Delete the "Wikimedia Folder" manually in the directory I stated above.

2. Restart your computer.

3. Launch the Huggle application and set everything to your best preferred look, including your "settings". Feel free to take as much time as you like. ( Most of the settings will automatically have been set according to the yaml configuration.js left on the users Wikipedia subpage. However, it is still important to check )

4. When you are satisfied with the look. Exit the application from the "X" Icon on your top right. DO NOT use the abort click under the "System" tab or press the "escape" key. You will know your preferences have been saved when you witness a loading bar properly "saving" what you have set up. A fresh Wikimedia folder will also be created that was deleted.

5. Launching Huggle again should now auto read the settings you left and should not stress you out setting them up again.

6. If this doesn't work. You may report back.

On the other hand, I also see an issue with the warning unit, that I absolutely must agree with.

I have been comparing the source code differences between (3.4.12) and (3.4.13) and have discovered a few abnormalities in the source code of (3.4.13), that might be the reason for these buggy user warnings.

Since the program is based on C++, most tech engineers that use this programming suit may contain slightly a few bugs, which most likely are never noticeable. These software types require quick patches every now and then.

In that case, If you want to experience a stable performance with the application, you may want to download (3.4.12) as there is clearly no issue with the warning unit. Except for the fact that performance will be very slow when multi-tasking than in (3.4.13).‎ Criticize (talk) 12:32, 12 September 2025 (UTC)[reply]

Thanks for the response Criticize! Weird, I'm not sure how things got corrupted, but I'll definitely take a look! :-D ~Oshwah~^{(talk) (contribs)} 22:28, 13 September 2025 (UTC)[reply]

Hello,

Previously (in the last years) Huggle consumed the "spam" feed from ClueBot NG, essentially the wikipedia changes feed + score (https://github.com/huggle/cluenet-relay).

Is this still of interest/value to Huggle? I notice the bot is not in the IRC channel anymore, so perhaps it is entirely legacy at this point.

Currently we are dropping around 50% of the messages being sent to IRC to avoid the flood protection, a simple solution would be to drop the (high volume) spam channel and ultimately perhaps stop sending to IRC entirely (this was done in the past, but then someone asked for it back).

If a data feed is of interest, this perhaps could be exposed via a websocket/http stream interface, it would require some development, but not a huge amount. - Damian Zaremba ^{(talk • contribs)} 19:20, 30 September 2025 (UTC)[reply]

Hi Damian, the bot still exists on one of my VPS, but from time to time it disconnects in a way that it's unable to reconnect automatically (which is probably the case now) and I just stopped checking on it (due to being too busy IRL), I will see if I can get it back on, it shouldn't be much work, it's just not trivial to figure out if it works, it's a bridge between 2 IRC networks and I don't even use IRC much anymore. Petrb (talk) 19:38, 30 September 2025 (UTC)[reply]

Thanks Petrb, I appreciate the pains of IRC bots. I'll continue looking at ways to improve this on our end. - Damian Zaremba ^{(talk • contribs)} 10:11, 1 October 2025 (UTC)[reply]

We also have the option to write there directly - https://github.com/cluebotng/irc-relay/pull/3 - if that's better for you. - Damian Zaremba ^{(talk • contribs)} 18:56, 2 October 2025 (UTC)[reply]

Specifically https://github.com/cluebotng/irc-relay/pull/3/files#diff-5076cccfa55d95bde66ed16a1cf0f70290ced1b359a1e43642687c82efe2bd7fR9, the main advantage being is you are not loosing 50% of the messages not sent to libera.chat. - Damian Zaremba ^{(talk • contribs)} 18:59, 2 October 2025 (UTC)[reply]

Hi everyone — I’m Ashik Ahamed, a PhD student at Clarkson University (USA). I’m researching Wikipedia “special tags” and reversion tools (e.g., Huggle). I’ve installed Huggle, but when I try to revert edits it seems read-only—I don’t have rollback rights. Could someone advise the correct way to test Huggle on this wiki (prerequisites, local policies), and whether I should request rollback (and where), or use an alternative like Twinkle until then? I won’t revert live content until I understand the policies; I’m looking for hands-on familiarity for research. Any pointers or links to the right permission request page and best practices would be greatly appreciated. Ashik Ahamed CU (talk) 14:13, 1 October 2025 (UTC)[reply]

The place to request rollback is WP:PERM/RB. However you may want to build some anti-vandalism experience before applying there. –Novem Linguae (talk) 22:30, 1 October 2025 (UTC)[reply]

I was doing a vandalism reversion session on Huggle and someone objected to one of my reversions. They replied to the user warning Huggle sends them, which I think should give me a notificaition on Huggle the same way as if someone had posted on my talk page (it doesn't). They subsequently reverted my edit a few more times. Because Huggle didn't display the reply notification, the conversation could have gone a lot differently than it did. I had no idea they were even sending me a message. He kept getting madder and madder at me (judging by the wording they used), presumably because he took offense at the template wording. Is there anything that can be done on Huggle to prevent this? Gommeh 📖   🎮 02:54, 7 October 2025 (UTC)[reply]

which I think should give me a notificaition on Huggle the same way as if someone had posted on my talk page (it doesn't). I don't remember Huggle having this feature. Talk page watchers, does this feature sound familiar to anyone? –Novem Linguae (talk) 03:56, 7 October 2025 (UTC)[reply]

Why is Huggle not using the standard uw templates and instead using its own versions? For example, Huggle has Template:Huggle/warn-1 when the standard is Template:Uw-vandalism1. Gonnym (talk) 09:43, 20 November 2025 (UTC)[reply]

@Gonnym: Huggle adds a direct link to the diff of the edit it reverted when warning the user, which Huggle's own templates (but not the standard templates) support. The second parameter of Huggle's templates are used to show a link to the edit, whereas the second parameter of the standard templates are used to leave a custom message. —⁠k6ka 🍁 (Talk · Contributions) 12:34, 20 November 2025 (UTC)[reply]

Can't that feature just be added to the main template? Seems a reasonable feature to add. Gonnym (talk) 13:23, 25 November 2025 (UTC)[reply]

@Sugar Tax I haven't reverted the revert, but just wanted to say that on https://test.wikipedia.org/wiki/Wikipedia:What_Test_Wiki_is_not, it specifically states one of the things not allowed is testing AWB, and that implies that Huggle is also not allowed as well. FantasticWikiUser (talk) 20:26, 10 December 2025 (UTC)[reply]

Huggle and AWB are two completely different tools. I don't see anything there indicating Huggle is not allowed to be used for testing on testwiki. Sugar Tax (talk) 20:30, 10 December 2025 (UTC)[reply]

Ah, that makes sense. I suppose that it certainly isn't easy to use Huggle on external wikis (outside the WMF) while it is easier to use AWB on external wikis. FantasticWikiUser (talk) 20:35, 10 December 2025 (UTC)[reply]

Huggle is being developed on testwiki, so it absolutely can be used there. Petrb (talk) 18:57, 22 December 2025 (UTC)[reply]