This is a great idea! Adding this prefetch should be indeed fairly easy on the ProofreadPage side.

I believe I'm the closest of what we could call a "maintainer" of the current version. Marco made a project to rewrite the tool, the backend seems to be more or less finished but the frontend as not moved much.

@EBernhardson This bug seems to be related to the change in MediaWiki search PHP API. May someone from your team investigate it?

Priority: High for Wikisource (breaks a special page)

Change deployed on Wikisource.

I just made a change that should fix the problem: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ProofreadPage/+/547490
It is based on a fix for Timeless by @Isarra (thank you!) that I just merged: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ProofreadPage/+/533327/3

Priority set to high: breaks the UI of all Wikisource Page: pages on the default skin.

@Bmueller Thank you for the proposal! It looks great to me. +1 to split into two groups. Having a significant amount of time like you proposed for the last step with everyone seems very useful to me because the two groups conclusions might overlap and/or conflict significantly.

I agree with Amir that this is a very important topic.
For example, Wikisource workflows rely a lot on templates that are slightly different in each wikis, making very hard hard to roll out change in all wikis. It leads to an increasing technological gap between big and small wikis.
Global templates/modules might decrease the technical gap that exists between wikis.

@Tpt I can't remember if we ever added the magicword for overwriting and/or removing it on a specific page.

@kaldari Done. The Community Tech team is already a maintainer of the tool.

It maybe happens because the update of the page_props DB table is delayed until after the refresh of the Index: page.

@Reedy Thank you!

@Aklapper Indeed. Thanks!

@Lydia_Pintscher Improving JSON-LD structure like I proposed requires a strong refactoring of Purtle. I would not commit to do it anytime soon and I believe no one else would. So, I don't think it's a good idea to block JSON-LD deployment for that.

Extension:Replace_Text only works on pages content with content model "wikitext". ProofreadPage Page: pages are using an other content model ("proofread-page"). Extension:Replace_Text might be extended to support ProofreadPage content models to.

QueryPage was supposed to use the returned values of QueryPage::getOrderFields() to sort the results instead of value. it seems that recent code dropped partially this feature. Adding back the full support of QueryPage::getOrderFields() or, at least, strongly deprecate it seems the proper way to go.

It is maybe related to T184867. Has the first page of the PDF a smaller size orresolution than the other ones?

Option B seems the most usable to me and the most consistent. Prefixes like "c-wd" has the disadvantage of still having "wikidata" in it, and it's imho quite confusing.

Related guidelines: http://kb.daisy.org/publishing/docs/html/index.html

Thank you!

Wsexport is now using /data/project/wsexport/tool/temp as a temp directory. There are some files still leaked there, maybe because of an error while generating them.

An error that seems to be related:

@Samwalton9 This OAI-PMH feed was targetting the Index: pages of Wikisource, so instead of having "Hamlet" you might have "The Complete Works of William Shakespeare, volume 1, 1919". It's probably not what you are interested in. @Samwilson tool sounds more suitable to the Wikipedia Library use case.