MediaWiki talk:PageNumbers.js

From Wikisource
Jump to navigation Jump to search

Certain page numbers are seemingly not handled elegantly[edit]

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:-

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)[reply]

Some random thoughts on stuff to do[edit]

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 .offsetTop in Firefox
    • By forcibly setting negative offsets to zero
    • I can think of no scenario where this use case would legitimately generate negative .offsetTop values
  • Implement workaround for .offsetTop in Webkit
    • By detecting that the .offsetTop for the span for page N is smaller than for the span for page N - 1.
    • And briefly forcing that span to be display: inline-block to get the correct .offsetTop.
    • 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 .addCSS() 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)[reply]