Misplaced Pages

Revision as of 20:18, 30 December 2010

• Table of contents
• First discussion
• End of page
• New post

• WP:VPT
• WP:VP/T
• WP:TECHPUMP
• WP:PUMPTECH

Newcomers to the technical village pump are encouraged to read these guidelines prior to posting here. Questions about MediaWiki in general should be posted at the MediaWiki support desk.

view · edit Frequently asked questions (see also: Misplaced Pages:Technical FAQ) Click "" next to each point to see more details. If something looks wrong, purge the server's cache, then bypass your browser's cache. This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown. No, we will not use JavaScript to set focus on the search box. This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an accesskey property on it (default to accesskey="f" in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences. No, we will not add a spell-checker, or spell-checking bot. You can use a web browser such as Firefox, which has a spell checker. If you have problems making your fancy signature work, check Help:How to fix your signature. If you changed to another skin and cannot change back, use this link. Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem. If an image thumbnail is not showing, try purging its image description page. If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear. For server or network status, please see Wikimedia Status. If you cannot reach Misplaced Pages services, see Reporting a connectivity issue.

Village pumps

policy

tech

proposals

idea lab

WMF

misc

• Refining the administrator elections process
• Blocks for promotional activity outside of mainspace
• Voluntary RfAs after resignation
• Proposed rewrite of WP:BITE
• LLM/chatbot comments in discussions

• view
• edit
• history
• watch
• archive
• talk
• purge

Essay on tiny 40 expansion depth limit

I have drafted an essay, "WP:Avoiding MediaWiki expansion depth limit" to begin dealing with the MediaWiki (1.16) severely restricted limit of 40 levels for nested templates and if-else nesting. That essay begins to explain the problem for a wide range of readers, as a desperate effort to handle this unbelievable, miniscule limit of 40 levels of nested if-else logic (which restricts the nesting of templates). While it is occasionally good to dwell on extreme efficiencies of markup coding techniques, the creation of that essay is just a last-resort effort to defuse the problem. Limiting conditional logic to 40 levels (in this century) is just mindboggling ("Someone please update the 1970s punchcard which has limit=40, perhaps having dimpled chad "0" at 400, and re-submit the MediaWiki software to the cardreader"). I am still hoping someone, anyone, can "bump" the expansion depth limit to 100, or at least 60, levels of nested if-else logic. Naturally, many major templates on Misplaced Pages have been written with no clue that a totally debilitating limit existed (who would even imagine 40 pitiful levels), which can make templates simply generate incorrect results, with absolutely no warning to the readers (see essay examples about: {str_len|123456789...} ). I have already begun notifying some major template talk-pages about the depth-limit problems, and rewriting those templates. I think this will be an easy crisis to avert. -Wikid77 (talk) 20:16, 20 December 2010 (UTC)

P.S. The MediaWiki software is, otherwise, very powerful: a single #switch can have more than 1,400 branches (as in Template:Convert/date which checks 4 formats for each of 366 days in one #switch). Also, when {Convert} is modified, then over 325,000 articles can be reformatted within 5 hours (while also recomputing measurement conversions in each of the 325,000 pages). The limit of 40 if-else nesting is the Achilles heel in the vastly powerful preprocessor for the MediaWiki markup language. -Wikid77 00:42, 21 December 2010 (UTC)

You do understand that a depth of 40 nested if-else conditionals is not really "tiny", right? That's potentially 2 parse tree nodes, which is quite a bit. Moreover, even though it would be rare to actually generate so many parse tree nodes from real code, there are WP:BEANSish reasons why the parser has to assume that the worst case scenario is a real worry. To be honest, the long-term solution is going to be adding Lua scripting to MediaWiki as a replacement for the current half-baked ParserFunctions. Until that happens there will always be problems. — Gavia immer (talk) 20:33, 20 December 2010 (UTC)

Well, 40 is small for our users. On the surface 40 might seem like a lot: a teenager probably thinks a 40-year-old has lived many years, but at age 39, then 40 years doesn't seem like the end of life. In real-world applications, a guarded command structure of 40 levels would be very limited, such as when implementing a decision tree using simple, nested if-else-if-else logic. Not all branches are full: some decisions could require checking 35 "pre-conditions" before processing a 6-level result (total: 41). Several of us had abandoned hope of creating "super-smart" templates, due to fears they could not be used without exceeding the expansion limit. Now we realize when if-logic is not deeply nested, then a super-smart template could make 250 clever, rapid, if-then decisions and keep running; part of it could check dozens of values in a #switch as incurring only +1 level of nesting (regardless of total branches in the #switch). Please note that some template editors have even selected nation codes by comparing nations as flag-image templates (rather than comparing names of nations!). I was stunned that nations had to have the same flag+width+height+name structure to match. The actual complexity of Misplaced Pages's real-world applications has been a challenge for keeping templates simple. That is why I suggested an expansion limit of 60, for now, to see if any other problems are released. Meanwhile, people need to avoid problems by reducing the if-else nesting. -Wikid77 00:42, 21 December 2010 (UTC)

I have also commented, but at WT:Avoiding MediaWiki expansion depth limit. --Redrose64 (talk) 20:44, 20 December 2010 (UTC)

• I am creating some unnested utility templates, for use inside large templates (some infoboxes), where typical templates such as {{str_len|0.1234567}} with depth 9, would add too many levels of nesting, when 1 or 2 levels would have fit. -Wikid77 (talk) 14:09, 23 December 2010, revised 11:49, 26 December 2010 (UTC)
• Some of the new unnested templates are:

· {{strlen_short}} - to handle string length 0-50, with 2 expansion levels, not 9 as {{str_len}}.

· {{strfind_short}} - find string using 5 levels rather than 18 depth of {{str_find}}.

For details, see: Template talk:Str_find. -Wikid77 19:49, 28 December 2010 (UTC)

You're aware that the reason that the depth is so low, and the reason that the StringFunctions extension is not enabled, is because the system administrators (e.g. Tim Starling) don't want us to start implementing parsers withing wikicode, right? If they wanted, the devs could turn on native "len" and "pos" functions with a simple configuration change. But they have rejected that idea. — Carl (CBM · talk) 20:05, 28 December 2010 (UTC)

• Aha! I thought so. I've always suspected there was an evil parser cabal, the Lexical Alliance of Language Resistors (LALR) who are planning to rewrite "David Beckham" in FootballerJava. We only have 1.5 million articles about sports (so far), but imagine what could be done, generating articles in FootballerJava! ...an article for every person who ever kicked a ball, each with a navbox linking 100,000 other teenagers, yes: nothing less than total wikiworld domination (just kidding). But, seriously, there are over 478,600 uses of {{str_len}} using 9 expansion levels, plus when counting {str_left} & {str_find}, there are over 2.4 million transclusions, so we know users intend to proliferate string templates beyond 3 million times. Anyway, I just now created redirect "token scanner" (and the plot thickens, Viva LALR!). -Wikid77 (talk) 15:12, 29 December 2010 (UTC)

Page title bug

The above displayed on User talk:Hell in a Bucket. ~NerdyScienceDude 16:43, 23 December 2010 (UTC)

It's because the page contains transclusions of Special pages. That generally messes things up quite badly (I don't know why it isn't simply forbidden, since it's known not to work).--Kotniski (talk) 17:05, 23 December 2010 (UTC)

Yep, this is a longstanding bug that has never been coompletely fixed. /ƒETCHCOMMS/ 18:17, 23 December 2010 (UTC)

Off topic: Nice user info script you've got there. That will be useful. Svick (talk) 10:32, 26 December 2010 (UTC)

Weird error on loading WP:VPT

I typed in http://en.wikipedia.org/WP:VPT into my address bar and I got:

Internal error

Jump to: navigation, search
PPFrame_DOM::expand: Invalid parameter type
Backtrace:
#0 /usr/local/apache/common-local/wmf-deployment/includes/parser/Parser.php(2733): PPFrame_DOM->expand(Object(PPNode_DOM), 0)
#1 /usr/local/apache/common-local/wmf-deployment/includes/parser/Parser.php(935): Parser->replaceVariables('????(Redirected...')
#2 /usr/local/apache/common-local/wmf-deployment/includes/parser/Parser.php(335): Parser->internalParse('????(Redirected...')
#3 : Parser->parse('????(Redirected...', Object(Title), Object(ParserOptions), true, true, NULL)
#4 /usr/local/apache/common-local/wmf-deployment/includes/StubObject.php(58): call_user_func_array(Array, Array)
#5 /usr/local/apache/common-local/wmf-deployment/includes/StubObject.php(76): StubObject->_call('parse', Array)
#6 : StubObject->__call('parse', Array)
#7 /usr/local/apache/common-local/wmf-deployment/includes/OutputPage.php(1145): StubObject->parse('????(Redirected...', Object(Title), Object(ParserOptions), true, true, NULL)
#8 /usr/local/apache/common-local/wmf-deployment/includes/GlobalFunctions.php(884): OutputPage->parse('????(Redirected...', true, true)
#9 /usr/local/apache/common-local/wmf-deployment/includes/Article.php(1121): wfMsgExt('redirectedfrom', Array, '<a href="/w/ind...')
#10 /usr/local/apache/common-local/wmf-deployment/includes/Article.php(806): Article->showRedirectedFromHeader()
#11 /usr/local/apache/common-local/wmf-deployment/includes/Wiki.php(493): Article->view()
#12 /usr/local/apache/common-local/wmf-deployment/includes/Wiki.php(70): MediaWiki->performAction(Object(OutputPage), Object(Article), Object(Title), Object(User), Object(WebRequest))
#13 /usr/local/apache/common-local/wmf-deployment/index.php(117): MediaWiki->performRequestForTitle(Object(Title), Object(Article), Object(OutputPage), Object(User), Object(WebRequest))
#14 /usr/local/apache/common-local/live-1.5/index.php(3): require('/usr/local/apac...')
#15 {main}

I reloaded the page and it worked. I cannot reproduce this now. Any idea what happened? /ƒETCHCOMMS/ 19:06, 25 December 2010 (UTC)

Uh, oh, I was saving the parking chair article and I got something similar:

Internal error

Jump to: navigation, search
PPFrame_DOM::expand: Invalid parameter type
Backtrace:
#0 /usr/local/apache/common-local/wmf-deployment/includes/parser/Parser.php(2733): PPFrame_DOM->expand(Object(PPNode_DOM), 0)
#1 /usr/local/apache/common-local/wmf-deployment/includes/parser/Parser.php(518): Parser->replaceVariables('{{editnotice lo...')
#2 /usr/local/apache/common-local/wmf-deployment/includes/parser/Parser.php(4194): Parser->preprocess('{{editnotice lo...', Object(Title), Object(ParserOptions))
#3 /usr/local/apache/common-local/wmf-deployment/includes/MessageCache.php(674): Parser->transformMsg('{{editnotice lo...', Object(ParserOptions))
#4 /usr/local/apache/common-local/wmf-deployment/includes/GlobalFunctions.php(744): MessageCache->transform('{{editnotice lo...')
#5 /usr/local/apache/common-local/wmf-deployment/includes/GlobalFunctions.php(707): wfMsgGetKey('editnotice-0', true, true, true)
#6 /usr/local/apache/common-local/wmf-deployment/includes/GlobalFunctions.php(655): wfMsgReal('editnotice-0', Array, true, true)
#7 /usr/local/apache/common-local/wmf-deployment/includes/EditPage.php(369): wfMsgForContent('editnotice-0')
#8 /usr/local/apache/common-local/wmf-deployment/includes/EditPage.php(271): EditPage->edit()
#9 /usr/local/apache/common-local/wmf-deployment/includes/Wiki.php(553): EditPage->submit()
#10 /usr/local/apache/common-local/wmf-deployment/includes/Wiki.php(70): MediaWiki->performAction(Object(OutputPage), Object(Article), Object(Title), Object(User), Object(WebRequest))
#11 /usr/local/apache/common-local/wmf-deployment/index.php(117): MediaWiki->performRequestForTitle(Object(Title), Object(Article), Object(OutputPage), Object(User), Object(WebRequest))
#12 /usr/local/apache/common-local/live-1.5/index.php(3): require('/usr/local/apac...')
#13 {main}

Not sure what's going on here. /ƒETCHCOMMS/ 19:06, 25 December 2010 (UTC)

I got a similar error (I'm afraid I didn't save the backtrace) just now while editing Battle of Nanking. Submitting the identical text again succeeded, so it wasn't an issue with the edit. — Gavia immer (talk) 20:03, 25 December 2010 (UTC)

I got a few more of these, randomly (sometimes upon previewing an edit or simply trying to read a page). Reloading always seems to work, though. /ƒETCHCOMMS/ 21:07, 25 December 2010 (UTC)

I've seen this three times in the last half hour, the last a minute ago. The first time accessing my watchlist, the last an article. Reloading each time worked for me. The exact trace is slightly different to the above so here it is:

#0 /usr/local/apache/common-local/wmf-deployment/includes/parser/Parser.php(2733): PPFrame_DOM->expand(Object(PPNode_DOM), 0)
#1 /usr/local/apache/common-local/wmf-deployment/includes/parser/Parser.php(935): Parser->replaceVariables('{{pp-semi-prote...')
#2 /usr/local/apache/common-local/wmf-deployment/includes/parser/Parser.php(335): Parser->internalParse('{{pp-semi-prote...')
#3 : Parser->parse('{{pp-semi-prote...', Object(Title), Object(ParserOptions), true, true, 404184523)
#4 /usr/local/apache/common-local/wmf-deployment/includes/StubObject.php(58): call_user_func_array(Array, Array)
#5 /usr/local/apache/common-local/wmf-deployment/includes/StubObject.php(76): StubObject->_call('parse', Array)
#6 : StubObject->__call('parse', Array)
#7 /usr/local/apache/common-local/wmf-deployment/includes/Article.php(4024): StubObject->parse('{{pp-semi-prote...', Object(Title), Object(ParserOptions), true, true, 404184523)
#8 /usr/local/apache/common-local/wmf-deployment/includes/Article.php(4006): Article->getOutputFromWikitext('{{pp-semi-prote...', true, Object(ParserOptions))
#9 /usr/local/apache/common-local/wmf-deployment/includes/Article.php(1349): Article->outputWikiText('{{pp-semi-prote...', true, Object(ParserOptions))
#10 : Article->doViewParse()
#11 /usr/local/apache/common-local/wmf-deployment/includes/PoolCounter.php(59): call_user_func(Array)
#12 /usr/local/apache/common-local/wmf-deployment/includes/Article.php(904): PoolCounter_Stub->executeProtected(Array, Array)
#13 /usr/local/apache/common-local/wmf-deployment/includes/Wiki.php(493): Article->view()
#14 /usr/local/apache/common-local/wmf-deployment/includes/Wiki.php(70): MediaWiki->performAction(Object(OutputPage), Object(Article), Object(Title), Object(User), Object(WebRequest))
#15 /usr/local/apache/common-local/wmf-deployment/index.php(117): MediaWiki->performRequestForTitle(Object(Title), Object(Article), Object(OutputPage), Object(User), Object(WebRequest))
#16 /usr/local/apache/common-local/live-1.5/index.php(3): require('/usr/local/apac...')
#17 {main}

--JohnBlackburne_deeds 00:38, 26 December 2010 (UTC)

I've got a much bigger and nastier-looking screen of chars like the above while making this edit. I didn't save the error :( But I did notice that instead of Internal Error, its was something like Wikimedia Internal Error, with Wikimedia mentioned a few more times... I can also confirm that it happened on Wikimedia Commons too. Rehman 00:35, 26 December 2010 (UTC)

I have had the same garbage as JohnBlackburne, three times in the last hour. In each case it has happened when I tried to save a page, so I have gone back, pressed save again, and all has been fine. --BrownHairedGirl (talk) • (contribs) 01:10, 26 December 2010 (UTC)

Someone on ANI says that per irc discussion, the devs know about this and are working on it. 67.117.130.143 (talk) 02:07, 26 December 2010 (UTC)

I've had an Internal error with a message similar to the above twice in the last few hours. I was looking at turtle articles at the time not VPT or any other notice board. Regards, SunCreator 02:09, 26 December 2010 (UTC)

It's happened to me at least ten times today. Luckily, when it's happened during an edit, it seems that the edit still goes through regardless, so it's just more of an annoyance more than anything else. Silverseren 02:14, 26 December 2010 (UTC)

This has been filed in the bug tracker under bug 26429. Krinkle (talk) 02:15, 26 December 2010 (UTC)

This is also affecting my stub link colour gadget, and all links are showing up orange. I'm guessing this is because the stub gadget is trying to load these articles and being given one of these internal errors. - ʄɭoʏɗiaɲ  _¢ 02:38, 26 December 2010 (UTC)

I have been getting a few of these errors today as well, but refreshing the page to get it to load worked every time. Maybe if it happens again I will save the error and post it here (like anyone needs yet another error posted here. ;-) X-D). 02:52, 26 December 2010 (UTC)

I saw a similar error a few times in the last day; both loading pages and committing edits. When attempting to commit an edit, it failed with error message (no changes to history); I reattempted, and it worked. Same thing for attempting to read a page.

Internal error

PPFrame_DOM::expand: Invalid parameter type
Backtrace:
#0 /usr/local/apache/common-local/wmf-deployment/includes/parser/Parser.php(2733): PPFrame_DOM->expand(Object(PPNode_DOM), 0)
#1 /usr/local/apache/common-local/wmf-deployment/includes/parser/Parser.php(518): Parser->replaceVariables('{{editnotice lo...')
#2 /usr/local/apache/common-local/wmf-deployment/includes/parser/Parser.php(4194): Parser->preprocess('{{editnotice lo...', Object(Title), Object(ParserOptions))
#3 /usr/local/apache/common-local/wmf-deployment/includes/MessageCache.php(674): Parser->transformMsg('{{editnotice lo...', Object(ParserOptions))
#4 /usr/local/apache/common-local/wmf-deployment/includes/GlobalFunctions.php(744): MessageCache->transform('{{editnotice lo...')
#5 /usr/local/apache/common-local/wmf-deployment/includes/GlobalFunctions.php(707): wfMsgGetKey('editnotice-0', true, true, true)
#6 /usr/local/apache/common-local/wmf-deployment/includes/GlobalFunctions.php(655): wfMsgReal('editnotice-0', Array, true, true)
#7 /usr/local/apache/common-local/wmf-deployment/includes/EditPage.php(369): wfMsgForContent('editnotice-0')
#8 /usr/local/apache/common-local/wmf-deployment/includes/EditPage.php(271): EditPage->edit()
#9 /usr/local/apache/common-local/wmf-deployment/includes/Wiki.php(553): EditPage->submit()
#10 /usr/local/apache/common-local/wmf-deployment/includes/Wiki.php(70): MediaWiki->performAction(Object(OutputPage), Object(Article), Object(Title), Object(User), Object(WebRequest))
#11 /usr/local/apache/common-local/wmf-deployment/index.php(117): MediaWiki->performRequestForTitle(Object(Title), Object(Article), Object(OutputPage), Object(User), Object(WebRequest))
#12 /usr/local/apache/common-local/live-1.5/index.php(3): require('/usr/local/apac...')
#13 {main}

Internal error

PPFrame_DOM::expand: Invalid parameter type
Backtrace:
#0 /usr/local/apache/common-local/wmf-deployment/includes/parser/Parser.php(2733): PPFrame_DOM->expand(Object(PPNode_DOM), 0)
#1 /usr/local/apache/common-local/wmf-deployment/includes/parser/Parser.php(935): Parser->replaceVariables('{{MedalTableTop...')
#2 /usr/local/apache/common-local/wmf-deployment/includes/parser/Parser.php(335): Parser->internalParse('{{MedalTableTop...')
#3 : Parser->parse('{{MedalTableTop...', Object(Title), Object(ParserOptions), true, true, 397508042)
#4 /usr/local/apache/common-local/wmf-deployment/includes/StubObject.php(58): call_user_func_array(Array, Array)
#5 /usr/local/apache/common-local/wmf-deployment/includes/StubObject.php(76): StubObject->_call('parse', Array)
#6 : StubObject->__call('parse', Array)
#7 /usr/local/apache/common-local/wmf-deployment/includes/Article.php(4024): StubObject->parse('{{MedalTableTop...', Object(Title), Object(ParserOptions), true, true, 397508042)
#8 /usr/local/apache/common-local/wmf-deployment/includes/Article.php(4006): Article->getOutputFromWikitext('{{MedalTableTop...', true, Object(ParserOptions))
#9 /usr/local/apache/common-local/wmf-deployment/includes/Article.php(1349): Article->outputWikiText('{{MedalTableTop...', true, Object(ParserOptions))
#10 : Article->doViewParse()
#11 /usr/local/apache/common-local/wmf-deployment/includes/PoolCounter.php(59): call_user_func(Array)
#12 /usr/local/apache/common-local/wmf-deployment/includes/Article.php(904): PoolCounter_Stub->executeProtected(Array, Array)
#13 /usr/local/apache/common-local/wmf-deployment/includes/Wiki.php(493): Article->view()
#14 /usr/local/apache/common-local/wmf-deployment/includes/Wiki.php(70): MediaWiki->performAction(Object(OutputPage), Object(Article), Object(Title), Object(User), Object(WebRequest))
#15 /usr/local/apache/common-local/wmf-deployment/index.php(117): MediaWiki->performRequestForTitle(Object(Title), Object(Article), Object(OutputPage), Object(User), Object(WebRequest))
#16 /usr/local/apache/common-local/live-1.5/index.php(3): require('/usr/local/apac...')
#17 {main}

TheFeds 04:59, 26 December 2010 (UTC)

I just got an other one of these error messages when refreshing my watch-list (the first error I have had in a while today). I copied the error messsage, and it is contained below.

Internal error

Jump to: navigation, search
PPFrame_DOM::expand: Invalid parameter type
Backtrace:
#0 /usr/local/apache/common-local/wmf-deployment/includes/parser/Parser.php(2733): PPFrame_DOM->expand(Object(PPNode_DOM), 0)
#1 /usr/local/apache/common-local/wmf-deployment/includes/parser/Parser.php(935): Parser->replaceVariables('(for '''Retro00...')
#2 /usr/local/apache/common-local/wmf-deployment/includes/parser/Parser.php(335): Parser->internalParse('(for '''Retro00...')
#3 : Parser->parse('(for '''Retro00...', Object(Title), Object(ParserOptions), true, true, NULL)
#4 /usr/local/apache/common-local/wmf-deployment/includes/StubObject.php(58): call_user_func_array(Array, Array)
#5 /usr/local/apache/common-local/wmf-deployment/includes/StubObject.php(76): StubObject->_call('parse', Array)
#6 : StubObject->__call('parse', Array)
#7 /usr/local/apache/common-local/wmf-deployment/includes/OutputPage.php(1145): StubObject->parse('(for '''Retro00...', Object(Title), Object(ParserOptions), true, true, NULL)
#8 /usr/local/apache/common-local/wmf-deployment/includes/GlobalFunctions.php(884): OutputPage->parse('(for '''Retro00...', true, true)
#9 /usr/local/apache/common-local/wmf-deployment/includes/specials/SpecialWatchlist.php(54): wfMsgExt('watchlistfor', 'parseinline', 'Retro00064')
#10 : wfSpecialWatchlist(NULL, Object(SpecialPage))
#11 /usr/local/apache/common-local/wmf-deployment/includes/SpecialPage.php(793): call_user_func('wfSpecialWatchl...', NULL, Object(SpecialPage))
#12 /usr/local/apache/common-local/wmf-deployment/includes/SpecialPage.php(561): SpecialPage->execute(NULL)
#13 /usr/local/apache/common-local/wmf-deployment/includes/Wiki.php(254): SpecialPage::executePath(Object(Title))
#14 /usr/local/apache/common-local/wmf-deployment/includes/Wiki.php(64): MediaWiki->handleSpecialCases(Object(Title), Object(OutputPage), Object(WebRequest))
#15 /usr/local/apache/common-local/wmf-deployment/index.php(117): MediaWiki->performRequestForTitle(Object(Title), NULL, Object(OutputPage), Object(User), Object(WebRequest))
#16 /usr/local/apache/common-local/live-1.5/index.php(3): require('/usr/local/apac...')
#17 {main}

-- 06:30, 26 December 2010 (UTC)

Received an internal error while creating a new page

On User_talk:75.210.113.12

PPFrame_DOM::expand: Invalid parameter type
Backtrace:
#0 /usr/local/apache/common-local/wmf-deployment/includes/parser/Parser.php(2733): PPFrame_DOM->expand(Object(PPNode_DOM), 0)
#1 /usr/local/apache/common-local/wmf-deployment/includes/parser/Parser.php(935): Parser->replaceVariables('{{#switch: {{{c...')
#2 /usr/local/apache/common-local/wmf-deployment/includes/parser/Parser.php(335): Parser->internalParse('{{#switch: {{{c...')
#3 : Parser->parse('{{#switch: {{{c...', Object(Title), Object(ParserOptions), true, true, 404269001)
#4 /usr/local/apache/common-local/wmf-deployment/includes/StubObject.php(58): call_user_func_array(Array, Array)
#5 /usr/local/apache/common-local/wmf-deployment/includes/StubObject.php(76): StubObject->_call('parse', Array)
#6 : StubObject->__call('parse', Array)
#7 /usr/local/apache/common-local/wmf-deployment/includes/OutputPage.php(1145): StubObject->parse('{{#switch: {{{c...', Object(Title), Object(ParserOptions), true, true, 404269001)
#8 /usr/local/apache/common-local/wmf-deployment/includes/GlobalFunctions.php(882): OutputPage->parse('{{#switch: {{{c...', true, true)
#9 /usr/local/apache/common-local/wmf-deployment/includes/OutputPage.php(2522): wfMsgExt('anontalkpagetex...', Array, Array)
#10 /usr/local/apache/common-local/wmf-deployment/includes/OutputPage.php(2510): OutputPage->addWikiMsgArray('anontalkpagetex...', Array)
#11 /usr/local/apache/common-local/wmf-deployment/includes/Article.php(1170): OutputPage->addWikiMsg('anontalkpagetex...')
#12 /usr/local/apache/common-local/wmf-deployment/includes/Article.php(945): Article->showViewFooter()
#13 /usr/local/apache/common-local/wmf-deployment/includes/Wiki.php(493): Article->view()
#14 /usr/local/apache/common-local/wmf-deployment/includes/Wiki.php(70): MediaWiki->performAction(Object(OutputPage), Object(Article), Object(Title), Object(User), Object(WebRequest))
#15 /usr/local/apache/common-local/wmf-deployment/index.php(117): MediaWiki->performRequestForTitle(Object(Title), Object(Article), Object(OutputPage), Object(User), Object(WebRequest))
#16 /usr/local/apache/common-local/live-1.5/index.php(3): require('/usr/local/apac...')
#17 {main}

Nakon 08:39, 26 December 2010 (UTC)

I have moved this new section here, as it is related to the errors above. Regards. -- 08:46, 26 December 2010 (UTC)

Should be fixed now, according to the tech channel. If anyone still gets a similar error screen, please note it here. Cheers. Bugzilla:26429.  Chzz  ►  17:57, 26 December 2010 (UTC)

Misplaced Pages Mathematics

The quality of Misplaced Pages's mathematics is dwindling. Not the content, but the presentation. It is becoming more and more inconsistent in displayed style, which ideally should be entirely consistent. Let me give a rough example of mathematics I see.

Let x∈C be a value such that x²+2x+1 = 0. Let ${\displaystyle K=\mathbb {Q} }$ where ${\displaystyle \mathbb {Q} }$ is the set of rationals. Note that ${\displaystyle x}$ serves as a field extension to ℚ where only linear combinations of numbers of the form ${\displaystyle \scriptstyle a{\sqrt {pr+q}}\pm b}$ exist. We want an δ>0 such that for each ε>0 one has ${\displaystyle 0<\vert f(x)-L\vert <\delta }$.

This example above was just made up on the spot, so ignore the actual math. It should appear, in my opinion, as

Let ${\displaystyle x\in \mathbb {C} }$ be a value such that ${\displaystyle x^{2}+2x+1=0}$. Let ${\displaystyle K=\mathbb {Q} }$ where ${\displaystyle \mathbb {Q} }$ is the set of rationals. Note that ${\displaystyle x}$ serves as a field extension to ${\displaystyle \mathbb {Q} }$ where only linear combinations of numbers of the form ${\displaystyle a{\sqrt {pr+q}}\pm b}$ exist. We want an ${\displaystyle \delta >0}$ such that for each ${\displaystyle \varepsilon >0}$ one has ${\displaystyle 0<\vert f(x)-L\vert <\delta }$.

The second one might appear uglier, but is far more consistent than the first one. Let me be clear about what the consistencies are. We have...

1. the use of italic variables (x),
2. the use of emboldened sets (C),
3. the use of the math environment (${\displaystyle x}$),
4. the use of Unicode (ℚ), and
5. the use of \scriptstyle (compare ${\displaystyle {\sqrt {ax+b}}}$ to ${\displaystyle \scriptstyle {\sqrt {ax+b}}}$).

I am not proclaiming articles are like the first example above with that much inconsistency, but especially from a global point of view on Misplaced Pages, there is an enormous amount of inconsistency.

Why is consistency important?

• Text-based browsers can uniformly deal with tagged data. So can good ol' normal browsers. Misplaced Pages contributors are blurring the line between style and content — syntax and semantics — which I find to be a grave mistake, especially as an avid LaTeX user. For some things I'm sure it's appropriate, like using quoted markup to indicate emphasized content.
• Using a single, consistent notation for mathematics allows for changes to be made to the mathematics easily. Mathematics' style can be scraped, parsed, processed, all that.
• It makes reading Misplaced Pages articles much more pleasing, than seeing 10 different styles for something.

I do my best to try to increase the consistency of pages if I have the time, but I can't alone.

Consistency also helps with this next point: that Misplaced Pages should start moving away from generating images. Misplaced Pages probably uses enough processing power on constantly rendering LaTeX markup. At the moment, Misplaced Pages wants some 16 million USD for server duties and all that. If money is an issue, which it clearly is a concern, then here's a way to decrease server load: don't render the mathematics server-side. Some people don't even like the PNGs and it makes for absolutely awful printing. The book-making feature of Misplaced Pages is great, until you start having mathematics, in which case you get sloppy, low-resolution output.

MathML is a flop. I don't want to get into any debate about it, but it was designed not by mathematicians nor by typographers. I think, at the moment, the best answer is to use something like MathJax, which does one of two things:

1. Uses pre-rendered images to typeset mathematics using JavaScript, or
2. uses native STIX fonts from one's computer to render the mathematics (again, using JavaScript).

MathJax produces absolutely beautiful mathematics by using LaTeX's rendering algorithms, and if one has STIX fonts installed, then one has scalable/vectorized mathematical typesetting suitable for printing. The STIX fonts were designed by mathematicians and typographers, and were designed for the web. Moreover, it is context sensitive. If the color of the font around it changes, so does the color of the mathematics. Same with size and all that. Best of all, it requires about 2 lines of JS at the header of each page, and doesn't require any special mathematics notation; >math< is compatible.

If you want to see an example of MathJax, perhaps see this post on my blog:

—quadrescence 23:52, 25 December 2010 (UTC) — Preceding unsigned comment added by Quadrescence (talk • contribs)

Anything that requires JavaScript is a non-starter for me. Having to install more fonts (STIX) is a non-starter for me. Anything that requires images to render and read is a non-starter for me. I think you need to concentrate more on compatibility and accessibility. HumphreyW (talk) 23:59, 25 December 2010 (UTC)

JavaScript is optional for the user. STIX is optional. Misplaced Pages requires images right now to render, though surely you can disable it. I think compatibility has been in mind, and the goal is to actually increase accessibility, instead of this hodgepodge of styles we have right now. I hope you actually read what MathJax is. —quadrescence 00:52, 26 December 2010 (UTC) — Preceding unsigned comment added by Quadrescence (talk • contribs)

Someone's got this working on WP. See e.g. Help talk:Displaying a formula#Formulas as SVG?. I had it enabled for a while but disabled it as it was just too slow. It needs to be done server-side to offer acceptable performance with our formulae heavy maths articles, but right now it uses Javascript client-side. There were also problems rendering a few formulae, very few and obscure but the sort of problems that would likely not get fixed until MathJax is officially supported.

And you should not have an external link in your signature, as per WP:SIG#EL. Please stop using it, one link on your user page is enough.--JohnBlackburne_deeds 00:56, 26 December 2010 (UTC)

Of course there will be errors in rendering. People are writing pretty hacky LaTeX on Misplaced Pages to begin with, precisely to avoid the problems images give. As for performance, one can disable JavaScript if they so wish (or use crappy images as a fallback option). Also, Misplaced Pages's bot keeps claiming that I'm not signing. Dumb bot. ~~~~ —quadrescence 01:09, 26 December 2010 (UTC)

<offtopic> "Also, Misplaced Pages's bot keeps claiming that I'm not signing. Dumb bot." That is probably because you are not linking to your user page and talk page. HumphreyW (talk) 01:43, 26 December 2010 (UTC)

(edit conflict) The bot says you're not signing because you're not doing it correctly. Your signature must include a wikilink to either your userpage or your talk page. Anomie⚔ 01:44, 26 December 2010 (UTC)

Please take the discussion about my signature to the appropriate place. —quadrescence 03:00, 26 December 2010 (UTC)

It's not a server performance thing, it's more about the tension between getting reasonable-looking complicated math (LaTeX) and not wanting to spew PNG's into the browser when the math is simple enough that HTML and Unicode hacks (X_n) are good enough to get it across. I think it would take a pretty big cultural shift to do much different than this. The current mixed approaches is ok for our purposes (communicating content to the reader) even if it's not so elegant for fans of semantic markup. The same thing happens on Mathoverflow, which uses Mathjax. I'm personally not much of a believer in semantic markup for Misplaced Pages anyway, since Misplaced Pages is supposed to be a reference work edited by humans for a direct readership of humans. We're not here to be unpaid labor for data miners. 67.117.130.143 (talk) 01:46, 26 December 2010 (UTC)

Yes, for reading by humans, on this device called a computer, which happens to vary from place to place, and which happens to not be equivalent for everyone. Semantic markup is what allows everyone to see the same thing modulo their style or accomodations. If it didn't, we wouldn't use HTML, we'd use RTFs or something. And yes, the current approaches "work ok for getting a point across", but so would Misplaced Pages entirely in plaintext or whatever. When I think of encyclopedia, I think authoritative and professional, the latter which MathJax enables. —quadrescence 03:00, 26 December 2010 (UTC)

Just a few words, as I was pointed to this discussion. MathJax is fine and great, and you may want to test it yourself on Misplaced Pages using my experimental MathJax user extension. However, two issues will probably prevent MathJax from ever being the default rendering method on Misplaced Pages: users have reported it to be quite slow for the moment, and the extent of LaTeX and additional non-LaTeX "texvc" (including all its bugs) that MediaWiki supports will never be fully supported by MathJax. So the best we can hope for is good, optional support for MathJax, similar to what my user extension provides. Good means support of most TeX features used on Misplaced Pages, and fast enough to not deter most users. There is definitely process going on in regards to the latter, and I'm looking forward to it. Regarding server-side rendering, this comes down to generating images, and the only thing we can do better than now is switching to SVG images – something that is pretty unlikely to happen in the near future, in part because of poor support by some browsers (IE). Nageh (talk) 09:24, 26 December 2010 (UTC)

• Try supporting a wider range of math styles, I like: x^2 + 2*x + 1 = 0, where the caret "^" denotes the exponent and star "*" means to multiply. Using that style, variables can have multi-letter mnemonic names, such as "max" and "min" or "width", rather than every equation having: x, x', y, y', etc. There is an oriental revelation which advises: "When something seems very difficult to do, then try doing it more, not less (in case a lack of familiarity or some minor issue was the reason for the difficulty)". I had several math professors who wrote equations, by hand, up on the board, and get this: they all had different handwriting (OMG, yes, inconsistent, not-the-same handwriting, even using different hands: some left, some right, some both hands). Can you even imagine the psychological horror of seeing formulas written by hand by professional mathematicians, like Albert Einstein did all the time? Well, wanting to actually learn what other people know, rather just my same style all day long, I opened my mind to reading what other people wrote, and guess what? I was able to read complex math formulas, even written by hand! Yes, despite all the initial horror, it did not warp my little mind, and I went further to learn computer technology which made the math formulas seem like petty special cases of a vastly diverse world using numerous, fascinating styles. Now, even in music, we have electronic keyboards with hundreds of options, using a myriad of special buttons, but the oriental proverb was the secret: "When something seems very difficult to do, then try doing it more, not less". Embrace diversity. -Wikid77 (talk) 12:32, 26 December 2010 (UTC)

MathJax is ridiculously slow. Even on Google Chrome, which has one of the fastest JavaScript engines, the math examples on your blog take nearly 2 seconds to load, on top of the page load time. On IE8, its more like 5 seconds. It takes about 10 seconds on my iPod touch. The fallback for JS disabled or an unsupported browser is just the LaTeX text, which is hardly a graceful fallback. Its also massive, its 16 MB and more than 30,000 files. Most of the files are images/fonts where only a few will be loaded on any given page, but on the mathjax demo page, there's still 174 kB of minified and gzipped JS/fonts loaded to render it. Mr.Z-man 16:26, 26 December 2010 (UTC)

Mnemonic shortcut WP:PUMPTECH

I have created a more mnemonic shortcut as "WP:PUMPTECH" for use around general readers, following the original format of "WP:PUMP" where WP:VPT might be misread as "WP:VTP" in the wiki-alphabet soup. The other shortcuts are still there, such as: WP:VP/T with the slash. -Wikid77 (talk) 12:54, 26 December 2010 (UTC)

Seems reasonable. Incidentally, I also made WP:VTP - I've mistyped as that myself. Redirecteds are cheap.  Chzz  ►  17:12, 26 December 2010 (UTC)

Blue links show brown on some servers

I have noticed that, sometimes, the wikilinks to large articles are showing as brown (tiny-article) color, as if one of the wiki-servers doesn't do blue links today. I wonder if this is a temporary issue, or something that will keep recurring, such as those months when GIF images did not auto-thumbnail and had to be stored as the exact size to show clear resolution. -Wikid77 (talk) 13:02, 26 December 2010 (UTC)

Something weird

(Probably posting this in the wrong place, but here goes anyway.) So I'm looking through some historical contributions and come across 195.93.21.38 (talk · contribs). Apparently, that IP was blocked for 24 hours on 15 November 2006, edited again two days later and hasn't been blocked since - but the contribs page shows the 15 November 2006 block as active, which makes no sense. Anyone able to work out why? Alzarian16 (talk) 18:22, 26 December 2010 (UTC)

I believe it's a known bug, it's displaying the wrong block information. If you check Special:BlockList/195.93.21.38, it's blocked by two different range blocks. See also Special:Contributions/195.93.21.0, which isn't showing any indication that it is covered by the same range blocks. Anomie⚔ 18:39, 26 December 2010 (UTC)

That would explain it. Thanks. Alzarian16 (talk) 18:46, 26 December 2010 (UTC)

Latin Extended Additional

There used to be a lot of problems for Windows users displaying characters in the Latin Extended Additional Unicode range. Could some people verify whether this problem still exists in recent versions of Internet Explorer (7 and up)? The fonts Lucida Sans Unicode and either Microsoft Sans Serif or Tahoma should cover most of this range.

Could you have a look at User:Ruud Koot/ḂḃḄḅḆḇḊḋḌḍḎḏḞḟḠḡḢḣḤḥḪḫḲḳḴḵḶḷḸḹḺḻṀṁṂṃṄṅṆṇṈṉṖṗṘṙṚṛṜṝṞṟṠṡṢṣṨṩṪṫṬṭṮṯṾṿẈẉẊẋẎẏẒẓẔẕʿẖʾ and report if this page displays correctly (both the three lines of text and the title itself). Especially the last three characters, these should be read "half-ring, h-underbar, half-ring" and might need to come from two different fonts. Please, list the versions of your browser, operating system, Office (this affects the fonts you have installed), and uncommon fonts you might have installed. Thanks, —Ruud 19:08, 26 December 2010 (UTC)

Using IE9 Beta, Windows 7 Home Premium 32-Bit, and Office Home and Student 2007, all three lines and the title are displayed. The characters look the same, but there is a minimal variation in font size that I didn't notice without a close look. I haven't installed any seperate fonts. 1ForTheMoney (talk) 20:08, 26 December 2010 (UTC)

Using Windows XP shows all lines correct, with the first line (default font) with a slightly larger font in IE8, but smaller in Chrome. Note that Misplaced Pages uses Arial Unicode MS as the preferred font when using {{unicode}} in IE. — Edokter • Talk — 20:38, 26 December 2010 (UTC)

As far as I was able to determine the {{unicode}} "hack" is only needed for IE6 and below, but currently does affect (not in a positive way, due to a change in the font size) IE7 and above. What I'm trying to determine is if we can:

1. deprecate and remove {{unicode}},
2. safely use characters from the Latin Extended Additional range in article titles (we've historical been somewhat overcautious with this, but there does not seem to be a good reason for this any longer).

—Ruud 21:24, 26 December 2010 (UTC)

It is sometimes needed for all browsers running on Windows, not just IE. As long as Windows has poor unicode support, we're stuck with some form of hack to force the proper font, at least for those ranges in unicode that might break up. {{Transl}} also uses the .Unicode class, that is why they look the same.

We try to avoid unicode in article title, simply for the reason that it needs to be typable, or have a non-unicode redirect. — Edokter • Talk — 00:42, 27 December 2010 (UTC)

I think this is untrue. Non-IE browsers have an easy time choosing the correct font. And if Windows is missing fonts by default, a template cannot change it since we do not have the possibility to embed custom fonts here. -- Prince Kassad (talk) 01:24, 27 December 2010 (UTC)

Doesn't Firefox use a custom font renderer (freefont, cairo) on Windows too? I don't believe I had a font installed which contained both "ẖ" and "ʾ", so IE7's rendering engine does seem to be smarter than IE6's. I might be overlooking something, though. —Ruud 01:56, 27 December 2010 (UTC)

Yes, Firefox uses its own custom renderer. All other browsers, to my knowledge, rely on Uniscribe. -- Prince Kassad (talk) 15:39, 27 December 2010 (UTC)

But when I tested this on Windows 2003 with IE7 the text rendered fine, including the title (which cannot be forced to use a font using {{unicode}}, I vaguely remember that for this reason the title is always displayed using Arial Unicode MS if available). —Ruud 01:52, 27 December 2010 (UTC)

(edit conflict) The page linked to above in the original post by Ruud displays the text perfectly okay for me. I am using I.E.8. 01:57, 27 December 2010 (UTC)

Edoktor, would you be able to produce a testcase which fails on IE7/8/9, but succeeds when using {{unicode}}? —Ruud 02:00, 27 December 2010 (UTC)

It was some time ago, but This Is Spın̈al Tap would not display properly without the unicode template. Here it is without the template: This Is Spın̈al Tap. It uses a N-diaeresis, which is pretty exotic. — Edokter • Talk — 03:29, 27 December 2010 (UTC)

Both versions of that phrase (i.e. with and without the {{Unicode}} template), Edokter, work fine for me (no problems displaying the characters), although the {{Unicode}} template causes that version of the text to display slightly different from the regular text. Again, I am using I.E.8. Maybe it is just differences in the font sets different computers have. ????:-( 03:52, 27 December 2010 (UTC)

They both look fine for me as well in both IE8 and Firefox, but oddly enough, not in Chrome 8. In the version without the unicode template, I do see dotless 'i', but then a very small serif 'n' followed by a square. — Edokter • Talk — 04:01, 27 December 2010 (UTC)

Both phrases look fine for me as well, noting that the Unicode text stands out from the regular text due to its font. (As a side note, I switched on Compatibility Mode for a small test (which I believe makes the browser behave like IE7) and found that Ruud's test and Edokter's phrases still display correctly, although the first line is shorter than the second and third lines.) 1ForTheMoney (talk) 14:48, 27 December 2010 (UTC)

Using either IE8 (compatibility view off) or Firefox 3 on Windows XP with Office 2003, Edokter's first phrase looks fine but in the second phrase the diaresis is shifted to the right so it is now almost completely over the a. In IE8 (compatibility view checked) the n-diaresis of the second phrase is a square. A dotless i appears in both phrases in both browsers. I cannot view the complete title of Ruud's test page (nor does a horizontal scroll bar appear) because I am using a monitor with a 4×3 aspect ratio (it ends with the Rr set). All three lines of text appear correctly in IE8 (compatibility view off or checked) but using Firefox the half-circles appear closer to superscript < > in the first line and superscript in the last two lines. The first line is longer than the last two lines in IE8 (compatibility view off or checked) but in Firefox the first line is shorter. — Joe Kress (talk) 09:34, 29 December 2010 (UTC)

IE tables and height/width:100%

Not a question but I thought you guys might find this interesting.

Internet explorer doesnt handle style=height:100% or width:100% in table correctly.

But if you create a css stylesheet with the exact same thing on it and place class=yournewtableclass on your table or table within a table it works fine.

Just granpa (talk) 02:52, 27 December 2010 (UTC)

Or at least it doesnt screw up quite as badly

Just granpa (talk) 02:59, 27 December 2010 (UTC)

• Misplaced Pages class=wikitable or class=infobox forces a space margin outside the table, and causes tables beyond width=98% to reach 102% wide with a bottom scroll-bar. Reset the margins:
   class=wikitable  width=100%  style="margin:0 0 0 0"
  See essay "WP:98 percent table width anomaly" for examples where setting "margin-right:0" will fix over-wide wikitables, etc. -Wikid77 (talk) 12:19, 29 December 2010 (UTC)

Cannot access WikiBlame?

"403 Forbidden

You don't have permission to access /wikiblame.php on this server. Apache/2.2 Server at wikipedia.ramselehof.de Port 80"

Is it me?

Firefox/3.6.13  — Preceding unsigned comment added by SalineBrain (talk • contribs) 03:38, 27 December 2010 (UTC)

What were you doing when that happened? Someguy1221 (talk) 03:44, 27 December 2010 (UTC)

Happens to me as well. I did, however, find that http://wikipedia.ramselehof.de/wikiblame_inverse.php works. Or there's http://toolserver.org/~soxred93/blame. PleaseStand 04:28, 27 December 2010 (UTC)

Seems to be working fine for me.Sumsum2010·T·C 19:21, 27 December 2010 (UTC)

I had the same problem until about 12 hours ago. Dougweller (talk) 19:36, 27 December 2010 (UTC)

That's because of this change to MediaWiki:Histlegend, which changed the link to wikiblame_inverse.php. The http://wikipedia.ramselehof.de/wikiblame.php URL still does not work. PleaseStand 21:04, 27 December 2010 (UTC)

WP:BUNCH fixed ?

It seems that by sheer coincidence we have fixed WP:BUNCH, one of the oldest and most annoying layout rendering issues that MediaWiki has. In looking to fix the white border around thumbnails (something fixed a while ago on en.wp), User:Fomafix (from de.wp) made the suggestion to use "overflow:hidden" on the headers. Not only does this work to avoid having the lines run into thumbnails and infoboxes, but as a side effect, User:Edokter discovered that it seems to fix the bunching problem as well. The code is now enabled on en.wp, please report if you see anything strange that might be related. —TheDJ (talk • contribs) 20:04, 27 December 2010 (UTC)

Sweet! This will make laying out pictures far easier. With that issue gone we could also update a bunch (lolpun) of manual of style rules that were set to avoid this issue in articles. - ʄɭoʏɗiaɲ  _¢ 20:19, 27 December 2010 (UTC)

Who-ever discovered this definitely deserves a barnstar! Sumsum2010·T·C 20:32, 27 December 2010 (UTC)

Apparently we tried this before, and there are some issues with this solution, namely with IE for Mac (headers disappear completely) and with rtl wiki's on some older browsers. We probably no longer care about any of these older browsers however. Something to look further into, but definetly looks like a keeper for en.wp to me. —TheDJ (talk • contribs) 20:43, 27 December 2010 (UTC)

Awesome. I never understood the whole fixbunching thing anyway :P /ƒETCHCOMMS/ 22:53, 27 December 2010 (UTC)

Also, does this mean we should remove the existing fixbunching templates, or just leave them in place? /ƒETCHCOMMS/ 23:06, 27 December 2010 (UTC)

Could disable the code for it to quickly determine the widespread effects of this and see if anything is affected negatively. I'd be surprised if Internet Explorer has ANY market share in Macs (support ended 5 years ago). The latest BS they pulled with IE9 is sure to remove its usage from PC's in the coming years. - ʄɭoʏɗiaɲ  _¢ 23:41, 27 December 2010 (UTC)

You can already see the effects of WP:BUNCH, which has all fixes (divs, templates and the like) listed and examplified. I see no difference, other then that the no-fix example is now fixed. I think we can blank the templates in 30 days, when caching has caught up. — Edokter • Talk — 23:52, 27 December 2010 (UTC)

I have tested this in Internet Explorer 6, Internet Explorer 8, Internet Explorer 9 preview 7, Firefox 2, Firefox 3.6, Firefox 4 beta 8, Opera 10.63, and Chrome 8. Bunching no longer occurs in Example 1 (the one that is supposed to exhibit bunching) on WP:BUNCH in these browsers: IE6, IE8, Firefox 2, Firefox 3.6, and Opera 10.63. However, bunching still occurs in some browsers, namely: IE9 (preview 7), Firefox 4 beta 8, and Chrome 8. So the problem is not really fixed. — This, that, and the other (talk) 06:31, 28 December 2010 (UTC)

Looking at Misplaced Pages:How to fix bunched-up edit links#Example 1, IE 9 Beta 9.0.7930.16406 on Win7 does not show bunching. Neither does Firefox 3.6.10, Safari 5.03, Opera 10.63 and Chrome 8.0.552.224.

Here is the Wikimedia Traffic Analysis Report - Browsers as of October. ---— Gadget850 (Ed)  13:24, 28 December 2010 (UTC)

I don't see bunching using Firefox 4 beta 8 (Linux). Bunching does return, as expected, if I use Firebug to remove the overflow:hidden from the new CSS rule for headers. Did you forget to bypass your cache or something? Anomie⚔ 14:38, 28 December 2010 (UTC)

I don't see bunching in Chrome 8 as well. You must purge your cache on each browser to enable the fix. — Edokter • Talk — 15:06, 28 December 2010 (UTC)

I do not think that bunching is fixed for me. I had to add the {{Fix bunching}} template to General Electric (following the directions at WP:BUNCH, as the edit link bunching was a problem there, caused by the infobox and image on the right side of the article. 00:38, 29 December 2010 (UTC)

Which browser are you using? Did you WP:Bypass your cache? Anomie⚔ 01:22, 29 December 2010 (UTC)

Oh, I am using I.E.8. I did not think about trying to bypass the cache to fix the problem. I just went over to the GE article to remove the {{Fix bunching}} templates so that I could test the cache-bypassing thing, but I edit-conflicted with Edokter, who alkso was removing them! X-D Anyway, it looks okay now that I have bypassed the cache. Thanks for the suggestion. 02:00, 29 December 2010 (UTC)

TwinkleWarn.js and CAT:NAMECONCERNS

Why are various users' copies of a user script called "twinklewarn.js" showing up in Category:Wikipedian usernames editors have expressed concern over? This doesn't make sense at all. (The master copy of said script is User:AzaToth/twinklewarn.js, which is also in the category.) — This, that, and the other (talk) 09:04, 28 December 2010 (UTC)

It is due to the line:

alert("You must supply a reason for the {{uw-username}} template");

If it was modified to:

alert("You must supply a reason for the {"+"{uw-username}} template");

Then it would no longer be an issue. -- WOSlinker (talk) 10:06, 28 December 2010 (UTC)

WOSlinker is an administrator himself, so he can fix the issue himself. HeyMid (contribs) 13:12, 28 December 2010 (UTC)

I didn't do the change straight away just incase anyone else had any comments to make but I've done that changes now. -- WOSlinker (talk) 16:51, 28 December 2010 (UTC)

Then he also could change the category-name not to end in a preposition (or delete it outright for being useless). ―cobaltcigs 03:47, 29 December 2010 (UTC)

You are welcome to nominate the category at WP:CFD if you wish. -- WOSlinker (talk) 10:05, 29 December 2010 (UTC)

Why would the category name need to be changed? Anomie⚔ 12:35, 29 December 2010 (UTC)

Single logon and meta

I've just edited a page at meta and found I was logged out, even though I have single logon enabled and it generally works. Does anyone else have this problem?--Kotniski (talk) 15:40, 28 December 2010 (UTC)

Single logon generally doesn't work for me unless I've already logged on during the current browser section, at least with IE7. However it works more reliably with IE8 and Firefox. Graham87 04:31, 29 December 2010 (UTC)

It always works for me when going to other language Wikipedias, Wiktionary etc. Is it not enabled for meta? Is there anyone for whom it does work for meta?--Kotniski (talk) 09:26, 29 December 2010 (UTC)

It works fine with meta for me. You might need to make sure your third-party cookies are enabled, first. /ƒETCHCOMMS/ 22:55, 29 December 2010 (UTC)

Regarding Misplaced Pages server locations and legal issues

Could someone take a look at this thread, and comment regarding the issues raised? Thanks in advance! ---My Core Competency is Competency (talk) 18:58, 28 December 2010 (UTC)

Sorting Misplaced Pages links?

Hi, I have a long list of Misplaced Pages links saved in a plain text file. A lot of the links are out of date and are redirects or their appropriate article has been removed. Is there any automated way of sorting through these links (e.g. automatically removing dead links and replacing redirects)? I am running Debian for what it matters, so tools like wget and awk are available. —Preceding unsigned comment added by 92.30.179.250 (talk) 22:25, 28 December 2010 (UTC)

If you install Python wikitools, you can use the following Python script:

import sys
import wikitools
wiki = wikitools.Wiki()
for line in sys.stdin:
  page = wikitools.Page(wiki, line.strip())
  if page.exists:
    print page.title

like this:

python sorting_links.py < pages.txt > sorted_pages.txt

where pages.txt contains names of the pages you want to sort, one on each line. The script removes changes that don't exists and follows redirects. Svick (talk) 19:16, 30 December 2010 (UTC)

Rollbacking technical assist

I was granted Rollbacker rights in August 2009, and have used it to what I feel has been good effect. Except, unfortunately, when I'm browsing my watchlist on my iPhone. Probably a half-dozen times now I've been uncareful when browsing my list and accidentally tapped "Rollback". I try to stop the page load, but the reaction time is usually too fast, and I wind up having to rollback my rollback, and feel like an idiot. I know there're web functions to identify browsers upon load; is there any way to strip the "Rollback" from one's watchlist when Misplaced Pages detects I've loaded the page in mobile Safari? — pd_THOR | 04:34, 29 December 2010 (UTC)

I don't know about browser-specific techniques, but you might try using User:Zvn/confirmwatchlistrollback.js, a script that makes rollbacking from the watchlist require a separate confirmation. This doesn't really affect rollback times when you need to do it, but it will prevent accidental rollbacking. — Gavia immer (talk) 04:50, 29 December 2010 (UTC)

Building on what Gavia immer has suggested, perhaps the following might be of use?:

if (navigator.userAgent.match(/iPhone/i) || navigator.userAgent.match(/iPod/i)) {
    importScript("User:Zvn/confirmwatchlistrollback.js");
}

That will activate the confirmation only when you're on an iPhone or iPod. I've got a few more tricks to optimize the iOS interface, if you're interested. {{Nihiltres|talk|edits|⚡}} 06:07, 29 December 2010 (UTC)

Awesome! Just put that in my vector.js? — pd_THOR | 06:35, 29 December 2010 (UTC)

Assuming you're using Vector, then yes. That's all you need to do. — Gavia immer (talk) 06:53, 29 December 2010 (UTC)

Thanks so much! — pd_THOR | 18:46, 29 December 2010 (UTC)

I'd also like to use something like this, but would like it completely disabled for the iPhone -- is that possible? Mike Christie (talk – library) 13:43, 29 December 2010 (UTC)

Something like

if (navigator.userAgent.match(/iPhone/i) || navigator.userAgent.match(/iPod/i)) {
    $j('.mw-rollback-link').remove();
}

Would do the trick. Happy‑melon 00:28, 30 December 2010 (UTC)

I tried that, and I still see the rollback link in my watchlist. I reloaded the monobook.js to bypass cache but it made no difference. Is there anything else I could try? Thanks. Mike Christie (talk – library) 14:11, 30 December 2010 (UTC)

Misplaced Pages IPv6 deployment

As the IPv4 address space on the internet is coming to an end, Misplaced Pages should support IPv6. Is there any plan or schedule for IPv6 deployment? Thanks :) ContinueWithCaution (talk) 21:47, 29 December 2010 (UTC)

The MediaWiki software does support IPv6. For Misplaced Pages and its sister projects, the biggest issue is that we make heavy use of SQUID caches, and the version of SQUID that we use (as of the last time I checked) doesn't support IPv6. Current versions of SQUID do support IPv6, but moving to a current version is likely to be a huge pain, so you can imagine that nobody wants to do it until it really becomes necessary. — Gavia immer (talk) 22:03, 29 December 2010 (UTC)

Given that the global IPv4 address pool is expected to run out in a month or so, to be followed by a whole world of hurt as mass IPv6 deployment is progressively (and for some large providers that didn't bother to plan, quite suddenly and unexpectedly) forced on an unwilling world by force majeure as the RIR pools run out, I'd say that moment has arrived. In particular, mobile users, and readers in places like China and Africa will be forced onto v6 faster than anyone else, and the alternative is for Misplaced Pages's new IPv6-only readers to reach Misplaced Pages over IPv4 proxy/protocol translation middleboxes, which will be even worse than going directly to v6.

At the very least, Misplaced Pages should be looking to get v6 transit from its transit providers now, and making sure that its DNS infrastructure works with v6, perhaps by putting up a ipv6test.wikipedia.org parking page that other users can test. This would also allow online testing of IPv6 brokenness, etc. by running test scripts that try to do test fetches from existing pages over ipv4. -- The Anome (talk) 22:29, 29 December 2010 (UTC)

Updated: Also, take a look at this: Measuring and combating IPv6 brokenness: Tore Anderson, RIPE 61, Rome, November 2010 -- IPv6 brokenness is now down to ~0.05%, and likely to decline further as OS X 10.6.5 rolls out to a wider audience. With a bit of semi-automated DNS whitelisting (ask Google!), that could be made even better. -- The Anome (talk) 22:40, 29 December 2010 (UTC)

The new data center is the first priority. Let's take it one major architectional rework at a time. P.S. infrastructure already runs IPv6. Basically only the mediawiki and squid installations don't do ipv6 yet, but MediaWiki is at least able to. 1.17 has several updates that fix a few bugs on the IPv6 front. But as soon as the datacenter is operational, I agree that IPv6 should be high on the list. —TheDJ (talk • contribs) 00:11, 30 December 2010 (UTC)

PS. I note that brokenness for wikipedia is still around .3%. See also http://ipv6and4.labs.wikimedia.org/ —TheDJ (talk • contribs) 00:29, 30 December 2010 (UTC)

Templates in upload pages

Where is the template that shows the directions for uploading, like at the link above? I feel compelled to change the hyphens to endashes :) /ƒETCHCOMMS/ 22:56, 29 December 2010 (UTC)

In MediaWiki:Uploadtext and the subpages of Misplaced Pages:Upload/Uploadtext. Graham87 03:03, 30 December 2010 (UTC)

Thanks! I just realized it was linked to in the upload page ... d'oh. /ƒETCHCOMMS/ 03:18, 30 December 2010 (UTC)

Text sizer

Hello, I am aiming to have a template for use firstly on en.wikisource (but I am interested in its applicability in other wikis). Currently, there are many text sizes in use, in order to capture any artistic value found in the original publication during digitization. The text size by default is good for reading many works, but many would be nice if larger. However, this gives an inconsistent appearance. Also, resolution, browser and PC settings make many of the works look drastically different. Where I've been working, in Children's literature, has made it clear that the availability to change text size would prove useful; a child using the text to read would benefit from having larger text. A popular work like s:The Velveteen Rabbit may be too small and strenuous to read the entire line (as even I tire from reading a line small and long). Immediate benefits would be:

1. Uniformity among the appearance of pages (defaulted)
2. One less parameter to consider when building
3. Give users the option of size regardless of their browser/PC settings (most important)

A "toggle button" is what I imagined, (switching the prior text to this) something unobtrusively found in the corner of the work. I don't know how to develop something like this, at all. Can someone help me? - Theornamentalist (talk) 23:15, 29 December 2010 (UTC)

Do you mean something like pressing ctrl-+ for your browser? I can't imagine this would be too difficult to do via javascript, even as a site-wide thing. A lot of news sites (i.e. this ABC News article have this functionality. /ƒETCHCOMMS/ 23:28, 29 December 2010 (UTC)

Yes, something exactly like that. I wasn't even aware of that function in my browser. I think that we should have that option available internally in WS. - Theornamentalist (talk) 23:30, 29 December 2010 (UTC)

Template {{lowercase title}} not working on ilomilo

Hi, I've added {{lowercase title}} to ilomilo, but it doesn't seem to be working, even when I purge the article, or log out. However, it works fine on the talk page at Talk:ilomilo. My best guess is that the title is in italics for some reason, and this interferes with the lowercasing. Any ideas? Can it be fixed? twilsonb (talk) 02:14, 30 December 2010 (UTC)

At Template:Infobox video game, the infobox used in the article, it automatically italicizes the title. Lowercase and Italics will not work on the same title, I do not know why. Sumsum2010·T·C 02:27, 30 December 2010 (UTC)

No, it works fine; just in this case we have effectively two instances of DISPLAYTITLE and only the last one is in effect. /ƒETCHCOMMS/ 02:30, 30 December 2010 (UTC)

I never knew two different DISPLAYTITLE's could work together until now. Sumsum2010·T·C 03:53, 30 December 2010 (UTC)

(edit conflict) Yep; it's italicized due to the infobox and the two templates are conflicting. Fixed using displaytitle after the infobox. There should be a parameter in all the infoboxes for this, really (if I didn't miss there already being one). /ƒETCHCOMMS/ 02:29, 30 December 2010 (UTC)

There isn't a parameter in {{Infobox}} or {{Infobox video game}}, so either we can make {{Italic title}} and {{Lowercase title}} compatible (if possible), or add a parameter to {{Infobox}} and friends. But this is way beyond me! twilsonb (talk) 12:46, 30 December 2010 (UTC)

Related changes filter

Is there a way to identify removal of internal links using the "related changes" filter. (similar to the external links removed tag?). There is a persistent sockmaster who removes internal links to India, Hindu and Hinduism in all sorts of articles and i am trying to trace his changes. --Sodabottle (talk) 03:33, 30 December 2010 (UTC)

My first ever attempt to upload an .svg file (all 8 tries were failures)

After trying, and failing, eight times to upload the following file

File:Logo_for_US_National_Whitewater_Center.svg

I gave up and uploaded the .png version of the file, no problem

File:Logo_for_US_National_Whitewater_Center.png

What did I do wrong? I kept getting a black rectangle in the .svg file. It never showed up on my computer file; it was only on Misplaced Pages after I made the upload. HowardMorland (talk) 03:58, 30 December 2010 (UTC)

Looking at the source, I find flowRoot elements which means you are using flowed text, which is not compatible with the SVG renderer. There should be an Unflow command in the text menu of most applications. You are also using Arial, a proprietary font that the renderer may or may not show properly— use DejaVu San instead. See Misplaced Pages:SVG Help. ---— Gadget850 (Ed)  04:34, 30 December 2010 (UTC)

(edit conflict)Anomie just fixed it. I believe that the problem was that there were some unnecessary flowRoot and text elements (not even relevant to the correct display of the logo) that prevented our rsvg SVG renderer from working properly and that we don't have Arial Narrow on the servers. In the future, you can avoid the latter problem by selecting text that is in a font other than that listed in m:SVG fonts in Inkscape and choosing Object → Convert to Path before uploading, or just use a different font. PleaseStand 04:38, 30 December 2010 (UTC)

It was the flow elements; your upload 2 minutes before mine also seems to have fixed it, but MediaWiki didn't warn me about the upload conflict. I also converted the text to path since this is a logo; for a diagram or something where the specific font used is not important, it would be much better to keep the text as text and just choose a supported font. Anomie⚔ 04:44, 30 December 2010 (UTC)

Thanks. I'm not sure what you did or how, but I am just learning to use Inkscape. Hopefully, I will figure it out. Inkscape does have an Unflow option in the text menu, so I will try to use it. Thanks again. HowardMorland (talk) 13:36, 30 December 2010 (UTC)

• Misplaced Pages noticeboards
• Misplaced Pages features
• Pages automatically checked for accidental language links