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?

In T12347#9912216, @Quiddity wrote:

Thank you for the reply and the draft @JJMC89 , much appreciated.
I will postpone including this in Tech News for now, in the hopes that someone can write/update the related documentation.

In T364690#9898721, @Vladis13 wrote:

In T364690#9896615, @Soda wrote:

In T364690#9896515, @Vladis13 wrote:

And why, on each rendering, does the code recompile the index (mapping), although it does not change, and scan the pdf to Commons, which is not needed, since only text from the database is used? And besides the optimization problem, this leads to the discussed breakdown of the mass of pages.

As I said before the compilation does not happen on each render. It happens when a template transcluded/related to the page changes OR when the page is purged OR when the page is edited (basically ProofreadPage and the underlying parser treats the <pages /> tag like a series of templates and updates are triggered whenever mediawiki decides that the templates need updating).

Please answer my question above, and don't quibble with words. Re-compilations happens during rendering, or a couple of times less often when saves page/transclusions, there is almost no difference. Because when proofreading a book, there making a mass of edits/savings on tens and hundreds of pages of transclusions. And on each of these thousands of edits for each book, as you say, the code doing useless duplicates of re-compilations and https-requests to the Commons pdf, this leads to the discussed breakdown of the mass of pages of mass Wikisources.
Whereas in reality, the index page is usually edited only a few times, creating the desired listpages, nothing needs to be recompiled and everything will work without errors.

Please answer my question above, why?

In T364690#9896515, @Vladis13 wrote:

In T364690#9896511, @Soda wrote:

In T364690#9896454, @Vladis13 wrote:

In T364690#9895464, @Vladis13 wrote:

In T364690#9798210, @Soda wrote:

In T364690#9793607, @Vladis13 wrote:

In T364690#9793548, @Uzume wrote:

In T364690#9793303, @Vladis13 wrote:

This shouldn't happen because the <pages/> mechanism works with text in Page and Index NS. Whereas the mediafile is in File NS. These are independent spaces.

But they aren't independent because the Index and Page pages depend on the File (and the Page pages also depend on the Index).

No, <pages/> only uses existing text in Page NS, file is absolutely not needed for this and is not used, why. Page and Index NS only use file during index page creation and visually assist users in proofreading. So, <pages/> should continue to display that text without breaking pages when the file is deleted.

That's incorrect, ProofreadPage depends on the File namespace to build the pagelist, figure out valid Page: namespace pages and determine the transclusion order of the pages.

That's what I said. The file is needed only at the modes of creating the pagelist (index) and proofreading.

The <pages /> tag should only take the text of pages from the local Wikisource database, according to a list of a pre-generated index. Why would it access an image file in the Commons repository?.. Sounds like nonsense. If this is indeed the case, then this is a major non-optimization of the code.

The index is computed based on the image file, or through manually linked pages as a fallback. I do not see why this is a "major non-optimization" or "nonsense".

You state that with EVERY reading of a page of a work by site readers, the index is re-generated, scanning the file in the Commons repository. This is a time-consuming and resource-intensive operation.

Then it should be like this:

• Only when saving the index page (Index NS) does the extension analyze the arguments of the <pagelist /> tag (which defines the mapping: pdf page number = book page number or literal label), creates an index (mapping, it’s short, banal "[{1: 'image'}, {2: 4}, {3: 5}, etc. according to the number of pdf pages]"), and is saves in the database. This is all.
• When a reader opens a page of a work, the <pages/> tag works only with database 1) takes the pages mapping from the database, takes the range of page numbers according to the arguments in the tag, 2) takes the text of the pages from the database, cuts out the sections specified in the arguments, renders html: gluing the texts of the pages, inserting between them the page numbers of the book with links to the pages of the Page NS, according to the mapping (index). This is all.

Compare the resource costs of generating an index from scratch for each read, and one only when saving the index page. I think this is obvious.

The recompilation happens on page save or link update on related pages, not on every render.

And why, on each rendering, does the code recompile the index (mapping), although it does not change, and scan the pdf to Commons, which is not needed, since only text from the database is used? And besides the optimization problem, this leads to the discussed breakdown of the mass of pages.

In T364690#9896454, @Vladis13 wrote:

In T364690#9895464, @Vladis13 wrote:

In T364690#9798210, @Soda wrote:

In T364690#9793607, @Vladis13 wrote:

In T364690#9793548, @Uzume wrote:

In T364690#9793303, @Vladis13 wrote:

This shouldn't happen because the <pages/> mechanism works with text in Page and Index NS. Whereas the mediafile is in File NS. These are independent spaces.

But they aren't independent because the Index and Page pages depend on the File (and the Page pages also depend on the Index).

No, <pages/> only uses existing text in Page NS, file is absolutely not needed for this and is not used, why. Page and Index NS only use file during index page creation and visually assist users in proofreading. So, <pages/> should continue to display that text without breaking pages when the file is deleted.

That's incorrect, ProofreadPage depends on the File namespace to build the pagelist, figure out valid Page: namespace pages and determine the transclusion order of the pages.

That's what I said. The file is needed only at the modes of creating the pagelist (index) and proofreading.

The <pages /> tag should only take the text of pages from the local Wikisource database, according to a list of a pre-generated index. Why would it access an image file in the Commons repository?.. Sounds like nonsense. If this is indeed the case, then this is a major non-optimization of the code.

The index is computed based on the image file, or through manually linked pages as a fallback. I do not see why this is a "major non-optimization" or "nonsense".

You state that with EVERY reading of a page of a work by site readers, the index is re-generated, scanning the file in the Commons repository. This is a time-consuming and resource-intensive operation.

Then it should be like this:

• Only when saving the index page (Index NS) does the extension analyze the arguments of the <pagelist /> tag (which defines the mapping: pdf page number = book page number or literal label), creates an index (mapping, it’s short, banal "[{1: 'image'}, {2: 4}, {3: 5}, etc. according to the number of pdf pages]"), and is saves in the database. This is all.
• When a reader opens a page of a work, the <pages/> tag works only with database 1) takes the pages mapping from the database, takes the range of page numbers according to the arguments in the tag, 2) takes the text of the pages from the database, cuts out the sections specified in the arguments, renders html: gluing the texts of the pages, inserting between them the page numbers of the book with links to the pages of the Page NS, according to the mapping (index). This is all.

Compare the resource costs of generating an index from scratch for each read, and one only when saving the index page. I think this is obvious.

In T364690#9895441, @Vladis13 wrote:

In T364690#9798244, @Uzume wrote:

https://gerrit.wikimedia.org/r/1031631

It seems like that patch, when merged might solve the issue with finding <pagelist/> usage when the File media cannot be properly processed

The patch has not been accepted so far. Am I wrong, or will the broken pages and their tracking never be fixed?

This request appears to be stalled, setting the status to reflect this task's current state. @SatyamMishra Given the comments above, I think having the community vote on an "autopatrolled" user group (and having an "only autopatrolled" user group) is probably a good next step.

I haven't had time to look at Buster migration, but will do it within 15 July :)

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;
 }

Adding @jsn.sherman, @Scardenasmolinar and @Novem_Linguae could you guys take a look and provide a review :)

Potential fix:

This should already be fixed in 1.43-wmf.8 which should be deployed on Thursday.

In T12347#9852076, @Sdkb wrote:

We need to separate "people" out into readers and editors. For readers, the protection level has minor salience for information literacy purposes, as it can indicate e.g. how wary they should be of information on the page. For editors, the "can I edit?" question is primary, but the overall protection level still has some value for understanding the overall situation with the page (and can be accessed through the notice in the edit window or through the page information page).

I've removed everything that was Wikisource-related :)

@Ankry I see the code snippet is still there in plwiki's common.js, is it still required ?

In T211314#9849978, @Tacsipacsi wrote:

And yet it’s still used on a bunch of wikis…

In T12347#9844517, @Soda wrote:

In T12347#9844450, @mwilliams wrote:

Thanks for sharing @Soda! I'm seeing the same icon (Lock with nothing in it) for both semi-protected and fully protected. Is that to be expected as any update to the icon to visually communicate its protection level would be at a higher/ more specific presentation level?

In T12347#9841301, @RHo wrote:

It would be extremely helpful if screenshots could be added (and/or a patchdemo created) to show what the proposed change is for design review. Curious if for example how the proposed change differs from the exisitng padlock style, position, and behaviour as the current protected enwiki pages like this one:

Sent the information. (in an email titled Re: Information for T366032 (Sohom Datta))