Actually, why not just show the page status indicator and page links wherever the <pages/> tag is used? It's also impossible to test stuff out in User space or the Wikisource space (which is where the Sandbox is at enWS).
Since there is a limited number of places books generally are published up to 1900 (in English, at least), it should be fairly robust to also consider placenames also separated by commas and semicolons (e.g. London, Green & Co.)
Wed, Nov 18
Wed, Nov 11
This has since been uploaded by Fæbot: https://commons.wikimedia.org/wiki/File:California_Digital_Library_(IA_auctionpricesofb02livi).pdf
Tue, Nov 10
Mon, Nov 9
@Soda, I don't have proof, but I think how it works is that the later attributes of the pagelist tag take priority over previous ones if there's an overlap. However text labels like "-" don't have a "numeric nature" any more, so a number scheme like "roman" has no effect.
I made a gadget (with proxying web service) to do this for the IA from an Index page. In theory the same system can work for Hathi too, but it needs an API key.
Oct 18 2020
I also can't seem to provoke Jenkins into running on the changeset.
@Xover Gerrit change here: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/634781
Oct 2 2020
It looks like newly-derived works receive a page numbering JSON file as well, for example: https://ia801506.us.archive.org/13/items/lnewman/lnewman_page_numbers.json
Aug 8 2020
@Soda thank you! Should I open a further issue for the other fields mentioned by @Xover? Several of those fields could be actively useful in gadgets at Wikisource and obviate the need for some fairly dodgy, if time-honoured, workarounds.
Jul 2 2020
Jun 30 2020
Jun 13 2020
Indeed, currently I get next/prev/index and current page offset in the file by scraping the links and wgTitle, which is not ideal.
Jun 11 2020
@Alex_brollo I think this might be due to things like this in the djvu_xml file:
If you look in the scandata XML file at the IA, some pages are marked <addToAccessFormats>false</addToAccessFormats>. For example the registration images (generally first and last, sometimes more). Skipping these images then brings everything back into alignment.
Jun 8 2020
Feb 6 2020
Also if the div starts with a line break (e.g. from a template):
* <div style="color:red;"> First paragraph. </div>
<ul> <li> <div style="color:red;></div> </li> </ul> <p>First paragraph.</p><!-- not red! -->
Feb 5 2020
I think the confusion comes from the message left at enWS Scriptorium by Max Klemm:
Sep 10 2019
@Xover exactly. Though I think it makes more sense for it to be pushed forward into the next <td>, otherwise it will be on a row that came from the previous page.
@ShakespeareFan00, no. The contents of MediaWiki:Proofreadpage pagenum template are inserted at the start of each transcluded Page. In the case of enWS, this is a span with a class of pagenum and some other bits and bobs. The local JS (on enWS, MediaWiki:PageNumbers.js) then uses those spans to insert the visible page numbers in the left margin.
Jul 26 2019
I think this is potentially the same as T215165?
Feb 5 2018
Sadly, I don't think arrow keys can be used as accessKey attributes, so if you do want arrow keys (which seem like a good idea to me), a JS method might be required. For example, this works for me (but the Shift-Alt prefix is not correct on all platforms):
Also, the forward/back buttons in the top tab bar should probably have rel="next" and rel="prev" attributes on them. This makes the paging explicit, which is generally good practice and also helpful for browser extensions that provide keyboard shortcuts for paging (like Vimperator and friends).
Sep 27 2017
Aug 24 2017
@Mahir256 yes, it does appear to be a duplicate. Sorry for the noise.