MediaWiki talk:PageNumbers.js

Certain page numbers are seemingly not handled elegantly
I was advised to bring this concern here when I closed https://phabricator.wikimedia.org/T122395

Recently when completing a work https://en.wikisource.org/w/index.php?title=NIOSH_Hazard_Review:_Carbonless_Copy_Paper&oldid=6025625

I did a Transclusion, where the page numbers generated by this script came up as missing or undefined, I checked the Index: based on a comment made in respect of something that was mentioned here - https://phabricator.wikimedia.org/T122196#1900902 about the pagenumbers.JS script being involed. This got me thinking as to whether the script was becoming confused due to the presence of "semi-raw" text with invalid or illegal charcters.

Removing the "." character in the pagelist for the Index concerned meant the Pagenumbers were no longer Undefined.

The relevant Index revisions being:-
 * https://en.wikisource.org/w/index.php?title=Index:NIOSH_Hazard_review_of_Carbonless_Copy_Paper.pdf&oldid=6025633 - where the page numbers transclude., and
 * https://en.wikisource.org/w/index.php?title=Index:NIOSH_Hazard_review_of_Carbonless_Copy_Paper.pdf&oldid=6025631 which has the "." the page numbers did not transclude as expected.

It has subsquently been suggested in a thread on the scriptorum (https://en.wikisource.org/w/index.php?title=Wikisource:Scriptorium&oldid=6027054) thet there are some other possible gotchas for the current incarnation of this script.

As it would be a time consuming (but not impossible) task to review 3000 (possibly more) or so Index pages over a single "illegal" character, is there a way for this script to be overhauled so that it can:


 * 1) At the very least warn about potentially difficult (or long "page-numbers" see Scriptorum thread) or
 * 2) Cook/wrap the formatting, so that it's possible to use otherwise illegal charcters, or even full blown formatting like a period or full-stop in "page-numbers".

It was also noted in the Scirptorum thread that at present this script wasn't considered Unicode stable, whilst this may not be a priority issue on English Wikisource, it may be a concern on other Wikisource where the script used relies extensively on Unicode for text/numeral representation. ShakespeareFan00 (talk) 23:33, 24 December 2015 (UTC)

Some random thoughts on stuff to do
Since I've been digging around this code a bit recently, here are some more or less random half-formed thoughts on stuff that might be worthwhile to do (or might be stupid and pointless; I haven't decided yet :D).


 * Gadget-ify the script
 * Would let individual users disable it and prevent it from being loaded at all.
 * Which in turn makes it possible to experiment with changes in a user script sandbox.
 * Would then need to set it as default so that all users and non-logged in users get it unless they opt out.
 * Would require porting it to be ResourceLoader compatible.
 * Would probably make it easier to tweak which namespaces it is active in.
 * The current approach is to forcibly load it for all users in all namespaces through MediaWiki:Common.js and then manually disable it in the other namespaces using code in Common.js
 * Tweak the page numbers off/inline/left/right and layouts toggle links to be more intuitive (checkboxes? in a submenu?)
 * Maybe split layout code into a separate Gadget? Why have layouts and page numbers code in the same Gadget?
 * Implement workaround for  in Firefox
 * By forcibly setting negative offsets to zero
 * I can think of no scenario where this use case would legitimately generate negative  values
 * Implement workaround for  in Webkit
 * By detecting that the  for the span for page N is smaller than for the span for page N - 1.
 * And briefly forcing that span to be  to get the correct.
 * Alternately, perhaps making the span non-empty by inserting a no-break space or some fancy Unicode character would be sufficient.
 * Maybe move the style sets for the different layouts into separate CSS files?
 * That would get them out of the script code.
 * We could then use the  function to add and remove them as needed.
 * And the code really rather badly needs some inline comments for documentation.
 * And it can probably be structured better too, but I'm not really sure how as yet.

So, half-formed ideas and not all of them may be even feasible, much less worth the inevitable change cost. But worth investigating and discussing at least, I think. --Xover (talk) 08:35, 7 September 2018 (UTC)