MediaWiki talk:PageNumbers.js

Uppercase?

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)

done

Notes

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

JS Error

I'm getting the following error when I access s: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 s:pt:MediaWiki:PageNumbers.js be interfering in some way with MediaWiki:PageNumbers.js from oldwikisource? -Aleator 12:18, 16 April 2011 (UTC)

I'm also getting the error in Firefox 4 when trying to edit s:en:The Velveteen Rabbit.[1] Kaldari 17:28, 20 April 2011 (UTC)

Ah, when editing. That's true, also pt.source pages that Helder told for MF 3.6! :( -Aleator 23:31, 20 April 2011 (UTC)

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)

Fun with container wrap

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)

Done, too much the habit of mediawiki allowing such idiom... — Phe 23:50, 15 December 2011 (UTC)

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)

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)

Container wrap overkill

It is requested that an edit or modification be made to this protected page. Please remove this template after the request is fulfilled.

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)