Agreed, this should need to block the train

(Moving to code-review requests)

In T323632#10793676, @Novem_Linguae wrote:

Even though i created this ticket (3 years ago), looking at it with fresh eyes i am not sure this is the best approach. These values are normally set in operations/mediawiki-config and there is a standard way to do it there.

For preparing to deploy pagetriage to ruwiki, i imagine iniquity setting yp a localhost wiki with pagetriage and exploring the features. Then noting their preferred settings. Then we can make one big settings patch for the mediawiki-config repo and be all done with configuring.

Where community configuration could hypothetically come in handy is if there are some settings that need to change a lot. I am not sure pagetriage wg variables need to change often though. I think they typically stay static.

In T393135#10787210, @DLynch wrote:

I did a little work on a related-but-separate take on this, as an edit-check inside of VisualEditor that'd warn a user when they were about to use a gendered term in an edit they were making. https://meta.wikimedia.org/wiki/User:DLynch_(WMF)/EditCheckGenderedTerms.js

In T388771#10640699, @kostajh wrote:

Thanks for your feedback, @Soda.

I'm unsure why this effort is spent building a new <UserInfoCard> component instead of spending the time making Reference previews, article previews, and the like user/script extensible and then building this feature on top of them ?

In my opinion, building the user info card in an extension will be more effective over a user script or gadget, from the point of view of stability, performance, discoverability, development velocity, and maintainability. I understand where you are coming from, and hope you can see my point of view on this as well.

I've spent a fair bit of time not trying to rewrite Navigation-Popups-Gadget. I'm unsure why this effort is spent building a new <UserInfoCard> component instead of spending the time making Reference previews, article previews, and the like user/script extensible and then building this feature on top of them ?

In T387339#10584413, @LGoto wrote:

Hi @Soda thanks for submitting this proposal! For the microtasks, could you add any Phabricator links or specific examples that could help a potential contributor?

The content here is generated from a interface message.

In T388095#10613970, @SunloungerFrog wrote:

My personal opinion, and I am new to NPP, so wouldn't want to disrupt the muscle memory of those who have been reviewing longer term.

However, I find it unintuitive that there are apparently two places to send a message from the curation toolbar: 1. from the "review" dialog (the tick), where a message may be sent to both the article's talk page and the creating editor's talk page, and 2. from the "tag" dialog (the tag), where a message may be sent to the creating editor's talk page only.

In T388095#10612469, @SunloungerFrog wrote:

T207452 is the previous ticket associated with the little red message alerts. As @Novem_Linguae said, there is currently no way - at least not one that I've found - for an NPP reviewer to post a comment only on the article's talk page and not also message the creator.

Coming at this issue from a developer's POV, my first thoughts are that this would significantly duplicate the existing functionality surrounding the feedback module, which already shows red alerts when any user leaves feedback on the talk page and allows reviewers to provide feedback to the creator or reviewer.

https://gerrit.wikimedia.org/r/c/mediawiki/extensions/PageTriage/+/1099747 ?

Huh, I stand corrected. My understanding/impression was that when Twinkle tags redirect, it does not convert them to articles but that does not appear to be the case.

The correct solution to this is fixing T375440, not moving the code around.

Yep

Based on talking with the Moderator-Tools-Team, we should delay the implementation of this feature until after the migration of info module to VueJS is finished.

In T362827#10489123, @Kgraessle wrote:

I had one issue testing this locally, when you select tags the button is not updating with the number of tags selected, see screenshot below

@Ninovolador I've tried looking at this before, the patch is part of a larger series where one depends on the other and there are issues with the previous ones, which makes merging anything in the chain separately need a lot of time.

What is the context behind this ticket ?

That would need to be deliberate, I don't think this is a case of a patrol-conflict.

I'm struggling to comprehend which part of this is not intended behavior ?

In T381732#10389122, @Gopavasanth wrote:

Nice observation @Soda, could you also share the steps you have followed to remidate the same?

@Gopavasanth The issue was a mis-configured redis server that ran out of space.

It's working now!

Ack! Looking.

Update ext.checkUser.clientHints to obtain list of fonts and generate a canvas fingerprint

Have we exhausted all avenues of passive fingerprinting? Canvas and font fingerprinting feel like a massive overreach in terms of violating a user's privacy in a way that a user cannot explicitly opt out of. (Outside of ceasing to edit Wikipedia)

In T380822#10357518, @Wargo wrote:

1. I think all these options, including keywords, should be checkboxes, not radios. You can then add different criteria and disable some of them, like this field.
2. I think, there should not be radios and checkboxes next to the inputs. Emptying field should be enough.

In T379301#10301476, @DTorsani-WMF wrote:

This looks like the @color-warning is being applied as a background color, when that is actually meant to be used as a text color. There is a @background-color-warning-subtle token that is meant to be used for backgrounds.

In order to ensure proper accessibility across both light and dark modes, I would suggest using the Codex InfoChip as it is intended to be used. We recently made some updates to the color and style of InfoChip, so this new version may work better for this use anyways.

If not mysqldump, at least mariadb-dump should be included.

I don't think the first error has much to do with PageTriage besides the fact that it loads CU and ORES in the same environment.

In T326940#10233463, @kostajh wrote:

In T326940#10233458, @Soda wrote:

In T326940#10233435, @kostajh wrote:

In T326940#10233423, @Soda wrote:

@kostajh I think this a fragile stop-gap approach, since we are effectively breaking/disallowing this configuration from ever existing. Can you point out what exact work ProofreadPage 's pagequality extension needs (or how I can test if ProofreadPage works with temporary accounts) ? I'll be happy to test and/or make the necessary changes.

I think it would involve setting $wgAutoCreateTempUser['enabled'] = true; in your local environment, enabling the extension, and then checking the feature set of Proofread Page to validate that nothing is broken.

Hmm, tested, does not appear to have show-stopping bugs (no full-page errors),
Only one thing, I assume having the username as part of revision output like so:

<noinclude><pagequality level="3" user="~2024-1" /></noinclude>....<noinclude></noinclude>

is not a problem?

That seems fine to me. How did you test, can you share your steps?

In T326940#10233435, @kostajh wrote:

In T326940#10233423, @Soda wrote:

@kostajh I think this a fragile stop-gap approach, since we are effectively breaking/disallowing this configuration from ever existing. Can you point out what exact work ProofreadPage 's pagequality extension needs (or how I can test if ProofreadPage works with temporary accounts) ? I'll be happy to test and/or make the necessary changes.

I think it would involve setting $wgAutoCreateTempUser['enabled'] = true; in your local environment, enabling the extension, and then checking the feature set of Proofread Page to validate that nothing is broken.

@kostajh I think this a fragile stop-gap approach, since we are effectively breaking/disallowing this configuration from ever existing. Can you point out what exact work ProofreadPage 's pagequality extension needs (or how I can test if ProofreadPage works with temporary accounts) ? I'll be happy to test and/or make the necessary changes.

@kostajh Why would the pagequality permission be unavailable to a temp account on their first edit ?

This is a symptom of the issue, not the actual issue.

Is there consensus for this ? I think implementing this feature is fine, making it the default would (imo) require some semblance of a community consensus.

Don't we already highlight articles that are 60 minutes old?

@kostajh Which parts are affected ? I remember working on this for a bit in early 2023.

I trawled through Logstash and wasn't able to find any errors :(

I can't reproduce this at all, @Innisfree987 could you provide some more context on how you encountered this error ?

CropTool has been having similar issues and is unable to connect to mediawiki.org and/or commons.wikimedia.org. See Commons_talk:CropTool#Unable_to_open_any_image_in_CropTool.

Per RFC above.

Boldly closing this as declined, phetools OCR hasn't been up for a while (since 5 years?) and with the Grid engine shutdown of the tool, a revival seems unlikely.

Hmm, this doesn't appear to be a regression after a bit of digging, the associated code (includes/Hooks.php:227-231) seems to have been last changed 4 years ago.

In T217223#10040350, @Novem_Linguae wrote:

Oh, and @Soda, you mentioned "Based on using the debug mode". Can you talk a bit more about this? If I want to also use debug mode to see what you see, any tips for me to enter debug mode? Is this a Visual Editor / DiscussionTools debug mode or something else?

The debug mode pops up when you use ?debug=true to any URL and then open the DiscussionTools dialog (to see the model changes, you need to select <show model> and <update on change>). It seems to be specific to VisualEditor/DiscussionTools.

I had similar results on a Pixel device that I own. Tho based on some percussive testing this seems like just a side effect of T217223. It seems like Android (and other Google-adjacent hardware) is missing some events that the VisualEditor tracks. In my experience, the reproduction case is as such:

That page was documenting the progress of the project with the same name.

Triaging this as high, since this is adding quite a few old pages into the queue. @jsn.sherman could y'all take a look at the linked patch :)

In T370593#10000626, @Novem_Linguae wrote:

Maybe it'd be a good idea to go back to the status quo ante behavior immediately. Then once that fire is out, we can take our time and potentially re-RFC the issue.

This is indeed a regression caused by the linked patch, however, I'm a bit uneasy fixing this due to the existence of T159028 (cc @Pppery who mentioned this in the NPP Discord). Maybe we could get a consensus that implementing T159028 is no longer desirable?

+1 to this, a Wikisource yearinreview will be a good idea

The steps should approximately be:

• Create a page
• Delete said page
• Create a new page with the same name
• Check that PageTriage shows: "possible issues: previously deleted"
• Move said page to a new title

In T363533#9968679, @Anujagrawal wrote:

@Aklapper Check on patch failed and according to console it happened due to linting errors. What could i do?

@Anujagrawal Can you link to your patch ?

@Balajijagadesh Could you explain what the difference is ?

See https://github.com/Jayprakash-SE/indic-ocr/pull/8

@Balajijagadesh which Indic OCR service is this ?

I don't think this can be reproduced since we moved hosts over the bookworm system (the logs are in the now shutdown system)

I assume these have community consensus ?

Hmm, that is weird, my patch does not touch afd_status and related variables in any way (in fact the patch should have no effect on the Javascript being loaded). I'll try to check this tmrw.

Is this ready for use in other extensions ?

Thanking bots is allowed globally.

In T363250#9938034, @Pppery wrote:

I have been ticking off done items from the checklists. The biggest delayer is Countervandalism-Network - nothing has been done there since August 2023, and about half of the post-creation tasks are pending only that. But I have no idea what to do to cause that to be done.

In T363250#9928848, @Dcljr wrote:

In T363250#9917916, @Soda wrote:

In T363250#9917903, @Hakimi97 wrote:

Hi, our community from Malay Wikisource is curious about normally who will be in charge of the configuration for the namespaces, logos and wordmarks? Will the configuration of the namespaces, logos and wordmarks done after all the wiki import task done, or the configuration could be setup at anytime?

Nobody in particular is in charge. Y'all will need to follow the general steps outlined in Requesting_wiki_configuration_changes

Are you saying these unchecked items in the task description have to be requested separately by the wiki community? I thought they were already "in the pipeline" to be done.

In T366032#9928634, @Dzahn wrote:

Hello @Soda,

this is still pending. Based on the tickets you linked that you work on, maybe you can ask @Samwalton9-WMF to be your sponsor? Do you normally chat with any WMF staff somewhere?

Let us know which teams and we can try to help.

Marking this as declined since you can now thank bots per this global RFC and subsequent implementation at 984288. :)

In T365071#9927056, @Jdlrobson wrote:

@Novem_Linguae we are aiming to deploy dark mode to all wikis on 16th July. Do you need any help working out what to do for this ticket?

In T366991#9894076, @Kgraessle wrote:

In T366991#9886912, @Soda wrote:

In T366991#9886099, @Kgraessle wrote:

Hi @Soda
Thanks for your work!

I have one suggestion to move the blocked check before the role check so that it accounts for anyone who is blocked even if they are autoPatrolled or patroller. How it is coded It will never run the is blocked check for those users. Is there a specific reason for this? If that's the case then we should add a test case for people who are blocked even if they are autopatroller and patroller.

if (
        $patrolPermissionStatus->isBlocked() ||
       $autopatrolledPermissionStatus->isBlocked()
) {
       $this->dieBlocked( $patrolPermissionStatus->getBlock() );
        return false;
}

 if ( $isPatroller && $isAutopatrolled ) {
         return true;
 }

I think we should be fine since $this->getAuthority()->definitelyCan(...) also evaluates blocks and will never allow

if ( $isPatroller && $isAutopatrolled ) {
        return true;
}

to execute and return with true. The added integration test also tests for this case since it uses sysop which has both autopatrolled and patrolled rights on a default instance.

However, that being said, the code doesn't make sense from a semantic/readability POV and I've changed it.

In T366991#9886134, @Novem_Linguae wrote:

nit: unnecessary extra space at the end of $pageId = $this->makeDraft( 'Test ' ); (after the word Test) in two places

Fixed :)

0001-Prevent-blocked-users-from-being-able-to-review-unre.patch4 KBDownload

Hello Soda, thanks for your work, I took another look and it looks great!
I have one minor review comment:
The false is unreachable here after the dieBlocked function is called.

if ( $patrolPermissionStatus->isBlocked() ||$autopatrolledPermissionStatus->isBlocked() ) {
			$this->dieBlocked( $patrolPermissionStatus->getBlock() );
			return false;
}

In T363250#9917903, @Hakimi97 wrote:

Hi, our community from Malay Wikisource is curious about normally who will be in charge of the configuration for the namespaces, logos and wordmarks? Will the configuration of the namespaces, logos and wordmarks done after all the wiki import task done, or the configuration could be setup at anytime?