Admin at cswiki and Wikidata. Tech-Ambassadors, +2 on MediaWiki. Contribute to Pywikibot.
User Details
- User Since
- Oct 12 2014, 12:35 PM (440 w, 5 d)
- Availability
- Available
- IRC Nick
- matej_suchanek
- LDAP User
- Matěj Suchánek
- MediaWiki User
- Matěj Suchánek [ Global Accounts ]
Yesterday
I think we can just disable the condition limit in this context.
I think -lang:ckb is the false trace here. The upstream call that throws the exception is langlinks = page.langlinks(). There is probably an interwiki link to a site that Pywikibot does not recognize.
This is too Wikimedia-specific (or even Wikipedia-specific). I'd prefer having this as a utility function or application logic rather than making it part of the model.
This is the source of the exception:
The reason for the regression is T215247. Imagine you have the archive partitioned by the year (month, etc.) and the counter. Then, by the year's end, the counter could have increased up to 5. When the year ticks, the counter stays at 5, but you want to start from 1. We solve this by having the bot check for archive existence and decrement the counter in a loop until it finds an existing archive.
Tue, Mar 14
The script is here: P45844. But it can only test "all numeric" dates, such as "14. 3. 2023". So it makes sense for all languages that need to recognize inputs like these.
Mon, Mar 13
Mon, Mar 6
Fri, Mar 3
Thu, Mar 2
Wed, Mar 1
Feb 21 2023
Feb 19 2023
Feb 18 2023
Feb 17 2023
I will try to summarize what I have learned.
The query planner may start from the image table (iterating rows by img_timestamp in descending order), find the matching row in recentchanges (likely using rc_namespace_title_timestamp or rc_name_type_patrolled_timestamp index) and look up ct_rc_id = rc_id AND ct_tag_id = # in change_tag (also indexed). If the chosen tag is rare (or hasn't been used recently), the scan of the image table will take a lot of time, and the query will time out.
Feb 11 2023
Does STRAIGHT_JOIN have anything to do with that? Would something like the fix for T298225 (SpecialRecentChanges::isDenseTagFilter) help?
Please upload your changes as a patch for review to Gerrit, where the code can be reviewed.
I believe this is another problem solved by the fix for T307865.
It does not display on https://en.wikipedia.beta.wmflabs.org/wiki/Special:Contributions?safemode=1, so it seems to be some local customization.
Feb 5 2023
Yes, or wikibase_edit_tests.py, if you plan testing write actions.
Feb 4 2023
Feb 3 2023
I can't say it is okay, but it's somewhat understandable, given that the entries keep a reference to the revision, which the filter is supposed to evaluate.
For the time being, it's necessary to find an unconfusing way of presentation, such as:
Feb 2 2023
Cannot reproduce.
Feb 1 2023
I believe it doesn't. This problem occurs in PhpDateTimeParser, which is used after the other two fixed parsers. So as long as they "catch" all these dates (and I hope they now do), PhpDateTimeParser simply won't be used and this bug should not happen.
Yes, Pywikibot already uses that library.
Jan 26 2023
I think this was fixed (or at least improved) with T139603: Show text changes when moving text chunks (#2). No screenshot was provided.
The link is dead, and no screenshot / sample text to reproduce was provided.
Jan 25 2023
Regarding T140960, how does it relate?
Jan 24 2023
The above patch adds an optional single-tag filter (incl. inversion). It uses the recentchanges table (already joined when "Hide patrolled uploads" was selected), which limits the results to the last 30 days.
The following queries (filter for/out uploads with the "cross-wiki-upload" tag, all or unpatrolled only) can be tested for performance:
Jan 20 2023
No, keep it for now.
Jan 18 2023
Jan 15 2023
Jan 14 2023
Jan 12 2023
From the patrollers' point of view, the current behavior is a bit destructive because it irreversibly deletes the rows and leaves no way to patrol them later, even though they have not expired yet. It's also inconsistent with the situation when the page is moved without leaving the redirect. Then, the rows are kept. Therefore, I second this request.
Jan 11 2023
Note that T174349: Allow tag filter on Special:RecentChanges and Watchlist to be inverted (enable the not operator) has finally been implemented. Instead of using CSS, just exclude (highlight) the tag from your default recent changes view. I guess this task can be closed.
Jan 9 2023
"all-numeric" should already be handled in both TimeParserFactory and MonthNameUnlocalizer, if I got it right.
SDC does not seem to provide this information. It's accessible for files on all wikis using:
Jan 6 2023
Jan 4 2023
Jan 2 2023
It's still quite a mystery to me why that happens and why it happens for Czech, but not e.g., English. (I suspect the results come from PhpDateTimeParser.)
Jan 1 2023
There are still some gaps, and the support is somewhat lame (e.g., not possible to create a lexeme). I had already updated a similar warning on https://www.wikidata.org/wiki/Wikidata:Creating_a_bot.
Dec 30 2022
Dec 28 2022
Dec 25 2022
Maybe there is a way to optimize SiteLinkCollection.toJSON further so that we don't do unnecessary API calls (though they get cached).
But this would not fix the problem because sometimes you really have to read a different site information (this is the operation that failed) and it should not matter whether you've already got an account there or not. Maybe something changed upstream?
Dec 16 2022
Dec 15 2022
So it does FORCE INDEX (log_actor_type_time), which is defined as
Dec 14 2022
I was primarily focused on fixing the parent task T221097. When you use Czech (cs) as the interface language and type some dates in the format "DD.MM.YYYY" or "DD. MM. YYYY", they are either parsed with the day and month swapped or the produced date is completely nonsensical. (This does not happen when you use English.)
For example:
- "11. 12. 2022" is interpreted as "November 12th, 2022", although "December 11th, 2022" is expected.
- "07.05.1997" is interpreted as "June 30th, 1997" (huh?), although "May 7th, 1997" is expected.
Dec 13 2022
Dec 10 2022
Dec 6 2022
Plus it requires knowledge of how the editEntity dictionary needs to be structured, which isn't readily available for non-trivial examples.
Dec 4 2022
I have made a visualization of how each day is handled. It is interesting to see the patterns and also how they change depending on the input format and year:
Just make all changes to the item's attributes and then call item.editEntity:
Dec 3 2022
There are several places in Wikimedia deployed code where rc_new is still used in queries: