Also if you already have other templates that could be used, you just need to change the template names in the yaml file, you can easily find them when you search for huggle/warn-
Nov 2 2020
Oct 5 2020
Hello, sorry for coming so late to the party, what exactly do you need help with right now? I can already login to viwiki using Huggle, but obviously in read-only. If you want to enable write mode, I recommend translating the edit summaries in configuration file and importing / creating the warning templates:
Hello, yes, but where?
I guess my answer resolved this?
Ah yes, it's essentially tool tip for a forward button, which works just like in your web browser.
Jul 29 2020
It seems that xmlrcsd crashed on wmflabs, I don't really know why. It's restarted.
Jul 22 2020
I am wondering how we could implement this, so that this path can be specified on one place only. Because it needs to be defined both in Huggle source code somehow (so that Huggle knows where to look for extensions) as well as CMake so that it knows where to write the compiled extensions.
there is currently no maintainer for debian package format, it was replaced with snap format which is built automatically via Canonical's build farm. Unless someone takes over maintaining the .deb packages, I think we should obsolete it.
Apr 25 2020
I'd like to at least connect beta releases to edge channel is there a way to do that?
Apr 24 2020
I updated it to latest but I'd like to know how to automate this
how can I change everyone to edge? I just know how to update to specific version
Apr 13 2020
lowering down since almost everything that devs are needed for was done, if you need any further help, please let me know
Apr 9 2020
ok I couldn't find any issue after I removed it, I believe it's resolved now, this version with fix was not released yet, and even when it is, old versions of Huggle will still be used for a while though.
I can't really reproduce this, it seems it's not happening on Mac, but this should probably fix it: https://github.com/huggle/huggle3-qt-lx/commit/c6f964f60b2ba519e2643e21d060d61f7c6eebac
Apr 6 2020
So the proposed fix should be implemented as this:
Apr 5 2020
The thing is I don't understand how could the stack jump from DisplayRevid to PostProcessEdit(), the function DisplayRevid doesn't have any call to that in it:
it isn't easy to repoduce, my guess it happened once only and never since?
Mar 31 2020
I mean, try to get some inspiration from UNIX, it was invented around 1970 and most of old C code from that time still compile on modern UNIXes... that's what I call a stable API :P
There are multiple problems with this, it's burried in very old code that I wrote so long time ago I am not sure about the logic anymore. This commit removes it - https://github.com/huggle/huggle3-qt-lx/commit/8638b179899ff92b2a3ef2defcb6d17de511a791 but it needs some intensive testing, because I literally just removed the rvparse from API call and now I am observing what it broke.
but is that something very specific only to wikidata? I am not sure if there is parsedcomment in other wikis? Or is there?
Mar 29 2020
Really curious what else did I break while fixing this bug :)
So I investigated this and found the reason, it's related to flow of current message system in connection with reverting:
note this bug is not "invalid" there is just no better closure reason, such as "unreproducible"
I have to close this task as it's impossible to reproduce for me, if you run to this issue again, please have a look which feed provider is active - XmlRcs, IRC or API. Also please copy paste full system log from Huggle. That's very important for me.
this task is very hard to reproduce
Mar 27 2020
Sorry to be late to the party - regarding "undocumented options", we keep documentation for options on place that not every one is probably aware of, here: https://www.mediawiki.org/wiki/Manual:Huggle/Deploying/DefaultConfig.yaml and even the options you claim to be undocumented, are in fact there ;)
ha, seems this was forgotten during migration to new server
Mar 25 2020
Mar 24 2020
Feb 17 2020
both instances were shut down, you can delete them in 14 days from now
Feb 14 2020
So I successfuly migrated wm-bot core and bouncers, next step is to move MySQL DB, then instance wm-bot2 can probably be nuked.
NAT is not going to be possible as old instance is going to be deleted
Feb 11 2020
I just spent couple of hours trying to get it to run with latest mono / dotnet core and there are some major issues with getting old 3rd dependencies running, so it will need a bit more time
Feb 3 2020
I will try to implement this during this year's hackathon
Feb 2 2020
I successfuly created a new instances for PG and wm-bot, now I need to migrate the data from old ones and then it should be done
Jan 23 2020
Hello, sorry for the delay, all obsolete instances are gone now
Jan 2 2020
Sorry I wasn't much available during holidays, there is a long-needed migration to new VM being prepared, hopefully in next few weeks I will get to it
Nov 25 2019
Yes, that's where the code is and that's where you should fix it!
Oct 21 2019
Yes, this task is still open, it's just extreme lack of active developers that resulted in nobody looking into this.
Sep 11 2019
+1 Experienced and trusted
Aug 28 2019
this diff information is retrieved by RC feed provider, it's not computed by Huggle
wm-bot uses space as parameter separator, so I think in this case:
Jul 17 2019
xmlrcsd crashed for some reason
Jul 16 2019
@Rfarrand hi Rachel, did you get the e-mail from him? Can you please have a look in that?
Jun 26 2019
- upload a patch against operations/mediawiki-config, file wmf-config/throttle.php (should be self-explanatory) and ping me to deploy it
- make the IP available to me somehow (in this case, I'll need datetimes as well - whole Wikimania?)
Jun 25 2019
range is here: https://phabricator.wikimedia.org/P8657