Example: https://meta.wikimedia.org/w/index.php?title=Special:Contributions/SHIT_SHIT_SHIT_SHIT_SHIT_SHIT_SHIT_CRAP_CRAP_CRAP_CRAP_POOP_POOP_POOP vs https://meta.wikimedia.org/w/index.php?title=Special:CentralAuth/SHIT_SHIT_SHIT_SHIT_SHIT_SHIT_SHIT_CRAP_CRAP_CRAP_CRAP_POOP_POOP_POOP.

I'm pretty sure this is not expected behaviour. I've seen a user (not mentioning his username as it is highly abusive) that was hidden, and while his central auth showed that "there is no global account", the local contributions page didn't and only presented the block notice.

In T276195#6875967, @Legoktm wrote:

I don't think counting # of wikis is a good indicator for the actual perf impact GlobalWatchlist has. Instead it would be better to count the number of titles across all the watchlists. If someone is only watching like 5 pages on 50 wikis, those queries are going to be really fast compared to if you're watching 200k pages on 2 wikis.

On my device, the global watchlist takes just above 3 seconds to reload. 50 might be a bit high, but why not.

I am currently using the script with 32 wikis.

Thanks to whoever did it.

At least the usernames seemingly can't be registered.

The user log does not suggest any pages were created after July 2020.

That's right, thanks.

@MusikAnimal Why not отклонено последнее \d+ изменение|отклонены последние \d+ изменени(я|й) or even отклонен(о|ы) последн(е|и)е \d+ изменени(е|я|й)?

In T262631#6621863, @MusikAnimal wrote:

I also want to get the preload template translated.

In the light of T262631, I don't think this task is necessary.

Unrelated, anyone know how to make the admin instructions section headings not show up in the Table of Contents at https://meta.wikimedia.org/wiki/MediaWiki_talk:XTools-AutoEdits.json ?

See, for example, https://www.wikidata.org/w/index.php?title=Q25945246&action=history, https://www.wikidata.org/w/index.php?title=Q25945256&action=history, https://www.wikidata.org/w/index.php?title=Q25945263&action=history, https://www.wikidata.org/w/index.php?title=Q25945274&action=history, https://www.wikidata.org/w/index.php?title=Q25945289&action=history, https://www.wikidata.org/w/index.php?title=Q25945302&action=history, https://www.wikidata.org/w/index.php?title=Q25945344&action=history, https://www.wikidata.org/w/index.php?title=Q25945350&action=history, https://www.wikidata.org/w/index.php?title=Q25945373&action=history, https://www.wikidata.org/w/index.php?title=Q25945422&action=history, https://www.wikidata.org/w/index.php?title=Q25945438&action=history, https://www.wikidata.org/w/index.php?title=Q25945481&action=history, https://www.wikidata.org/w/index.php?title=Q25945484&action=history, https://www.wikidata.org/w/index.php?title=Q25945487&action=history, https://www.wikidata.org/w/index.php?title=Q25945496&action=history, https://www.wikidata.org/w/index.php?title=Q25945510&action=history, https://www.wikidata.org/w/index.php?title=Q25945524&action=history, https://www.wikidata.org/w/index.php?title=Q25945530&action=history, https://www.wikidata.org/w/index.php?title=Q25945534&action=history, https://www.wikidata.org/w/index.php?title=Q25945536&action=history, https://www.wikidata.org/w/index.php?title=Q25945545&action=history, https://www.wikidata.org/w/index.php?title=Q25945553&action=history, https://www.wikidata.org/w/index.php?title=Q25945554&action=history, https://www.wikidata.org/w/index.php?title=Q25945558&action=history, https://www.wikidata.org/w/index.php?title=Q25945559&action=history, https://www.wikidata.org/w/index.php?title=Q25945560&action=history, https://www.wikidata.org/w/index.php?title=Q25945566&action=history, https://www.wikidata.org/w/index.php?title=Q25945584&action=history, https://www.wikidata.org/w/index.php?title=Q25945599&action=history, https://www.wikidata.org/w/index.php?title=Q25945611&action=history, and https://www.wikidata.org/w/index.php?title=Q25945616&action=history.

Um, is this supposed to be fixed? Currently, PLBot still redirects a lot of the items emptied by a merge.

@MusikAnimal This tool is used quite a lot, so maybe you could implement my suggested regex?

I mean, this could be resolved independently for now, but the linked task is probably better for the long term.

Now works, see https://www.wikidata.org/wiki/Special:Diff/1263046123/1287057623.

This seems to be experienced by many users, see the report at https://www.mediawiki.org/wiki/Topic:Vsc0kdj189lrmhzj.

Thanks for clearing this up; I thought inflected forms were an additional functionality due to the misunderstanding above.

In T157218#6476509, @DannyS712 wrote:

The current code is documented as only show [private logs] upon specific request to avoid suprises so it may be a good idea to continue supporting the all "public" logs at Special:Log, and have a separate way to request showing all public and private logs the user can see. Perhaps Special:Log/withprivate? or something?

I tried changing the spelling variant on the linked lexeme, but the language code is not recognised. Is that because the change is not yet deployed?

Not sure if I should have created a separate task, but the regex is once again (T200791) not strict enough, making this edit being marked as done through the tool. I mean, it's not a big issue, but where is the problem in using \[\[WT:EDIT\|Assisted instead of just \[\[WT:EDIT?

There have been three autopromotes on enwikibooks now, including me.

In T237191#6464905, @DannyS712 wrote:

@matmarex the rights should probably also be removed from the users with blocks, since they were autopromoted due to a bug.

It is, so I support the second linked proposal to base this time on the time of inactivity (additionally). Maybe this would be enough to cover the blocked users as well.

Duplicate of T119964?

Hmm, I should have been autopromoted to autoreview on enwikibooks now, right?

In T129638#5883779, @TerraCodes wrote:

I can't reproduce this, so perhaps this has been fixed?

@He7d3r As already mentioned above:

In T157271#3070073, @Jc86035 wrote:

There's an AWB-style script on enwiki (it's rather buggy but works for simple non-regex find-and-replace). Is the replacement going to be based on it

In T180150#3865933, @Tom.Reding wrote:

in the "Alerts" window, I sometimes see "Long article with a stub tag" in those situations. AWB does not remove the tag in those cases. Is there a character-count grey-area where the alert is displayed, above which it triggers the removal?

Here's what I found under https://en.wikipedia.org/wiki/Wikipedia:AutoWikiBrowser/General_fixes#Tagger_(Tagger):

• Removes {{stub}} if article has more than 500 words (comments, categories, defaultsort and persondata are excluded from word count).
  • Words in bulleted text are divided by 2 to avoid destubbing pages with big lists and little text.

At the same time, https://en.wikipedia.org/wiki/Wikipedia:AutoWikiBrowser/User_manual#ALERTS reads:

• "Long article with a stub tag." — Alerts if article has more than 500 words and a stub tag

Maybe you just hadn't activated genfixes when you encountered the alert? It is also possible that the alert configuration does not divide the words in bulleted lists by two (would like to read from a developer about that); that would be something I'd consider a bug.

From the two edits this tool makes mentioned above, I'm not sure there are any non-trivial parts of the edit summary that could be used to unambiguously identify the tool. I mean, "böjningsform av" is a phrase anyone could use when creating an inflection form, and "assisterat" does not really specify what tool is used. Maybe you can contact the developers to add "assisterat" with a link to the tool documentation to every edit the translation editor makes?

Huh, since when do we have tag and tags parameters in parallel?

In T262124#6445276, @MusikAnimal wrote:

Merged. Thank you @mdaniels5757! We really need more help with maintaining the AutoEdits config. I'm debating inventing a system similar to the spam blacklist, where a JSON config page (admin protected) lives on each project, such that the community can maintain the list of tools without having to go through XTools developers.

Seems like a good idea; with the global AutoEdits configuration on Meta. Where will we keep the language-specific tools then?

Thanks, that helps a lot! I'll probably post a list of needed configuration additions right here.

While this is simple to add to the configuration, as a result of T200791, similar changes have to be done for other projects. Does anybody know where the localisations for AWB can be viewed so that we can batch-import them in some way?

In T262147#6439949, @Jony wrote:

I didn't mean that, some edits will tag something else with twinkle tag, (i.g mw-undo) as we also count mw-undo as CVN automated edits. so, we can't consider those edits as twinkle edits.

Another update; the STiki tag is now excluded from both undo and rollback.

I'm not sure this should be global, as there aren't that many projects that use Twinkle, and enwiki, for example, started using twinkle with a lower-case letter as the tag (see T262147), but I won't really oppose if it is added globally.

I guess https://meta.wikimedia.org/wiki/User:Xiplus/TwinkleGlobal is some kind of start?

I don't think we do that usually (and AFAIK, we did count Twinkle reverts twice). There is the option tag_excludes in the configuration, so twinkle could be added as such to the configuration for mw-undo, but there is currently no parameter to exclude a specific regex from the results for a tool (as XTools looks for edits satisfying regex OR tag). If we add the tag as an exclusion, it would only make sense (and prevent confusion) if we add the regex for the link in the edit summary as an exclusion as well. Maybe you could create a task to add such a parameter if you think it's necessary?

Okay, so first, RedWarn now uses the tag RedWarn (almost 40K edits according to Special:Tags). Secondly, it now uses the syntax \[\[W:en:WP:RW\|\(RW \d+\)\]\], as far as I understood from the above link. Thirdly, it seemed to use \[\[Wikipedia:REDWARN\|\(RedWarn \d+\)\]\] before, see, for example, this edit. Therefore,