You need to install a JDK (Java Development Kit), at least JDK 10 (it solves a few issues on Mac installation), and after you can use the installer or the installation through getdown.

New run for enwiki 2 (27/05/2021)

New run for enwiki 1 (27/05/2021)

New run for frwiki (26/05/2021)

@Jdlrobson
One remark made on frWP is that the identifier of the fields should be more descriptive and stable, so that CSS styling can be safely applied on some fields. Currently, it seems that the fields identifiers are auto-numbered so they can change with new versions or even for different usages of the page (depending on what other fields are added or not). Would it be possible to have meaningful identifiers for the fields, instead of things like ooui-php-18 currently in ProtectionForm for the checkbox for the cascade protection?

I just saw your message on frWP sysop board: feel free to close again, but I still believe there's something going on with Protect-cascade

According to the comment on Group-sysop.css, it says that "it hides MediaWiki:Protect-cascade, which shouldn't be used". And indeed, when I check again https://fr.wikipedia.org/w/index.php?title=Gilbert_Moses&action=protect&safemode=1, the box title says "Protection en cascade - A NE PAS UTILISER" (Protect cascade - DO NOT USE). So what has changed about the usage of "Protect-cascade" ?

@Jdlrobson
Here's the current status :

In T274934#6835129, @Jdlrobson wrote:

Just to confirm I understand the issue, per @Aklapper I am also seeing the following - is this what is supposedly missing?:

If so, I'll explore what could be happening here..

@NicoV could you also confirm you do not see it on the following URL:
https://fr.wikipedia.org/w/index.php?title=VTV_1&action=protect&safemode=1
?

I thought it was happening again today, I even took screenshots, but I noticed one line with several hundreds modifications from Wikidata for a single user page...
It was probably something similar last time, I think we can close this task.

It should be fixed.

Thanks for the notification @GoingBatty . I completely refactored this part for performance, and it seems I introduced a few bugs on the way... I will try to fix it today.

It should be done.

It's done.

I've modified WPCleaner to allow working on a subset of regular expressions when running in bot mode. This is based on optionally defining a group name for each regular expression, and configuring the bot to run only on a selected list of groups (by default, no groups are selected).

Sorry for the delay, but I just pushed a new version that should keep the bot flag when creating a new subpage (as it was missing, it's probably not watched), but the bot flag will still be there when updating the subpage (in case someone added it to its watchlist). Does this seem ok to you? (and does it work as expected on cswiki ?)

@Etonkovidova
Thanks for the answer. The problem lasted for almost a day, and I wasn't the only one having the problem (I asked here). I hope it was a temporarily glitch

In T269225#6707499, @ArielGlenn wrote:

In T269225#6706807, @NicoV wrote:

@ArielGlenn

At least for frWP, it seems the step "Recombine articles, templates, media/file descriptions, and primary meta-pages." doesn't start even if the step "Articles, templates, media/file descriptions, and primary meta-pages" is done for more than 20 hours. See https://dumps.wikimedia.org/frwiki/20201220/

They seem done to me.

2020-12-21 01:41:19 done Recombine articles, templates, media/file descriptions, and primary meta-pages.

    frwiki-20201220-pages-articles.xml.bz2 4.6 GB

Note that the servers running everything else but enwiki have the old version of the utils so they wil work just as they always have.

At least for frWP, it seems the step "Recombine articles, templates, media/file descriptions, and primary meta-pages." doesn't start even if the step "Articles, templates, media/file descriptions, and primary meta-pages" is done for more than 20 hours. See https://dumps.wikimedia.org/frwiki/20201220/

Yes, I understand that typo list pages can only be changed once a new AWB release has been rolled out (and probably after some time to be sure users have upgraded). That's why I'm pushing to include this patch, so that it won't be too long before modifications can be made in the typo list pages. At least, once I know this patch will be included, I can also start modifying WPCleaner to take advantage of this, even before we can add the new attributes to the typo list.

I just pushed a new version that should remove the bot flag for the edits on the main talk page. I can't test it properly on frWP, can you tell me if it works on csWP ?

Ok, thanks for the example, I will see to remove the bot flag for the edit on the main talk page.

I modified WPCleaner a few months ago to remove the bot flag when adding warnings on talk pages (or subpages), to have a better chance of article authors noticing the warning. What better way do you think of?

Hello @Rjwilmsi (or other AWB developer?): what is the process to submit patches?

Thanks @ArielGlenn , I could download the dump analysis for frWP

In T56947#6657213, @Tgr wrote:

In T56947#6654187, @Esanders wrote:

The volume in the above mentioned edit filter (T56947#2098243) would be a good metric for success. It might be useful to have it on more high volume wikis.

Note that the filter only catches changes to dates (which is a good way to avoid false positives, but it avoids the vast majority of true positives too). So it's a good way of measuring whether problematic edits become less frequent, but not a good way of measuring how frequent they are, in an absolute sense.

Done.

Done as part of the builder for internal links (see T257141).

Dump analysis done, and automatic fixing tested.

The switch to Java 8 is done, other improvements (using Optional<>, using Nullable and Nonnnull annotations, streams, lambda...) will be done in other tasks.

First version done. I will run a dump analysis and see what can be fixed automatically.

Done. Each error can be in its own package: for example, for error #501, package will be api.check.algorithm.5xx.50x.501.