Wikipedia:Village pump (technical)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

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

The technical section of the village pump is used to discuss technical issues about Wikipedia. Bugs and feature requests should be made at BugZilla.

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.

« Archives, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212

Why are PNG's limited to 12.5 million pixels?

As a web-safe and lossless format, we should give this format full support. 12.5 mexapixels is now an affordable amateur camera. Is there any way to improve the thumbnail tool so it can support larger png files? - ʄɭoʏɗiaɲ ^τ _¢ 03:55, 20 January 2011 (UTC)

Basically this is just development work that needs to be done. The existing thumbnail tool reads the entire file into memory at once and has other scalability limitations. What's needed is a tool that works incrementally, efficiently, and with minimal memory overhead at any one time. This proves rather tricky because the pixels of a PNG are encoded in scan order, not using a quadtree. The best way to help is to build such a tool, integrate it with the latest Mediawiki, and submit a patch.

One interesting approach I just thought of is to create an "intermediate resolution" version that is cached - the intermediate resolution version would be slow to generate, but it would be under the current pixel limit and could be used to create any thumbnails smaller than itself. Dcoetzee 06:49, 20 January 2011 (UTC)

Heh, if I even knew where to begin, I would. I'm more of the one that takes the pictures; I'll leave coding to the experts. - ʄɭoʏɗiaɲ ^τ _¢ 18:50, 20 January 2011 (UTC)

Alas you rather highlight the issue - it's no-one's idea of fun :) So, in a volunteer-driven project, it's just not going to get done. Maybe one day the WMF could get it programmed (since they have that wonderful motivator known as "money"), I suppose, but I'm not holding my breath. Ah well. - Jarry1250 ^{[Who? Discuss.]} 19:57, 20 January 2011 (UTC)

Some people find coding fun. I think the fact is that much of this stuff is hidden under the hood. Where is the current thumbnail generator code located, for someone to pick apart and modify? - ʄɭoʏɗiaɲ ^τ _¢ 20:22, 20 January 2011 (UTC)

Thumbnailing is currently done by calling the ImageMagick utility which is what generates the high memory usage (roughly 4 bytes per pixel). One would need to either modify ImageMagick to provide a more conservative memory mode (and get those modifications accepted by the ImageMagick developer community) or one would need to develop an alternative means for Mediawiki to generate thumbnails from large images, and get our developer community to use that alternative. Dragons flight (talk) 20:54, 20 January 2011 (UTC)

ImageMagick has support for tera-pixel image sizes, what's needed is probably just to invoke the right ImageMagick options from MediaWiki. Command line example from here: convert -define registry:temporary-path=/data/tmp -limit memory 16mb logo: -resize 250000x250000 logo.miff Nicolas1981 (talk) 05:48, 24 January 2011 (UTC)

Hhmmm, apparently "limit memory" was added in late 2007. I hadn't seen that before. You are right that there may now be a solution. Dragons flight (talk) 06:32, 24 January 2011 (UTC)

PS. Since it appears to substitute disk caching for memory, it might still be too burdensome under some circumstances, but it maybe possible to adjust the limits. Dragons flight (talk) 06:40, 24 January 2011 (UTC)

Even a small boost to 15 million would be enough for most standard cameras. Thats enough to support 4230 x 3420. - ʄɭoʏɗiaɲ ^τ _¢ 15:50, 26 January 2011 (UTC)

Is there a better or more proper venue I could take this to? Its a small change to make a lot more detailed photos compatible. - ʄɭoʏɗiaɲ ^τ _¢ 17:28, 29 January 2011 (UTC)

The suggested fix has been included at bugzilla:9497. Maybe you could vote for that bug too. So far it has received only three votes, which isn't exactly much for such a long-standing and fairly serious limitation IMO. --Morn (talk) 13:04, 30 January 2011 (UTC)

There is no sign of a viable fix at that bug. As pointed out pngds is subject to random crashes. OrangeDog (τ • ε) 11:14, 31 January 2011 (UTC)

I'm just looking to get the current limit increased, not to recode or use new software. I'm guessing I'd do that at the Meta village pump? - ʄɭoʏɗiaɲ ^τ _¢ 15:03, 31 January 2011 (UTC)

No, at bugzilla. However, I imagine that the devs won't increase it by a large amount due to performance, and won't increase it by a small amount as there is little benefit. OrangeDog (τ • ε) 15:40, 1 February 2011 (UTC)

I'm not sure if increasing the size is a good idea. There is a reason why the limit exists ManishEarth^{Talk • Stalk} 16:00, 1 February 2011 (UTC)

Slowness and timing out error message

I use Firefox, and I have no similar issues with any web site but Wikipedia. This has been coming on for months, but used to be only once in a while.

Over the Jan 15-17 weekend, I noticed Wikipedia was really slow, no matter the page or action. You could take little mini-naps waiting. And the Timed Out message with the "try again" option kept coming up. Wikipedia's speed recovered after the weekend, but the timed out messages have gotten worse. Sometimes it's every other click of the mouse, or every third or fourth. Way too much. It's only Wikipedia. My cache was cleared. Maile66 (talk) 14:23, 21 January 2011 (UTC)

Wikipedia is often slow, even down sometimes. It happens to all of us. If you're only having the problem with Wikipedia and have cleared your cache etc., then that just simply makes it more likely that the website and not your browser, Internet connection, etc. is the problem. Gary King (talk · scripts) 05:49, 22 January 2011 (UTC)

One thing that can sometimes make a difference (here in the UK anyway) is the server that you log in through. In the normal course of things the secure server is very slightly slower than the normal server, but if the normal server goes dead slow you may find that the secure server is running at its usual speed.

When you go for the "Log in / create account" link at upper right, you get to the login screen for the normal server. If you don't actually log in there but read down the page, you'll see "Consider logging in on the secure server. That takes you to another login screen, where you can log in using your normal ID and password. --Redrose64 (talk) 11:51, 22 January 2011 (UTC)

Thanks for the helpful advice. Maile66 (talk) 12:43, 22 January 2011 (UTC)

This problem is probably being caused by difficulties connecting to bits.wikimedia.org, responsible for serving various site scripts, due to routing issues – are you in the UK, by any chance? ([1]) This problem is alleviated by using the secure server since those scripts etc. that are usually served by bits.wikimedia.org in the non-secure environment are served directly from the secure server. 217.137.122.112 (talk) 13:09, 22 January 2011 (UTC)

As a UK user, I've experienced the same problem, and tried the secure server. However, on every WP page I go to, I have to dismiss the MS "do you only want to view the secure content" pop-up. Can this be overcome just for WP? (I'd like the pop-up to remain for other sites).
Arjayay (talk) 16:36, 22 January 2011 (UTC)

Assuming you're using Internet Explorer (since you said "MS"), you can disable those popups just for Wikipedia by following these instructions. Gary King (talk · scripts) 17:03, 22 January 2011 (UTC)

Thanks - Indiana University uses simple instructions! so double-thanks Arjayay (talk) 19:31, 22 January 2011 (UTC)

I'm using secure server and have the same issues as Maile66. I'm in the UK and the problem does get worse as the day goes on(likely as more US traffic). At times I get a 50% fail rate to posting. I rarely do a 'show preview' anymore because the fail rate is high. I just submit and if it fails.....after about 15 seconds, hit back and submit again. I've only double posted once. Still it's not a fun way to edit. Regards, SunCreator ^(talk) 16:54, 22 January 2011 (UTC)

Ironically today is about the best it's been for weeks. Maybe because it's Saturday? Regards, SunCreator ^(talk) 16:56, 22 January 2011 (UTC)

NTL routing issues have been recently fixed; try again now and see whether your problems have been resolved. 217.137.122.112 (talk) 17:08, 22 January 2011 (UTC)

I am experiencing the exact same issue; always thought it was something to do with my network... I am logging in from Sri Lanka. Rehman 02:59, 23 January 2011 (UTC)

Wikipedia was just offline to me for a period of about 7 minutes. I guess the time of day means lots of traffic in America now? Anyway, thought it worth noting the downtime. Regards, SunCreator ^(talk) 03:32, 23 January 2011 (UTC)

"The server at en.wikipedia.org is taking too long to respond." is part of the error message. What someone mentioned as "50% fail rate" is sometimes the norm, regardless of weekend/weekday or time of day or night. Frustrating. Maile66 (talk) 03:38, 23 January 2011 (UTC)

More bugaboos

Reference my earlier post about slowness and timing out. I use Firefox. It's still doing that, even worse. But now it has an added kick. It's logging me out. That nonsense just started about half an hour ago, but thought it was worth mentioning, in case anyone else is experiencing Wikipedia's mood swings. Maile66 (talk) 01:23, 26 January 2011 (UTC)

• I also noticed terribly slow response time, the past few days, where perhaps 1 in 10 edit-previews would time-out (So, I made mirror edits in a text-editor window to avoid losing all edits due to time-out). The developers might have restricted user resources, for a few days, in preparation for the dot-17 release (MediaWiki 1.17) which has numerous tiny changes to slightly adjust internal data structures, and totally remove some sections of deprecated code (rather than just leave it, who cares). Some group has created a children-will-like-it upload screen for Wikimedia Commons, with a cartoon explaining the process (I'll bet the upload-cartoon doesn't cover analyzing a fair-use rationale to comply with changes to international copyright law!), just the basics for users new to Commons upload of "free" images. They are improving secure login to allow returning to non-secure browser windows (but any celebrities had best continue editing with secure-post mode). A lot of clerical changes: it's mostly like re-arranging deck chairs (or coal shovels) on the Titanic, rather than building new ships to solve major concerns. Bigger changes usually happen to templates or policies than to the MediaWiki features. Remember, last year we removed the WP:CANVAS censorship which warned people not to tell others about new articles: now if you write a new article and tell 9 people, you can't be accused of conspiracy to provide too much valuable information. I think we will need to have a 2nd Wikipedia, which can risk major new features without the fear that the ONE Wikipedia will die if a new feature has a severe bug. -Wikid77 06:49, 26 January 2011 (UTC)

Aha. Yes, I experienced being logged out too. It seemed to me that it happens after leaving Safari (I use FF and Saf), with (or without?) FF open & logged in.

Re my report below about being logged out, I use Firefox, but do have IE open and minimised in order to run AWB, which I do from my NSH002 account. --NSH001 (talk) 11:58, 26 January 2011 (UTC)

I had similar issues with firefox, only it was 100% logging me out. Switching to rekonq solved the problem. Not sure what was going on. Sailsbystars (talk) 14:56, 26 January 2011 (UTC)

Connection timed out

I've been getting an increasing number of "connection timed out" messages in the last few days, and just wondered whether anyone else had noticed the same thing. SlimVirgin ^{TALK|CONTRIBS} 05:26, 26 January 2011 (UTC)

• Yes, in various locations, for over 5 days, while we ran other websites quickly. Sometimes, 1-in-10 edit previews would time-out (leading to, "I had better copy this edit-buffer to an external text editor or risk losing all"). Currently, the Arabic Wikipedia is as slow as a tourist walking through the deep sand in the Sahara. See concerns above:

• #Slowness and timing out error message
• #More bugaboos

I suspected the developers are testing new MediaWiki 1.17 on some servers, but maybe not. I didn't see any great, giant new features in 1.17, but all computer-math is showing 15/16 digit precision, rather than some having 12/13 digits, a few weeks ago (so that indicates system upgrades). I am working on essays to improve performance, such as making {Cite web} & {Cite book} run 4x times faster & smaller, which are 95% the wikitext of scholar's articles. Also, we need to avoid those large bottom navboxes which are causing "50,000" articles to reformat all the time. Over 1.1 million navboxes are typically doubling the size of "every" article on Wikpedia (it should be running twice as slow for everyone). --Wikid77 07:31, 26 January 2011 (UTC)

I thought the problem was my Internet connection...good to know that it's the servers. Nyttend (talk) 14:12, 26 January 2011 (UTC)

I don't believe this is the case: although some servers may have been taken out of rotation for other reasons, testing 1.17 is unlikely to be one of them. 1.17 is still in code review. Happy‑melon 15:22, 26 January 2011 (UTC)

Thanks, Wikid, I was about to contact my ISP. I know that citation templates slow things down (I wish we could find a way to stop encouraging people to use them), but which are the navboxes that are causing the problem? SlimVirgin ^{TALK|CONTRIBS} 23:56, 26 January 2011 (UTC)

I have also had an unusual number of connection time outs, 'server not available' messages, and general slowness of response, over the same recent periods as mentioned by the posters above. These problems are only related to WMF sites. I connect from Thailand using MacOS with FFox and Safari through good DSL (at home and in the office) and EGPRS (EDGE) when on the move (and sometimes a smart phone). Kudpung (talk) 01:48, 27 January 2011 (UTC)

being logged out

This has happened to me 2 or 3 times this morning. Very annoying. Unlike others above, Wikipedia doesn't seem any slower than usual. Just thought I'd mention it here, in case others are having the same problem. --NSH001 (talk) 11:30, 26 January 2011 (UTC)

It's happened to me too over the last couple of days. SlimVirgin ^{TALK|CONTRIBS} 00:03, 27 January 2011 (UTC)

Saying "It doesn't work" is pretty useless in trying to get this fixed. At a minimum, your location, your ISP, connection details, etc would be helpful to the people who can even begin to look at this. Q ^{T C} 01:20, 27 January 2011 (UTC)

Q, if the problem were my ISP/connection/location, or similar, this would not be the place to discuss it. I posted the message to discover if the problem might be with the servers or their software. Fortunately the problem has not recurred since I reported it above. --NSH001 (talk) 08:35, 27 January 2011 (UTC)

It happens to me too with increasing frequency. Fortunately I notice before pressing the 'save page' button, because the skin goes back to the vector default, whereas I, wisely, use monobook which is far more stable and has a much more practical interface. Kudpung (talk) 01:48, 27 January 2011 (UTC)

It just happened to me about five seconds ago. I just refreshed the page I was on a couple times and I was magically logged-on again.--Brianann MacAmhlaidh (talk) 08:48, 27 January 2011 (UTC)

It looks like a rogue server. Can you identify the server which showed you as logged out? (View source, and look at the "Served by" at the very bottom) Platonides (talk) 23:37, 28 January 2011 (UTC)

Formatting numeric templates on Arabic WP

I do not speak Arabic, so I am wondering if anyone here knows of a CSS style that forces left-to-right text on the Arabic Wikipedia (or other right-to-left languages). I have ported the Template:Convert subtemplate for temperature ranges, {{Convert/Dual/LoffAoffDxSoffT}}, but the output, usually of the form "10–20 °C (50–68 °F)" is being scrambled in Arabic due to Latin letter "F" within parentheses "( )". Currently, I am hiding the letter "t" (as font color=white) at the start/end to force Latin-text alignment, as left-to-right:

• Hiding "t" at start/end:   t10–20 °C (50–68 °F)t.

However, is there a browser style directive (or some template, because {nowrap} still scrambles parentheses), which does not introduce hidden text, but can directly format text as left-to-right in the Arabic Wikipedia? There's no hurry on this, because the 2 hidden t's work okay for now. -Wikid77 21:10, 25 January 2011 (UTC)

In depth, Unicode Bidi Algorithm covers this for most browsers. Hardcoding, you could use uniciode bidi-formatting 'control' characters Unicode_character_property#Bidirectional_writing. The special characters LRE, RLE, LRO, RLO, PDF ('pop') can control/overrule the F-property 'latin'. They are ‮invisible‬, but just take a look how they work. ‮Amazing‬, innit? ‮10–20 °C (50–68 °F)‬. Need more?-DePiep (talk) 22:29, 25 January 2011 (UTC)

Adding: the algorithm UAX#9 is here, but is not easy reading. Some 28 rules must be applied to a character string (in memory), using the 19 bidi-types in the above linked table, while interpreting paragraph breaks, linebreaks and looking at neighboring character properties. A group of rules is specific for LtoR numbers in RtoL scripts, but as you write an "F" or so might break the logic. (detail: in LRO and RLE &tc, O=override, E=embed, and 'Pop Directional Format' (pop) is the general closing bidi-bracket for the latest (closest, deepest nested) LRx/RLx bidi-bracket). -DePiep (talk) 22:47, 25 January 2011 (UTC)

So would this solve it: the number & dimension sequence must be LtoR in Arab. Simple would be: the template outputs: LRO‭Template:Convert/-‬PDF. The ()-bracket are kept too. Will be more difficult when there are Arabic words etc in: say "From 10 to 20." would have to translate into: "RLOFrom LRE10PDF to LRE20PDF.PDF", so: "‮From ‪10‬ to ‪20‬.‬". (using Embedding within an Override. Do NOT change the sequence of the characters: in memory they will stay LtoR always. The browser will reorder them as defined when sending them to the display) -DePiep (talk) 23:00, 25 January 2011 (UTC)

To answer the actual question, the CSS property is "direction" and can take values of "ltr" or "rtl". OrangeDog (τ • ε) 00:45, 26 January 2011 (UTC)

There was also this question: is there a browser style directive (or some template [...]), which does not introduce hidden text, but can directly format text as left-to-right in the Arabic Wikipedia. -DePiep (talk) 01:58, 26 January 2011 (UTC)

• Thank you both. In this case, the unicode characters worked to override each temperature word and retain the flow of the surrounding Arabic text: using "‮F°&#x202C" reversed the text as "°F" without disturbing the nearby Arabic text. They have a special symbol for "F" Fahrenheit, but at least, now, Arabic Wikipedia has the temperature-range conversions which they have been wanting for nearly a year now. Considering the mind-boggling differences between the Arabic Wikipedia and enwiki, this 1-day one-year solution was as you said, "‮Amazing‬" ("Amazing"). Thanks again. --Wikid77 05:25, 26 January 2011 (UTC)
  • You might want to consider using templates to insert those characters. Allows easy changes, and {{LRO}} is probably easier to read than ‮ and friends. (perhaps we should add a magicword/tag or something to MediaWiki itself ? —TheDJ (talk • contribs) 11:41, 28 January 2011 (UTC)

centralNotice inconsistency

… .notice-collapsed-wrapper-stew2011-noms {
    margin: 2px auto 0; …

Because of this margin, even with a cookie saved to hide the notices at the top, pages "randomly" jump around 2px every now and then (when the "Candidates for the 2011 steward elections…" notice is chosen). This is not a big problem, in fact I couldn't even reproduce it on Windows, but it is annoying, and I do find it unnecessary. That particular notice has a significant amount of custom CSS inserted and I don't really understand why. Shouldn't these notices be more or less uniform? At least the ones that are just text anyways? ¦ Reisio (talk) 07:53, 26 January 2011 (UTC)

Which browser and which skin ? —TheDJ (talk • contribs) 11:49, 28 January 2011 (UTC)

This should be fixed once the cache clears (5 minutes). Had to remove a superfluous div that was not included in the collapse definition. Kaldari (talk) 22:39, 28 January 2011 (UTC)

Using #switch: 'p' does not match 'p'

(Few days ago I did a neighbouring(?) report on this font-related class="IPA" disrupts a #switch:). {{IPAsym}} uses #switch:. Input is a IPA-character, output is the corresponding IPA article. But when entering the character using numeric reference like &amp#x0070;, it fails to find it. Example with the regular 'p':

• {{IPAsym|p}} → Voiceless bilabial plosive
• {{IPAsym|p}} →
• {{IPAsym|{{StripWhitespace|p}}}} →

Any hints on solving, or should I work around it? -DePiep (talk) 12:01, 26 January 2011 (UTC)

According to the template's documentation, you can only enter IPA characters or IPA numbers; HTML entities do not work. — Edokter • Talk — 15:03, 26 January 2011 (UTC)

"p" is an "IPA character". But Unicode does not know or handle an "IPA character" differently: to you, me & Unicode it is just a regular "p". The point is: when entered by typing (or copypasting), it is recognized by "#switch:", when entered by p, it is not recognised. "p" is an easy example, non-US-keyboard chars (like ð) have the same behaviour/problem. -DePiep (talk) 00:26, 27 January 2011 (UTC)

This is expected behaviour, as p and p are not the same. Consider instead |, the encoded form of the pipe character... you wouldn't want that to be treated in the same way as its raw counterpart, would you? :D Happy‑melon 15:13, 26 January 2011 (UTC)

No. I expect p (rendered) and p to be the same. It is the same character. Another expected the same is p. Maybe you mean to say explainable different? -DePiep (talk) 00:26, 27 January 2011 (UTC)

re the pipe symbol & encoding: what you describe is the my Q other way around. There is nothing I may "want" in behaviour. We "expect" in behaviour. When I encounter pipe-problems, sometimes I can handle them (e.g. by using the template {{!}}). But that is understandable logic to me by now (I use that in #if: table-building). Saying "(A) =/= A is expected", as you do here, is not logic to me. -DePiep (talk) 00:42, 27 January 2011 (UTC)

HTML entities are decoded by the browser. Mediawiki never knows what the encoding means. This behavior is desirable in some cases, and is unlikely to change. Dragons flight (talk) 00:46, 27 January 2011 (UTC)

That is it then. Any option (class, CSS, template, trick, dunno) to solve it this/our side? -DePiep (talk) 00:53, 27 January 2011 (UTC)

Wanna say thanx to the contributors, despite of diffs. -DePiep (talk) 00:56, 27 January 2011 (UTC)

What's wrong with the trivial option of inputting the letters directly rather than with entities?—Emil J. 12:12, 27 January 2011 (UTC)

Nothing wrong with that. The option stays. In the current ~150 calls of {{infobox IPA base}}, all input does so (either by character, or by "IPA number" -- none by hex). The question rose, when I tried to use the hex or decimal editors input (in a regular article page) to a valid IPAsym output article name. This would reduce the essential main input to two out of three: IPA-number -- symbol -- Unicode-decimal-value. E.g. the font does display well through Unicode-HTML-reference (but that same code does not return the IPAsym article name, as is the issue here). After this thread, the solution must be: editor expected to enter all three out of three. That will do, we'll just have to instruct (document for ) the editor. -DePiep (talk) 02:03, 28 January 2011 (UTC)

• Using a #switch, to check separate characters, would need both values in each bar-branch: such as "p | &#x0070;" to match either the literal "p" or its hex-code. A #switch can have over 1,400 values in the branches. Long term, I think we need to change the NewPP preprocessor to allow metacharacters, such as the UNIX "\b" or "\t" for a space or a tab, at least to treat some entities such as "&nbsp;" as the 1-character value &#160; with string length of 1. Currently, using "&#32;" is a 5-character string (&-#-3-2-;), and "&nbsp;" is a 6-character string until displayed. UNIX has used the backslash "\" as the escape character to denote text metacharacters because file path names used the forward slash ("/"). Using that method, prepending a backslash could denote "\&#x0070;" as the 1 character "p" rather than the current literal 9 characters. Worrying about performance, I would expect the preprocessor to just place 1 character in the text, rather than 88-character marker text which "<nowiki>xx</nowiki>" currently generates. -Wikid77 13:36, 27 January 2011 (UTC)

Wikid: way beyond my scope, but I get the idea. For now, I am OK with the explanation by User:Dragons flight: "rendered in the browser", i.e. after the template is solved. That's it. -DePiep (talk) 02:03, 28 January 2011 (UTC)

It would be more controllable to introduce a parser function {{#decodeentities:...}} which fully-unescaped references. "&#32;" is a five-character string, in the HTML source as well as in wikitext. There are some situations where you do want to be able to evaluate it as one character, and some situations where you wouldn't. Introducing new behaviour for previously-unmagic notation is dangerous, and would require a huge amount of testing on old and current revisions. Implementing it through a parser function or similar provides the same functionality without impacting on existing wikitext. Happy‑melon 13:28, 30 January 2011 (UTC)

Keymanweb alternate language input facility safe?

Hi, Can someone help me with any feedback regarding the User:Keymanweb/Keymanweb virtual keyboard? The monobook.js page suggests that I check out the Village Pump if in doubt so here I am. By the way, I did a search for keymanweb but did not see many results. My main wory is that the user page and user talk page for keymanweb did not help at all in veryfing the safety/robustness of this tool. Any help appreciated.-Deepraj | Talk 20:20, 27 January 2011 (UTC)

Its from the commercial website www.keymanweb.com by Tavultesoft. It loads external JS and has the potential for keylogging, but seems wider used than just here. If you want to be sure, you need to do a full review of the code (i don't have the time). How much do you trust the company ? :D —TheDJ (talk • contribs) 12:24, 28 January 2011 (UTC)

Help with a Navbox

 Done
Hi folks. I've made this template: Template:Interior Ranges of British Columbia It seems to work nicely on the template namespace, but when transcluded to an article, like Dunn Peak massif, it doesn't open up. Any tips/fixes? The Interior(Talk) 03:49, 28 January 2011 (UTC)

You need to add the parameters group1=whatever, group2=whatever, to have each sub navbox show up. I don't really see the point of that #if parser, so you might as well remove the {{#if:{{{group1<includeonly>|</includeonly>}}}{{{sect1|}}}{{{section1|}}} and related for group2. /ƒETCHCOMMS/ 04:49, 28 January 2011 (UTC)

Sorry to be dense, but where should the Group parameter be added? I tried removing the "#if" lines, but ... result was not optimal.The Interior(Talk) 06:20, 28 January 2011 (UTC)

I have cleaned up the navbox a bit and put it on Dunn Peak massif the way I think it should be. Do you find it okay now? Svick (talk) 11:15, 28 January 2011 (UTC)

Perfect! I'll have to take a look at what you did to fix. I really appreciate it, the double collapsible w/columns was a bit ambitious for me. Looks great, thanks again to both for taking a look. The Interior(Talk) 17:33, 28 January 2011 (UTC)

Numbers often 3-digit but what length are strings

What is probably the most-common string length in English Wikipedia usage, such as with counting (by {{Template:Str_len|abcdef}}=6)? In designing shorter ways to handle character strings (and numeric strings), I have found that, by far, the most common numbers in conversions are 3-digit integers, such as 115 in {{convert|115|km|mi|0}} → 115 kilometres (71 mi). Perhaps 70% of conversions are 3-digit integers, then 3-digit decimals, with 2-digit integers less common (scanned by wiki-searching for Convert option "abbr=on"). However, I can't yet think of an easy way to scan through uses of {str_len} to find the typical size of character strings counted on English Wikipedia. The WP:Database_reports list {Str_len} as used 480,510 times. However, many uses are buried in the inner reaches of complex templates, so I dread sampling article edits from the nebulous Special:WhatLinksHere/Template:Str_len, where an article's text has nothing, but uses an infobox layer invoking {str_len} deeply hidden within. Anyway, I guess I could edit through several many pages in that list. Does anyone know of any count data, already gathered about this issue, or typical infobox string codes? There's no hurry on this. Just curious if the typical length is 3 or 4 or 7 (etc.). -Wikid77 08:20, 28 January 2011 (UTC)

• Average string length is italicized article-title length: 19? Okay, it appears the average string length for {str_len} is the average length of italicized article titles: 19 characters (based on a sample of 10,000 titles). The titles are those "353,026" pages using Template:Italic_title to italicize films, books, albums (etc.), up to the left-paren. "(" suffix. So, I think I found Template:Italic_title is the "elephant in the room" of string usage, using {{Str_find}} 4 times for every title with "(" and hence, using {str_len} 5 times for every such title. Because {Str_find} uses 99 {str_left} (with {padleft}) for every string searched, then {Italic_title} is using 450 calls to {padleft} for every title containing left paren "(" in the title. {Italic_title} always invokes {str_find} 1 or more times, so that's at least 35,303,000 calls to {padleft}, plus 350 more uses of {padleft} for each italiziced name with "(" in the title, probably nearly 30 million. So, {Italic title} is using more than 64 million calls to padleft. Based on a sample of 10,000 italicized titles, where 2336 titles had parentheses "()", the indication is that 82,500 articles using {Italic title} have "()". Hence, the processing for "()" adds nearly 82,500 x 350 = 28,875,000 more calls to {padleft}. I have mentioned this under Template_talk:Italic title, for possibly improving operation, long term. More later. -Wikid77 20:18, 28 January 2011, revised 07:48, 29 January 2011 (UTC)

Glitch

IP reverted vandalism here; content does not match difference. Tried to remove manually, but edit mode doesn't match the content, either. --Confession0791 ^talk 09:05, 28 January 2011 (UTC)

The vandal duplicated most of the page content inside a comment in this edit. Whoever tried to remove it manually didn't notice that, and edited the part inside the comment instead of the text that was actually being rendered. I think I reverted it to the last good revision for you, but someone should probably read it over to make sure more crap didn't sneak in earlier. Anomie⚔ 12:14, 28 January 2011 (UTC)

Signature Issues

Hi, i'm having trouble with my signature as it's too big to fit into the box and i haven't even finished. What i have so far is "Jenova" but it should be in bold and have a black background around just the "Jenova" part with 20 just in black at the end. Can anyone explain how to do this? Thanks 09:24, 28 January 2011 (UTC) — Preceding unsigned comment added by Jenova20 (talk • contribs)

What about Jenova20? That should save some characters from the limit (and it also makes more sense logically). Svick (talk) 11:18, 28 January 2011 (UTC)

If you use <u> tags you can save perhaps (4 − 1) × 2 × 6 = 36 bytes and also make the underlining color match the text color instead of being a continuous red or blue bar. ―cobaltcigs 16:12, 28 January 2011 (UTC)

This signature fails per Web Content Accessibility Guidelines. ---— Gadget850 (Ed) ^talk 17:32, 28 January 2011 (UTC)

In particular, the yellow "n" is very difficult to see against the background colour of this page (the orange "e" isn't much better). The background is a pale greenish-blue here, but other talk pages differ: you shouldn't make assumptions about the background colour of any page. You'll notice that in my own signature, where a colour is set the background is also set (i.e. <span style="color:#d30000; background:#ffeeee">Red</span>), and there is a high degree of dark/light contrast between the two forced colours. --Redrose64 (talk) 17:50, 28 January 2011 (UTC)

• Yellow could be "color=gold" then use "lime" with color=black on "20", set background:#999 for gray, plus "<b>" for bold, as: Jenova20, with quotemarks removed in the wikitext: [[User:Jenova20|<b><span style="background:#999"><font color=red>J</font><font color=orange>e</font><font color=gold>n</font><font color=lime>o</font><font color=blue>v</font><font color=purple>a</span><font color=black>20</b>]]. I don't think quotation marks are needed with the one-word colors. The Firefox browser doesn't use color=0, so put color=black for "20", but Firefox also allows omitting each end-tag </font> to shorten the signature. -Wikid77 08:27, 29 January 2011, revised 11:10, 29 January 2011 (UTC)

Maybe the n is supposed to be so faint that other editors have to guess which letter it is? I know what I would guess, and I believe it's not in line with the username policy. Hans Adler 10:43, 29 January 2011 (UTC)

Quotation marks are indeed not required with one-word colours when used in the <font>...</font> element. They are only required in HTML element attributes when the attribute data contains any character other than letters, digits, period or minus. So, <font color=blue> does not require quotes, but <font color="alice blue"> and <span style="color:blue"> both do (because of the space in the former, and the colon in the latter).

Firefox may permit the omission of the closing </font> in certain circumstances (see below) but that doesn't mean that other browsers do too. You cannot assume that all target users have the same browser, nor even that some browser quirks are universal. It's not good HTML to leave any tag unclosed, with very few exceptions: within the <body>...</body> section, the only tags which ordinarily permit non-closure that I know of are the inherently self-closing tags (<br>, <hr> and <img>); certain block elements (such as <p>) and certain elements which are intended only for use within blocks (such as <dd>, <dt>, <li>, <td>, <th> and <tr>). I know of no inline elements (and both <font>...</font> and <span>...</span> are inline elements) for which non-closure is valid HTML. --Redrose64 (talk) 16:42, 29 January 2011 (UTC)

singing with tildes doesn't work

I have recently changed my username, and as you will probably notice as you read on, signing with four tildes doesn't seem to work. I still get a notification on my talk page that i have to sign my posts. any ideas? Rafy talk — Preceding unsigned comment added by Rafy (talk • contribs) 16:17, 28 January 2011 (UTC)

In order for SineBot to detect your signature as a proper signature, it has to contain a link to your user or talk page. The bot has no way of knowing that you have changed your username, you should fix the links to point to your current user page.—Emil J. 16:37, 28 January 2011 (UTC)

Are you signing with four tildes? Three tildes only produces your signature without a timestamp. Your signature does not contain a timestamp, which is causing signbot to think you're not signing your posts. — Edokter • Talk — 16:36, 28 January 2011 (UTC)

Ok let's test this after changing link and using 3 tildes... Rafy talk — Preceding unsigned comment added by Rafy (talk • contribs) 17:02, 28 January 2011 (UTC)

Use four tiles and change "ravi84m" to "Rafy" in your prefs. –xeno^talk 17:05, 28 January 2011 (UTC)

Oke I hope it workes now. Rafy talk 17:07, 28 January 2011 (UTC)

Yep it worked... Thanks guys Rafy talk 17:10, 28 January 2011 (UTC)

Just a suggestion: the font size is a little big. Would probably be a good idea to ensmallen it somewhat. –xeno^talk 17:13, 28 January 2011 (UTC)

 Done-- Rafy talk 19:05, 28 January 2011 (UTC)

as an aside, I think you meant to say 'debiggen' not 'ensmallen' - ballon logic, that --Ludwigs2 19:09, 28 January 2011 (UTC)

A cromulent observation. –xeno^talk 23:42, 28 January 2011 (UTC)

keymap of 'save page' and 'show preview' buttons?

When I'm editing a page, I'll often type in my edit summary and hit the return key to submit. However, every once in a while I'll do that and it will trigger the 'show preview' button rather than the 'submit' button. I can't figure out what causes that difference. does keymapping to buttons change via some undocumented feature, or am I miskeying, or is this just some reasonably frequent but random fluke? Not a big issue (it's just confusing), but if there's an intentional way to trigger a show preview rather than a submit that would be useful information. --Ludwigs2 16:18, 28 January 2011 (UTC)

The Save Page button should always be activated when hitting Enter on the Edit Summary because it appears first in the HTML, even though there are three submit buttons on the edit page (Save Page, Show Preview, Show Changes). I've never had the problem that you are describing. Has this been happening for a long time? Gary King (talk · scripts) 21:47, 28 January 2011 (UTC)

The Tab key can move between buttons but in my browser it takes several Tabs before Show preview or Show changes becomes active. PrimeHunter (talk) 00:56, 29 January 2011 (UTC)

@ Gary: no, it happens occasionally (I'd say once or thrice a month). It could be a Safari-dependent thing - a semi-random rendering mistake, a weird undocumented 'feature' that I'm somehow triggering accidentally (and yeah, it's not a tab key thing - that would take it to the 'minor edit' checkbox first). Unfortunately I can't replicate it on demand; I was just hoping someone else had a clue about it. --Ludwigs2 03:03, 29 January 2011 (UTC)

All I can say is it's probably something on your end, as something has got to seriously be out of whack for the page to be served that way to your browser. Meaning, even if your browser rendered the page strangely, the order of the submit buttons shouldn't change. For instance, maybe it's a Firefox extension if you're using that browser, etc. Gary King (talk · scripts) 04:40, 29 January 2011 (UTC)

No autogenerated table of contents at Talk:Cherokee

Talk: Cherokee is a lengthy talk page with many sections, but there is no autogenerated table of contents at the top. The archive pages for this talk page do have autogenerated tables of contents (and I do see these tables on other long talk pages, so I assume it's not something in my preference settings). I've looked at the code and I don't see anything obvious to account for this. I suppose a solution would be simply to add manually the code for a table of contents, but I would like to understand this function better, so I would appreciate it if someone could explain why the autogenerating function isn't working there. Thanks,--Arxiloxos (talk) 17:00, 28 January 2011 (UTC)

Looks like removing Template:WikiProject Oklahoma and two others (total templates three or less) produces the TOC. -DePiep (talk) 17:28, 28 January 2011 (UTC)

(edit conflict)It's not a fault with this talk page, but with two of the project banners. If you remove both of

{{WikiProject Oklahoma |class=B |importance=Top |tulsa-task-force=yes }}
{{NorthAmNative |class=b|important=mid|0=A  }}

the TOC is generated normally. If you remove just one of these, it isn't. --Redrose64 (talk) 17:29, 28 January 2011 (UTC)

• It has to do with the deprecated assessment subpage, which I've just deleted after pasting it onto the talk page. –xeno^talk 17:34, 28 January 2011 (UTC)

Spaces in external links

How can I encode spaces in external links? To explain: I would like to let users write {{gbmappingsmall|NH 714 684}} so that it displays prettily: as NH 714 684. But unfortunately it breaks down totally: NH 714 684. I need a function that will remove each space or convert each space to %20 or _ when forming the external link. Does such a function exist? — [[::User:RHaworth|RHaworth]] (talk · contribs) 22:37, 28 January 2011 (UTC)

Urlencode, I guess: NH+714+684. You might want NH%20714%20684 instead, which replaces spaces with %20 instead of +. Ucucha 23:13, 28 January 2011 (UTC)

As a matter of fact, it doesn't; I guess mw:Help:Magic words#URL data is lying (or describing a version of MediaWiki different from the one Wikipedia is running). Ucucha 23:50, 28 January 2011 (UTC)

Many thanks - just what I wanted. Yes, the WIKI and PATH options seem to have been dropped. As Our Ford would have said "you can have any separator you like as long as it is + But {{anchorencode}} is available to give NH_714_684 providing you don't need its other translations. — [[::User:RHaworth|RHaworth]] (talk · contribs) 05:36, 29 January 2011 (UTC)

Signature Length

Why can't the signature length box in "My preferences" be longer, so users can do more markups and such. CTJF83 02:45, 29 January 2011 (UTC)

Excessive signature length is usually seen as disruptive. More information on the signature guidelines regarding length are available at Wikipedia:SIG#Length. Nakon 02:52, 29 January 2011 (UTC)

How can I propose to make the available space sightly longer? I just wanna add and link "chat" on the end of my current one. CTJF83 03:14, 29 January 2011 (UTC)

You can probably condense your current signature by a bit with some CSS-foo. Nakon 03:21, 29 January 2011 (UTC)

If you can come up with something to help me out, I'd appreciate it. Please post to User_talk:Ctjf83#Sig. I'll look in 9 hours after work. CTJF83 03:26, 29 January 2011 (UTC)

I think you can omit quotemarks on word colors and every closing "</font>" when inside a span-tag (<span>), plus use color=gold (shorter than "yellow"), as: CTJF83, now with the shorter wikitext: [[User:Ctjf83|<font color=red>C<font color="#ff6600">T<font color=gold>J</font><font color=green>F<font color="#0000ff">8<font color="#6600cc">3]]. You might need one closing "/font" but not all of them. Each font color changes the prior color, "<font color=blue>" as: "This is blue text". HTML was NOT originally designed to demand a matching end-tag "</font>" for every font tag, but I don't know what the HTML fascists are planning.
The World Wide Web was designed by physicists, not by computer scientists, so it was peculiar that way: it allows "<center>" but not margin "<left>" or "<right>" which the center is between (so clueless). Now that computer experts are involved, it is still backward, and they should allow word "hue" (to avoid spelling bias against "colour"), plus denote non-nested tags perhaps as "<#" to use "<#font hue=red>" where the pound-sign "#" would indicate to omit the closing "/font" tag. Anyway, it seems like we need a WP essay about shortening signature text. -Wikid77 09:41, 29 January 2011 (UTC)

Except that markup isn't closing the font tags properly, leaving the text in blue or green until they are closed. The colors in this signature fail per Web Content Accessibility Guidelines. ---— Gadget850 (Ed) ^talk 10:22, 29 January 2011 (UTC)

• All of Wikipedia seems to fail the Web Content Accessibility Guidelines, based on the brightness formula: ((Red value * 299) + (Green value * 587) + (Blue value * 114)) / 1000. The brightness of tan is: 191.352 compared to the brightness of red: 76, a difference of 115, not the required 125, so redlinks would likely be considered invalid brightness in note boxes. The focus needs to be on "almost passing" the guideline, as an acceptable approach. -Wikid77 12:34, 29 January 2011 (UTC)

We aren't discussing "all of Wikipedia", just this signature. If there are problems in other areas, then those need to be discussed and fixed as needed. ---— Gadget850 (Ed) ^talk 17:20, 29 January 2011 (UTC)

<font>...</font> is a deprecated element, use <span>...</span> instead, or <b>...</b> if you want to save some characters. You do need the tags to be properly nested, as Graham says, you're causing no end of problems for users of screendreaders etc otherwise. Wikid, the HTML 3.2 specification, which introduced the <font> tag, clearly indicates that it "Requires start and end tags"; I don't know where you got your HTML-history from, but it's not accurate. The most recent version of HTML, HTML5, has moved to reduce the number of tags which need to be matched, loosening the restriction for various block elements like <p>, but that logic cannot be applied to inline elements.

The signature string is stored in a 255-byte database field, and increasing the size would require a database schema change, which I very much doubt will happen even if you ask for it. Happy‑melon 11:11, 29 January 2011 (UTC)

I agree that HTML5 still has major design problems, but most browsers seem to keep working anyway. Hopefully, those screenreaders will be fixed to match the real world, and accept changing a font without using the end-tag "</font>" as has been done for years. If the font is blue, and black is needed, just put "<font color=black>" and keep going. I realize the omission of end-tags thwarts the use of nested font styles, but it needs to be expected, and so span tags limit the font scope. The word "e-mail" has been misspelled as "email" in over 90% of webpages, so years ago, Google started matching either spelling as being the same word. It would make sense for all dictionaries to formally define "email" as a valid alternate spelling. If most people set their screenreaders to announce font colors, then perhaps let users know that multi-color signatures will be cumbersome to hear. When a committee designs an unworkable language feature, it typically has a real-world patch to become usable, so expect font settings to continue in that manner. -Wikid77 12:34, 29 January 2011 (UTC)

Can I ask whether you've tried reading this page with the greenscreen gadget enabled? If not, please do so: go to your preferences and check the box labeled ""Use a black background with green text on the Monobook skin"". Then come back and read your comment above, and perhaps you'll understand what we mean by lack of accessibility. Black text is not part of the MediaWiki style, it is a browser default. Adding <font> is not resetting to the browser default, it is imposing black text, whether or not that's what users want, and regardless of whether that's even accessible to users. Happy‑melon 13:14, 29 January 2011 (UTC)

And we aren't here to fix HTML or correct popular spelling, but to write an encyclopedia. Let's fix what we can. ---— Gadget850 (Ed) ^talk 17:20, 29 January 2011 (UTC)

So....how do I get the colors, gray background, and a link to my talk page with the word "chat"? CTJF83 12:51, 29 January 2011 (UTC)

I would try to shorten your signature instead of expanding it. It already is four lines of text which is quite excessive. Garion96 (talk) 17:24, 29 January 2011 (UTC)

This is an encyclopedia. I'm sorry, but if you can't get a short enough signature yourself, you're probably obsessing over it too much. Let's keep building an encyclopedia! (says the user who spent a good hour trying to design his own sig. :P) /ƒETCHCOMMS/ 05:37, 1 February 2011 (UTC)

Impending watchlist bankruptcy

I'm headed for watchlist bankruptcy again. Rather than dumping everything, I'd really like to have some sort of filter, e.g., that dumps heavily-watched pages, but keeps things that are on few watchlists. Alternatively, I'd be happy dumping anything that I haven't edited either the article or the talk page for, say, 90 days (especially user pages). Is there anything out there along these lines? WhatamIdoing (talk) 05:07, 29 January 2011 (UTC)

Drop me an email with the list, I can run it through several filters. ΔT _{^{The only constant}} 05:09, 29 January 2011 (UTC)

There also is a way to easily check in your watchlist if articles are redirects. That always gets rid of a couple of hundred articles for me. Garion96 (talk) 17:33, 29 January 2011 (UTC)

How many are 'bankruptcy'? I'm heading towards 7,000. Dougweller (talk) 16:27, 31 January 2011 (UTC)

Watchlist bankruptcy isn't usually invoked because of a technical restriction, but when someone finds they are having trouble managing their watchlist (see Wikipedia:Don't overload your watchlist!). I believe there are some technical issues when you exceed a certain number - "9800" is mentioned on the previous link and Wikipedia:WATCHLIST#Size limitation - but I was well beyond that number (I think close to 17000) when I declared watchlist bankruptcy last October, so that figure is probably a bit dated. –xeno^talk 16:38, 31 January 2011 (UTC)

Ive had over 50k before. ΔT _{^{The only constant}} 16:41, 31 January 2011 (UTC)

Thanks. I figure that so long as I can see 12 hours worth of changes I'm ok. Dougweller (talk) 16:42, 31 January 2011 (UTC)

I gave up trying to manage my watchlist when it got past 2,000. It's one of the few major MediaWiki features I never use. The issue is that there are always some gadget(s) or program(s) that I don't realize has an auto-add-to-watchlist setting and I run a couple thousand pages in it. /ƒETCHCOMMS/ 05:39, 1 February 2011 (UTC)

Gadget: Black Background

I was curious as to whether a gadget similar to the "Use a black background with green text on the Monobook skin" could be created for the vector skin. With the monobook gadget enabled and using the vector skin, it seems mostly alright other than the main header, which if I recall can be changed through CSS settings. Sorry if this was posted in the wrong section, and thanks for your time - NeilHynes - ^Talk_Edits 06:34, 29 January 2011 (UTC)

Oh yes, forgot to add this as well: The boxes which constitute the front page seem to be hard coded as being white rather than transparent, making it pretty hard on the eyes while this gadget is enabled. Is there any way to fix this as well? NeilHynes - ^Talk_Edits 06:51, 29 January 2011 (UTC)

• It might be a good idea to adjust the brightness of whichever screen you are using, on a day/night basis, to reduce eyestrain. Perhaps lower the brightness during dark hours. Also, avoid facing bright windows behind a computer, as focusing on computer screens might cause more intense viewing than normal reading of a printed book. There is a lot of medical research about eyestrain with computer screens. -Wikid77 10:15, 29 January 2011 (UTC)

Page protected from moving personal stub page to

I have recently created a personal stub page, currently located at User:Trident13/Boticca which I wish to move to the page titled Boticca, but am told by the system that I can not move it to that mainpage as the page Boticca is presently protected. How do I find out the reasons for the protection, and would be grateful for advice on next steps. Rgds, - Trident13 (talk) 22:45, 29 January 2011 (UTC)

The page is protected from being created, so I believe you can request that it be unprotected by going here, and giving your reason. Gary King (talk · scripts) 22:59, 29 January 2011 (UTC)

Noticed that, thanks for the confirmation Gary! Rgds, --Trident13 (talk) 23:02, 29 January 2011 (UTC)

en dashes and searching text

The MOS (in MOS:ENDASH) suggests en dashes rather than hyphens in certain constructions, including in article titles. The only real problem with that is that it makes it very difficult to search for the term within the article text. Is there any way for en dashes to be counted as hyphens when searching, just as case distinctions are ignored, or is that entirely browser dependent? — kwami (talk) 01:48, 30 January 2011 (UTC)

It's browser dependent. You'll probably need a browser that supports regular expression searches in order for it to do what you want, or you could just do each search manually. Gary King (talk · scripts) 02:15, 30 January 2011 (UTC)

I was thinking of general accessibility to our readers. This would be an argument against implementing the MOS. — kwami (talk) 12:18, 1 February 2011 (UTC)

Question about a possible change to Twinkle

I delete a fair number articles proposed for speedy deletion. I almost always check to see that the original editor of the article is notified (I don't always check attacks, vandalism or redirects.) In most cases the editor has been notified, probably because many taggers use Twinkle and that generally does a notification automatically. However, some new editors getting into CSD work don't yet know about Twinkle, and occasionally Twinkle is claimed to miss one.

How hard would it be to make a minor modification to Twinkle, so that when it adds the CSD template to the article, then adds a notification to the original editor, it could also add a note to the CSD template indicating that "user:foo received a notification". Then I could skip checking the 90% or so that do notify, concentrate on determining whether the CSD is warranted, and only track down notification issues in those cases where it hasn't happened?

(I know this ultimately belongs at Proposals, but I wanted to see if there were technical hurdles I've missed, or if I should be talking to AzaToth or someone else.)--SPhilbrickT 02:31, 30 January 2011 (UTC)

Best place to post would be Wikipedia_talk:TW#Feature_Requests CTJF83 02:33, 30 January 2011 (UTC)

Thanks, will post there.--SPhilbrickT 15:15, 30 January 2011 (UTC)

{{Ffdc}}

I know {{Deletable image-caption}} has already been converted to use dated category system to enable tracking and cleaning up of stale tags. I took a whack at trying to use the same dated system with this template, however the way the parser function #time operates it does not accept the current format that is passed by the log parameter. I would appreciate a way to resolve this issue, as I often find really stale tags that need removed, and these dated categories make it soo much easier to sort though the mess. ΔT _{^{The only constant}} 03:32, 30 January 2011 (UTC)

Unable to open article tabs in new browser tab

I can open any in-text link in a new browser tab (IE8), but when right clicking on an article tab such as "Discussion" or "Edit" I do not get this option, but rather the option set associated with right clicking on background or regular text. I can not be sure, as I use other Wikis, and may be confused, but I think this is new, and that I used to be able to open these in a new tab. Peter (Southwood) ^(talk): 08:16, 30 January 2011 (UTC)

It's a known IE8 bug. Right-click right next to the text to get the proper menu, or "middle"-click (press the wheelbutton) the link to open it in a new tab immediately. — Edokter (talk) — 10:16, 30 January 2011 (UTC)

Performance synergism gives amazing performance

Nearing the end of January, and the performance issues are really reaping major synergistic benefits. As you might know, that old, archaic essay "WP:Don't worry about performance" had become a negative mantra, casting a cloudy chill on improving performance issues. As part of the "Performance Resistance Movement", I have done the exact opposite now: to focus on performance in my spare minutes around Wikipedia. While re-writing some string-handling templates to avoid the 40-level expansion nest limit, I have again discovered:

• Performance synergy: Improving just a few aspects, of total performance, will create a synergy which produces other major improvements. I wrote {{strlen_quick}} to focus on using only 5 expansion levels (rather than 9-to-14 deep); however, in the process, I discovered ways to make it 2x times (TWICE) the speed of the "fully optimized" {str_len}, as it runs 12x times shorter. An article now can use 37,000(!) instances of {strlen_quick}. An effort to make {Italic_title} 4x times faster (such as with "(film)" suffix) has synergized as 100x(!) faster. The synergism works that way: start trimming a few if-else branches and end with a template 12x shorter, or 100x faster, than before.
• POV-pushing is overcome by multiple POVs: The cure for POV-pushing seems to be to allow multiple WP:POV forks (not delete them). Example: all algorithms for getting string-length counts had been deleted down to one POV, which used binary search of strings. I resurrected the other deleted variations, and thereby found techniques to transcend the one remaining POV method, with a hybrid POV method, running 2x times faster and 12x shorter. This concept was formalized in the Strategy Wiki, to have an Arab-POV version of article "Palestine" to overcome systemic bias in the so-called NPOV article. Meanwhile, that concept has led to massive improvements of string templates. The whole idea of POV-forks can be seen in the crucial Recovery of Aristotle from the Arab world, which had kept accurate texts of Aristotle, beyond those censored by the Church. As Pliny said, "There is always something new out of Africa."

Performance synergism will "bootstrap" to higher synergism: by improving the performance of string templates, they can be used in lists of string data containing 5,000 examples on 1 page, to analyze ways to further improve those string templates and others. I have discovered simple ways to streamline {Cite_web} and {Cite_book} to allow over 1,000 references within a separate list page, replete with the COinS metadata. We could even have a "references-population" template, which supplies current sources to multiple articles, all sharing from the same large, central {Cite_web} list, because improving performance had made keeping a large central template of current sources possible. The task began as a focus on improving template performance, and then led to the epiphany that POV forks are the solution (not the problem), while leading to a way to maintain current WP:RS sources within numerous articles at one time. Amazing performance synergism. -Wikid77 (talk) 12:58, 30 January 2011 (UTC)

Let me be the first to say that I don't really understand the connection between the Israel-Palestine conflict, and string processing templates... :D But let me also be the first to congratulate you on these performance enhancements.

You might want to read the recent wikitech-l thread on WP:PERF; I think it you'll find it interesting. Happy‑melon 13:42, 30 January 2011 (UTC)

I guess the credit should go to 2006-2007 User:Polonium and others, for the alternate string-length algorithms. I had learned in college that performance can often be improved perhaps 5x faster (re: Donald Knuth), but the template speed increases of 12x, 100x or 1,000x faster are still a shock to me. Also, using many large parameters in a template consumes the "post-expand include size", so reducing a numeric formula parameter by using {#expr: <formula>} can shrink the post-expand or argument sizes as perhaps 5x smaller. I was stunned when {strlen_quick} reduced the post-expand by 12x, increasing capacity from 2,900 instances to allow 37,000 uses of {strlen_quick} per page! The other string algorithms had been deleted, or rather redirected, so there was only one POV for how to check string lengths. I guess the Strategy-Wiki issue for an Arab-POV fork of article "Palestine" would reveal insights not found in the main article, just as the faster string algorithms were gone from the main {str_len} template. A classic case of "POV funnel" is the Amanda Knox case, where many Europeans did not understand how she is in major TV news in America, every few months, as "will she get a fair re-trial and be set free" rather than wondering what motive for killing her flatmate of 6 weeks. The MoMK article was reduced to omit Knox's "POV-boring" background as a guitar-playing, honors student who called her roommate about their Halloween costumes the day before the murder. See, the POV-boring details are what made the case notable in the U.S. as why would a "straight-A" student, who sings with guitar, work 7 jobs in Seattle to pay her way as an exchange student in Italy, then want to kill her British roommate of 6 weeks (whose rent money vanished) but leave no hair, fingerprint or DNA evidence, unless she was hit by police to give a false confession as she testified? Understandably, some European users always removed those boring details as insignificant, as WP:UNDUE POV-boring text compared to other details. Only when an article can focus on the POV-boring concepts of a "huggy bookworm" whose new friend died, can readers understand why millionaire Donald Trump advised boycotting Italy until Knox is freed. Perhaps that focus is similar to a Arab-POV article about Palestine, where seemingly POV-boring or only-an-Arab-would-care details are being omitted, but I'm not sure there. For checking string-length, the better solution was in the deleted (or redirected) WP:POV fork templates which had faster, shorter algorithms. Having multiple pages about an issue can lead to a better understanding of the all-encompassing (encyclopedic) viewpoints. That's the multi-template connection to multi-POV Israel-Palestine articles. -Wikid77 23:49, 30 January 2011 (UTC)

Please stop saying synergy. It makes me retch. OrangeDog (τ • ε) 17:46, 30 January 2011 (UTC)

Perhaps I should say that performance improvements are a "win-win game" (!) where the "pie gets bigger" rather than users fighting over the pieces of the pie?!?! -Wikid77 23:49, 30 January 2011 (UTC)

Oh please, enough! I have to listen to that kind of b/s speak all day long! We need to realign our white space initiatives on a going forward basis. – ukexpat (talk) 16:36, 31 January 2011 (UTC)

SVG upload problem

I'm trying to copy de:Datei:AutoBild.svg to WP-EN for use at Auto Bild, but all I get is:

Internal Error

key 'pvtmmk3paxdmo1izgpl340zprg0bp73.' is not in a proper format

Backtrace:

#0 /usr/local/apache/common-local/wmf-deployment/includes/upload/UploadBase.php(557): UploadStash->stashFile('/tmp/phpOmEzJy', Array, NULL)
#1 /usr/local/apache/common-local/wmf-deployment/includes/upload/UploadBase.php(569): UploadBase->stashSessionFile(NULL)
#2 /usr/local/apache/common-local/wmf-deployment/includes/specials/SpecialUpload.php(322): UploadBase->stashSession()
#3 /usr/local/apache/common-local/wmf-deployment/includes/specials/SpecialUpload.php(413): SpecialUpload->showUploadWarning(Array)
#4 /usr/local/apache/common-local/wmf-deployment/includes/specials/SpecialUpload.php(167): SpecialUpload->processUpload()
#5 /usr/local/apache/common-local/wmf-deployment/includes/SpecialPage.php(561): SpecialUpload->execute(NULL)
#6 /usr/local/apache/common-local/wmf-deployment/includes/Wiki.php(254): SpecialPage::executePath(Object(Title))
#7 /usr/local/apache/common-local/wmf-deployment/includes/Wiki.php(64): MediaWiki->handleSpecialCases(Object(Title), Object(OutputPage), Object(WebRequest))
#8 /usr/local/apache/common-local/wmf-deployment/index.php(117): MediaWiki->performRequestForTitle(Object(Title), NULL, Object(OutputPage), Object(User), Object(WebRequest))
#9 /usr/local/apache/common-local/live-1.5/index.php(3): require('/usr/local/apac...')
#10 {main}

I've tried changing the destination file name, but to no avail. --Morn (talk) 11:23, 30 January 2011 (UTC)

The file is on Commons, so already available for use here - File:AutoBild.svg - no need to reupload. Not sure what's causing you the error though.--Nilfanion (talk) 11:53, 30 January 2011 (UTC)

Oops, you're right, it's already on Commons. I've seen this error previously and as far as I recall you could make it go away by changing the file name (removing spaces or something). Somehow that did not seem to do the trick here, though. --Morn (talk) 12:41, 30 January 2011 (UTC)

Having trouble editing/unintended vandalism

OK, so I was working on the 2010-11 Australian region cyclone season, and just adding the dissipation date for 06U (revision on 00:22 4 January), and although I had gotten the changes I wanted, I somehow exposed some formatting in the line of the table for TC Tasha. This was due to an infinite loop. What I did (if I remember correctly) was that I was submitting it, and it got stuck in the infinite loop. So, I either closed the computer (it was a laptop) or hit the Back button on the browser (I don't remember which), and then the formatting came out all screwy. I am using Safari version 5.0.3 on a Mac OSX Version 10.6.6 with a 2.4 GHz Intel Core 2 Duo processor. (The loop occurs even when I am editing small sections of a larger page, though the loop does not always happen, even when I am editing larger pages.)

(In fact, as I am typing this, the page for the 2010-11 South Pacific cyclone season is stuck in an infinite loop, while I am trying to edit that page.) — Preceding unsigned comment added by VeryPunny (talk • contribs) 19:12, 30 January 2011 (UTC)

What kind of infinite loop are you experiencing? Can you copy and paste any error messages that you see? Gary King (talk · scripts) 22:56, 30 January 2011 (UTC)

No, there are no error messages, the screen is just frozen, but otherwise works normally. Interestingly, this does not happen when I am simply browsing around without editing. — Preceding unsigned comment added by VeryPunny (talk • contribs) 17:12, 31 January 2011 (UTC)

Transparent table background.

For a long time, the plain table background was white, but this has changed to transparent in the upcoming 1.17 release of MediaWiki. Since there may be templates that rely on a white background, I'm putting the following code in Common.css, in order to spot any glitches that may pop up before 1.17 is deployed. — Edokter (talk) — 21:08, 30 January 2011 (UTC)

/* Transparent table background. Remove when 1.17 is deployed */
table {
    background-color: transparent;
}

• So, now, a table will default to transparent background, but a quotebox or preformat-box will remain white, as shown below:

This indented table now defaults to transparent, but class=wikitable will remain white. This is a quotebox, indented by leading spaces. However, the quotebox (above) & preformat-box (below) remain white. This text is within the tags <pre></pre>. Tables are often used for multiple columns in see-also sections.

So, people should change any unclassed tables which need to be white, by setting style="background:white". -Wikid77 10:06, 31 January 2011 (UTC)

Basically yes, but since all pages already have a white background (in Vector), it would not be absolutely necessary. (PS. Wikitables and pre-formatted boxes have a gray background.) — Edokter (talk) — 19:29, 31 January 2011 (UTC)

William H. Ryan, Jr.

The William H. Ryan, Jr. Table of Contents has a line " * 4.1 Non-state Territories of the United States" appearing under References. The Commonwealth of Pennsylvania is one of the original thirteen states. Some technical person should investigate. Please tell me if I should be reporting this situation elsewhere, rather than here. --DThomsen8 (talk) 15:49, 31 January 2011 (UTC)

It's a badly-written navbox {{U.S. state attorneys general}} --Redrose64 (talk) 15:52, 31 January 2011 (UTC)

 Done - I've fixed it now. --NSH001 (talk) 16:34, 31 January 2011 (UTC)

Thank you. That was a really quick fix. --DThomsen8 (talk) 16:45, 31 January 2011 (UTC)

Thumbnail software

Which thumbnail software does Wikipedia use? According to Mediawiki, it should be either ImageMagick or GD. But I'm not sure which, and how it's implemented (on commons, for an image, there's no thumb.php?size=xyz etc.). I'm thinking of fixing the bugs with Animated GIF thumbnailing. Thanks, ManishEarth^{Talk • Stalk} 16:19, 31 January 2011 (UTC)

Wikipedia is probably using the recommended ImageMagick, since the ImageMap extension requires it, apparently, and it's installed here. Gary King (talk · scripts) 18:45, 31 January 2011 (UTC)

Yes, it's ImageMagick. The parameters for calling it will be in svn somewhere - you could check related bugzilla issues which may lead you there. OrangeDog (τ • ε) 18:55, 31 January 2011 (UTC)

Thanks! ManishEarth^{Talk • Stalk} 01:43, 1 February 2011 (UTC)

Keep getting logged out

Hi, I'm using Internet Explorer 8; I always check the stay logged in checkbox, but in the last few weeks Wikipedia won't remember my login for more than 20 minutes. I've tried clearing my cookies as suggested but that didn't fix the problem. Any ideas? Thanks. Some guy (talk) 20:28, 31 January 2011 (UTC)

You can try Firefox, Opera, or Chrome. Otherwise see if Update for Internet Explorer for Windows Vista (KB2467659) is what is causing your problem. – Allen4names 21:03, 31 January 2011 (UTC)

Is there a bot that can add WikiProject templates based on categories or stubs?

I wonder if there is a bot that could check which articles in a given category (ex. Polish singers) or using given templates (ex. Poland-bio-stub) are not categorized with a corresponding WikiProject assessment template (ex. WikiProject Poland template), and then add the wikiprojects template to those talk pages (preferably, assessing it as stub if the articles have a stub template)? That seems like something a bot should be able to do with a good success rate. --_{Piotr Konieczny aka Prokonsul Piotrus| talk} 20:52, 31 January 2011 (UTC)

Sure, see Category:WikiProject tagging bots. –xeno^talk 20:56, 31 January 2011 (UTC)

Footnote formatting Flag will not go away when I changed an "ibid" to a footnote

Cleared up and "ibid" footnote issue on this page: http://en.wikipedia.org/wiki/Jacquie_Jordan

But the message following wikipedia flag/box has not gone away: "Constructs such as ibid. and loc. cit. are discouraged by Wikipedia's style guide for footnotes, as they are easily broken. Please improve this article by replacing them with named references (quick guide), or an abbreviated title."

I was wondering what I am missing RE formatting, etc...

Mark Parsons — Preceding unsigned comment added by Parsonseditor (talk • contribs) 21:13, 31 January 2011 (UTC)

The message is a note added by a user, not an automatically generated tag - it won't go away until explicitly removed. I've done so, now. In future, please do feel free to remove the notices when the issue's been resolved! Shimgray | talk | 21:24, 31 January 2011 (UTC)

This is bizarre

In Double (basketball), Quadruple-double section, NBA subsection, in the notes, it reads:

"Olajuwon was originally credited a quadruple-double as shown by the box score; however, the NBA stripped Olajuwon of one assist assist after reviewing the game tape.[52]"

However, when I went to remove one "assist", there was only one there. Is this my computer? ~EDDY ^{(talk/contribs)}~ 01:20, 1 February 2011 (UTC)

It shows only one for me in the rendered text. Have you tried clearing your browser cache? Ucucha 01:23, 1 February 2011 (UTC)

I see only one "assist", too. I can't think of any reason why that word would appear twice for you; it shouldn't be a cache problem, either, since "assist assist" hasn't appeared in the article before, at least not in the past few dozen edits. Gary King (talk · scripts) 03:03, 1 February 2011 (UTC)

Left floated image overlaps table of contents

TOC and image overlaps

While reading the Jingshan Park article I noticed that the TOC and image overlapped. I'm using Safari on Mac OS X and the bug only appears if the browser has a particular width, although at other withs the image border can overlap the text.--Salix (talk): 12:21, 1 February 2011 (UTC)

Too many floating element wil cause problems sometimes. I've moved the image to the right. — Edokter (talk) — 12:45, 1 February 2011 (UTC)

Special:NewPages in reverse order

Currently, Special:NewPages lists new pages in chronological order from newest to oldest. Users have to make an effort to patrol at the back of the backlog. I have two questions.

1. Is it possible to make Special:NewPages list pages in reverse chronological order from oldest to newest?
2. Have we ever considered going in reverse order before?

Thanks. - Hydroxonium (H₃O⁺) 15:19, 1 February 2011 (UTC)

What effort? There's a backlog link . Anyways, for a history page or NewPages, just add ?dir=prev (or &dir=prev if there already is a question mark in the URL) to the URL. ManishEarth^{Talk • Stalk} 16:07, 1 February 2011 (UTC)

Or click on the "earliest" link to go to the earliest pages. Gary King (talk · scripts) 17:17, 1 February 2011 (UTC)

Oops. I should have clarified that. There are over 1,000 users patrolling the front of the list and only a handful patrolling the back of the list. So several hundred articles fall off the end and aren't reviewed each month. If the list is reversed, then maybe more people would patrol at the end instead of the front. - Hydroxonium (H₃O⁺) 17:36, 1 February 2011 (UTC)

I doubt they'd be willing to change it. It's newest-to-oldest probably because every single page listing edits on Wikipedia are newest-to-oldest (Recent Changes, history pages, even nomination pages like WP:FAC, WP:RFA, etc.). And people are used to newest-to-oldest already. Gary King (talk · scripts) 17:38, 1 February 2011 (UTC)

Problem with contributions not moving after username change

Last year, Feb 22 2010, I RTV'd per CHU [2]. However, not all of my contributions moved over [3], even though my old userpage claims the username is not registered [4] and there is no "user contributions" link in the toolbox section. Can the remaining 3 or 400 contributions be moved over to the other username (see [5] for new user name on 2/22/2010). If not, can they be moved to a similar named username. Rgrds. --64.85.215.37 (talk) 19:29, 1 February 2011 (UTC)

Can't rename a user that doesn't exist. I'll post a note at bugzilla:17313 to see if we can get a dev to intervene. –xeno^talk 19:35, 1 February 2011 (UTC)