+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 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 :)

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

I will note Exporting Issues should be solved by the Wikisource extension which adds a download button on pages that can be downloaded.

Noting that implementing infinite scrolling will effectively result in a decline of T325607 since infinite scrolling is effectively unsupported by Google bot. :(

In T365806#9829770, @cscott wrote:

These are proposals/help-wanted for now. The WMF annual planning process also deals better with discrete features/interventions, so if we can collaboratively hammer out the mechanics here it makes it easier to insert into planning to get resources allocated.

@Tgr, as mentioned above the Wikisource extension appears to already doing this server-side on a separate WMCS cluster. Also, the Collection extension was removed from Wikisource a while ago (see T358437).

Doesn't the Wikisource extension already account for this ?

@cscott Do you plan on working on these in the long term? Or are these just ideas?

Pushing this to MediaWiki-Engineering to help figure out code review since (based on the Maintainers docs) they own the API component.

Looking at @Edtadros's screenshot, the divider in [ edit | edit source appears to be of insufficient contrast, is this a seperate bug or a something we missed ?

https://gitlab.wikimedia.org/toolforge-repos/matchandsplit uses the configuration and appears to be working mostly fine.

My solution with Redis+Celery is to add a health check script that pings my worker(s), if the worker does not respond, Kubernetes kills the trainwreck and restarts the container.

I got nerd-sniped by this task and created a rough implementation for this API parameter.

undefined should not show up there at all. This is a side-effect/symptom, not the actual issue.

@Pppery This can be done locally by editing MediaWiki:Guidedtour-tour-twa1.js

Hi, this proposal unfortunately was not selected for this year's GSoC program. We had multiple amazing applications this year and we had to make the tough decision of choosing a single candidate. Not being selected for this particular year does not reflect on your abilities or your qualifications. Hope you don't feel discouraged, and we hope you will stay on and continue contributing to the Wikimedia movement in some capacity :)

Hi, this proposal unfortunately was not selected for this year's GSoC program. We had multiple amazing applications this year and we had to make the tough decision of choosing a single candidate. Not being selected for this particular year does not reflect on your abilities or your qualifications. Hope you don't feel discouraged, and we hope you will stay on and continue contributing to the Wikimedia movement in some capacity :)

Hi, this proposal unfortunately was not selected for this year's GSoC program. We had multiple amazing applications this year and we had to make the tough decision of choosing a single candidate. Not being selected for this particular year does not reflect on your abilities or your qualifications. Hope you don't feel discouraged, and we hope you will stay on and continue contributing to the Wikimedia movement in some capacity :)

Hi, this proposal unfortunately was not selected for this year's GSoC program. We had multiple amazing applications this year and we had to make the tough decision of choosing a single candidate. Not being selected for this particular year does not reflect on your abilities or your qualifications. Hope you don't feel discouraged, and we hope you will stay on and continue contributing to the Wikimedia movement in some capacity :)

unassigning for now.