Tue, Sep 4
Closing at resolved, as it was a configuration issue related to br.source only, and it seems to have been solved.
Aug 4 2018
Jul 12 2018
Jul 11 2018
The change is live, it is now possible to sort by the number of pages that need to be validated.
Jul 6 2018
Jul 3 2018
Jul 2 2018
Jun 30 2018
I uploaded a patch for the first point, "Add a sort by the number of page remaining to correct".
Jun 28 2018
Jun 15 2018
On vec.wikisource, which has a small number of pages, PagesWithoutScans correctly doesn't show disambiguation pages.
So this seems to be more of a configuration problem.
The special page tries to exclude disambig pages, first by looking into Mediawiki:Proofreadpage-disambiguationspage, which should contain the pagename of the disambiguation template (only one); if this is not found, it looks into Mediawiki:Disambiguationspage, which should contain a list of all disambiguation templates.
On br.source, the first one points to a non-existing template, the second is empty.
Can you try to set either one of these two messages and see if this solves the problem?
Jun 14 2018
The odd/even feature is now available. Instructions have been added to https://wikisource.org/wiki/Wikisource:ProofreadPage#The_%3Cpagelist/%3E_tag
There is one page originally in the Page: namespace which is now appearing in https://pms.wikisource.org/wiki/Special:Contributi/Candalua as "Special:Badtitle/NS250:Agrumi - August Kopisch - 1838.pdf/56". Is it possible to fix it? (or delete it, whatever is easier - it's just one page)
Jun 12 2018
Jun 8 2018
Looks like something is wrong with the namespaces. Right now I see the following namespaces exists:
Pàgina ns102 - Discussion ëd la pàgina: ns103
Tàula: ns104 - Discussion ëd la tàula: ns105
Page: ns250 - Page talk: ns251
Index: ns252 - Index talk: ns253
Jun 7 2018
Done. It is now possible to configure then new system messages "proofreadpage_qualityX_summary".
Jun 6 2018
Jun 4 2018
What is the situation here? I see that a change has been submitted and modified several times (last edit on March this year), now why is it stalled?
May 31 2018
Closing as resolved.
May 30 2018
It's a nice idea! However, the syntax 6to105=onlyodd won't allow to choose the numbering style or to assign a fixed value.
Instead, I'm thinking of adding another block to the "range" syntax, like:
Let assume that the page Page:foo.djvu/1 contains the wikitext hyphen- and the page Page:Foo.djvu/2 contains -nated
May 29 2018
I opened a similar request T195873 on behalf of the Japanese community.
I submitted a patch for a possible solution. After some research, I decided to go for the "regular hyphen solution", as it is the most intuitive for the users, and the least likely to create problems with parsers, Visual Editor, and everything (but I would appreciate some feedback about this).
May 20 2018
May 17 2018
I created a separate task for the site request related to zh.source: T194875.
This is related to T60062, which is about providing a default index template
I'm removing the ProofreadPage tag, as this seems not related to the extension, but more like a general issue about how templates (and namespaces) work.
May 6 2018
I'm currently working on this. My plan is:
- to mirror the 3 current styles normal, roman, highroman I would introduce folio, folioroman, foliohighroman
- for clearer reading, show both the r and the v, in superscript
To simplify the problem, I'll assume the first page in the range is always a recto.
May 5 2018
Ok, second try. This new patch uses a configuration variable rather than a system message, as suggested by Tpt.
The project(s) which want to suppress the space between pages will have to set wgProofreadPagePageSeparator = "".
By default the value will be   as before.
May 4 2018
May 3 2018
Seeing that this task was still stalled, I finally gathered the courage to prepare a patch myself, following wmr's and Sam Wilson's suggestions.
I named the new system message MediaWiki:Proofreadpage page separator.
Apr 30 2018
Apr 29 2018
Oh, it was not clear to me that your suggestion involved non-sysops too, now it makes more sense. Anyway, our need is just for sysop actions, like mass deletions (which happen periodically, every time that some new Wikisource subdomain is approved and content is migrated there and needs to be deleted).
No, why should we complicate things? We have very few sysops and crats, and they're active in other projects as well, so we surely don't want the extra paperwork of posting requests and granting them.
Feb 20 2018
Jan 8 2018
I tried WsExport with mobi format several times in the last weeks. Most of the time it gave a "Bad gateway" error, but in a few occasions it worked correctly. I don't know if this can help.
Nov 8 2017
Aug 4 2017
I also noticed the same behaviour since today.
Also T102888 (show interwikis from Wikidata on special pages) still has to be solved.
Since today, even the hard-coded interwikis are not displayed anymore. I can see them on https://it.wikisource.org/wiki/MediaWiki:Recentchangestext, but not on https://it.wikisource.org/wiki/Special:Recentchanges.
This behaviour has also been reported on T172461.
Feb 28 2017
Feb 27 2017
Jan 30 2017
Jan 7 2017
Sep 26 2016
Sep 24 2016
While now the zoom buttons always work for me (thank you @Tpt!), I noticed that sometimes it is still not possible to move the image. When this happens, clicking on one of the zoom buttons makes the image moveable again.
Sep 23 2016
@Samwilson Since 2 days ago, when switching to the horizontal layout, the image becomes extremely big. Is it related to this change?
Tested on it.ws and en.ws, same behaviour.
Sep 12 2016
The problem seems to be in the final lines of https://phabricator.wikimedia.org/diffusion/EPRP/browse/master/modules/page/ext.proofreadpage.page.edit.js
It looks like $(window).load() for some reason is not firing. I am not sure how to fix it though.
Sep 9 2016
The limitation of linking to one page per wiki will be overcome when T128173 will one day be implemented. In the meantime can you please proceed to give Wikidata access to wikisource.org? Are there other technical reasons for not doing it?
Sep 5 2016
In addition to what Billinghurst reported about Wikisource, page transclusion is also a major cause for the need of purging: very often, when a transcluded page is modified, the transcluding page remains outdated even for several minutes, and we have to purge it to refresh it.
Mar 3 2016
Developers: will this task get easier if T64717 is implemented?
So now some THOUSANDS of pages on it.wikisource and elsewhere are BROKEN, thanks to this change. And nobody even cared to tell us in advance. Great.
Yes, but while the change in itself is correct, it has broken all the pages using the old syntax!
So either this change is reverted, or a bot should be run on all subdomains to change all pages to the new syntax.
Feb 25 2016
OK. I'm opening a formal discussion on the project to gather consensus about the move:
Feb 22 2016
Jan 11 2016
Dec 22 2015
Dec 1 2015
Oct 23 2015
Oct 8 2015
Oct 6 2015
Sep 14 2015
Sep 2 2015
Aug 25 2015
@Aklapper: so what are the answers to my questions? "Yes"? "No"? "Maybe"?
@Krenair: is community consensus the only obstacle? Should we open some poll to get the consensus?