Jump to content

Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by The Banner (talk | contribs) at 17:24, 16 August 2011 (→Bug?). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts
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.


Linking from "Search" to "Help:Search"

Someone has asked why Special:Search does not have a link to Help:Searching. I guess this is the best noticeboard to make it happen. -- John of Reading (talk) 09:44, 1 August 2011 (UTC)[reply]

Another point is that clicking on "Advanced" on the search page brings up only a set of check boxes for namespaces; it doesn't provide access to all of the available functions (intitle searching and so on). This is misleading, as I suspect readers would assume that "Advanced" is as advanced as it gets (i.e. they'll conclude that no other functionality is available, and won't bother clicking on the help link to discover the extra stuff, even if there is such a link).--Kotniski (talk) 09:53, 1 August 2011 (UTC)[reply]
Those options are nice! I had no idea they existed, must have been asleep when they were introduced. One easy measure would be to change MediaWiki:Searchmenu-new and MediaWiki:Searchmenu-exists: instead of "For search help, please visit Help:Searching" we could have "For search help and an explanation of advanced options, please visit Help:Searching." But I agree that the "advanced" tab should be renamed "free namespace selection" or provide non-namespace based advanced options. —Kusma (t·c) 10:11, 1 August 2011 (UTC)[reply]
This is bug 21988. MER-C 10:39, 1 August 2011 (UTC)[reply]
The currently blank MediaWiki:Search-summary is displayed at the top of Special:Search. I agree that the former version [1] was bloated, but I suggest simply saying Help:Searching, similar to the German Wikipedia: de:MediaWiki:Search-summary (they use a piped link). PrimeHunter (talk) 13:32, 1 August 2011 (UTC)[reply]
That would be an improvement, certainly, but I don't think the previous version was much too bloated - precisely because of the fact that the extra functions are not available under "Advanced" or any other link where they would be expected to be (and since that's a bugzilla matter, we can't expect it to change any time soon), we ought to say explicitly that there are advanced options available, otherwise no-one will know to look for them.--Kotniski (talk) 13:55, 1 August 2011 (UTC)[reply]
How about "For search options, see Help:Searching." as the text of MediaWiki:Search-summary? —Kusma (t·c) 08:47, 2 August 2011 (UTC)[reply]
That would work for me. (Then if that appears on the search results page as well, we can remove the link to Help:Searching from the other MediaWiki pages that we added it to, to avoid duplication.)--Kotniski (talk) 09:28, 2 August 2011 (UTC)[reply]
Done and removed duplicates. —Kusma (t·c) 10:26, 2 August 2011 (UTC)[reply]

It seems to make more people look at the help page: [2]. —Kusma (t·c) 06:04, 5 August 2011 (UTC)[reply]

...and leave useless feedback at Help:Searching/feedback (edit | talk | history | links | watch | logs). -- John of Reading (talk) 15:09, 10 August 2011 (UTC)[reply]
Gawd that page was awful. I skimmed each one and found nothing worth saving so I removed them all. I'm sure it'll just keep happening though. Killiondude (talk) 17:38, 10 August 2011 (UTC)[reply]

Template:CTableEnd

On this old version of WikiProject Disambiguation#Participants, I've noticed a bug with Template:CTableEnd. The template seems to hide the section header ==External watchlist== from view. When I put {{clear}} after CTableEnd, then the section head did display, see: the current page. Could someone figure out why Template:CTableEnd is causing the section header to be hidden on the immediately following section? Thanks much, --Funandtrvl (talk) 18:41, 7 August 2011 (UTC)[reply]

It looks like the combination of width=100% and align=left in the collapsible table causes the table to eat the succeeding h2, at least in Firefox and Chrome. Possibly the {{clear}} should be added to {{CTableEnd}}, but it may not be appropriate in all uses of the template. Ucucha (talk) 18:55, 7 August 2011 (UTC)[reply]
Yes, it's happening in IE9 also. I don't know enough about the coding to say if adding "clear" would be the right solution. Maybe it needs a div or break at the end? --Funandtrvl (talk) 19:00, 7 August 2011 (UTC)[reply]
Its due to the "align:left;" it makes the table float left, but it is also fullwidth, causing the header to be "hidden" to the right of the table. Removing the "align=left" from CTableStart fixes the problem. —TheDJ (talk • contribs) 18:23, 8 August 2011 (UTC)[reply]
Thank you for everyone's help, I removed "left" from table-align, and I think that worked. --Funandtrvl (talk) 21:47, 9 August 2011 (UTC)[reply]

For past few days I've been having trouble with the Navigation popups working on things like in my watchlist. Hovering over dif or hovering over history than last and it not working. I already did the bypass of my cashe, what now? This kind of thing has happened in the past and it was a new upgrade that made things not work. Thanks, --CrohnieGalTalk 11:04, 8 August 2011 (UTC)[reply]

Is anyone checking into this problem? I know I'm not alone with this situation. Also there was problems with popups awhile ago that ended up being because of some software update or something. I am ignorant when it comes to this stuff but I really would appreciate some help here. As it is I'm not doing too much because I have to click on everything I want to look at in my watchlist. It's only a problem when I hit diffs or last (in the watchlist is history, then there is last, it doesn't work with popups), everything else seems to work though which is strange to me. If someone is looking into this and if that's the case, please just drop a note here saying so. Thank you in advance for you time, --CrohnieGalTalk 00:03, 11 August 2011 (UTC)[reply]

Set an upper limit for the rendering resolution of uploaded images

Moved from WP:HD § Set an upper limit for the rendering resolution of uploaded images
 – Question seems to be more appropriate here. --Toshio Yamaguchi (talk) 12:42, 8 August 2011 (UTC)[reply]

Is it possible to set an upper bound for available sizes an .svg image is rendered as PNG? The concrete example in question is File:University of Chicago Modern Etched Seal 1.svg. While I think the resolution of 500px is fine to illustrate the intricate details in the image, having this image rendered at a resolution of 2000px is not needed in my opinion and is a violation of WP:NFC Policy 3 b. Is it possible to restrict the rendering choices for the file to a maximum of 500px and if so, how can I do this? Toshio Yamaguchi (talk) 12:42, 8 August 2011 (UTC)[reply]

It's not possible to 'code' a size limitation into an SVG, because it is just made up of shapes; hence, if the svg is available to display, anyone could download it and display/use it at any resolution they wanted. Consider e.g. "a red circle with a blue diagonal line across the middle, and a yellow circle half the size of the red one" - that's the type of information that the encoded content of an SVG describes. The question "how big is it" cannot be answered.
We could stop mediawiki from having the 'display at 2000px' option, but that isn't really solving anything. It's the way an SVG works; it doesn't have a 'size' - just shapes, which can be displayed at any res you wish.  Chzz  ►  13:31, 8 August 2011 (UTC)[reply]
Indeed, the "S" in SVG stands for "scalable". SVG images may be defined to have a "default" size, but this is not enforced. For example, the icons like found on many railway route diagrams are "defined" as 500px by 500px, but are never shown that big, typically they are 20px x 20px. This particular file contains code that essentially means "on a 500x500 grid, move to point 250,0 and draw a vertical red line 500 high and 100 thick; then draw a red disc centred at 250,250 of radius 150". The "sizing" within the SVG file itself is merely so that the shapes may be described in terms other than percentage. --Redrose64 (talk) 17:24, 8 August 2011 (UTC)[reply]
Limiting the rendering resolution would also have to restricted to non-free content, or to individual files. Several SVG maps (File:Arctic.svg, for example) benefit from the large rendering options. MKFI (talk) 11:02, 9 August 2011 (UTC)[reply]

WHOIS on toolserver not working?

I keep getting a 404 Page Not Found error when doing a WHOIS from the link on an IP contributions page, see [3]. Is it me or is it the toolserver, or is it this specific tool? Anyone know and/or can fix this? Thanks! --Jayron32 18:18, 8 August 2011 (UTC)[reply]

I have had problems with every toolserver tool I've tried to use today, (dab solver, DAB Challenge bonus list, most bonus list links, etc.)--JustAGal (talk) 19:09, 8 August 2011 (UTC)[reply]
There were reports about toolserver being down earlier today on the toolserver mailing list, but it seems to be okay now. User<Svick>.Talk(); 22:08, 8 August 2011 (UTC)[reply]
It appears there are some issues with the toolserver, but I'm not an expert. - Hydroxonium (T•C•V) 04:16, 9 August 2011 (UTC
The toolserver is making the tool work incorrectly. Me I need the toolserver WHOIS for Abuse response, but I can use others. ~~Ebe123~~ talkContribs 11:54, 9 August 2011 (UTC)[reply]

Reformatting articles for NUMBEROFPAGES

Someone mentioned that the WP "Main_Page" is reformatted for each new reader, due to using variable {{NUMBEROFPAGES}} to show the "current" count of English articles, as in:

  • Near top of Main_Page:   "6,923,428 articles in English"
(Main_Page uses "[[Special:Statistics|{{NUMBEROFARTICLES}}]]").

The Main_Page is viewed over 4.2 million times per day, so is it true that using {NUMBEROFPAGES} will cause the article page to be reformatted for each reader? I recently noticed how some article pages seem to be pre-formatted, with the specific reader's username overlayed at the top of the pre-formatted page. Also, it is somewhat goofy to say "3,705,387 articles" when pages are added, or deleted, each minute, like saying, "This hour has 3,591 seconds left" when merely reading the phrase takes a few seconds away from the 3,591 remaining seconds. So, if the Main_Page is really being reformatted for each reader, over 4.2 million times per day, then perhaps it should be changed to show:

  • Near top of Main_Page:   "Over 3.7 million articles in English"

Then continue to show that static text for 98 days, until the count goes "Over 3.8 million" (while "Over 3.7" would still be correct when having even more articles). Any thoughts? -Wikid77 (talk) 11:35, 9 August 2011 (UTC)[reply]

No! We should be exact. ~~Ebe123~~ talkContribs 11:56, 9 August 2011 (UTC)[reply]
How about "[[Special:Statistics|Lots of]] articles in English"? Far less overhead that way. — Bility (talk) 16:53, 9 August 2011 (UTC)[reply]
It is not nearly that bad. First of all, for most editors, almost any page is 'reparsed' anyways. Second, a change in the "number of articles" won't purge the page from the squid caches, so ' ip readers' will see the number of the 'last parse' of the page, until someone makes and edit to the actual content of the page that will actually purge the main page from the squid. —TheDJ (talk • contribs) 17:51, 9 August 2011 (UTC)[reply]
 Chzz  ►  18:03, 9 August 2011 (UTC)[reply]
WP:PERFORMANCE. Are you noticing a measurable slowdown in viewing the main page as a consequence of it having this code on it? No? Then Don't Panic™ Happy‑melon 11:55, 10 August 2011 (UTC)[reply]
Indeed. All Wikipedia pages are heavily cached (even for logged-in users), so this sort of thing won't cause any problems. Even if there was an increase in server load, the server admins would notice it before we would. — Carl (CBM · talk) 12:00, 10 August 2011 (UTC)[reply]

Normally, when I start editing I go to my watchlist and check any changes since I last logged in. When I see ones that I want to check, I right-click them and open them in a new tab. Recently, this has become extremely slow (that is, before the contextual menu appears). It seems to be connected with how many wikilinks there are on a page, I have the same problem when right-clicking on a long history or contributions page, or within very long articles with many wikilinks. Things are faster with short articles/histories/etc. Even on shorter lists, though, right-clicking is slower than on non-WP sites. Sometimes the wait is very long and I get a essage that a script is running, if I choose to interrupt the srcipt, the contextual menu appears immediately. I use Firefox 5.0 under Windows 7 Professional. The problem is not computer-specific, because I have it on different computers. Anybody have any idea what may cause this? --Crusio (talk) 13:25, 9 August 2011 (UTC)[reply]

Protip: Middle-click opens in a new tab. This will change your life. --Golbez (talk) 13:28, 9 August 2011 (UTC)[reply]
The record will show that the use of ten exclamation points and an "OMG" fits with my earlier prediction that it will change your life. ;) --Golbez (talk) 14:21, 9 August 2011 (UTC)[reply]
For those whose mouse has just two buttons but also has a wheel between those, pressing the wheel in can behave like a middle button. It does for me anyway. Windows XP. --Redrose64 (talk) 14:15, 9 August 2011 (UTC)[reply]
Category:Wikipedians whose life has been changed by User:Golbez. -- John of Reading (talk) 14:29, 9 August 2011 (UTC)[reply]
👍 Like Killiondude (talk) 17:39, 10 August 2011 (UTC)[reply]
heh, or click shift (at windows) for open the link in a new tab. for a background tab press ctrl (on mac command). mabdul 17:20, 9 August 2011 (UTC)[reply]

Diff triggers download

I have been running into this problem for quite some time. Every time I want to compare two revisions in a history page, I see a prompt saying index.php is to be downloaded. Whether I use IE 9, Firefox 5, Safari 5 on native Windows 7 or Firefox 5 on a VirtualBox'ed Ubuntu 11.4 the symptom is the same. The issue seems to be unique to the English Wikipedia. I have tried diff'ing on the Chinese, Japanese and Spanish Wikipedias, and the diff pages show up as expected. Any help? Kxx (talk | contribs) 16:40, 9 August 2011 (UTC)[reply]

Do you have "Use external diff by default" checked in the Editing tab of your preferences? — Bility (talk) 16:49, 9 August 2011 (UTC)[reply]
I've had this issue before. I believe it happened to me when my connection was not functioning properly. Does it act like it's going to take a long time to load the page then it just opens a download dialogue box? IIRC, that's how it did it to me. Killiondude (talk) 16:57, 9 August 2011 (UTC)[reply]
This also happens fairly frequently to me in the way Killiondude describes; it's when there's a slowness on either my or Wikipedia's side. Ucucha (talk) 18:17, 9 August 2011 (UTC)[reply]
Same here. Usually it happens when the server kittens are on strike. Titoxd(?!? - cool stuff) 20:15, 9 August 2011 (UTC)[reply]
Didn't know I got that checked. Maybe due to a random click. Problem solved. Thanks a lot. Kxx (talk | contribs) 23:28, 9 August 2011 (UTC)[reply]

New messages alert via background colour

Is it possible to change some aspect of the skin when one has "new messages" - e.g. changing the page background from white to grey, or someth?  Chzz  ►  18:12, 9 August 2011 (UTC)[reply]

Should be easy to do with some JavaScript. Ucucha (talk) 18:14, 9 August 2011 (UTC)[reply]

The following code does it for me: 

$( function($) {
    if($("#mw-youhavenewmessages").length > 0) {
        $("#content").css("background-color", "gray");
    }
}
);

The gray color is not easy to miss, but you can change "gray" to some other color if you like it better. Ucucha (talk) 21:42, 9 August 2011 (UTC)[reply]

Actually, scrap that; it also makes the background gray when there is no new message. I'll try to find out why. Ucucha (talk) 21:43, 9 August 2011 (UTC)[reply]
Fixed. Put the above code in Special:Mypage/common.js to get the gray background. Ucucha (talk) 21:49, 9 August 2011 (UTC)[reply]
That is nifty - but any idea why it wouldn't work in Opera? (works fine in Chrome.) Avicennasis @ 03:32, 10 Av 5771 / 10 August 2011 (UTC)
I suppose Opera treats some kind of JavaScript and/or CSS differently (it also worked for me in Firefox). Are you seeing any JavaScript errors (wouldn't know where to look for those in Opera, though)? Ucucha (talk) 03:41, 10 August 2011 (UTC)[reply]
It works fine in Opera, I just tried it. The problem is with the importScriptURI("http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js"); line in User:The Earwig/afc-helper.js, which seems to be stopping the background colour from changing some how. If someone wants to try and pick apart http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js to figure out exactly what is going on then be my guest ;) - Kingpin13 (talk) 11:12, 10 August 2011 (UTC)[reply]
Afc helper should remove that import of google's jquery. MediaWiki has it's own jquery enabled at all times for a couple of months now already. Including multiple copies is bound to be problematic. 62.140.137.85 (talk) 18:25, 10 August 2011 (UTC)[reply]
Thanks very much, I'll give it a try!  Chzz  ►  09:07, 10 August 2011 (UTC)[reply]
Hmm; something odd, here. If/when I go to some user talks, the background colour changes - even though I don't have new messages. Possibly, it is when a user talk has a {{tb}}, and it 'sees' the "You have new messages" from that?  Chzz  ►  08:54, 15 August 2011 (UTC)[reply]
That template shouldn't affect it. Got an example page? It could be if someone is using a yellow "leave me a message" bar which uses the same class stylinh as the usermessage bar. --Errant (chat!) 10:12, 15 August 2011 (UTC)[reply]
Yes, or more precisely, an element that has class="usermessage". I changed the above to check for a different element of the new message bar that is hopefully less prone to false positives. Ucucha (talk) 11:04, 15 August 2011 (UTC)[reply]
Definitely better. Thanks again,  Chzz  ►  01:52, 16 August 2011 (UTC)[reply]

Citation Templates while editing

At some point, possibly about a week ago, the tool to insert citation templates from the editing window seems to have disappeared. The tool was really convenient, and its absence is annoying. (If it matters, I'm using IE8) Chris857 (talk) 00:21, 10 August 2011 (UTC) st 2011 (UTC)[reply]

Citations via the edit toolbar work fine for me, and so I think it's a problem local to your machine or your account. For starters, check "Enable enhanced editing toolbar" in your editing preferences; check javascript is enabled in the browser. --Tagishsimon (talk) 01:06, 10 August 2011 (UTC)[reply]
Yes, I did have the enhanced editing toolbar selected and javascript enabled. However, when I deselected "Enable enhanced editing toolbar", the "older" toolbar actually has a citation tool. Chris857 (talk) 01:41, 10 August 2011 (UTC)[reply]

Missing table of contents

Why is there no table of contents on the Talk:Anne Hathaway (actress) page? Is one of the templates preventing it? The Mark of the Beast (talk) 01:20, 10 August 2011 (UTC)[reply]

If {{WikiProjectBannerShell}} is commented out, or if all the templates in it are commented out, the table is shown. I couldn't find any one Wikiproject template that caused the issue. After that I gave up. –droll [chat] 02:20, 10 August 2011 (UTC)[reply]
Frank fixed it the old fashioned way adding the TOC magic word. Seems to override whichever template (or combination thereof) was causing it to disappear. Skier Dude (talk) 02:25, 10 August 2011 (UTC)[reply]
But the fix still has issues, in that the first four entries in the TOC are spurious. It would be good to track down the root cause. --Tagishsimon (talk) 02:34, 10 August 2011 (UTC)[reply]
The reason was that the /comments subpage had a header, which caused the TOC to be hidden somewhere in the middle of the WPBannerShell. I fixed it by deleting said subpage. Ucucha (talk) 02:39, 10 August 2011 (UTC)[reply]

Certain pages not disappearing from watchlist

I'm hoping this is in the right section. I'm using Wikipedia:Hide Pages in Watchlist to hide several pages I am watching, and while it hides most of them, there are still some pages (such as Template talk:Infobox television and Wikipedia:Manual of Style (linking)) that it doesn't hide.

My CSS page. Lachlanusername (talk) 05:19, 10 August 2011 (UTC)[reply]

You hade two major problems. First of all, many of the lines you added had an error. A ; instead of a : The 2nd problem was with the encoding of some of the characters in the titles. There are certain rules applied to titles when they are converted into classes. These rules are apparently not well described in the Help page you were consulting. —TheDJ (talk • contribs) 18:39, 10 August 2011 (UTC)[reply]

Deprecation of Collapsible tables and NavFrames

Hi!

I've updated the sandbox version of Template:Hidden and some test cases in order to help in the migration from Collapsible tables and NavFrames to the jQuery.makeCollapsible plugin. Could someone test if the test cases are working on browsers not yet listed under the #Compatibility section? Except for the cursor change when using Windows (described in the second topic listed below), which I think could be fixed by adding some extra CSS rules to MediaWiki:Common.css, the template is working as usual and I think it could be updated to the new version.

See also:

Helder 19:12, 10 August 2011 (UTC)[reply]

There is some problem with the header text annoyingly jumping left when expanded which it does not do with the existing. Monobook/Firefox 3.6. Keith D (talk) 22:12, 10 August 2011 (UTC)[reply]
I can confirm this behavior on Chromium 12.0.742.112 (90304) and Firefox 5, using Ubuntu 11.04 and both on vector and monobook.
I think the cause is the difference in the lenght of the texts "Expand" and "Collapse" which are used in the toggles. Adding the following CSS fixed the problem for me:
.mw-collapsible-toggle {
	width: 70px;
	text-align:right;
}
(making sure that 70px is great enought for both texts). Helder 14:47, 11 August 2011 (UTC)[reply]
Is there a bug reported for that? --Locos epraix ~ Beastepraix 20:49, 15 August 2011 (UTC)[reply]
Not yet, I think. Helder 23:19, 15 August 2011 (UTC)[reply]

IMHO, the animation gets boring after a while (too slow?). --Locos epraix ~ Beastepraix 19:53, 11 August 2011 (UTC)[reply]

View this page on regular Wikipedia

For the last few minutes I was getting what I assume are mobile Wikipedia pages. The urls looked normal. Was I the only one? Dougweller (talk) 20:53, 10 August 2011 (UTC)[reply]

No you were not! Jan1naD (talk • contrib) 20:54, 10 August 2011 (UTC)[reply]

THIS IS what happened !

Someone deployed a change to all the servers. This change was broken and caused everyone to end up in the new experiment "mobile view" of the website that will soon replace the current en.m.wikipedia.org. The problem was live for about 5 minutes, when it was reverted. For more information see the serveradmin log or the Twitter feed. —TheDJ (talk • contribs) 21:10, 10 August 2011 (UTC)[reply]

Switched to mobile version?

Is it me or why did my default Wikipedia switch to the mobile version? It's back now, but for a few minutes, I couldn't access it. --Funandtrvl (talk) 20:53, 10 August 2011 (UTC)[reply]

Small glitch. Someone deployed faulty code. —TheDJ (talk • contribs) 20:54, 10 August 2011 (UTC)[reply]
Happened to me too, on two different browsers (Chrome and Safari on OS X). Logged out, everything looked ok; logged in, mobile version, unable to switch to the real Wikipedia. Seems to be good again now. —David Eppstein (talk) 20:55, 10 August 2011 (UTC)[reply]
Glad to see (maybe not...) it wasn't just me. Did someone fall asleep at the tech desk or hit the wrong button?? :-) --Funandtrvl (talk) 20:58, 10 August 2011 (UTC)[reply]

Mobile site without asking for it

Ok, I'll bite -- any reason I just got randomly tossed into the mobile version of Wikipedia, and couldn't get out of it until I logged in to the secure site? --SarekOfVulcan (talk) 20:53, 10 August 2011 (UTC)[reply]

That just happened to me too. How irritating. I couldn't get rid of it even by clicking on "permanently disable mobile site" at the bottom of the page. I had to clear my browser cache and cookies and log back in. ~Amatulić (talk) 20:55, 10 August 2011 (UTC)[reply]
Funny how it took us all about the same amount of time to show up here. :-) --SarekOfVulcan (talk) 20:56, 10 August 2011 (UTC)[reply]

A lot of pages are loading first in the mobile form for me. This seems to be browser independent since it has happened in both Chrome and Firefox. It started when I went to the page Illinois, and no matter how many times I tell it to disable the mobile form is still happening for some pages such as Connecticut. JoshuaZ (talk) 20:54, 10 August 2011 (UTC)[reply]

See above. ~Amatulić (talk) 20:56, 10 August 2011 (UTC)[reply]

Me, too. Just once but I wasn't looking at many pages then. Jim.henderson (talk) 20:57, 10 August 2011 (UTC)[reply]

Me too. Bus stop (talk) 20:59, 10 August 2011 (UTC)[reply]
Me too. I switched off experimental versions in preferences and it went away. Truthkeeper88 (talk) 21:00, 10 August 2011 (UTC)[reply]
(edit conflict) I didn't do anything, and it went away. Therefore cause and effect has not been established. Bus stop (talk) 21:03, 10 August 2011 (UTC)[reply]
Indeed - anyone who thinks they fixed bypassed the error just did something as it was fixed server-side. –xenotalk 21:12, 10 August 2011 (UTC)[reply]
I wasn't suggesting I fixed the error. I couldn't back out of it and tried settings and posted here. Meanwhile it was fixed on the servers. Truthkeeper88 (talk) 21:16, 10 August 2011 (UTC)[reply]
Fun for the whole family =0 –xenotalk 21:19, 10 August 2011 (UTC)[reply]

I'm confused. What cause the glitch to force us on the mobile form? JDDJS (talk) 21:02, 10 August 2011 (UTC)[reply]

Someone made a configuration error (or something). It took about 6 minutes to resolve. –xenotalk 21:10, 10 August 2011 (UTC)[reply]
Thanks for the explanation. But anyways, now I know where I can disable (hopefully, see below) the article feedback thingy. That thing takes up too much of the screen. --Funandtrvl (talk) 21:14, 10 August 2011 (UTC)[reply]

Article Feedback Tool - can't disable it

transferred from Wikipedia:Help desk

I have Don't show the Article feedback widget on pages ticked in my preferences, yet the **** thing still keeps appearing on pretty well every page. HELP!! What's worse, I'm mainly working on stubs, which in my view shouldn't be rated anyway. Jan1naD (talk • contrib) 19:45, 10 August 2011 (UTC)[reply]

Did you bypass your browser cache? – ukexpat (talk) 19:59, 10 August 2011 (UTC)[reply]
Yes, when I first set the preference, but that was a week or two ago. I've just done it again and it works. Do I have to do this every time I restart Windows? I use Firefox 3.6 with XP SP3. Jan1naD (talk • contrib) 20:13, 10 August 2011 (UTC)[reply]
I take that back. It still keeps doing it. [Ctrl-F5] removes it but it reappears a few pages later. Jan1naD (talk • contrib) 20:24, 10 August 2011 (UTC)[reply]
Hmmm, maybe the techies at WP:VPT can help... – ukexpat (talk) 20:44, 10 August 2011 (UTC)[reply]

So, can anything be done? Jan1naD (talk • contrib) 20:57, 10 August 2011 (UTC)[reply]

Isn't this the same problem reported at bug #30281? Helder 21:20, 10 August 2011 (UTC)[reply]
I'm not sure how this 'hiding' works, but how you describe the problem, to me sounds as if you possibly have a faulty javascript/userscript/gadget installed that is interfering with some of the other scripts. —TheDJ (talk • contribs) 21:23, 10 August 2011 (UTC)[reply]
Sounds like a similar bug, at least. This is the content of my vector.js.
if( typeof( TwinkleConfig ) == 'undefined' ) TwinkleConfig = {}; // DO NOT REMOVE THIS LINE - ALL TWINKLE 
TwinkleConfig.watchRevertedPages = [ ];
TwinkleConfig.watchWarnings      = false;
is that a possible cause? Jan1naD (talk • contrib) 21:34, 10 August 2011 (UTC)[reply]

So, I switched out twinkle and commented out the JS, and I can't reproduce the problem. Coincidence? Possibly, I'll keep monitoring it. I haven't used twinkle for some months, so doesn't matter to me. Thanks for the dialogue, though I may be back. Jan1naD (talk • contrib) 21:41, 10 August 2011 (UTC)[reply]

Yep, it's back. Still no fix available. Jan1naD (talk • contrib) 14:42, 11 August 2011 (UTC)[reply]

This is very strange. You and User:Peridon are the only affected users as far as I'm aware. I've looked at both your preferences because I, like TheDJ, suspected Gadgets, but I don't see anything significant that you have in common, other than that Peridon uses Twinkle and you apparently used to. Do I read correctly that disabling Twinkle made the problem go away temporarily, but that it's back now? Could you also answer the same questions that I asked Peridon? --Catrope (talk) 13:13, 13 August 2011 (UTC)[reply]

Thanks for the question, Peridon Catrope. It's only happening on FF 3.6, and only on one machine. It must be something to do with cookies or the cache, I've tried clearing the cache but it's obvious I'm not getting it right. I did follow the instructions on WP:Bypass your cache. Jan1naD (talk • contrib) 17:02, 13 August 2011 (UTC)[reply]

Interestingly, Peridon was only able to reproduce this on FF 3.5, so it might be related to the browser version. I've asked him to help me debug it using Firebug. If you feel adventurous, you can do that too; see the instructions I left on Peridon's talk page. --Catrope (talk) 18:19, 14 August 2011 (UTC)[reply]

Question only on getting to redirect page

I've had no problem in the past going to a redirect page to make changes where required. I can't seem to get to Education in Maine in any fashion. Wind up at strange page though redirect "appears" to be constructed correctly (look-ahead feature) to "Maine#Education." The first link never arrives there, which isn't my problem. I need to get to the redirect page. Thanks. Student7 (talk) 21:04, 10 August 2011 (UTC)[reply]

It appears to work now; a suitable link to the redirect is this. Grandiose (me, talk, contribs) 21:05, 10 August 2011 (UTC)[reply]
Thanks a lot! Student7 (talk) 23:57, 10 August 2011 (UTC)[reply]

Browser freezing when I load page history

Firefox has recently started freezing (not responding) when I look at page histories that have anything more than just a few revisions. It freezes for a minute or two, then starts responding again. I was using an old version of Firefox, so I downloaded the latest, but it makes no difference. I usually have my preferences set to load 1,000 revisions. I've changed this to 500, 400, etc, but the freezing only stops when I get to 50.

The same thing happens with default preferences, except for the number of revisions shown in page histories. It only happens with Firefox.

Can anyone think what kind of thing might be causing this, so I know where to start troubleshooting? SlimVirgin TALK|CONTRIBS 00:49, 11 August 2011 (UTC)[reply]

Possibly you have some JavaScript working on history pages that is taking a lot of time. You didn't add anything to your monobook.js recently, but perhaps it's a gadget, or one of your imported scripts got changed. Ucucha (talk) 02:39, 11 August 2011 (UTC)[reply]
Happens to me all the time and has for years. But it's worse on IE. The Mark of the Beast (talk) 05:17, 11 August 2011 (UTC)[reply]
It would be helpful to know what version and what OS. --Izno (talk) 06:13, 11 August 2011 (UTC)[reply]
Firefox was slow last week for me too, but this week it's working better. Try clearing your recent history (see Tools on the toolbar), and go to http://www.java.com/en/download/installed.jsp to check that you have the latest Java, Version 6 Update 26. Also see web pages take too long to load at Firefox Help for some more ideas. --Funandtrvl (talk) 07:18, 11 August 2011 (UTC)[reply]
Maybe it would help by disabling as much features as possible, e.g. I turned Flash of in the site-specific preferences. mabdul 09:06, 11 August 2011 (UTC)[reply]
Okay, thanks everyone, that gives me a few things to try. SlimVirgin TALK|CONTRIBS 16:44, 11 August 2011 (UTC)[reply]
  • I've had similar problems with Firefox, for months, but also in IE, when trying to list history &limit=3000, which ran for more than 1 hour, even though 3,000 is just 60x times more entries than the default 50 revisions (3000=60*50) displayed within seconds (so if 50 revisions display in seconds, then 3000 shouldn't require 1 hour, but instead finish within several minutes). I think, months ago, the history-tab list was faster, hence, I suspected all the inherited CSS-style class parameters might be applied, as extreme overhead, to format each revision in the list. I'm not sure how much slower those CSS styles, or mouse-over gadgets, would run. Then also, I suspected U.S. computer rules require notifying, and opening an FBI or Homeland Security dossier, when people try to hunt through 3000 revisions looking for information, which would cause the display to run slower when being viewed by spooks snooping through your computer records. I already learned not to search for the word "atom" and any word (even in Greek) that goes "boooom" in the same search-engine lookup: I got all kinds of military sites hitting my firewall ports, soon after. Anyway, if someone finds a way to make Firefox list 250 history entries quickly, let us know. Thanks. -Wikid77 (talk) 08:34, 12 August 2011 (UTC)[reply]

unused documenation

Hello, please see Template:R_from_other_capitalisation, as it's seen this template used for documentation about redirects but please see this. nothing is showed (except categories). I think there is something for force to show this text and if there is not such a good thing so why we use unused documentation?:)Ladsgroupبحث 02:20, 11 August 2011 (UTC)[reply]

I think any text on a page that is a redirect gets eaten by the parser. I'm not sure, but this may not have been the case in earlier versions of MediaWiki. Ucucha (talk) 02:37, 11 August 2011 (UTC)[reply]
It's certainly been the case for as long as I remember (about two years) that text on redirects is hidden except when viewing a diff (or when previewing an edit). So, compare Kung fu panda 2 with this. --Redrose64 (talk) 13:13, 11 August 2011 (UTC)[reply]

Opting out of a global Javascript

Hi, over at Commons there is a discussion about adding a link to Special:MyUploads in the top right, next to My Contributions (see Commons:Commons:Village_pump/Proposals#Special:MyUploads; the concept has general support though with requests for improving Special:MyUploads). Now I've made a Javascript which does this, Commons:User:Rd232/myuploads.js, but I don't know how to give users the ability to opt out of having this additional link once that code is added into Commons' Javascript page. I think the usual thing is a Gadget "turn X off", but I've no idea how to do it. Could someone who knows how please come to Commons and help implement this (in a hands on way, more than a giving-tips way)? I ask here because I think it's the best place to find the necessary expertise. Many thanks. Rd232 talk 12:02, 11 August 2011 (UTC)[reply]

One line of CSS should do the trick: 
li.pt-upl { display: none; }
(haven't tested it myself). Ucucha (talk) 17:15, 11 August 2011 (UTC)[reply]

Alternatively, a piece of JavaScript like this (which could be turned into a gadget, and I haven't personally tested it either): 

$( function ( $ ) {
   $("#pt-upl").css('display', 'none');
} );

Ucucha (talk) 17:17, 11 August 2011 (UTC)[reply]

Any idea why completely unprotected articles have View source tab instead of Edit? Clicking on the View source tab does bring up a normal editing interface, and if I purge the page (with &action=purge) it correctly displays Edit tab... perhaps this glitch is only visible to IP editors? I have noticed this before, but didn't really pay any attention. This time I got curious enough to click the Random article link in the sidebar 100 times, and got 9 articles which showed View source tab instead of Edit. None of them has ever been semi/fullprotected, and purging fixed them all. 88.148.249.186 (talk) 16:50, 11 August 2011 (UTC)[reply]

Your IP address may have been autoblocked, that is, automatically blocked for a period of time after being used by a user who was blocked with the autoblock option on, and you probably had to purge in order to uncache the block.Jasper Deng (talk) 16:54, 11 August 2011 (UTC)[reply]
Hm. I'm not sure if it checks expired autoblocks, but tools:~nakon/autoblockfinder.php doesn't show anything for that IP address. Killiondude (talk) 17:02, 11 August 2011 (UTC)[reply]
No, this is a static IP and is only used by me (residential ADSL). For me, this glitch is not a problem, I just got curious about it. But if all the IPs see a missleading text in one page out of ten... what actually is cached: is it just the text of the article in HTML, or also parts of the interface -- perhaps a complete page including tabs, sidebar etc? 88.148.249.186 (talk) 17:23, 11 August 2011 (UTC)[reply]
This was also reported at Wikipedia:Village pump (technical)/Archive 88#"Page is protected" - but it is not, and I can edit anyway via View Source and Wikipedia:Village pump (technical)/Archive 91#"View source" on unprotected pages... I have also experienced it when logged out. I haven't seen a bug report on it. PrimeHunter (talk) 17:25, 11 August 2011 (UTC)[reply]
88..., there are multiple levels of caching on Wikipedia, including I believe caching of the parsed wikitext and of the complete HTML page (cf. mw:Manual:Caching). What may be going on is that you are getting a page that was cached when it was rendered for a blocked user, but that's just a guess. Ucucha (talk) 17:29, 11 August 2011 (UTC)[reply]

How do I delete a picture I uploaded?

How do I delete a picture I uploaded? I uploaded some pictures (such as this one that is only a part of another image), how do I delete these pictures without sending them to the pictures deleting requests?-- Someone35 (talk) 18:57, 11 August 2011 (UTC)[reply]

Add {{Speedy|reason here}} on the page on Commons. I'll delete the one you linked for you. But just for the record Commons is a separate project of the Wikimedia Foundation and has its own set of admins, templates, etc. Killiondude (talk) 19:02, 11 August 2011 (UTC)[reply]
k, i'll do that tomorrow-- Someone35 (talk) 19:39, 11 August 2011 (UTC)[reply]

proposal for additional pronunciation information

in response to:

  • Where did you encounter the problem? Please add links when possible.

i would not describe this as a problem. but here are my observations and i am looking for some guidance.

i was visiting the url: http://en.wikipedia.org/wiki/Mohandas_Karamchand_Gandhi

and i came across the following:

pronounced [mo???n?d?a?s? k?r?m?t??nd?? ga?nd??i]

the question marks are all characters that are unrecognizable to my editor of choice, which is SciTE.

so i followed a few links and came across this article: http://en.wikipedia.org/wiki/Pronunciation_respelling_for_English

then i went to: http://en.wikipedia.org/wiki/Wikipedia_talk:Manual_of_Style_%28pronunciation%29

there seems to be some interest among native english speaking people: 

   "how do i pronounce this correctly??????"

as an american, i am fully aware, that as an american, i am totally unaware of anything even remotely "International". i still buy gas by the gallon and not by the liter (pardon me litre).

on the other hand, i am a retired mathematician and programmer. so please let me make some comparisons:

say i were amongst any of the following: 

   The IPA is used by foreign language students and teachers,
   linguists, speech pathologists and therapists, singers,
   actors, lexicographers, artificial language enthusiasts
   (conlangers), and translators.

from: http://en.wikipedia.org/wiki/International_Phonetic_Alphabet

i would hazard a guess and say this set comprises less than 1% of native english speaking people who visit en.wikipedia.org.

therefore the rational seems to be: 

   The pronunciation of English words in Wikipedia
   is given in the International Phonetic Alphabet (IPA)
   using the following transcription, which is not specific
   to any one dialect.

the problem with this is: it is not specific to ANY dialect!

except: 

   foreign language students and teachers,
   linguists, speech pathologists and therapists, singers,
   actors, lexicographers, artificial language enthusiasts
   (conlangers???), and translators.

so here is my comparison...

suppose i WERE one of those folks who actually uses the: 

   International Phonetic Alphabet (IPA)

and i wanted to know what the square-root of two was...

should i first have to learn about the natural numbers, then the set of integers and then the rationals and set notation to prove that the square-root of two is not a rational number and then learn that it is also neither a transcendental or complex number or quaternion?

so here's where the looking for guidance part comes in...

since i am retired... all that information provided to make sense of this international alphabet which has been around since 1888, (but simple american folks like mathematician's have never heard of!) actually looks interesting to me, but that is probably because i LIKE looking at unintelligible symbols! but on the serious side, i have found this to be quite irritating.

so here is my proposed solution:

when a new topic is started, i see: "needs citation" all over the place. now those comments may all be made by other wiki readers who can't keep their fingers off the "needs citation" button. but my solution would require a bit of programming... so here goes...

how about i create a simple database, and every so often the topics which contain the: International Phonetic Alphabet (IPA) symbols are matched against this database and we stick a tiny, tiny, little icon near it (so as not to offend) so that when you pass your mouse cursor over it, you actually DO get some help on how to pronounce the word. of course this would only be for the native english speaking wiki's.

if you think this solution might work, let me know, i will be happy to code it, for the sake of all us simple folk who would like to know how to pronounce: Mohandas Karamchand Gandhi correctly...

thank you.

sincerely,

brian oslick bdo1964@att.net 08.08.2011 Bdo1964 (talk) 22:35, 11 August 2011 (UTC)[reply]

  • There has been discussion to simply include the "re-spelled" pronunciation, probably in a footnote, because "almost no one in the world" can read IPA whatever. To perhaps answer your main question, "Mohandas Karamchand Gandhi" is pronounced as "Mo-hahn-dass Kah-rahm-chahnd Gahn-dee" (I think); however, other names might benefit from a rhymes-with pronunciation, as in "Ayn Rand" rhymes with "Wine stand" (or such). So, some people have pronounced "Gandhi" to rhyme with "candy" whereas others would rhyme "gone free" for "Gandhi". Many people pronounce "New York" as "Nu-Yorrk" whereas others (locals?) say "nuh-Yawk" while "New Orleans" can be "Nu Orluns" or "Nawlins" or French "Ohr-lay-ahnn" (etc.). Only very rare words cannot be re-spelled or rhymed. -Wikid77 (talk) 06:24, 12 August 2011 (UTC)[reply]
    • Re: "Mo-hahn-dass Kah-rahm-chahnd Gahn-dee": the sound written as "a" in this transcription is really more of an "uh" sound in the middle name, so that "kuh-rum-chund" would be closer.
As for the topic at hand: I agree that IPA isn't that widely known: it's becoming more common in dictionaries- but that doesn't mean everyone is familiar with it. Still, IPA has the advantage that it's completely independant of one's own accent: The problem with the "respelling" method is that different people may read it differently depending on where they're from.
For me, as a California native, "hot", "bought" and "caught" all rhyme. For someone from New York, they don't (then there's "merry", "Mary" and "marry", which sound the same to me, but which may have two or three different pronunciations for others). It may be possible to avoid such cases, but it would require a good knowledge of the patterns of variation- and with people from all over the world reading it, there would be lots of variation.
There's also the option of linking to a recording (if you click "listen" next to Gandhi's name in that article, you should be able to hear how a native speaker pronounces it), though not everyone has an ogg plugin on their browser Chuck Entz (talk) 07:35, 16 August 2011 (UTC)[reply]
TL;DR. This "IPA is too weird" thing is a perennial argument; see Talk:International Phonetic Alphabet and WT:IPA for scores of copies of it. Also, I don't see how this topic is relevant to this village pump. rʨanaɢ (talk) 08:54, 16 August 2011 (UTC)[reply]
For what it's worth, the particular proposal above ("intuitive" mouseover text with IPA stuff) has been made before, I'm pretty sure someone even has a trial version of it somewhere. As for the particular article in question, it already has an audio recording linked right after the IPA transcription, so this whole discussion seems like a solution in search of a problem. rʨanaɢ (talk) 08:57, 16 August 2011 (UTC)[reply]

Emergency fix for Template:Convert/m

RESOLVED at 06:59, in Template:Convert/outAnd. -Wikid77 07:28, 12 August 2011 (UTC)[reply]

Something has gone wrong inside Template:Convert and conversions of "m" (metres) are showing vastly wrong amounts, as just a few inches, in many (thousands?) of articles, such as the height of tennis player Andre Agassi as just 11 inches: "1.80 m (11 in)". A quick fix would be to install sandbox Template:Convert/m/sandbox as Template:Convert/m to stop showing any inches and just force all default conversions of "m" to decimal feet. The difference would be:

  • {{convert|1.80|m}} → 1.80 metres (5 ft 11 in)  ←showed "(11 in)" at 5:33, 12 August
  • {{convert|1.80|m/sandbox}} → 1.80 m/sandbox[convert: unknown unit]

Once Template:Convert/m has been patched from the sandbox, then we can take more time to see how to fix this confusing problem, and prevent any future massive screw-ups. However, there are other problems because conversions force "m" to "ftin" which no longer works, so this is a long-term nightmare:

  • {{convert|1.80|m|ftin}} → 1.80 metres (5 ft 11 in)
  • {{convert|1.73|m|ftin}} → 1.73 metres (5 ft 8 in)

The problem might occur within Template:Convert/outAnd which was recently changed to avoid "0 m" as "1 ft 0 in".
I am thinking Template:Height should be rewritten as a highly stable, simple template, rarely if ever changed. If any questions, ask below, and I will watch this topic for a few hours. Several templates are involved in the calculation of 1.80 metres as "11 in" so I am not sure where the problem actually occurred; the patch to Template:Convert/m is just to bypass conversions to the ft&in style of numbers. -Wikid77 (talk) 05:39, revised 06:04, 12 August 2011 (UTC)[reply]

Infobox question

When filling in Template:Infobox AFL player NEW on an article, a comma will always appear after the date of death, regardless of whether or not the place of death has been filled in. Is there something someone can do to the infobox so that it only appears when there is something after it? It looks odd otherwise. Any help would be much appreciated. Jevansen (talk) 05:46, 12 August 2011 (UTC)[reply]

Problem is probably line 35:
{{!}} colspan="2" {{!}} {{{death_date<includeonly>|</includeonly>}}}, {{{death_place<includeonly>|</includeonly>}}} - that rogue comma between the date & place... Probably needs <span class="role"> opening & closing - will leave it to someone with a bit more expertise. Skier Dude (talk) 06:11, 12 August 2011 (UTC)[reply]
  • Use #if:{{{parameter|}}} before punctuation: The typical format would be to check the parameter (with empty "|" default) before showing the punctuation as comma. So, try:
{{!}} colspan="2" {{!}} {{{death_date<includeonly>|</includeonly>}}}{{ #if:{{{death_place|}}}|, {{{death_place<includeonly>|</includeonly>}}}}}<!--endif {deathplace}-->
That way, the comma "," would only be shown when parameter {{{death_place}}} has been specified as text to appear. -Wikid77 (talk) 07:42, 12 August 2011 (UTC)[reply]

Using lang-sa variable

On the page http://en.wikipedia.org/wiki/Panini

I found that the expression (hacked by spaces, so it display here as source): . . . ( S a n s k r i t : { { l a n g - s a | पा णि नि } } ) . . .

evaluates to: ... (Sanskrit: Sanskrit: पाणिनि)

where the double "Sanskrit" does not look nice.

In the sandbox, I tried: . . . ( { { l a n g - s a | S a n s k r i t } } : पा णि नि ) . . .

but it evaluates to the same.

Also, I could not find "lang-sa" in the variables documentation.

I'd like to add the same entry into the German page, but it would be nice not to copy a known error.

Any advice or help would be highly appreciated.

Thanks — Preceding unsigned comment added by Andreas.Stankewitz (talk • contribs) 10:00, 12 August 2011 (UTC)[reply]

{{lang-sa}} isn't a variable, so I wouldn't expect to find it in the variables documentation. It's a template, and as such has its own doc page (which is displayed in a pale green box when you view the template page Template:Lang-sa), but it's admittedly rather scant on information. Most of the useful documentation is actually shown on the generic {{lang}} page.
The {{lang-sa}} template, like the others in the {{lang-xx}} series, generates its own linked language name, so there is no need to provide one of your own. I have removed the superfluous one.
Although there is a German equivalent to Panini at de:Panini, there is no de:Vorlage:Lang-sa template page. I don't think that the German Wikipedia has any multilingual support templates directly equivalent to our {{lang-xx}} series - if they did, I'd expect to find a "Deutsch" entry in the left margin of {{lang-fr}} at the very least. You would need to use {{lang}} and create your own link, as in [[Sanskrit]]: {{lang|sa|पाणिनि}}. --Redrose64 (talk) 11:31, 12 August 2011 (UTC)[reply]

Searching for forum contributions in Wikipedia forum throws goggle error message

This is a bug report, which was refused by the bugzilla guys (see bug 30340) but suggested to be posted here. So it be.

User intention: Search for already existing entries in Wikipedia's technical forum

Steps to repeat: Open page http://en.wikipedia.org/wiki/Wikipedia:Village_pump Click on any "search" link, e.g. the one under "Technical"

Expected behavior: Show result list (obviously provided by Google)

Actual behavior: Google throws an error message telling me: "We're sorry... ... but your computer or network may be sending automated queries. To protect our users, we can't process your request right now."

I once read that this could happen with Google, so the source of the bug most likely is not related to Wikipedia. Still, this is a crucial function when using the forums, and should work.

I'm running a private network with a well configured WLAN and computers configured to defend malware as best as possible. It's quite unlikely that my network is the actual reason for Google's error message. But even if it is, it might hit other users too, and at the end is perceived as a Wikipedia problem.

Thanks — Preceding unsigned comment added by Andreas.Stankewitz (talk • contribs) 10:19, 12 August 2011 (UTC)[reply]

It's the {{google custom}} template. I've raised a thread at Template talk:Google custom#Broken link. --Redrose64 (talk) 11:47, 12 August 2011 (UTC)[reply]

See WP:HD#Strange appearance of wikilinks.

I noticed this while visiting the page BBB. Some of the wikilinks on this page appear in red, despite being bluelinks (ie. leading to an existing article). A screenshot of the appearance can be found here. I am using Safari on Windows 7. What could cause this and how can it be fixed? Toshio Yamaguchi (talk) 17:51, 12 August 2011 (UTC)[reply]

I don't know if it's exactly the same phenomenon or not, but I've noticed that whenever I use Twinkle to create an AfD, I have to go back and add a space before the name of the AfD page in order for the link (which works if you click on it) to be blue instead of red. LadyofShalott 18:01, 12 August 2011 (UTC)[reply]
It's not the same issue. The Twinkle issue is just one of timing between servers. If you do a server purge on the article page after you have used TW to create the Afd, the link in the Afd notice should turn from red to blue. – ukexpat (talk) 18:15, 12 August 2011 (UTC)[reply]
Just a note that I prefer doing AfDs manually (I'm an old-fashioned kind of guy) and I see this phenomenon as well (link to AfD being red until I purge the page). It's not Twinkle's fault. -- Atama頭 18:40, 15 August 2011 (UTC)[reply]
OK weird. So why does adding a space before the title make it turn blue? Am I in effect forcing a purge by doing that? LadyofShalott 18:53, 15 August 2011 (UTC)[reply]
Since WP removes unnecessary spaces, that's really a null edit - and does purge the page extremely well - often useful when one has updated a template and you want to see the result on the article - sometimes WP takes ages to catch up, a null edit on the article forces WP to reload all the templates on the page.  Ronhjones  (Talk) 19:00, 15 August 2011 (UTC)[reply]
Ah, thanks for the explanation! LadyofShalott 19:08, 15 August 2011 (UTC)[reply]

So what is happening with this proposal?

Could anyone supply an update on Wikipedia:Village_pump_(proposals)/Archive_74#Several_changes_to_file_naming, which seems to have passed without contention? --Ohconfucius ¡digame! 02:20, 13 August 2011 (UTC)[reply]

From what I can see, there are three issues raised in the discussion you've pointed to. For reasons I don't follow, these three issues have been added to an existing mediawiki bug report - Template:Bugzilla - which primary deals with a strictly unrelated issue, "Image file extension should not be part of the name". From a quick read through, discussions on whether and how the primary issue should be tackled have not exactly reached a conclusion, and I see indications that the bug is not being treated as highly urgent. And I think the three issues lately tacked onto the big report stand relatively little chance of getting a look-in. Further, at least one denizen of WP's bugzilla doesn't agree that there's need to make the changes advocated. The bottom line is that this is a mediawiki issue and not strictly an en.wikipedia issue.
I suggest that if you want to get progress you'll a) have to make and win a case for change on bugzilla, b) put together one or more new bug reports to separate "your" bugs from the 4421 bug and c) hope that the new bug listings get some priority amongst the very many existing bugs.
I note that there's a clear impediment to progress, in that should mediawiki code be changed in the way "your" bugs seek to have it changed, action will have to be taken to resolve however many cases there would then be of identically named images (i.e. ABC.JPG and abc.jpg would be fighting for the exact same namespace). That's not an insuperable issue, but it is a big big big problem affecting not only the naming of the corpus of files on on wikipedias, but also affecting all links to these files from all wikipedias. I can well see why a developer might conclude that the very slight supposed gain is not worth the tremendous effort that would be required. --Tagishsimon (talk) 02:48, 13 August 2011 (UTC)[reply]
Not everything that en.wp decides is a good idea is actually easy to implement :D The big problem here indeed is the decidedly large trove of images that we ALREADY have. Were it possible to start afresh, this would be easy peasy. As it stands now, it will be a humongous challenge of backwards compatibility and conversion, which needs to be absolutely without a single error. I estimate development time to get this implemented and properly enough tested at some 2-2,5 years at the moment (The time that it took to implement file renaming). And to be honest, there really are more important feature requests of smaller scale on the table in that area (think about copyright, author etc for a file as part of the database, so the files can be more easily reused). The developers have to decide what is the best way to spent their time and it is my opinion, and probably the opinion of many other developers, that there really are more important things to fix/make that will have a higher 'yield' in effect upon the user. —TheDJ (talk • contribs) 07:42, 13 August 2011 (UTC)[reply]
  • Hi there. I'm the original proposer. I view this much the same way I view the media blacklist; as a measure that would stop the creation of future issues while not really doing anything to address the past issues. One of the things that the blacklist does is prevent the upload of files with names like "File:DSC000238.jpg". A team of about a half dozen people have been manually renaming files that have those kinds of useless names and were uploaded before the blacklist came into effect. If the devs can't easily fix all the old issues, would it be possible to create a system where new issues are no longer able to be created? Would it be possible to force all new uploads into having one version of the filetype extension? In other words, the current system allows me to upload as ".jpg", ".jpeg", ".JPG", ".JPEG", etc, and the new system would only allow new files in the jpeg file type to be uploaded with say ".jpg". This wouldn't force people into using a specific filetype, but would limit each filetype to one using only one extension, like the new Commons Upload Wizard does. It also wouldn't affect previously uploaded files, grandfathering the old ones in. This change would knock off issues 2 and 3 of my original proposal, if I remember it correctly, and would probably be easy to implement, if not now, when the next upload wizards come out. Sven Manguard Wha? 00:43, 14 August 2011 (UTC)[reply]
    • A possibility I guess, one with less impact than the other proposals of fully decoupling filenames form extensions. Still we have a lot of "entry points" into the upload process. I guess a "title normalization" step would have to be introduced before the "title verification" step, that would require adding interface callbacks to give user feedback. A lot less complicated. Better filed as a separate ticket however. —TheDJ (talk • contribs) 11:08, 14 August 2011 (UTC)[reply]

Problem with the mobile site when viewed with Opera mini

Up until a few days ago, the mobile site looked the same in Opera Mini as it does in Firefox on a full sized computer. However, now when viewing the main page (with "mobile view" on or off), the "search box" is gone. When viewing an article, there's a "search box" but the "submit button" is a tiny little dot between the box and the big "home" and "random" buttons. Also the "view this page on regular Wikipedia" link is missing. (but I see it on Firefox)

Was there a recent redesign of the mobile site and was this redesign tested using multiple phones and browsers? --Ron Ritzman (talk) 02:42, 13 August 2011 (UTC)[reply]

There are actually two mobile websites at the moment. http://en.m.wikipedia.org, and the one you get when you click "mobile view" at the bottom of a normal page. There is a transition going on between the two systems. The skins of the new system are not fully supporting the same amount of layout options as the old skin, but it is being worked on and should visibly improve in the next month or so. I will notify the author of the new system about your problem (bugzilla:30356). On what kind of phone are you using Opera mini, and would you know the version of Opera that you are using ? That might be useful information for him. —TheDJ (talk • contribs) 07:48, 13 August 2011 (UTC)[reply]
Opera/9.80 (J2ME/MIPD; Opera Mini/6.24093/25.729; U;en) Presto/2.5.25 Version/10.54. The mobile site use to look best using the browser's "mobile view" feature. One box, one submit button, then the article text. --Ron Ritzman (talk) 12:55, 13 August 2011 (UTC)[reply]
This may also be due to the changed redirects based upon User Agent. In that case, please visit "myuseragent.com" with opera mini and note the exact User agent that is stated there. It might help. —TheDJ (talk • contribs) 07:59, 13 August 2011 (UTC)[reply]

It's a shame that logging in doesn't yet work with the mobile site or you could give users a choice of skins. Mobile displays vary in size more then full size computer screens do so it would be nice to have different skins optimized for different displays. On my issue, page appearance now seems to be inconsistent. With mobile view on, sometimes a page will look like they all use to with the search box on top, a little "spyglass" button below it and to the left for submitting followed by "home, random, and end" blue links. (I prefer this but others may not). Sometimes it's a search box with a tiny little dot below it for a submit button and sometimes there's no search box at all. --Ron Ritzman (talk) 21:18, 13 August 2011 (UTC)[reply]

Adding options like these is the end goal of integrating the older en.m.wikipedia.org into the standard software (new mobile view). That is a LONG road however, that requires not only mobile specific layout'ing, but also mobile specific outputparsers (that output the page in such a way that older mobile devices can read them as WML/WAP, or XHTML mobile profile). But that is the goal. (The skin you were describing btw, was the mobile "simple" skin, as opposed to the mobile "iphone" skin for touch devices, for en.m.wikipedia.org, there are actually about 8 skin variants for different devices). —TheDJ (talk • contribs) 11:14, 14 August 2011 (UTC)[reply]
I'm guessing that, without logging in and being able to set a preference, the skin is picked based on the user agent reported by the browser. --Ron Ritzman (talk) 05:14, 16 August 2011 (UTC)[reply]

502 Proxy error on secure server

I almost always get a proxy error when trying to load a diff from the history of an article. Refreshing does no good and it happens across browsers. This has been going on for weeks if not months. I'm assuming the page is timing out. Be nice to get it fixed....is this a known issue? RxS (talk) 05:13, 13 August 2011 (UTC)[reply]

Try to load the diff at the "normal" Wikipedia server, click the "Edit" button, scroll down the page and see if there are alot of template transclusions. If that is the case, that will explain the issue. HeyMid (contribs) 07:47, 13 August 2011 (UTC)[reply]
This happens when it takes the https termination servers too long to retrieve your request from the backend network services. It is a known issue, and can occur on any type of https request that takes the servers very long to process. I'm not sure if there is a solution. —TheDJ (talk • contribs) 08:03, 13 August 2011 (UTC)[reply]

errors at Category:Candidates for speedy deletion by user

For some reason a bunch of user talk pages are in this category right now despite not being visibly nominate for deletion. Some of them are even archive pages that haven't been edited since 2008. Beeblebrox (talk) 16:46, 13 August 2011 (UTC)[reply]

Its due to User:Knowzilla/Welcome being deleted, each page just needs purging I think--Jac16888 Talk 16:51, 13 August 2011 (UTC)[reply]
Scratch that, null editing will do it--Jac16888 Talk 16:52, 13 August 2011 (UTC)[reply]
It was another of knowzilla's pages that was deleted and caused it as well, sorted it out now. Makes a nice empty csd, been a while since I've seen that wasn't paying attention, its a subcat--Jac16888 Talk 16:58, 13 August 2011 (UTC)[reply]
Cool, thanks! Beeblebrox (talk) 17:14, 13 August 2011 (UTC)[reply]

This template ({{Hurricane season bar start}} generates a link depending on its input.

It is used in templates such as {{1962 Pacific typhoon season buttons}}

However, if you check the main link (at the top of the template) in Firefox, you cannot click it. It works just fine in IE.

Headbomb {talk / contribs / physics / books} 03:49, 15 August 2011 (UTC)[reply]

Delay in updating the search index

The Search Index has not been updated since 12 August.
Help:Searching#Delay_in_updating_the_search_index says this should be reported here. These backlogs frustrate us WikiGnomes in our tidying up, and we get a huge backlog of spelling, grammar and other mistakes to correct when it is eventually updated. Any idea when it might be updated?
Arjayay (talk) 14:26, 15 August 2011 (UTC)[reply]

I was just going to mention that myself. Maile66 (talk) 21:43, 15 August 2011 (UTC)[reply]
Still not been updated - any news? Arjayay (talk) 15:44, 16 August 2011 (UTC)[reply]
Maybe this is related to bugzilla:29679 / bugzilla:26304? Helder 16:33, 16 August 2011 (UTC)[reply]

Error in Article

I was reading about the US Army and in the "infobox" on the right it doesn't list Operation Urgent Fury as an engagement we fought in. I would like to have that changed in order to honor our 19 dead and 116 wounded soldiers. Thank you if can change it because I don't know how. — Preceding unsigned comment added by Cjonschmidt (talk • contribs) 03:04, 16 August 2011 (UTC)[reply]

Operation Urgent Fury (the Invasion of Grenada) is mentioned in United States Army#20th century and included in List of wars involving the United States. An infobox such as the one at United States Army should summarize important points and not include everything. The invasion of Grenada may not be significant enough to mention in the infobox but you can post a suggestion at Talk:United States Army. Note that Wikipedia is not a memorial, and it is an international encyclopedia with editors and readers around the World. PrimeHunter (talk) 04:26, 16 August 2011 (UTC)[reply]

Image referendum character error

Right now, on the CentralNotice, I'm just getting a long line of boxes of the sort you get when you are trying to view a script for which you do not have (a/the) correct font installed.

I'm logged in, and I've got everything set to en, so AFAIK I should just be seeing it in English (which I was before?). Is this just me...? - Jarry1250 [Weasel? Discuss.] 11:16, 16 August 2011 (UTC)[reply]

Happened to me too, briefly. The message was in some script that I didn't recognise (which means it was really fairly obscure...) The problem seems to have gone away now - the message is back in good old English. — This, that, and the other (talk) 11:19, 16 August 2011 (UTC)[reply]
According to the Google translator, it was Hawaiian but seems its back to English now. Thank heavens it wasn't just me seeing it! Bidgee (talk) 11:21, 16 August 2011 (UTC)[reply]
Yes, seems to be fixed now. Thanks all. - Jarry1250 [Weasel? Discuss.] 11:31, 16 August 2011 (UTC)[reply]

Bug?

For some time now I have trouble with "my" article List of Michelin starred restaurants in the Netherlands. If I change anything and try to save it, it ends up as a Wikimedia error. But if I open the article in another window, the edit has gone through. Not a clue what causes this. It is a 74Kb article, not too big as far as I know. I use Firefox 5.0 under Windows Vista latest version. Night of the Big Wind talk 12:42, 16 August 2011 (UTC)[reply]

I get the following error message:

Night of the Big Wind talk 12:56, 16 August 2011 (UTC)[reply]

This happens often when editing large or template-heavy pages. It is annoying but harmless; your edit does go through, you just don't get to see the rendered page. Reloading a few times tends to fix it. Ucucha (talk) 13:21, 16 August 2011 (UTC)[reply]
So, a job for the tech-guys with a priority in the "low/average"-band. Night of the Big Wind talk 17:24, 16 August 2011 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=445182896"