My apologies, this slipped my mind once my WiFi was restored. I’ll resolve the merge conflicts and reviewer comments within a few days and submit an updated patch. :)

Hi! Thank you very much for the patch review,. I’ve addressed all concerns, but due to a problem with WiFi (I am writing this on my phone) I’m currently unable to submit the new patch. I should be able to by next weekend when it is repaired. Thanks again! :)

There was a minor merge conflict in the patch caused by a change merged to main in the last few days, I’ve reconciled this, so it’s ready for code review now, but absolutely no rush for that! :)

Change rebased ontop of protected variable changes (latest master) and ready for code review!

Thank you for fixing the CSS - I couldn't figure out the right parameters myself! :)

Re the max size in bytes sometimes appearing on the same line as the dates, I'm trying to find a fix for the CSS to resolve this now, thank you very much to JSN and sam for the pickup! :)

Using the $wgMaxPageSize to pre-fill the form was actually a workaround for a another issue I couldn't resolve which was that there's no way to tell the difference between a user actually listing 0 as the max page size (which is a valid way to find only 0-byte pages which can exist) or leaving the field blank (thus not wishing for it to be used) when there is no default set. Setting the "default" value for the form in OOUI, which I set to the technical maximum possible page size, makes the box pre-filled with that number. I'm not too experienced with OOUI so if anyone sees a workaround that would be very much appreciated, I'll try and investigate and see if I can find another way we can do this.

Hmm... thank you for the pick up, I'm not quite sure what can be causing this but I'll investigate. :)

Also you can't use intitle: and then provide a regexp just for the title, something this patch supports in TitleQueryStringQueryBuilder (which is not the default one, that's TitleSimpleMatchQueryBuilder which provides better partial n-gram matching but it's configurable which one you use) .

Yes, I did consider that, @dcausse, but I believe fully supporting this functionality in CirrusSearch offers a more intuitive and maintainable solution than simply prepending intitle: to every word. For example, to search for "cirrus search test" in the Nuke title field, we'd have to write the Cirrus query as intitle:cirrus intitle:search intitle:test, which feels cumbersome and inelegant. By implementing a dedicated doSearchTitle method (as I’ve done in the patch with separate code paths), we can provide a future-proof solution that allows us to fine-tune key aspects—such as weighting and scoring—specifically for title searches versus full-text queries.

@kostajh I just re-wrote this using the task template, but totally understand how busy everyone is with temporary accounts so no-rush re code review! :)

All changes implemented! Thanks to everyone for their time and input! :)

Did all requested changes! Thank you so much @Scardenasmolinar for all your time in providing feedback to all of my patches!! :)

Clarifying that the new way for filters to raise validation warnings is needed, because currently you can only have an error that blocks the search process, and I believe the things I've routed through warnings aren't necessarily errors that make searching impossible, but the user should receive a notice with the search results about them.

Hi! Thank you everyone for your replies.

Can reproduce. Also triggers the mlwiki welcoming bot.

@Scardenasmolinar, sorry for this mistake! I have now fixed the issue in the latest patchset I've just uploaded, it was a tiny typo in just 1 line! I've made the code a LOT more readable now to prevent things like this (including not just determining access as true/false but providing the exact reason they don't have/have access) and also implemented new tests to prevent regression of this block bug.

Same! @Scardenasmolinar currently in the code, if you are blocked you can see nuke and use it to query BUT if you a blocked admin and your block applies to the delete right, you can't continue to the delete screen (both blocked and unblocked non-admins can't continue to this screen).

Hi! Thank you for sorting this. This doesn't add any new information (like size in bytes) to the list of pages section that's becoming a table in that ticket, it only adds filtering options (a min and max textfield) to the options section above the list of pages and the options section doesn't seem to be being modified in the ticket you linked. :)

I have coded this up and submitted a patch. I'm not sure why the bot isn't commenting it, but here's the patch: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/AbuseFilter/+/1115319 :)

Thank you for your thoughtful feedback and for reviewing this patch amid your team's current priorities. There's absolutely no rush for this patch to be reviewed, and thank you for taking the time out of your busy schedule to provide this information!

All tests are now passing and I've fully implemented all functionality. :)

Ignore the other one that was just posted above (it was a mistake because I had a typo in the Change-Id and is now abandoned). Sorry for the inconvenience.

Ignore the other one that was just posted above (it was a mistake because I had a typo in the Change-Id and is now abandoned). Sorry for the inconvenience.

Thanks Niharika for the update! :)

Proposed new query (will integrate into getQueryInfo()):

SELECT gu_name, 
       MAX(gu_id) AS gu_id, 
       MAX(gu_locked) AS gu_locked, 
       MAX(lu_attached_method) AS lu_attached_method,
       IF(lu_name IS NULL, 0, 1) AS lu_local_exists
FROM globaluser
LEFT JOIN localuser 
    ON gu_name = lu_name 
    AND lu_wiki = <current_wiki_id>
LEFT JOIN global_user_groups 
    ON gu_id = gug_user
WHERE gu_hidden_level = <HIDDEN_LEVEL_NONE>
GROUP BY gu_name;

"unattached or doesn't exist locally" is the English version of the string centralauth-listusers-nolocal.

All done! This was fun, languages are sooo interesting! :)

Korean transliteration docs done (https://www.mediawiki.org/wiki/Help:Extension:UniversalLanguageSelector/Input_methods/korean-revised-romanization).

Bali transliteration docs done (https://www.mediawiki.org/wiki/Help:Extension:UniversalLanguageSelector/Input_methods/ban-transliteration)! It was fun to do a deep-dive on how the language works. Moving onto the Korean one now...

Writing the help pages now. It doesn't look like Gsaurav641 decided to self-assign and work on the changes (it's been over a month).

Submitted to Gerrit! Waiting for a reviewer there :)