MediaWiki talk:PageNumbers.js

From Wikisource
Jump to navigation Jump to search

Issue with page numbers placement[edit]

There are issues with pagenum placements when some formatting are used cross paged. (cf. discussion on french wiki)

Examples of issues: there, there, there, there or there

I solved this issue with this modification in PageNumbers.js

It calculates the positions of page numbers using offset (relative to page) instead of position (relative to parent)

Can it be integrated in the global script?

BrainslugClaptrap (talk) 10:24, 8 April 2020 (UTC)[reply]

@Ankry: This modification would need the help of an interface administrator Assassas77 (talk) 20:23, 9 April 2020 (UTC)[reply]
@BrainslugClaptrap: Applied. Thanks for the fix. Ankry (talk) 04:54, 10 April 2020 (UTC)[reply]
@Ankry: This caused other issues because of undefined offset(parameter)
Examples: missing page numbers in s:fr:Le_Cabaret
New issue fixed with fr.wikisource.org/w/index.php?title=Utilisateur%3ABrainslugClaptrap%2FPageNumbers.js&type=revision&diff=10364548&oldid=10364547
BrainslugClaptrap (talk) 09:29, 10 April 2020 (UTC)[reply]
Done hopefully. :) Ankry (talk) 10:14, 10 April 2020 (UTC)[reply]

Uppercase?[edit]

Would it be better to have an uppercase for "Liens vers les pages" instead of "liens vers les pages" if other messages in the left margin have an uppercase too (as on the French wikisource?) Or would it be uglier? --Zyephyrus 08:43, 14 August 2010 (UTC)[reply]

done —unsigned comment by Koavf (talk) 03:25, 10 November 2018‎.

Notes[edit]

double div container : http://en.wikisource.org/w/index.php?title=Copyright_Act,_1956_%28United_Kingdom%29/Part_1&oldid=2002363

JS Error[edit]

I'm getting the following error when I access pt:Elementos de Arithmetica/Capítulo 2 using Google Chrome: 

Uncaught TypeError: Cannot read property 'parentNode' of undefined
init_page_numbersindex.php:176

The line contains this: 

var cs = self.pagenum_ml[0].parentNode.parentNode;

On Firefox it is: 

self.pagenum_ml[0] is undefined
https://secure.wikimedia.org/wikipedia/sources/w/index.php?title=MediaWiki:PageNumbers.js&action=raw&ctype=text/javascript
Line 176

Could someone fix it? Helder 02:14, 8 March 2011 (UTC)

So, the problem is still happening in pages like this. Could someone fix it, so that the page numbers are displayed again? Helder 15:16, 15 April 2011 (UTC)
I cannot see any error in Firefox 3.6.15 when viewing those pages, and I can see page numbers (can be hidden with "Ocultar numeração" option). But, could pt:MediaWiki:PageNumbers.js be interfering in some way with MediaWiki:PageNumbers.js from oldwikisource? -Aleator 12:18, 16 April 2011 (UTC)[reply]
I'm also getting the error in Firefox 4 when trying to edit en:The Velveteen Rabbit.[1] Kaldari 17:28, 20 April 2011 (UTC)[reply]
Ah, when editing. That's true, also pt.source pages that Helder told for MF 3.6! :( -Aleator 23:31, 20 April 2011 (UTC)[reply]

Any updates? Helder 17:19, 21 June 2011 (UTC)

It should be right now, at least in the most common case, I've some doubt about uncommon case like a source tab is present but no page are transcluded. Phe 18:32, 27 July 2011 (UTC)[reply]

Fun with container wrap[edit]

Can somebody humor me and change the existing self-closing tag to one with a normal end tag in the following...

$('#contentSub').nextUntil('#catlinks').wrapAll("<div id='text-wrap'><div id='text-container'><div id='text'></div></div></div><div style='clear:both'/>");

to the following...

$('#contentSub').nextUntil('#catlinks').wrapAll("<div id='text-wrap'><div id='text-container'><div id='text'></div></div></div><div style='clear:both;'></div>");

... in this .js ? TIA. -- George Orwell III 23:47, 15 December 2011 (UTC)[reply]

Done, too much the habit of mediawiki allowing such idiom... — Phe 23:50, 15 December 2011 (UTC)[reply]
Beside that, did you see really a bug with that ? jquery document it as valid for input to function taking html element, it's not html compliant, but jquery handle <div /> (or at least it's used in their documentation...) — Phe 00:04, 16 December 2011 (UTC)[reply]
Thanks. I've read up on this and many claim behavior as you do but never had it proved an absolute non-issue in all its application(s) (i.e. some browser versions can handle empty self-closing tags most of the time but never do they all handle it correctly all the time. I figure why introduce the chance if we don't have to).
The real issue(s) I'm trying to run to ground is, first, - why am I getting an 'unterminated string constant' error (line 15, char 21) only when the dynamic page is in &action equals edit/submit mode; but there are several other bothersome parts to dynamic layouts taking place here beside that one. Why any of this needs to take place so high up in the div tree (#contentSub) when the 3 dynamic defined divs really should be right at or after the div where class="mw-content-ltr" (no id assigned) is if I've follow the premise here correctly. -- George Orwell III 00:24, 16 December 2011 (UTC)[reply]

Container wrap overkill[edit]

This script needs a major overhaul by somebody who knows what they are doing (i.e. not me).

The issue now at hand since some point prior to the end of last year (I believe) was the intoduction of a proper DIV container wrap for everything typed into (then saved) in the bodytext field by Users in edit mode. This makes today's implementation of dynamic layouts somewhat outdated if not complete overkill.

Apparently, this new DIV is now genertated by default (starts at line 400) skin-wide thanks to intiatives based elsewhere that are dedicated to improving translation/language compatibility foundation wide. Since dynamic layouts "invented" its own DIV container wrapping scheme originally in the absence of such a useful container at the time, usurping some of the basic no-nos by extending itself "above & below" the normal output(s) of the pagetext field in the process, this additional .php generated container presents an opportunity to correct some long standing DL issues if not additional headaches in the future if left unaddressed now.

Forgive me if I get the specifics wrong here (re: not me above), but if I've understood the current series of actions taking place in this script, where the 4 or 5 most common pre-DL indentation/prose -type div wrappers are first swept up and added to the 4 newly generated Dynamic Layout specific divs then wrapped as a whole before rendering to final state for display by these lines... 

        $(id).prepend($('#contentSub'));
        $('#contentSub').nextUntil('#catlinks').wrapAll("<div id='text-wrap'><div id='text-container'><div id='text'></div></div></div><div style='clear:both'></div>");

... then I believe the new lines to correct and/or improve Dynamic Layouts in light of the coming changes should be something like... 

        $(id).prepend($('#mw-content-text'));
        $('#mw-content-text').nextUntil('div.printfooter').wrapAll("<div id='text-wrap'><div id='text-container'><div id='text'></div></div></div><div style='clear:both;'></div>");

...of course, rhat might not be 100% right either & there may be other lines and/or scripts that may need tweaking to reflect the new and proper #mw-content-text container, & only that #mw-content-text container (not #bodyContent, #contentSub and similar out-of-bounds inclusions). Again - I'm not the person who would know such specifics & how they might be corrected. All I know is the current scheme has one too many div containers now and dynamic layout wraps above/beyond what is typed/transcluded into the edit box as before.

CAVEAT: In this new container, (<div id="mw-content-text" lang="en" dir="ltr" class="mw-content-ltr">), language direction is absolutely important for any of this to "work" as desired, not only for us w/our Dynamic Layout adventures, but for the translation/language project(s) success as well. The above "guesstimate" for what the new lines should be is english specific (language direction is left-to-right so the suffix for the class is '-ltr'). See how this needs to be correct for the language in use here. I have no idea how to insure this would be "scripted in" to work as advertied either.

Thanks in advance for any input or feedback on making this happen -- George Orwell III (talk) 06:42, 17 March 2012 (UTC)[reply]

@George Orwell III: I've removed the {{tl|editprotected}} template since no action had been taken in six (!) years. Is there still something that needs doing here? Jon Harald Søby (talk) 12:38, 10 October 2018 (UTC)[reply]

Proper page number decoding[edit]

This script is mangling page numbers like "1–2" and "bìa phụ" at the Vietnamese Wikisource into "1.E2.80.932" and "b.C3.ACa_ph.E1.BB.A5". Please replace: 

        var num = decodeURI( a.id );
        if(num.match(/^.CE.9E/)) num="Ξ";
        if(num.match(/^.E2.80.93/)) num="—";
        if(num.match(/^.E2.80.94/)) num="—";

with: 

        // Switch to URL encoding, except for hex-like sequences that would turn
        // into ASCII control characters.
        var num = a.id.replace(/\.([2-68-F][0-9A-F]|7[A-E])/g, "%$1");
        try {
            num = decodeURIComponent(num.replace(/_/g, " "));
        }
        catch (exc) {
            num = a.id;
        }

This is essentially a lossy implementation of an anchordecode: that would reverse the anchorencode: parser function. The try is in there because there may be false positives.

 – Minh Nguyễn (talk, contribs) 07:02, 8 October 2014 (UTC)[reply]

Minh Nguyễn, could you please take a look at the English version of this implementation to see if anything needs tweaking there as well. TIA. -- George Orwell III (talk) 01:32, 9 October 2014 (UTC)[reply]
Thanks for the reminder. I requested a change there as well, with a lengthy explanation of where the anchor encoding is coming from. – Minh Nguyễn (talk, contribs) 05:45, 9 October 2014 (UTC)[reply]

Simpler alternative[edit]

Better yet, please change MediaWiki:Proofreadpage pagenum template to add data-page-number="{{{num}}}" next to id="{{{num}}}".

And in this script, replace: 

        var num = decodeURI( a.id );
        if(num.match(/^.CE.9E/)) num="Ξ";
        if(num.match(/^.E2.80.93/)) num="—";
        if(num.match(/^.E2.80.94/)) num="—";

with: 

        var num = a.getAttribute("data-page-number") || a.id;

This alternative would be 100% reliable for any wikis that make the required change in MediaWiki:Proofreadpage pagenum template.

 – Minh Nguyễn (talk, contribs) 08:01, 10 October 2014 (UTC)[reply]

I'm annoyed it need a change in each wiki, I'll try your first proposal. — Phe 11:59, 10 October 2014 (UTC)[reply]
Done, look like to work. — Phe 12:22, 10 October 2014 (UTC)[reply]

{{editprotected}}

Thanks Phe, although come to think of it, the first version may trap legal or constitutional documents with pages like "1.20". I think it would be much less risky to combine the two approaches: 

        var num = a.getAttribute("data-page-number");
        if (!num) {
            // Switch to URL encoding, except for hex-like sequences that would
            // turn into ASCII control characters.
            num = a.id.replace(/\.([2-68-F][0-9A-F]|7[A-E])/g, "%$1");
            try {
                num = decodeURIComponent(num.replace(/_/g, " "));
            }
            catch (exc) {
                num = a.id;
            }
        }

So wikis that set the data-page-number attribute in MediaWiki:Proofreadpage pagenum template get the most reliable page numbers, and everyone else may have to put up with "1.20" turning into "1 ". Sorry for the inconvenience.

 – Minh Nguyễn (talk, contribs) 07:38, 12 October 2014 (UTC)[reply]

@Mxn: Is this still needed? It's a open item from a long time ago, so I'd like to close it. —Justin (koavf)❤T☮C☺M☯ 18:40, 7 December 2021 (UTC)[reply]

Broken JavaScript[edit]

MediaWiki developers found that this page probably breaks JavaScript for users (example: not seeing the buttons when editing a page). You probably need to edit this .js page and/or MediaWiki:Gadgets-definition as in the examples at phabricator:T122755. List more pages to check.

If you have questions or need help, please ask at phabricator:T164242. You can login with your wiki account. Best wishes, Nemo 09:49, 14 May 2017 (UTC)[reply]

Twice url-encoded[edit]

@Koavf: I found a bug with this script and this page. As the commons file title has the & symbol, the link to each included page is not encoded properly. Albertoleoncio (talk) 19:09, 4 January 2023 (UTC)[reply]

Obrigado. I think the easiest solution is to move the file and consequently the index and some pages on ws.pt. A longer-term fix would be nice, but I'm not competent to fix it. —Justin (koavf)❤T☮C☺M☯ 19:28, 4 January 2023 (UTC)[reply]
@Koavf: Just replace decodeURI with decodeURIComponent on line 262. Albertoleoncio (talk) 03:09, 5 January 2023 (UTC)[reply]
Done —Justin (koavf)❤T☮C☺M☯ 03:42, 5 January 2023 (UTC)[reply]
Retrieved from "https://wikisource.org/w/index.php?title=MediaWiki_talk:PageNumbers.js&oldid=945704"