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.

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.

In T221097#8441237, @matej_suchanek wrote:

I have made a visualization of how each day is handled.

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.

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.

Yes, or wikibase_edit_tests.py, if you plan testing write actions.

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:

Cannot reproduce.

https://cs.wikipedia.org/wiki/MediaWiki:Gadget-courses.css

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.

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.

Regarding T140960, how does it relate?

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:

No, keep it for now.

In T156920#8470905, @Dreamy_Jazz wrote:

MassMessage implements it's own diff engine that can be used. It's called MassMessageListDiffEngine.

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.

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.

"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:

But in the case of 5. vs. 4., the length is the same; since PHP 8.0, uksort retains the original order in that case, but in production (PHP 7.4, until T319432) the sort is not stable and may apparently swap the dates around arbitrarily.

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.)

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.

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?

In T322178#8473081, @Mehrpw wrote:

In T322178#8449823, @Aklapper wrote:

Hi, this seems to be an on-wiki content problem. These are not tracked in Phabricator.

It is not. Please reread the above messages from other users a little more carefully.

So it does FORCE INDEX (log_actor_type_time), which is defined as

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.

Plus it requires knowledge of how the editEntity dictionary needs to be structured, which isn't readily available for non-trivial examples.

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:

There are several places in Wikimedia deployed code where rc_new is still used in queries: