Fri, Feb 14
@Xover. Indeed, I should have read the code more carefully. The existing code seems to trim the line jumps at the end of the header and the line jumps at the end of the footer does not seem to be considered by the parser. So the change should not break anything hopefully. Sorry for the noise.
@WMDE-Fisch @awight a significant set of users in Wikisource introduces lines jump at the beginning of the Page: pages body to introduce or not paragraph margins. This behavior has been broken for a small amount of time in the past and a significant amount of editors complained. Maybe removing line jumps is the good way to go, but this needs some thought in order to at least get an idea of the number of affected pages.
Tue, Feb 11
I have upgraded Calibre to 3.48 (version in Buster backports) on both wsexport-prod01.wikisource.eqiad.wmflabs and wsexport-dev01.wikisource.eqiad.wmflabs.
@Samwilson Only wikisource-dev01 was running calibre 3.48 from backports. I just upgraded wikisource-prod01 to the latest backport Calibre version.
Wed, Feb 5
@Xover Thank you for the ping and the great summary for the problem.
A minor detail: ns250 is used by ProofreadPage only on the new wikis. Sadly, older wikis uses different ids for historical reasons. But for all wikis with ProofreadPage installed the canonical name of the Page: namespace is "Page".
Tue, Feb 4
@MusikAnimal Thank you!
Jan 20 2020
@Urbanecm Thank you cat /home/tpt/two_factor_reset on ToolsForge bastion should display T243240
Jan 17 2020
T242517 seems to have fixed the problem. I believe that we could close this task. I don't see the point for ProofreadPage to have a workaround for this bug that is now solved and affects other parts of the MediaWiki platform.
Jan 16 2020
Note that wsexport did used to be on its own VPS, at wsexport.wmflabs.org. I can't find anything about why it was moved. I guess it was just easier to maintain (and maybe some required packages became available on toolforge?).
Indeed, the extension does not allow to create pages directly with the "validated" level.
Jan 7 2020
Thank you for the bug report! It should be fixed indeed.
Dec 19 2019
After spending an hour reading phe tools code and reading the tool logs, I believe I got an idea of the cause of the issue.
Dec 13 2019
Dec 12 2019
Deployed on all Wikisources \o/.
Thank you! Seems to work fine on enwikisource https://en.wikisource.org/wiki/The_Wind_in_the_Willows_(1913)
Yes, because Wikidata is not setup there yet.
It seems that my fix indeed solve the "success is not a function". So, I believe this task should be closed.
Dec 3 2019
Dec 1 2019
Nov 24 2019
Nov 14 2019
Nov 13 2019
Nov 12 2019
This is a great idea! Adding this prefetch should be indeed fairly easy on the ProofreadPage side.
Nov 11 2019
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.
Nov 6 2019
@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)
Oct 31 2019
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.
Oct 30 2019
Oct 25 2019
Oct 11 2019
@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.
Oct 10 2019
Sep 28 2019
Sep 25 2019
@Tpt I can't remember if we ever added the magicword for overwriting and/or removing it on a specific page.
Sep 20 2019
Sep 12 2019
Jul 29 2019
@kaldari Done. The Community Tech team is already a maintainer of the tool.
Jul 19 2019
It maybe happens because the update of the page_props DB table is delayed until after the refresh of the Index: page.
Jul 4 2019
@Reedy Thank you!
Jul 3 2019
@Aklapper Indeed. Thanks!
Jul 2 2019
Jun 27 2019
@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.
Jun 26 2019
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.
Jun 21 2019
Jun 17 2019
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.
Jun 13 2019
May 26 2019
It is maybe related to T184867. Has the first page of the PDF a smaller size orresolution than the other ones?
May 13 2019
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.
May 9 2019
May 6 2019
Related guidelines: http://kb.daisy.org/publishing/docs/html/index.html