Admin at cswiki and Wikidata. Tech Ambassadors & Translators, +2 on MediaWiki. Contribute to Pywikibot.
User Details
- User Since
- Oct 12 2014, 12:35 PM (501 w, 2 d)
- Availability
- Available
- IRC Nick
- matej_suchanek
- LDAP User
- Matěj Suchánek
- MediaWiki User
- Matěj Suchánek [ Global Accounts ]
Yesterday
Sun, May 19
Sat, May 18
Fair point, renamed.
Tue, May 14
Mon, May 13
Sun, May 12
Wed, May 8
I have been running into these lately, too. Especially when calling DataSite.loadrevisions.
Sun, May 5
I decided to start over and small.
Sat, May 4
Fri, May 3
Thu, May 2
Mon, Apr 29
First, we need to decide which is preferred, i.e., whether the multiline string should be interpreted as with or without the carriage return, or depend on the platform. (I think it's without.)
Sun, Apr 28
This is quite easy to do now, but it's unclear whether it's worth it. The usual motivation is to stop storing the username in each row to save storage and make renaming users trivial. The latter doesn't apply here since only user ids are stored for registered users (event_agent_id). The former applies only to events triggered by IPs.
However, soon, IPs will no longer be used to identify users. Writes to event_agent_ip will stop, old entries will persist forever, though.
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.
Apr 21 2024
Apr 20 2024
Not really. You can easily make a recursive rule without regex, like "a" -> "aa".
Apr 17 2024
Apr 15 2024
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.
Apr 14 2024
More evidence: there is no recent connection to nowiki in Wikidata.
Apr 13 2024
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.
Apr 12 2024
Apr 11 2024
Apr 9 2024
Apr 7 2024
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?
Apr 6 2024
Apr 5 2024
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".
Apr 2 2024
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?
Mar 31 2024
Mar 29 2024
Mar 28 2024
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.