Admin at cswiki and Wikidata. Tech Ambassadors & Translators, +2 on MediaWiki. Contribute to Pywikibot.
User Details
- User Since
- Oct 12 2014, 12:35 PM (497 w, 6 d)
- Availability
- Available
- IRC Nick
- matej_suchanek
- LDAP User
- Matěj Suchánek
- MediaWiki User
- Matěj Suchánek [ Global Accounts ]
Thu, Apr 25
Looks like there is still that one problem with credentials when running in PAWS:
Wed, Apr 24
That explains the "user that does not exist here". The bot is not registered on test.wikipedia.
If you log in to the bot account and visit a page on test.wikipedia.org, I believe it should solve the problem for you.
Your script is apparently making a request to test.wikipedia.org and fails, claiming you don't have an account there. It's not clear to me why.
Assuming you are using Herzi Pinki account (are you?), this is not true.
Sun, Apr 21
Sat, Apr 20
Not really. You can easily make a recursive rule without regex, like "a" -> "aa".
Wed, Apr 17
Mon, Apr 15
The code that is responsible for ensuring only one block is applied is here: https://gerrit.wikimedia.org/g/mediawiki/extensions/AbuseFilter/+/1807a077557ec1248b4ef87e46a58db3801d905b/includes/Consequences/ConsequencesExecutor.php#260.
Sun, Apr 14
More evidence: there is no recent connection to nowiki in Wikidata.
Sat, Apr 13
Idea (kind of compromise): Remove the UserGroupManager::addUserToGroup call from the database updater (SchemaChangesHandler). The user will be created when the extension is installed but will be promoted only if the wiki decides to use the aggressive counter-features.
Fri, Apr 12
Thu, Apr 11
Tue, Apr 9
Sun, Apr 7
In my opinion, this perfectly matches https://www.mediawiki.org/wiki/Manual:Reverts#Manual_revert
MariaDB [commonswiki_p]> SELECT rev_timestamp, rev_id, rev_sha1, rev_len, (SELECT GROUP_CONCAT(ctd_name SEPARATOR ',') FROM change_tag_def JOIN change_tag ON ct_tag_id = ctd_id WHERE ct_rev_id = rev_id) AS ts_tags FROM revision WHERE rev_page = 4966748 ORDER BY rev_timestamp DESC, rev_id DESC LIMIT 10; +----------------+-----------+---------------------------------+---------+----------------------------------------+ | rev_timestamp | rev_id | rev_sha1 | rev_len | ts_tags | +----------------+-----------+---------------------------------+---------+----------------------------------------+ | 20240406225557 | 866349068 | c57dpmffv1kxf8a0vx8qyl8znojhcya | 2948 | visualeditor-wikitext,mw-manual-revert | <-- manual revert | 20240406225508 | 866348947 | ew9uvbtwpzf879gv256fwqj5i2qyw14 | 2998 | mw-reverted | <-- reverted | 20240406225505 | 866348942 | agq18v28t4mfvyx5fx4favkobuydziw | 3047 | NULL | <-- reverted | 20240404153001 | 865841726 | agq18v28t4mfvyx5fx4favkobuydziw | 3047 | mw-reverted,wikieditor | <-- reverted | 20240404130859 | 865809957 | c57dpmffv1kxf8a0vx8qyl8znojhcya | 2948 | NULL | <-- base revision | 20200819214235 | 441012026 | c57dpmffv1kxf8a0vx8qyl8znojhcya | 2948 | NULL | | 20171016130632 | 263110882 | h9vi1gmsznx8i3pg0m5g1kue9omav1n | 570 | NULL | | 20150322224936 | 154363418 | q2me2b6y96ng7clj6og2fmoo0tc7bpr | 562 | NULL | | 20150225202308 | 151083926 | 3m9z162p02jdo6jxof2vurtaurje9f5 | 587 | NULL | | 20100614215051 | 40497753 | k8ovsfbuo8bp962xt2i5maqqb6lrql1 | 616 | NULL | +----------------+-----------+---------------------------------+---------+----------------------------------------+
#866349068's hash matches #865809957's hash, therefore all edits between are considered reverted. #866348942 is an exception, probably because it's a null edit that by definition cannot be reverted.
What is the expected behavior?
Sat, Apr 6
Fri, Apr 5
Maybe one of these recent changes is the cause?
It appears that wd admins are not willing to issue indefinite (or even long) semi-protection even for "the most common items since many contributors in the projects are not autoconfirmed on Wikidata and will not be able to add new articles if needed".
Tue, Apr 2
Has the option to automatically create the user account prior to the update if it doesn't exist on Wikidata been actually considered? Is it impossible, or is it just unclear whether we want to do it?
Sun, Mar 31
Fri, Mar 29
Thu, Mar 28
Mar 23 2024
I think mw.hook( 'wikipage.content' ) can help.
Mar 21 2024
On average, every tenth insertion.
Ideally, you would also see type=purge entries, as those are responsible for keeping the table compact...
Mar 15 2024
Mar 13 2024
Does selecting "Editor type" in "Dimensions" and only filtering by "Anonymous" not satisfy that?
https://stats.wikimedia.org/#/wikidata.org/contributing/edits/normal|bar|2-year|editor_type~anonymous|monthly
And if you want "unique" editors:
https://stats.wikimedia.org/#/wikidata.org/contributing/editors/normal|line|2-year|editor_type~anonymous*user|monthly
Mar 12 2024
Mar 9 2024
Not observed anymore.
Mar 8 2024
Mar 7 2024
Mar 6 2024
Mar 3 2024
Feb 26 2024
And apparently it's been reported once again since: T329575.
Feb 25 2024
Feb 23 2024
Did it.
For new properties, it is better to handle it on-wiki and delete and create it again. It doesn't require a sysadmin's ("deus ex machina") intervention.
Feb 21 2024
srwiki has three user-defined tags: Дискусија на Викимедијиној Остави, ToDoLister, Adiutor. But the activity on Special:Log/tag is minimal (and possibly unconstructive, exactly why the change would be useful).
Most wikis have no user-defined tags. Only 123 wikis should be concerned:
Using Special:AbuseFilter/tools:
Feb 20 2024
Chrome on Windows 10, Monobook skin.
T299308: Add Hide translations to Special:PrefixIndex made progress.
Apparently, there was an issue with the patrol button not showing up last week: T357213. I'm not sure if it is related, but it would be a weird coincidence...
Feb 19 2024
I guess T343115: On Special:PrefixIndex Properties and Lexemes are not shown with their Label resolved this.
Is there an error message or does the button just not display?
The change is in the database:
+------------+----------------+--------------+ | rc_id | rc_timestamp | rc_patrolled | +------------+----------------+--------------+ | 2434470175 | 20240215162738 | 0 | +------------+----------------+--------------+
Feb 18 2024
Feb 16 2024
3 is a big no-no because the behavior wouldn't match the user's expectations. 1 and 2 are ultimately the same (there would be an exception anyway). So this is just about showing a more user-friendly error message (instead of the default).
Note that this is blocked on T57755, which is an upstream task. If we chose to hardcode something and then upstream changed, it could be problematic because users would be forced to upgrade Pywikibot version.
Feb 15 2024
Occurrences across wikis: P56851 (111 filters on 40 wikis)
Query:
SELECT afa_filter, ctd_name FROM change_tag_def, abuse_filter_action WHERE ctd_user_defined = 1 AND afa_consequence = 'tag' AND ( afa_parameters = ctd_name OR afa_parameters LIKE CONCAT('%\n', ctd_name) OR afa_parameters LIKE CONCAT(ctd_name, '\n%') OR afa_parameters LIKE CONCAT('%\n', ctd_name, '\n%') );
Feb 14 2024
Unlike BlockedExternalDomains in its current shape, SpamBlacklist checks edit summaries for spam, too (T15599#173812, code snippet: T296102#9534553).
Feb 13 2024
The preferences are relevant only to those who use the old recent changes design ("Use non-JavaScript interface"). Others can configure their default directly on Special:Recentchanges/Special:Watchlist, then the preferences have no influence. (You can do much more in the views than in the preferences.)
Feb 12 2024
For reference, edit summaries are indeed conditionally checked for spam:
Feb 10 2024
I forgot to mention that, but it obviously does not apply here. The base revision was the eighth most recent.