Feb 3 2021
Apr 27 2020
Overall the question "how many is too many" (@Quiddity) is more philosophical rather then programmatical. While programmers normally prefer more casual definitions.
Apr 22 2020
Apr 20 2020
Yes, that would match perfectly.
I am a bit confused by reading https://www.mediawiki.org/wiki/Help:Notifications/Types#Page_links
Is it possible - or even default behavior that
- the page I once created is not anymore in my watch list
- the "Page link" notifications still arriving to me because I am the page creator
- so the only way to stop it is to uncheck "Page link" notification for my whole watch list?
To be honnest I'm not quite sure yet: it is not my demand but a reflection of the tech discussion with some arguments (initially linked). So I'm merely this task (feature request) technicak creator and translator.
But I forwarded your question asking to be concise so I would translate it: https://ru.wikipedia.org/wiki/Википедия:Форум/Технический#que01
Apr 7 2020
Nov 20 2019
The problem still persists at ru-wiki, MBH had to write a bot so once a day to patrol unpatrolled pages after autopatrollers' edits, Which is sounding just like it looks like (=~ wtf)
To avoid terms mishmash: ru-wiki uses FlaggedRevs as its top layer patrolling mechanics. So any further "patrol", "patrolling" means "actions as it is reflected over FlaggedRevs interfaces". If about native tools, then "old patrol", "old patrolling" (as they named in the web-interface).
Oct 7 2019
Oct 6 2019
To be clear I am not in any relations with the WM development team. I am not even a programmer (by my diploma). So my closing proposal doesn't have any authoritative weight. But honestly the way the problem has been last time described - it was a bit like "we used to use DynamicPageList against of its documented settings for desired results; now it refuses to work against of the documented settings - please fix it".
Oct 5 2019
That idea appeared to be plain wrong.
As a round #2 :-) - illogical and random character of the problem reminds me T224491 Which is marked as fixed but maybe that PHP 7 quirk came back here? So sometimes some edit context gets corrupted by one char (say "review" becomes "reviev" or something)?
Oct 4 2019
The extention page states that its authors are Aaron Schulz and Jörg Baach. It may worth to try to contact them because they may know something that only authors know (some hidden deep debugging mode to launch in case of troubles and the like).
Oct 3 2019
I got an idea of what may happen. If I'm right then all problematic articles have been once "patrollled" by setting their "quality" to 0 like
Oct 2 2019
Fresh to whatever UTC-related time (you figure out) problematic article states: https://ru.wikipedia.org/wiki/Википедия:Форум/Технический#samples01
OK, purely technically wrong, even reviewer cannot set it higher than 2(?) The point is that the underlying engine recognizes only zero accuracy state ("not patrolled") and non-zero accuracy state ("patrolled"). And anything else falls under the current editor rights and so we come.
As so far there are very few of "of course" things in it. Let's us take fact that "patrolling" is just an imaginary thing existing only as a social contract and nothing else.
The only real thing is "reviewing" the whole page (not a given edit) accuracy for its states "not acceptable" (0) and "acceptable" (1). And any "patroller" has right to set it to 0 or 1 - but only reviewer may set it to 2, 3 or 1001. So now what may happen if reviewer "patrolled" a page as accuracy==2 and some other "patroller" made an edit after that? Technically it is a request to change the "accuracy" criterion level beyond the allowance (0 or 1) - so the refusal. Just keep brainstorming, don't get too upset.
Oct 1 2019
Long time ago just for fun I wrote a patrolling script that works straight through the wrapping interfaces: https://ru.wikipedia.org/wiki/User:Neolexx/review.js
To the best of my knowledge en-wiki doesn't use FlaggedRevs extension (as a replacement for the native patrol mechanics). Compare
Sep 8 2019
(update) It seems that currently there is a way to check partial blocks by a 3rd party - through list=blocks query where boolean partial will be set then. For the test case (obviously it's JSON for practical things, I'm using xmlfm just for visual convenience here): https://ru.wikipedia.org/w/api.php?action=query&format=xmlfm&list=blocks&bkusers=Schekinov%20Alexey%20Victorovich
Sep 4 2019
I want to understand the use case better - are you using this query for an external tool?
Aug 20 2019
Mar 17 2019
To really laugh one may enjoy my "Type 25 pollution cleaner" I'm keep using these days
"Don't Shoot the Pianist"... I'm not too deep in IETF and WHATWG stuff so just quoting verbatim from the Chromium response (at the bottom after the line).
So as I understand - they have a word on it from specs guys, URI like urlencoded_part#non-ASCII_as-is_part are simply wrong. They will restore the fix in the next update. But the specs do not prevent any browser producer in the future simply reject such URI as malformed and possibly malicious. If my understanding is correct then such risk should be definitely accounted by the Wikimedia team.
Mar 16 2019
Yeah, they do get saved: just nobody knows about it unless MediaWiki savvy users of Wikipedia. And it just happens in the project that the max article edits and newcomers falls at week-ends.
gerrit is still dead https://www.isitdownrightnow.com/gerrit.wikimedia.org.html
Other related bug
continue from https://phabricator.wikimedia.org/T218393
I'm honnestly puzzled why does it take so long to fix.
Mar 15 2019
Oct 21 2018
To further explain "anything more reasonnable" as I see it, three options:
Oct 19 2018
Oct 21 2017
Why exactly Last News (Последние новости), not Most Popular News (Самые популярные новости) or any other template block of the desktop version?
Nov 16 2015
Nov 15 2015
Nov 14 2015
indeed purged through
sorry, posted before saw you response, gonna check now
Thinking over again, I do not understand how any ipblocks table (if it is), even somewhere/completely corrupted, might prevent to get a simple list of users? One cannot give some piece of info - just say "I cannot get it" by an empty string in the relevant query field, do not abort the whole query.