Jump to content

Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia
 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 (see how to report a bug). Bugs with security implications should be reported to security@wikimedia.org or filed under the "Security" product in 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.

server problems?

Wikipedia seems incredibly slow for me right now -- is it just me, or are other people noticing anything? —Steve Summit (talk) 03:34, 4 March 2014 (UTC)[reply]

I had been noticing this, but it seems to have cleared up by now:Jay8g [V•T•E] 04:26, 4 March 2014 (UTC)[reply]
Yup. —Steve Summit (talk) 06:34, 4 March 2014 (UTC)[reply]
I've found it getting slower through the day, but a reload of the browser speeds things up again. Probably irrelevant... Peridon (talk) 12:47, 4 March 2014 (UTC)[reply]
I was having a lot of problems yesterday evening New York time also. Reloading the browser didn't help. Robert McClenon (talk) 15:32, 4 March 2014 (UTC)[reply]
Between slow and painfully slow for me yesterday and today. I have reloaded a few times and given up on a few pages but it deteriorates quickly. Donner60 (talk) 02:56, 6 March 2014 (UTC)[reply]
It's been working fine in the mornings and afternoons EST but seems to slow to a crawl during evenings and makes WP nearly unusable during those hours.... Cloudchased (talk) 02:59, 6 March 2014 (UTC)[reply]
Where are you located? At a guess this sounds like a load-balancing problem in one of the Wikimedia data centres, and location is important when troubleshooting things like that. For what it's worth, I'm not having any problems at the moment. (I'm in Sapporo, Japan.) — Mr. Stradivarius ♪ talk ♪ 03:37, 6 March 2014 (UTC)[reply]
I agree with Cloudchased. It has been murder for the last 3 days at around 22:00 EST (US East Coast, or 03:00 UTC) and maybe an hour or two before and after that. Near Philadelphia. Chris the speller yack 03:58, 6 March 2014 (UTC)[reply]
U.S. East Coast. Donner60 (talk) 04:09, 6 March 2014 (UTC)[reply]
Now the 4th night in a row. Noticeably slower at 20:44 EST (US East Coast). Chris the speller yack 01:47, 7 March 2014 (UTC)[reply]
Me in NYC, OK so far, for once. Jim.henderson (talk) 02:02, 7 March 2014 (UTC)[reply]
Spoke too soon. Been intermittently balky, though not as bad as previous 3 evenings, for half an hour. Jim.henderson (talk) 02:46, 7 March 2014 (UTC)[reply]
Glad I found this thread, I thought it was just me. I've had problems the last 4 nights (East Coast US, approx. 0100-0400 UTC 3/4-3/7); occasionally I'd get a page served up, after a much-longer-than-normal wait, but it would more often just hang on me, giving me the first 1/3 of a page but never the rest. Not saying it was this bad all 3 hours, because after a couple of tried I'd give up and try later. No problems any other time of day, and no problems during this timeframe with any other website besides en.wiki. --Floquenbeam (talk) 20:57, 7 March 2014 (UTC)[reply]
At around 00:45 UTC on 6 March I tried to edit two long pages; the save attempts timed out after a minute with an error like this. After this happened five times for each page I gave up. Eight hours later I tried again, and both went through first time, and it took only a few seconds to save. Here they are: User:The Anome/Railway station list; Book:Stations Test. --Redrose64 (talk) 21:26, 7 March 2014 (UTC)[reply]
Now it's about the 6th straight evening partially wasted. Is any investigation proceeding? Chris the speller yack 01:37, 10 March 2014 (UTC)[reply]
I have been having these slowdowns again this evening, approximately 2200 EDT / 0200 GMT, in Washington, DC. I first above reported the problem on 4 March. I don't remember specifically whether it has been all seven evenings, but it has been close to that. I and other editors are reporting the problem on the US East Coast in the evening, on multiple evenings. Robert McClenon (talk) 02:06, 10 March 2014 (UTC)[reply]
FYI, I'm over on the East Coast, also near Philly, and these problems show up every single evening. Cloudchased (talk) 02:10, 10 March 2014 (UTC)[reply]
OP here. I'm in Boston. Very bad for me again last night (2014-03-09 20:15 EDT); fine this morning (2014-03-10 07:30 EDT). —Steve Summit (talk) 18:10, 10 March 2014 (UTC)[reply]
Very slow again for me tonight. It has been almost a week of problems. Real time changes is hanging up constantly as well. Almost impossible to counter vandalism with these problems. Donner60 (talk) 02:26, 11 March 2014 (UTC)[reply]
Slow again for me now (2230 EDT). My Reference Desk archiving bot (scsbot) is essentially useless.
See also this newer thread below. —Steve Summit (talk) 02:40, 11 March 2014 (UTC)[reply]
Me too. I'm wondering if it could be browser related? I use Firefox. Turned off a couple add-ons but that didn't seem to help. Carolmooredc (Talkie-Talkie) 00:36, 12 March 2014 (UTC)[reply]
I don't think it's browser-related. For me, the impact is greatest on my bot, which does not run in a browser at all. —Steve Summit (talk) 15:36, 12 March 2014 (UTC)[reply]
  • I have been having this problem for at least a week on two windows 7 laptops, one in NYC and one in NJ near Phila, using three different browsers, and not at all with other websites. The responses I got asking about this at the help desk a week ago were nothing, and at the computing ref desk today mocking from an IP sock in Europe and an established editor. The slowness ran tonight from about 630PM to 1130PM and in both cases I used a 'VERIZON DSL connection.μηδείς (talk) 05:41, 12 March 2014 (UTC)[reply]
I'm using Verizon DSL too. Haven't been on much last couple days so not sure how it's working now. Later: Take it back. It's still having periods of extreme slowness, especially on long pages. Carolmooredc (Talkie-Talkie) 22:46, 13 March 2014 (UTC)[reply]

Recurrent Server Problems, Evening on US East Coast

[this refers to this thread above]

We have regional consensus, then, that there is a problem with server performance every evening on the US East Coast. Is there a problem in the late afternoon on the US West Coast? Is there a problem in the small hours of the morning in the UK? Is there a problem in the morning in East Asia and Oceania? If so, then the problem is strictly time-dependent. If the problem is, as suggested, localized to the region and the time, then it does have something to do with load-balancing in the data centers. Robert McClenon (talk) 02:19, 10 March 2014 (UTC)[reply]

I have experienced similar issues in Texas. Not the US East Coast, but close enough that it could still be a regional issue. --Allen3 talk 01:44, 11 March 2014 (UTC)[reply]
I have had the same problems again this evening at about 2130 EDT / 0130 GMT in Washington, DC. That is, there has been a problem every evening for more than a week. As Allen3 says, it may be regional, if users in Texas are going through servers in Florida and users elsewhere are going through servers in California. Robert McClenon (talk) 01:54, 11 March 2014 (UTC)[reply]
I continue to have problems with slow loading and complete hangups on real time changes. It is very difficult to monitor and counter vandalism when this happens, not to mention discouraging. Donner60 (talk) 02:44, 11 March 2014 (UTC)[reply]
Another round of problems this evening. Interesting note is that I was having no problems editing at 23:56 but 10 to 15 minutes later it was taking 2 or 3 attempts to reload my watchlist and I was unable to load any of the talk pages I had just been working with. --Allen3 talk 00:47, 12 March 2014 (UTC)[reply]
Tonight was as bad as any during the last week, maybe even worse. Is anyone doing anything about this? If not, where do we go to get some action taken to correct it? Chris the speller yack 05:05, 12 March 2014 (UTC)[reply]
I agree. Very slow loading and complete hangups on real time changes. Seemed like some pages were not going to come up at all when diffs clicked on real time changes. Donner60 (talk) 05:16, 12 March 2014 (UTC)[reply]
Same in New York City, as discussed above in #server problems?. I've been watching more prime-time television instead. Jim.henderson (talk) 05:25, 12 March 2014 (UTC)[reply]
  • This has been going on for me in NYC and SJ area near Philly for a good ten days. See my questions at Help Desk which was ignored and at Computer Ref Desk which has been met with mockery. Occurs between 6p and Midnight, slowdowns to the point of total freeze but without crash on two windows 7 laptops whether I use Sfarai, IE, or Firefox. Suspect this may be a Verizon reaction to the recent net neutrality ruling. μηδείς (talk) 05:46, 12 March 2014 (UTC)[reply]
I'm almost certainly going through servers on the West Coast. I have not noticed any issue remotely as pervasive as the one described on any of the last several days. Other issues (e.g. Firefox crashing much more than normal for the last couple/few weeks), but not the ones described here, or the similar issues in the other thread(s?). I have experienced other slowdowns in the somewhat recent past, but those appeared to coincide with other issues reported here which were resolved.
Have any of you tried setting up a VPN to a site on the West Coast, or anywhere else, during the time you experience the problem on the East Coast. Or call a friend elsewhere who might try it at the same time you are experiencing the problem. Doing either of those could provide some useful information, particularly if you could have two machines up at once with one VPN'ed elsewhere and one routed normally. If one of you could set that up it would be able to 100% demonstrate the problem did not occur in X location while it was definitely happening at Y. Without something similar, we are all just guessing as to if any "I didn't see it" is actually at a time when the problem was being seen on the East Coast.
As we humans are, people rarely notice the times when things happen normally. Thus, it is difficult to say "Yes, I was actually trying to save a page, or look at my Watchlist, at exactly that time and had no problem." — Makyen (talk) 07:29, 12 March 2014 (UTC)[reply]
Well, user Medeis (μηδείς) may have something there with the Verizon angle. That's also my ISP. Is that true for all the folks who are seeing this problem? Chris the speller yack 14:18, 12 March 2014 (UTC)[reply]
Yes, it's on a Verizon DSL line that I observe the problem. I'll try the VPN experiment tonight. —Steve Summit (talk) 16:14, 12 March 2014 (UTC)[reply]
Setting up a VPN to an East Coast site would tell us (if it ran well) that it's not the region, but the ISP, right? Chris the speller yack 16:38, 12 March 2014 (UTC)[reply]
You are exactly right.
And... I just performed back-to-back tests, and I got terrible performance on the Verizon DSL connection and then, moments later, decent performance when I switched over to the VPN. I don't have time to post full details now, but it looks like Verizon just may be the problem. —Steve Summit (talk) 03:22, 13 March 2014 (UTC)[reply]
I am on Verizon FIOS (not DSL) and use Firefox. Problems are persistent, yesterday and today. I need to try IE but I suspect it will not differ. Donner60 (talk) 01:02, 14 March 2014 (UTC)[reply]
To answer a question that hasn't yet been asked, I am using Verizon DSL. I had the problems between about 1900 EDT and 2300 EDT on 11 March, 12 March, and 13 March again (that is, about 2300 GMT - 0300 GMT, 11-12, 12-13, and 13-14 March. Has anyone on the US East Coast who has the problem been using Comcast, or is it all Verizon? Robert McClenon (talk) 01:04, 15 March 2014 (UTC)[reply]
I had normal service and normal speeds earlier today, until about 2100 UTC. Now the pages open very slowly and won't fully load. It is looking like it is a Verizon issue. Verizon constantly puts up an ad about increasing internet speed (for an increased price, of course) when I activate my DVR. I suspect this could be another way of telling Wikipedia users, and perhaps users in general, that they might be better off paying for more service than they have needed to date than trying to get normal service in the evening/early night. Donner60 (talk) 02:13, 15 March 2014 (UTC)[reply]
Well, I am to the point where I think this needs to go on ITN and Wikimedia needs to take action. I am using Verizon now, and while today before 6PM EST in the US pages were loading almost instantaneously, as of 8PM EST they are taking 15 seconds at a minimum, if not just freezing up entirely. This is independent of browser, and only on WP and Wiktionary, no other sites. I feel like my own ISP is using stuxnet against me, and I pay the emm-effers outrageously for service 25X slower than their competitor's twice as expensive advertised rate. Can anyone point to an RS that would allow me to nominate this for an ITN listing on the front page? μηδείς (talk) 02:33, 15 March 2014 (UTC)[reply]
Have you called your ISP to let them know that you're having a problem? It's possible that they might not know about the problem, or might be able to tell you what's wrong. WhatamIdoing (talk) 04:12, 15 March 2014 (UTC)[reply]

I'm on Verizon in Central New Jersey and have been having the Wikipedia (Commons as well) slowness like others as well (including right now, 9:00 PM EDT). Last year, Verizon was throttling Youtube and I used the tricks in this blog post to block a range of IPs to get around their throttling. It generally worked though a couple of times Youtube was going just as slow as prior to the modification. Is there a similar IP address range for Wikipedia that can be blocked to get around this? —Mr. Matté (Talk/Contrib) 01:02, 17 March 2014 (UTC)[reply]

I see a lot of people reporting problems, but I don't see anyone confirming that Foundation staff has been informed in a proper way. If so many people are having such a problem, that might seem like a good idea. bugzilla. Since everyone is on east coast verizon apparently, it might be a peering issue. —TheDJ (talk • contribs) 01:49, 17 March 2014 (UTC)[reply]
I sent e-mail to ops over the weekend. Whatamidoing (WMF) (talk) 16:10, 17 March 2014 (UTC)[reply]
For what it's worth, I had an online chat with Verizon support tonight. They said that their techs had noticed the problem, and that I would not experience the problem tomorrow night, or ever again. Time will tell. I'll post tomorrow night how things are going around 9 to 10 p.m. Chris the speller yack 04:09, 17 March 2014 (UTC)[reply]
Thanks, Chris! (Worth a lot, I'd say.) I'll anxiously await tonight's developments. —Steve Summit (talk) 10:33, 17 March 2014 (UTC)[reply]
I add my thanks. Tonight is just about as bad as the past nights. I read Chris's post to mean the problem will be fixed by tomorrow night. We'll see. We also will see whether they just fix it for Chris or fix it in general. (I am not well informed enough to know whether than is possible.) Donner60 (talk) 01:38, 18 March 2014 (UTC)[reply]
Verizon did not fix the problem (as they promised), and they have been no help. Their techs only know how to monkey with the customer's computer. They want to mess with my wireless router's signal strength and take over my screen and keyboard. I told them "no way". I pinged Wikipedia, and it sent a 32-byte packet, and no packets got lost, so Verizon claims their network is fine. I can't get them to go to Wikipedia and retrieve a large page. I can't do much to help Wikipedia at this rate. Chris the speller yack 02:21, 18 March 2014 (UTC)[reply]
Still slow again for me tonight as well. I'll give it a try with Verizon Customer Support myself. —Steve Summit (talk) 03:20, 18 March 2014 (UTC)[reply]

I switched from Time Warner (100 over 50) to Verizon Fios (500 over 100) today (in NY), and when using Wikipedia and Commons it's much slower than the Time Warner service.-Godot13 (talk) 02:37, 18 March 2014 (UTC)[reply]

Hi folks, I'm Faidon from WMF's technical operations. Thanks for all of your reports and for identifying that Verizon is the common factor between all of you, this has been extremely helpful. The issues you're experiencing are most likely caused by network congestion, but our transit links with our ISPs are not congested, so it's likely something internal to the upstream ISP we use to reach Verizon (GTT, a tier-1 network) or something specific between Verizon and them. We've already mailed Verizon's NOC but we've had no reply so far. We were hoping that the promises made to their customers about the issue being fixed today would be true, but unfortunately apparently they didn't alleviate the issue.

I've just special-cased Verizon and redirected traffic to Verizon using another upstream ISP of ours (NTT America), so please do let us know if you're still experiencing problems today. We will continue the investigation and raise the issue with our upstream as well, in case there is something on their side. Thanks for your patience! Faidon Liambotis (WMF) (talk) 15:01, 18 March 2014 (UTC)[reply]

Thanks, Faidon, things seem much better tonight, for the first time in two weeks. Actually, I'm getting lightning-fast response. I give you credit for fixing it. I only wish we had started you working on it sooner. Many, many thanks! Chris the speller yack 01:38, 19 March 2014 (UTC)[reply]
I am getting good response now at approximately 2150 EDT. Thank you. Robert McClenon (talk) 01:52, 19 March 2014 (UTC)[reply]
I also have gotten good response for almost three hours now - for the first time in the evening and early night hours for about two weeks, as well. Thanks to Faidon Liambotis (WMF) as well as to Chris and Steve for their help in working this out. Donner60 (talk) 03:59, 19 March 2014 (UTC)[reply]
I also got better performance last night. Can't say whether it was back to normal or not, but definitely much better. Thanks, Faidon. —Steve Summit (talk) 14:00, 19 March 2014 (UTC)[reply]

Running network diagnostics

Although it may seem like it's just Wikipedia that's slow, due to the network structure that ISPs use, it can still sometimes be a wider problem caused by a failure on the ISP's end. In order to help the engineers in ops determine where the problem is, it would be helpful if people who are experiencing this slowness could perform a network diagnostic using something like traceroute to the English Wikipedia and save the results to a text file.

Instructions:

  • On Unix-like systems, such as Mac OS X and Linux, run traceroute en.wikipedia.org.
  • On Windows open a command prompt and type in tracert en.wikipedia.org. If you're on Windows, you could also run PathPing by typing pathping en.wikipedia.org which provides more detailed results.

Be patient when running these commands, as they can sometimes take a long time to execute. Save the entire result of whichever command you run to a text file. You could run these commands when you're not having the problems as well, to act as a control. The people in ops should greatly appreciate having this information.

Disclaimer: I'm not in ops, I'm just a person who's had to diagnose these sorts of problems before.

--Dan Garry, Wikimedia Foundation (talk) 17:49, 17 March 2014 (UTC)[reply]

Need to fix double redirect bots

FYI, the double redirect bots are working extremely slowly today. --Jax 0677 (talk) 00:35, 15 March 2014 (UTC)[reply]

Sinhala script size and Template:Lang

Has anyone else noticed that recently the Sinhala script has started to appear much larger than other scripts when used with Template:Lang and Template:Lang-si? It's OK when the template isn't used.

Sinhala English
Template:Lang ශ්‍රී ලංකාව Sri Lanka
Template:Lang-si Sinhala: ශ්‍රී ලංකාව Sinhala: Sri Lanka
Template:Lang-en English: ශ්‍රී ලංකාව English: Sri Lanka
Without template ශ්‍රී ලංකාව Sri Lanka

I've tried it with three different browsers (Firefox, Chrome and Safari) and they all show Sinhala script to be larger when the templates are used.--obi2canibetalk contr 20:42, 15 March 2014 (UTC)[reply]

It may be the fonts that you have installed on your computer. What I see above are four groups (split 4 & 5) of boxes containing hex codes like 0DC1 0DCA 0DBB 0DD3 etc. which means that I don't have a suitable font. --Redrose64 (talk) 20:48, 15 March 2014 (UTC)[reply]
I don't think it's the fonts on my computer because it looks OK without the template. And this is recent phenomena, I've had my computer for three years.--obi2canibetalk contr 21:03, 15 March 2014 (UTC)[reply]
For the first two rows, {{lang}} and {{lang-si}} have the same effect on your examples: they enclose the text in the HTML markup <span xml:lang="si" lang="si">ශ්‍රී ලංකාව</span>. On the third row, {{lang-en}} doesn't actually do anything, the rendered HTML is just the same as the row "Without template". What this suggests is that there is some special processing being done for <span xml:lang="si" lang="si"> --Redrose64 (talk) 21:18, 15 March 2014 (UTC)[reply]
I seem to recall UniversalLanguageSelector can do special processing based on lang attributes. This might depend on whether its web fonts option has been turned on. – PartTimeGnome (talk | contribs) 20:34, 16 March 2014 (UTC)[reply]
What you posted in the box above is all the same size for me. Whatamidoing (WMF) (talk) 16:12, 17 March 2014 (UTC)[reply]

Search box behavior changed

For it seems like at least two weeks, I no longer have the choice between "Search" and "Go" in the search box in the upper right hand corner.  I thought this might be discussed on this page, but I see nothing.  When I automatically display images, there is now a shape that looks like a "Q" on the right edge of the search box, possibly intended as a symbol for a magnifying glass.  A mouse hover over the box displays, "Search Wikipedia [f]".  My main question is how do I go directly to a Wikipedia page when I know the title?  I'm finding that in some cases, it is easier to open Google and search from there.  Unscintillating (talk) 22:20, 15 March 2014 (UTC)[reply]

I think it only happens if you don't have JavaScript. There is a previous discussion at Wikipedia:Village pump (technical)/Archive 124#Searchbox is broken & Search is overloaded. I wrote: "I also think there should be a Go option somewhere users can find. Here is one they wouldn't find but you can bookmark it: https://en.wikipedia.org/wiki/Wikipedia:Your_first_article#Title_for_your_new_article." PrimeHunter (talk) 22:46, 15 March 2014 (UTC)[reply]
  • Toggling Javascript doesn't seem to change anything.  I never have the option of "Go", except that you have now shown me a bookmark that has the feature.  I don't know if this helps, but when the problem first started, I still had both the "Go" and the "Search" buttons, but the buttons had been swapped.  I use Firefox 2.0.0.20, if that is a factor.  Unscintillating (talk) 00:10, 16 March 2014 (UTC)[reply]
Do you mean you had buttons labelled "Go" and "Search" at the top right? I only know those buttons from other skins but there they are to the left for me: https://en.wikipedia.org/wiki/Example?useskin=monobook, https://en.wikipedia.org/wiki/Example?useskin=modern, https://en.wikipedia.org/wiki/Example?useskin=cologneblue. Have you changed skin at Special:Preferences#mw-prefsection-rendering? The default Vector skin has the magnifying glass icon and no labelled buttons. PrimeHunter (talk) 00:29, 16 March 2014 (UTC)[reply]
I didn't pay much attention to the "Go" and "Search" buttons, but I'm pretty sure that they were where the magnifying glass is now, which is at the right margin of the display window.  I checked to be sure, but I only use Vector skin and have never changed it.  I clicked on the checkbox, "Widen the search box in the Vector skin.", but after I saved my preferences, nothing changed.  I normally run with Javascript disabled, turning it on as needed.  Unscintillating (talk) 01:09, 16 March 2014 (UTC)[reply]
Have you tried to first enable JavaScript and then completely clear the cache? Firefox 2.0.0.20 is from 2008. Maybe it's not compatible with the search changes made a month ago. But if you prefer to use Wikipedia without JavaScript then I don't know whether there is a way for anyone to get Go functionality in Vector, other than visiting a page with a Go button like Wikipedia:Your first article#Title for your new article or below (that code could be copied to your user page for easier access). PrimeHunter (talk) 11:01, 16 March 2014 (UTC)[reply]

 

@Unscintillating: What skin are you currently using? Have you changed your skin any time in the past two months? What is your browser and operating system? This should help us diagnose the problem. --Dan Garry, Wikimedia Foundation (talk) 18:13, 17 March 2014 (UTC)[reply]

Most of the questions you've asked the answers appear above.  I use Windows 98.  As for the Javascript potential change, my biggest problem is that the behavior with Javascript off has changed, in that I no longer have a "Go" functionality.  I've not seen anything change from toggling Javascript, although I have not tested turning Javascript on and then rebooting.  Also, toggling Javascript before the problem started, did not affect the Go button.  Unscintillating (talk) 23:05, 17 March 2014 (UTC)[reply]
Yes. As I mentioned, this patch changed the behaviour of the search box when Javascript is disabled. The patch was not actually written by a person at the Wikimedia Foundation, so I know as much about it as you do. You may have more luck speaking to MatmaRex, the developer who wrote the patch. --Dan Garry, Wikimedia Foundation (talk) 23:32, 17 March 2014 (UTC)[reply]
I think I should clarify that it is not a key point that the functionality of the search box has changed from "Go" to "Search".  If I still had both the "Go" and the "Search" buttons, I could and would adapt.  Unscintillating (talk) 17:57, 22 March 2014 (UTC)[reply]

Problems with citation template

The last few times I've tried to add a reference using the Citation template I have finished filling out the boxes and when I go to Add Citation it refreshes as if its been added but when it returns to the edit text screen the citation is not there and what I'd added has been lost. I edit using iPad and when I originally started editing with this I recalled I needed some help to get citation to work in the first place. Hope someone can assist. Eldumpo (talk) 07:47, 16 March 2014 (UTC)[reply]

Wikipedia:Village pump (technical)/Archive 124#Strangeness in the Add citation thingy may be related. --Redrose64 (talk) 07:56, 16 March 2014 (UTC)[reply]
  • Eldumpo, Redrose64, in that thread The Bushranger hit the nail on the head: after filling out the template you need to move back to the editing screen and click to move your cursor to the main text where you want to insert the citation. (I just lost another one cause I forgot.) It's totally infuriating, but that's what it is. Drmies (talk) 14:25, 21 March 2014 (UTC)[reply]

My virus program detected malware at one of Wikipedia's tools

I was checking the links on WP:Tools, and came across http://www.keybreeze.com/lettercommands.htm. I have McAfee Internet Security Suite, which blocked it as a malware site and marked it "red".

I wanted a couple more tests, so I checked virustotal and submitted the website to Anubis (Anubis.iseclab.org/). Virustotal said it was "suspicious" but inconclusive; Anubis (I think) confirms my suspicion.

I want to remove it, just to be safe. All it did was give hotkeys, anyway, which accesskeys and various other Internet programs can replace.

This may sound like a dumb question, but: will anybody be dumb enough to re-instate the link (assuming it wasn't a false positive report)—a WP:RANDY editor perhaps? I can never really tell. Meteor sandwich yum (talk) 22:43, 16 March 2014 (UTC)[reply]

Neither VirusTotal nor Anubis says it's suspicious. I'm pretty sure McAfee just had a false positive (that's common with hotkey programs). I don't think there's anything unsafe about it. Jackmcbarn (talk) 22:51, 16 March 2014 (UTC)[reply]
Yeah, I guess I'll re-instate it. Meteor sandwich yum (talk) 06:54, 19 March 2014 (UTC)[reply]

Open source code for 'read only'. By option?

Is it possible to open a page for read only, by option? More specific: I have TE right (no admin right). When developing code I work in a template /sandbox. To prevent accidental edit saving the (protected) live template code, I'd like to open that one in 'read only' mode by choice, maybe in an url link. Possible? -DePiep (talk) 09:54, 17 March 2014 (UTC)[reply]

There's probably a user script for that floating around somewhere, but there's no option built in to MediaWiki to do it. Jackmcbarn (talk) 11:50, 17 March 2014 (UTC)[reply]
The preference setting "Prompt me when entering a blank edit summary" (on the "Editing" tab) can act as a defensive against accidental edits. -- John of Reading (talk) 12:25, 17 March 2014 (UTC)[reply]
I started using User:Anomie/nosubmitsummary.js a few weeks ago. It stops you from being able to submit an edit by hitting "enter" in the edit summary window, and I've found it helps to prevent accidental edits. Another option (in Firefox, at least) is to right-click on the edit link and click "Open Link in New Private Window", which will make that window act as if you are logged out. — Mr. Stradivarius ♪ talk ♪ 12:33, 17 March 2014 (UTC)[reply]
One thing that you could do is to hide the "Save page" button. 
input#wpSave { display: none; }
in Special:MyPage/common.css will do it. In combination with User:Anomie/nosubmitsummary.js, this means that to save a page when you really want to, you need to use the appropriate keyboard shortcut - Alt+⇧ Shift+S in Firefox; ⇧ Shift+EscS in Opera; etc. --Redrose64 (talk) 17:31, 17 March 2014 (UTC)[reply]
Thanks all. Useful options. -19:46, 18 March 2014 (UTC) — Preceding unsigned comment added by DePiep (talk • contribs)

"protect" what

Tracked in Phabricator
Task T64722

Today, I was researching some of the ArbCom disputes when I saw a log entry from Phoenix7777 (talk · contribs) (see log entries) showing simply the word "protect" without reference to any target article. For reference the first instance was I believed targeted to the Senkaku Islands dispute, see Senkaku Islands log for this. I notice also that the page was previously fully protected from moves due to the warring happening there, and that Phoenix is not a sysop so he has no ability commit any sort of logged administrative actions.

  1. How many other editors have experienced this?
  2. Is this a bug and should I file a bugzilla ticket for it?

TeleComNasSprVen (talk • contribs) 10:07, 17 March 2014 (UTC)[reply]

Actually did a little more digging and I believe the culprit is AFTv5, as shown in this diff which has the same timestamp as the "protect" log entry. TeleComNasSprVen (talk • contribs) 10:13, 17 March 2014 (UTC)[reply]
All of the AFT5 log entries look odd now that AFT5 has been removed. Jackmcbarn (talk) 11:54, 17 March 2014 (UTC)[reply]
The html for the log entry says:
<li class="mw-logline-articlefeedbackv5"><input name="ids[54663738]" type="checkbox" value="1" /> 11:47, 6 February 2014 <a href="/wiki/User:Phoenix7777" title="User:Phoenix7777" class="mw-userlink">Phoenix7777</a> <span class="mw-usertoollinks">(<a href="/wiki/User_talk:Phoenix7777" title="User talk:Phoenix7777">talk</a> | <a href="/wiki/Special:Contributions/Phoenix7777" title="Special:Contributions/Phoenix7777">contribs</a> | <a href="/wiki/Special:Block/Phoenix7777" title="Special:Block/Phoenix7777">block</a>)</span> protect </li>
I suppose we could do something with mw-logline-articlefeedbackv5 but I'm not sure it's worth it. The article is not revealed. ids[54663738] is an id for the log entry. PrimeHunter (talk) 12:31, 17 March 2014 (UTC)[reply]

I'm alerting Fabrice Florin, the product manager who handled the Article Feedback tool and its recent removal from this wiki, to this issue. --Dan Garry, Wikimedia Foundation (talk) 18:57, 17 March 2014 (UTC)[reply]

Autofixing cite URLs with bar/pipe

I have expanded the autofixing of Lua wp:CS1 cite templates to begin rebuilding a URL which contains a vertical bar/pipe "|" and was parsed as an extra parameter at the bar. Does anyone know of common source websites which tend to have internal bars "|" in the URL? (it already handles "nl.newsbank.com") For multiple bars, there is the danger that Lua script could get the portions parsed in reverse order, unsure which portion to append into the URL first. I have an essay discussion at:

Reply either here or in that essay talk-page, as preferred. No hurry. Thanks. -Wikid77 12:22, 17 March 2014 (UTC)[reply]

I found a common case for bar/pipe in a URL is using Google Translate in a typical web link to translate a non-English source webpage, where "&langpair=it|en" will contain a bar/pipe between the 2 language codes, such as with "it|en" for Italian-to-English. -Wikid77 15:39, 21 March 2014 (UTC)[reply]

Category listing delay?

Recently I created {{old talk on redirect}}, which populates Category:Talk pages of pages converted to redirects. Except, when you look there, it doesn't. But if you look at pages where it's used (e.g. Wikipedia talk:De-adminship), the category does appear. Is this due to some delay in category listings being updated? — Scott • talk 12:24, 17 March 2014 (UTC)[reply]

Yes, it's a known delay for categories depending on changes in transcluded templates. A null edit of Wikipedia talk:De-adminship would force the category page to be updated with the page, but only with that page. PrimeHunter (talk) 12:36, 17 March 2014 (UTC)[reply]
Where a template is used to categorise pages, amending that template will not immediately recategorise all the pages that transclude that template, but instead it will create a job queue request. Until about nine months ago such template amendments would be processed in an hour or two; since then it's been much slower, and may take up to two weeks before all pages are properly recategorised. --Redrose64 (talk) 17:17, 17 March 2014 (UTC)[reply]

lolwut, edit from 8.8.8.8

Can someone explain this? It's an edit purporting to be from IP address 8.8.8.8, which is a Google public DNS server address, advising someone on a technical aspect of Wikipedia editing. Most explanations I can think of aren't persuasive. Maybe I'm missing something. 70.36.142.114 (talk) 14:33, 17 March 2014 (UTC)[reply]

That is indeed strange. No edits from 8.8.4.4, 2001:4860:4860::8888, 2001:4860:4860::8884, or even 4.2.2.2. I cannot think of any reasonable explanation. πr2 (t • c) 16:24, 17 March 2014 (UTC)[reply]
There are a few things. A mess up in the setup of ulsfo datacenter (last year we had entries under 10.something with eqiad center if i remember correctly), or something with XFF. But its so long ago, that ops doesn't really think they can still figure it out anymore. —TheDJ (talk • contribs) 23:19, 17 March 2014 (UTC)[reply]

Broken template somewhere, help?

Taking a look at Category:Pages with missing references list (usually populated by 20-100 mostly-article pages, now at 6k+ mostly-not-article ones), it's obvious that some kind of widely-transcluded something (template? module?) has been broken recently, resulting in ref errors being thrown at thousands of Portal- and Wikipedia-space pages. I've had no luck tracking down the broken transclusion with my usual methods; can I get some more eyes trying to figure out what happened? A fluffernutter is a sandwich! (talk) 15:37, 17 March 2014 (UTC)[reply]

Discussion at Help talk:Cite errors#Categorisation of reference errors. (this is also the talk page for the category) --  Gadget850 talk 15:56, 17 March 2014 (UTC)[reply]
That seems to be discussing labels used to categorize the errors for different namespaces, but doesn't address why 6000 pages are suddenly and (relatively? I've been away for the better part of a month) newly broken. Did some code somewhere change in a way that no longer works with reflists or something? A fluffernutter is a sandwich! (talk) 16:12, 17 March 2014 (UTC)[reply]
  • My understanding of the situation is this, those pages have had broken refs for quite some time but were exempt from being categorized for whatever reason. That exemption was decided to have been a bad idea and they are now categorized. Since there are so many of them however, I'm wondering if there is a better way to deal with them? They should not be all dumped in one big polluted category. — {{U|Technical 13}} (t • e • c) 16:24, 17 March 2014 (UTC)[reply]
  • Well, if they're genuinely pages with broken refs (as opposed to pages that ended up there because a template that the pages used is the page that's broken, which is what I had been assuming), it's not unreasonable for them to be in the category. It's a big backlog, but I and the handful of other people (and the bot - we still have a bot, I think) who work the category can chip away at adding reflists, the same as we usually do with articles. It's no more optimal for archives, drafts, and project pages to be throwing refs than it is for articles to be - we archive pages because we expect they might be of some reference use some day, and they're less useful when they're not displaying refs properly. And since the category is sorted by namespace, with "article" on top, we can still easily give articlespace the priority. A fluffernutter is a sandwich! (talk) 16:36, 17 March 2014 (UTC)[reply]
Portal pages don't normally include references - check out the featured portals linked from the top right of the Main page. So rather than adding reflists to portal pages, it would be better to remove the references. -- John of Reading (talk) 16:52, 17 March 2014 (UTC)[reply]
  • @Fluffernutter: I agree that they should be categorized, just not that they should all be dumped in one big category. I would think it better to create sub-cats per namespace.
@John of Reading: remove or convert from references using tags to hard coded references? I would prefer see them as hardcoded in most cases I think. — {{U|Technical 13}} (t • e • c) 17:09, 17 March 2014 (UTC)[reply]
@Technical 13: Remove. As on the Main page, readers should be able to verify the information by following the "Read more" link, or similar, from the portal page into the main encyclopedia. -- John of Reading (talk) 17:29, 17 March 2014 (UTC)[reply]
@John of Reading: (edit conflict) Yeah, it looks like the portal pages are generally angry because they include transcluded templates/blurbs that use references. I'm not particularly up on portal guidelines - is it considered optimal to have portal frontpages just not use refs at all? The other option would be to consider using local or template reflists to display what were apparently intended, way back when, to be displayed references. A fluffernutter is a sandwich! (talk) 17:30, 17 March 2014 (UTC)[reply]

cite doi automatic completion broken?

I created an article (Laricobius osakensis) with a couple of cite doi templates. Usually there is a delay in the bot filling in the citation. But it has been many hours and when I click on "jump the queue" I am taken to an error page. Is this a known problem? Abductive (reasoning) 17:01, 17 March 2014 (UTC)[reply]

I get the same errors. It was working yesterday. Smith609 is the operator of this bot and might know more. – Jonesey95 (talk) 20:26, 17 March 2014 (UTC)[reply]
This may be a broader problem. It recently was moved to http://tools.wmflabs.org/citations but that page, like many others on that server, now returns a 404 error. LeadSongDog come howl! 17:14, 18 March 2014 (UTC)[reply]
That it because you forgot the ending /. Then it gives a 503. I'm guessing this is due to the recent eqiad and lighttpd migration. *checks toollabs:?status tools-webgrid-01* Yep, there is no lighttpd-citations job. This means the maintainer (Mattsenate) should ssh to tools-login-eqiad, become his tool account, and run `webservice start' (assuming eqiad migration is already completed correctly; see eqiad migration). I had the same problem with my account. Feel free to go to #wikimedia-labs connect if you have any questions. Regards, πr2 (t • c) 17:43, 18 March 2014 (UTC)[reply]
Thank you. Will give the op a heads-up. |||| — Preceding unsigned comment added by LeadSongDog (talk • contribs) 18:08, 18 March 2014 (UTC)[reply]

How to search edit summaries?

Is there a way to search the text of edit summaries, either (1) within a single article or (2) across all Wikipedia articles?

If there isn't, can such a function be added? Dezastru (talk) 21:57, 17 March 2014 (UTC)[reply]

There used to be a tool, but it seems it's unmaintained atm and not working —TheDJ (talk • contribs) 22:34, 17 March 2014 (UTC)[reply]
This one seems to work, http://toolserver.org/~snottywong/commentsearch.html GB fan 22:51, 17 March 2014 (UTC)[reply]
Note that that tool looks for edits under one user, and there's no option to restrict it to a single article. You can do that manually, by picking the history tab for an article, listing as many edits as possible (500 limit), and using Control F to search. If there are more than 500 edits you will need to step through them 500 at a time and repeat the search each time (although most of the time I find what I want in the most recent 500 edits). StuRat (talk) 23:01, 17 March 2014 (UTC)[reply]
The tool by Sigma (found at the bottom of a contribs page as Edit summary search) is maintained - I know because I occasionally file bugs which later get fixed, see e.g. User talk:Σ/Archive/2013/December#summary.py is broken or User talk:Σ/Archive/2014/March#summary.py doesn't find all edits. It was working a few days ago, so we should assume that it's just temporarily down. Oh, and the limit for page history is 5000, not 500 - see my comment at #Block log searching. --Redrose64 (talk) 23:35, 17 March 2014 (UTC)[reply]
I'm guessing this is due to the recent eqiad migration. *checks toollabs:?status tools-webgrid-01* Yep, there is no lighttpd-sigma job. This means Sigma should ssh to tools-login-eqiad, become his tool account, and run `webservice start'. I had the same problem with my account. πr2 (t • c) 16:52, 18 March 2014 (UTC)[reply]
In browsers on Windows and Linux-based computers, the typical shortcut key for find-in-page is Ctrl+F. Also, rather than stepping through edits 500 at a time, you can edit the URL to add &limit=5000, which displays up to 5000 history entries on a single page. There are very few pages with more revisions than this, so stepping to a second page would be rare with 5000-per-page. – PartTimeGnome (talk | contribs) 23:39, 17 March 2014 (UTC)[reply]
  • Unless you are looking through the contributions of a specific user, in which case there can be pages upon pages (I have just over 20K edits myself) of results even at 5000 a pop. Also, I've noticed that some history pages still only show 500 results even if &limit=5000 is specified. I don't remember the details, but it is stupid annoying. — {{U|Technical 13}} (t • e • c) 01:21, 18 March 2014 (UTC)[reply]
Well, I was only referring to page histories rather than user contribs. I'm not sure why limit=5000 doesn't always work. There might be something else that can restrict the number of revisions shown. – PartTimeGnome (talk | contribs) 21:40, 18 March 2014 (UTC)[reply]

Thanks for the replies, everyone. I'll keep an eye on the page for that tool from Sigma, in particular, to see when it's running again. Dezastru (talk) 02:51, 18 March 2014 (UTC)[reply]

When a link in a citation has been cyber-squatted, how should we deal with it? It would be best to stop it being clickable, in case it now hosts porn, malware or other undesirable content. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:23, 18 March 2014 (UTC)[reply]

A specific example would help. Can you recover it via archive? Can you find an alternative source? Does it need to be linked— other than a web only source, a link is a convenience. --  Gadget850 talk 14:28, 18 March 2014 (UTC)[reply]
Well, the question was general, so the solution for a specific example might not suit all cases; I was thinking of writng a page odf guidance, if none already exists. That said, the example that sparked my interest is walkofstars-co-uk, in various citations on Birmingham Walk of Stars. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:17, 18 March 2014 (UTC)[reply]
Both WP:DEADREF and WP:EL have a little information that might be useful to you. WhatamIdoing (talk) 17:22, 18 March 2014 (UTC)[reply]
I have added the following table of bookmarklets to WP:DEADREF. I created these bookmarklets to make it easier and faster to find archives of a page which is no longer available (for whatever reason). All of these land on a page from which you can select different archive dates for the page, if multiple archives of the page exist. Doing so permits selecting an archive version that is as close as possible to the version of the page cited on |accessdate=. The WebCite and archive.is bookmarklets have only been minimally tested as I usually only have to check archive.org.
Bookmarklets to check common archive sites for archives of the current page
(all open in a new tab or window)
Archive site Bookmarklet
Archive.org javascript:void(window.open('https://web.archive.org/web/*/'+location.href))
WebCite javascript:void(window.open('http://www.webcitation.org/query.php?url='+location.href))
Mementos interface javascript:void(window.open('http://www.webarchive.org.uk/mementos/search/'+encodeURIComponent(location.href)+'?referrer='+encodeURIComponent(document.referrer)))
Archive.is javascript:void(window.open('http://www.archive.is/search/?q='+location.href))
— Makyen (talk) 21:32, 18 March 2014 (UTC) removed archive.is per WP:Archive.is RFC — Makyen (talk) 05:55, 19 March 2014 (UTC); restored archive.is, but struck-out — Makyen (talk) 10:05, 19 March 2014 (UTC); added Mementos interface to table — Makyen (talk) 11:17, 20 March 2014 (UTC)[reply]
Makyen: Thanks for adding that.
It looks like the site is now http://www.broadstreetbirmingham.com/broad-street-business-improvement-district/walk-of-stars/. I did not do a deep search to see if the pages in question are still available.
I did find an archive for the second citation at http://archive.is/CqQaw, but it was by Googling, as searching Archive.is did not return it.
And my initial advice stands. --  Gadget850 talk 23:16, 18 March 2014 (UTC)[reply]
@Makyen: I've removed the archive.is entry from the table you added. Per WP:Archive.is RFC, no links to archive.is should be used on Wikipedia. Jackmcbarn (talk) 00:07, 19 March 2014 (UTC)[reply]
@Jackmcbarn: Thank you for the pointer to WP:Archive.is RFC. I have removed the bookmarklet from my post above and the other page on which I placed it (in addition to the one you removed). I also removed an associated bookmarklet to create an archive instead of search for one (as with the above it was a set of three with archive.org and WebCite). Obviously, this is the first I have heard about this issue. Fortunately from my point of view, my use of archive.is has been decidedly tertiary with archive.org and WebCite being far more prominent. The only times I recall having used archive.is is when a needed archive has not been available at either of the other two.
So far, I have only read the closure and actual RfC, then skimmed parts of the responses. The behavior described is strange from someone purporting to be the owner of archive.is. More importantly, the RfC closure leaves enwiki in a strange situation where editors, such as myself, will unknowingly add links to archive.is which may be the only, or just easiest, place to find an archive of a particular page. I'm still reading through all the associated links. A pseudo-ban is not the appropriate place to leave the situation. However, this is not the proper place to open discussion as to where it should go from here. — Makyen (talk) 05:55, 19 March 2014 (UTC)[reply]
Just FYI: I had earlier amended my signature (above) attached to the original post of the table with bookmarklets. In doing so, I appended an additional timestamp using 5 tildes, as is the recommended guideline at WP:REDACT. If it should have a full signature, I am happy to use one in such an instance. I don't care either way. If a full signature should be used, then the guideline should be changed.
In retrospect, I should have used <del>...</del> on the line instead of completely removing it. I have restored the line, but left it struck-out. Chalk the deletion up to being a bit over-zealous about rectifying my non-compliance with an RfC about which I was previously unaware. However, for talk page continuity, it should remain. — Makyen (talk) 10:05, 19 March 2014 (UTC)[reply]
For what it's worth, I was the one who changed your signature from five tildes to four because I thought it was a mistake; I didn't know about that guideline. Thanks for letting me know; I'll keep it in mind in the future. Graham87 06:04, 20 March 2014 (UTC)[reply]
@Graham87: Absolutely not a problem. I appreciate it when someone fixes a signature of mine. I just thought I had misunderstood what I should be doing in such situations.
I have just found out about the Momentos interface. It looks like it will be useful, but the webpage interface has the limitation that it strips the query string from the URL for which you are attempting to find archives. This appears to be because the manual entry does not encode any of the URL special characters. While this is fine for many URLs, it significantly limits the pages for which archives can be searched for using their manual interface. When using manual entry on their webpage, simply changing the "?" to "%3F" in your search-for URL will be sufficient for it to work most, but not all, of the time.
I have updated the table (above) to include a bookmarklet for the Monentos interface. The bookmarklet properly encodes the URL such that the Mementos interface will function with more complex URLs. The bookmarklet is based on the one provided on their page. However, it does not use the deprecated "escape" function and opens in a new tab/window. — Makyen (talk) 11:17, 20 March 2014 (UTC)[reply]

Revision history, Edits by user is 503

A very useful tool Edits by user at the top of every articles' Revision history is currently Missing In Action. When will this tool be available again? It was formerly found on the 4th line from the top of Revision history, for example, at https://en.wikipedia.org/w/index.php?title=Talk:Sense_and_reference&action=history, the fourth external tool link, when counted from the left. Instead of the tool, you get The URI you have requested, http://tools.wmflabs.org/?503, is not currently serviced. --Ancheta Wis   (talk | contribs) 20:24, 19 March 2014 (UTC)[reply]

Scottywong needs to ssh to tools-login (now eqiad), become his tool account, and then run `webservice start' and start any other jobs which may have been lost. Feel free to hop into #wikimedia-labs connect if you have any questions. πr2 (t • c) 23:43, 19 March 2014 (UTC)[reply]
Just did that, and it didn't make a difference. Is it naive to believe that once you get your code working on Labs, it will continue working indefinitely if you don't touch it? If not, then I might need to transfer ownership of some of these tools, because I don't check on them routinely. ‑Scottywong| yak _ 23:49, 19 March 2014 (UTC)[reply]
Scottywong, Thank you for taking ownership of that tool. Now I get another kind of message: No web service. ... If you maintain this tool, You have not enabled a web service for your tool, or it has stopped working because of a fatal error. You may wish to check your logs or common causes for errors in the help documentation. --Ancheta Wis   (talk | contribs) 00:15, 20 March 2014 (UTC)[reply]
For what it's worth, and I am not trying to be troublesome, here is the status of the External tools on the Talk page:
  1. Revision history statistics · not working. it is hung
  2. Revision history search · working DE wiki
  3. Contributors · working toolserver.org
  4. Edits by user · MIA
  5. Number of watchers · working info#mw-pageinfo-watchers
  6. Page view statistics - working SE wiki
Perhaps it may be worthwhile for me to ask advice?? The other External tools appear to have different servers. --Ancheta Wis   (talk | contribs) 03:11, 20 March 2014 (UTC)[reply]
Scottywong: the webservice has not started (cf. toollabs:?status, search for "lighttpd-usersearch"). Are you sure you ran "become usersearch" before running "webservice start"? πr2 (t • c) 00:23, 20 March 2014 (UTC)[reply]
It started but failed. Hedonil says (verbatim) you should create a .lighttpd.conf file and add debug.log-request-handling = "enable" for a more verbose error log. Docs: wikitech:Nova_Resource:Tools/Help/NewWeb. πr2 (t • c) 00:41, 20 March 2014 (UTC)[reply]

Ugh. I don't have time to figure this crap out right now. I definitely did a "become usersearch" before running "webservice start". I have a feeling I'm going to go through the trouble of creating a .lighttpd.conf file (whatever the hell that is) and add debug.log-request-handling = "enable" (whatever the hell that is), and the result is that I'm going to get an archaic error log that doesn't tell me anything.

The tools have worked for months and I haven't made any changes to them whatsoever, I haven't even logged in to the Labs server for months. If someone wants to take over these tools, just say the word and they're yours. And tell me how to give you access to them. They're all written in Python. User:Σ has taken over some of my other tools, maybe he'll be interested in taking over more. It may be a week or longer before I have time to figure out why they're not working. The whole Tool Labs thing is way too complicated, obtuse, and poorly documented. ‑Scottywong| chatter _ 04:41, 20 March 2014 (UTC)[reply]

I don't object to annexing these tools into my account, but there is always the option of adding a few Pythoneers as maintainers. This is one of the main features of Labs that sets it apart from Toolserver.
On a side note, I just figured out how to set up the bare minimum to make them work under the new configuration. You can steal the conf file from /data/project/sigma/.lighttpd.conf and change the path to the Python interpreter. →Σσς. (Sigma) 07:25, 20 March 2014 (UTC)[reply]

Please accept my apologies for the trouble, Scottywong. While necessary, I am aware that the requirement to migrate from one datacenter to another did cause work and some inconvenience to volunteers. That said, I recommend strongly that you (and all Labs users) subscribe to the labs-l mailing list where advance warning and instructions are posted for any upcoming change; this way you'll get enough advance notice to schedule any intervention on your own schedule.

For the immediate issue, would you like me to add Sigma (or anyone else) as a maintainer to your tool if you don't have the opportunity to do so yourself? — MPelletier (WMF) (talk) 13:41, 20 March 2014 (UTC)[reply]

Sure, please add Sigma to all of my tools, thanks. If there are any other interested "Pythoneers", let me know. ‑Scottywong| prattle _ 13:52, 20 March 2014 (UTC)[reply]
 Done, I've added Σ. — MPelletier (WMF) (talk) 14:10, 20 March 2014 (UTC)[reply]

What happened to Duplication Detector at Labs?

Duplication Detector on Labs is vital to reviewing nominations at Did you know. It's link is on every template of every nomination. As of yesterday, I began getting a message that "No webservice. The URI you have requested, http://tools.wmflabs.org/dupdet/, is not currently serviced." It has been maintained by Dcoetzee who has not edited since Feb 2, 2014. Anybody know what is going on? — Maile (talk) 17:49, 20 March 2014 (UTC)[reply]

See any of several sections above re the need to restart services on wmflabs. You might pop him a wiki-email. LeadSongDog come howl! 21:36, 20 March 2014 (UTC)[reply]
In the meantime you can use the version on Toolserver: http://toolserver.org/~dcoetzee/duplicationdetector/ -- Diannaa (talk) 21:38, 20 March 2014 (UTC)[reply]
  • Actually, earwig's copyvios tool is incapable of checking an article against an actual source, so it's effectively useless for DYK purposes. Good to know that the duplication detector is still available on toolserver. Thanks, Diannaa. BlueMoonset (talk) 12:51, 21 March 2014 (UTC)[reply]

G7 not working anywhere in usertalkspace?

Look at User talk:Robertgreer/to do/dance2 as of this edit. Why does the template throw up the big warning? Did we want it to do this for every page in user talk space? Unlike a primary talk page (e.g. User talk:Robertgreer), this is simply the talk page for a userspace page, so it can be deleted like any other page. Nyttend (talk) 21:25, 20 March 2014 (UTC)[reply]

It's been a requirement for several years (specifically, since 20 July 2008‎) that {{db-author}} requires a |rationale= parameter when used on user talk pages. --Redrose64 (talk) 22:02, 20 March 2014 (UTC)[reply]
On primary talk pages, yes, but this is a subpage; why isn't it treated differently? I understand that someone might try sneakily to get a talk archive deleted this way, but one could simply move a talk archive to User: space and get it deleted easily. Nyttend (talk) 22:55, 20 March 2014 (UTC)[reply]
That is a question to raise at WT:CSD (perhaps WP:VPP), not here - it's not a technical matter but a policy matter. --Redrose64 (talk) 23:35, 20 March 2014 (UTC)[reply]
The user did try to give a reason but wrote {{db-author|1=cleanup}} instead of {{db-author|rationale=cleanup}} which would have avoided the warning. I have updated [1] the template to point to the right section Wikipedia:User pages#Deletion of user talk pages which I think allows deletion here considering it isn't the main user talk page or an archive of it, and the talk page has no purpose now. PrimeHunter (talk) 11:55, 21 March 2014 (UTC)[reply]

Thumbnail Preferences - max 300px

Currently under preferences the max selectable thumb size in articles is 300px (the default being 250px ). On many of today's monitors that is not much larger than a postage stamp. Can we get that limit increased? Saffron Blaze (talk) 22:03, 20 March 2014 (UTC)[reply]

The default is 220px. Thumbnails are not ment to act as full size images; they are 'thumbnails' after all. Try the new Media Viewer beta. — Edokter (talk) — 22:25, 20 March 2014 (UTC)[reply]
Further, our non-free content policy, which uses low-resolution non-free images, would not allow for images to be displaed at much larger sizes. --MASEM (t) 22:28, 20 March 2014 (UTC)[reply]
Why the lecture as if I am an idiot? I know what thumbnails are intended to do. I am saying they too small to be of any use on high resolution monitors. It was fine when all we had was 1024x monitors but now the defaults are often higher than 2560x. Moreover I wasn't asking for full resolution images, just slightly larger thumbs so I could at least see enough detail to decide whether the image is even worth opening. As to the beta Media Viewer, how is that functionally different from clicking on a thumb? Even if I were to use the viewer I would still need the thumbs to be larger.
The issue of "fair use" is a red herring. I was not asking for the actual image to be larger just the thumbs in the articles. Moreover, there is no firm legal criteria on allowable resolutions for non-free content. The guidelines only mention that images should be rescaled as small as possible to still be useful as identified by their rationale, and no larger. The image size to respect this notion seems based on old criteria and predicated on lower resolution monitors. Saffron Blaze (talk) 22:53, 20 March 2014 (UTC)[reply]
In general, it is inappropriate to assume any particular window size. You are applying what is typical for you and desiring to push it onto everyone viewing a particular article when doing so might make the article look much worse to them than the inconvenience of having a relatively small thumbnail image is to you. When adjusting this sort of thing on an article it is a good idea to view the page in a window which you can resize to a variety of widths so you can find a compromise which is reasonable for everyone. Further, keep in mind that a considerable amount of WP readership is now on mobile devices which tend to have a much smaller number of pixels available to display content.
As an example of going the other direction, the mw:Typography refresh recently was intending to force all MediaWiki projects using the Vector skin to a maximum page width of 715px. Upon getting negative feedback, they relented. This is intended as an example to indicate that opinions vary greatly as to the "proper" size of the window to view anything. The reality is that we should adopt page layouts which look acceptable under a variety of conditions. — Makyen (talk) 23:55, 20 March 2014 (UTC)[reply]
  • I am not doing any such thing and I would appreciate people stop talking out of their arse. If you go to your preferences and select appearance then look at the file options you will see an option to select your preferred thumb size. Default as pointed out is 220px. The max you can select for yourself is 300px. This is the size you will see when a hard pixel size is not included in the wiki code for a thumbnail. These smaller resolutions were fine on lower resolutions monitors, but is becoming inadequate now with QHD and 4K monitors. I asked that users be able to select a larger thumb size for themselves... NOT everyone else. Saffron Blaze (talk) 00:39, 21 March 2014 (UTC)[reply]
I'm not sure I understand the problem here: On QHD/4K Monitors you would have to scale up the text anyway (otherwise it would be much too small to read). If you scale up the text your browser should also scale up the thumbnails for you (if it doesn't maybe check you browser settings). Therefore the thumbnail is shown much larger than 220px, even if the setting you mentioned is kept at it's default. Therefore problem solved, isn't it? Since the images have defined a srcset HTML attribute you won't just see an upscaled image but an actually a higher resolved version therefore even gaining quality. --Patrick87 (talk) 01:43, 21 March 2014 (UTC)[reply]
Your inability to understand the issue makes it seem clear you won't have the answer yet I am confronted with another patronizing response. The assumption in your response is wrong. I don't want the text to get larger, I just want the thumbs to be larger. Saffron Blaze (talk) 04:31, 21 March 2014 (UTC)[reply]
Text sizes are normally given in points, not hard pixel values. Hence, for text, a properly-configured system should use however many pixels are needed for the text to appear at the desired size. E.g. 12 pt text should appear at a height of about 1⁄6 of an inch. However, image sizes are given in pixels. The same number of pixels are used regardless of resolution, so the physical size of the image is smaller at higher resolutions. Zooming is not a solution, since it also affects the properly-sized text. – PartTimeGnome (talk | contribs) 22:52, 22 March 2014 (UTC)[reply]
The options are determined by mw:Manual:$wgThumbLimits which says: "In order to reduce disk usage, users can only select a value from this list." The Wikimedia settings at http://noc.wikimedia.org/conf/highlight.php?file=InitialiseSettings.php say:
'wgThumbLimits' => array(
	'default' => array( 120, 150, 180, 200, 220, 250, 300 ),
	'+itwikiquote' => array( 360 ),
	'svwiki' => array( 120, 200, 250, 300, 360 ),
),
So the Swedish Wikipedia has a larger option 360 but fewer options in total (confirmed at sv:Special:Preferences#mw-prefsection-rendering). I don't know whether this was a compromise they requested. PrimeHunter (talk) 02:15, 21 March 2014 (UTC)[reply]
PrimeHunter, thanks, at least now I know it is possible and there is precedent for it. Saffron Blaze (talk) 04:31, 21 March 2014 (UTC)[reply]
First off, I do apologize, I certainly misunderstood what you were asking about.
However, I strongly suggest that you step back and assume good faith on the part of other editors. In response to three different editors you have come back with a response that has a belligerent tone and indicated that you believed the editors were "lecture[ing] as if I am an idiot", "talking out of their arse", or giving you a "patronizing response". Of the three, perhaps you could characterize what I said as "talking out of [my] arse", but it is much more productive to say something like "You appear to have misunderstood what I was talking about. I was referring to the personal preference available from the Appearance tab in your Preferences."
As a side note, you might find it beneficial to ask a more generalized question about how others deal with having small images on high resolution monitors rather than locking yourself into only thinking about one way to solve the generalized problem. There are a variety of methods to solving, or at least alleviating, the problem. — Makyen (talk) 06:04, 21 March 2014 (UTC)[reply]
If all people ever do is lecture about things they don't even understand it gets annoying and frustrating. People spend more time in telling people why they are wrong than actually helping. It's the power culture here at WP. I am just tired of it. Thanks for another useless lecture that serves nothing other than to bolster your own ego. Your suggestion does not address my concern nor help me in any fashion. Saffron Blaze (talk) 10:42, 21 March 2014 (UTC)[reply]
  • Makyen, you were clearly talking out of your a**. "Under preferences the max selectable thumb size in articles is 300px ... Can we get that limit increased?". This is not regarding MOS, not regarding how it displays with others, and it is definitely not related to window size (except as it is related to the screen's absolute maximum). The question was clear. The initial answers were well out of left field. PrimeHunter's answer below is much more useful. — Crisco 1492 (talk) 11:33, 21 March 2014 (UTC)[reply]
Saffron, I understand your annoyance. Replying without understanding the question is a frequent problem when discussing technical matters. However, venting off at people who get it wrong is not constructive. It deters others who might be able to help. Politely saying that a response is unhelpful and discussing why is better; if you can get someone to understand the issue, there's still a chance they could help. Even where they can't help, there could be others who didn't understand at first who could assist once given further explanation. – PartTimeGnome (talk | contribs) 23:22, 22 March 2014 (UTC)[reply]
I was hoping it would deter others from spouting wiki-isms and nonsense, as is all too frequent. I am indeed glad PrimeHunter wasn't scared off. Then again, he knew what he was talking about. Funny how that works. Saffron Blaze (talk) 23:36, 22 March 2014 (UTC)[reply]
Bugzilla:11118 - "Allow larger/user-specified thumbnail sizes" was closed as WONTFIX in 2008, apparently based on this 2007 statement by Brion Vibber: "That's not likely to happen; we'd prefer to reduce the number of available thumbnail sizes to save on bandwidth, cache, and thumb disk space."
Bugzilla:27839 - "Offer 460px and 620px as thumbnail size preferences" was a request for the French Wikipedia. It was first accepted but later reverted in 2013 by Antoine Musso as WONTFIX with the statement "The original request can not be fulfilled, that will cause too much stress on our caching and storage infrastructure. I have reverted the original fix with: https://gerrit.wikimedia.org/r/51182". That says: "Having different thumbnails sizes per wiki is not something we can properly support right now. Our cache and files infrastructure will end being filled with thumbs which are barely used beside on the french wiki."
Bugzilla:41712 - "hewiki asks to change default image sizes for thumb and gallery" was not about the maximal options but also had some relevant posts.
The English Wikipedia is the largest but perhaps a suggestion for larger thumb options should be at meta: and linked at other wikis? The max of 300 appears to be older than 2007. That seems like a long time considering the development in screen resolutions and storage prizes, but the number of files is growing and I don't know the involved costs. PrimeHunter (talk) 11:27, 21 March 2014 (UTC)[reply]
Since the new "Media Viewer" is being developed (which will requires the creation of a whole lot of new Thumbnails anyway) and srcsets are used as stated in my "useless and patronizing" answer above (that means thumbnails are already generated at sizes of 330px and 440px as alternatives to the standard size of 220px and similarly at 1.5x and 2x the size of the other selectable thumbnail sizes) I think in principle a big number of cached resolutions should already be available and storage space / RAM seems not to be that much of an issue any more. I think it would be important to choose the sizes wisely though (so the already cached versions can be reused and as few new thumbnails as possible need to be created/cached) and all projects should use the same values. However larger thumbnails require a lot more of space, maybe that's the reason many small sizes but no large sizes are available. --Patrick87 (talk) 15:58, 21 March 2014 (UTC)[reply]
Before bitching at you I tried the media viewer. It does nothing until you click on the image. What I was hoping for was to see the article itself illustrated with larger images. If I wanted larger images by clicking I can get that already. Perhaps I am missing something as the viewer is beta, but if the viewer is intended to provide larger thumbs at some point that would indeed meet the aim. Saffron Blaze (talk) 22:54, 21 March 2014 (UTC)[reply]
Blaze Saffron, I am trying to understand the issues you are raising. I offer my personal setup and experience with a section in one of the oldest WP articles, scientific method#Overview, specifically the Galileo image in the Overview section. The markup is in old-fashioned style, from about 10 years ago.

[[Image:Galileo.arp.300pix.jpg|thumb|150px|According to Morris Kline,... ]]

If I edit the wikilink so the width of the thumbnail is 450px, After clicking 'Show preview' I get the article, with Galileo embedded in it, but with Galileo's image increased in size (similarly, Galileo decreases if I edit the width of the thumbnail to, say 50px).

Is that what you are trying to accomplish for viewing on your hi-resolution display?

On the secondary monitor, the article is 22.5" wide, with Galileo's image width 2.4" wide when viewed with defaults. My current secondary monitor is 24" diagonal, about 22.5" across, and 12.75 " high. The displayed resolution is 1366x768. I can view the secondary monitor without strain or magnification, while leaning back in my chair, a viewing distance of 48". The primary monitor is 11.6" diagonal, 10" across, about 5.6" high (a Chromebook, but I am running Ubuntu on it). I can read Wikipedia without strain on the Chromebook (I do lean forward when viewing the Chromebook), but the secondary monitor is essential when trying to read the details in stopped videos, for example.--Ancheta Wis   (talk | contribs) 00:34, 22 March 2014 (UTC)[reply]

  • Ancheta Wis, In the example you provided the markup has a hard pixel size of 150px. That is very unfortunate as it forces me to view that image at the forced size despite using a WQXGA+ monitor. If you remove that hard pixel size then people will see it at 220px unless they change the default setting in their preferences. A user can increase their default thumb size is to a max of 300px. On any monitor at QHD or above, that 150px image is but a tiny bit of colour and even at 300px it is barely acceptable, especially for landscape oriented images. I would find my reading and viewing of articles more rewarding if the thumbs were more like 400-450px. So, you essentially described the effect I want to achieve, but I don't want it done through hard pixel sizes as in your example (using hard pixel sizes is actually frowned upon in the WP MoS and image use policy). Does that answer your question? Saffron Blaze (talk) 04:21, 22 March 2014 (UTC)[reply]
Coming back from above, non-free images are not a red herring in this discussion. People reduce non-free to no more than 300px - for the most part - because no thumbnail presently can go above this size. If we increased the max thumbnail size that people would select, this would encourage (not via policy) for people to reduce only down to that size, which harms the free content mission and our fair use defense should that ever be challenged. Yes, free imagery doesn't have this problem but the max thumbnail size is irrespective of works being free or not. So there is more to this than just making WP look better for people with large monitors. --MASEM (t) 04:42, 22 March 2014 (UTC)[reply]
Actually "fair use" is anathema to the free cultural works movement because by definition "fair use" imagery is not actually free. That's why it is not hosted on Commons where "free to use" is taken literally. Regardless, I think your concerns over "fair use" image size is unwarranted when you see what sizes news media orgs use when applying "fair use" doctrine. The case law does not support your position as well. You are looking to restrict people's enjoyment and access to this project over the boogey man in the closet and we all know the bogey man does not exist. Saffron Blaze (talk) 18:10, 22 March 2014 (UTC)[reply]
It's not just "fair use" issues, it's our non-free policy. We are specifically more stricter than fair use so that we stay fair outside the point where the legal defense of fair use could be possibly challenged. One example is stressing we use smaller images to avoid our fair use taking from being too large and/or impact the commercial value. Thus why NFCC Policy is related to the thumbnail max size since we're not going to want to store images that are much larger than that. This is a mandate from the Foundation so this is not a boogeyman to worry about but part of the limitations that the Foundation has set for non-free use. --MASEM (t) 18:28, 22 March 2014 (UTC)[reply]
Even the strict image use guidelines for non-free content places the lower end at 320px and discusses images up to 1000px. Suggesting 300px is the upper end is not only wrong it is detrimental to the project. Saffron Blaze (talk) 18:55, 22 March 2014 (UTC)[reply]
I never said the max image size for NFC can be 300px, but that 300px is generally the max size because 1) for nearly all original media, this size is of sufficient reduction to be okay by fair use, and 2) the max thumbnail size is 300px and we shouldn't be uploading pics of normal aspect rations that go much above that. --MASEM (t) 19:24, 22 March 2014 (UTC)[reply]
Oh for crying out loud User:Masem, I can see why Saffron is frustrated when met with such responses. As you say, our restriction on non-free images is to ensure they are not detailed enough to have commercial value. This applies to the image we host, not the size as it appears on the user's display. If the underlying image is restricted at 300px, say, then displaying it as a thumbnail at 400px involves basic digital enlargement the same as someone using the Zoom feature on their browser, and not dissimilar to just moving their nose closer to the monitor, neither of which breaks any copyright laws. There is no fundamental reason why the fair-use cap cannot remain at 300px while the displayed thumbnail is 2 or 3x that if desired. If current guidelines/practice have conflated thumbnail size with free-use max then that is trivial to rectify. Let's not create imaginary obstacles.
While the web has moved forward towards recognising differing display abilities, Wikipedia has not advanced. I've not been impressed with the beta features and had to turn them off. I see more and more editors using hard pixel sizes and ignoring the standard thumb. This stores up a problem that is not trivial to fix. If the default/max thumb does not increase with technology then editors will find a way round it, and do, to the detriment of users stuck with older tech in the third world, say. Better that editors could choose small/medium/large for thumbnails and leave the user's preferences to sort it out (or better still, adaptable per display). Many of use use different monitors at various times. I have an 1920 x 1080 display on a laptop, a measly 1280 x 1024 at work, a super 2560 x 1440 in my study, a lowly 960 x 540 on my phone and 1920 x 1280 on a tablet. If storage/memory-use is an issue for caching (and I suspect it is less of an issue than it used to be) then fewer choices are the answer -- it should be straightforward to get stats on which sizes are widely used. Larger sizes aren't just a cosmetic issue -- the richer an image we can display the more our educational mission is served. A map or diagram with more readable legends, a building with more detailed features, a face with more character. Really, this is a discussion about a decade past its date. -- Colin°Talk 19:38, 22 March 2014 (UTC)[reply]
I'm not complaining that a thumbnail that is scaled from a 300px to a larger size is a fair use issue. But what can happen is that if we do allow a larger size of thumbnail for all images, people that use the larger size, let's say, 450px will upload non-free thinking their image size is fine considering this thumbnail policy. And then others will follow to upload at this size, even though 300px is just fine otherwise. I won't deny that this argument alone is a potential slippery slope in considering the non-free aspect only, but it is a point in conjunction with the other arguments against the size increase (including the server limitations for thumbnails) to keep 300px as max. --MASEM (t) 20:52, 22 March 2014 (UTC)[reply]
I contend that your basic premise and concern that non-free content only be uploaded at 300px is baseless and bankrupt and not predicated on anything but a guess and a wave of the consensus hand. It has no legal standing and is not part of any policy statement from the WMF. However, I am willing to be proven wrong so I brought this issue to the WMF legal via Meta. Saffron Blaze (talk) 22:53, 22 March 2014 (UTC)[reply]
Again, I never said the maximum size a non-free could be uploaded is 300. But 300px is a good size to encourage uploaders to reduce their works to via the fact that thumbnail can never go larger than that (if no other size parameters are given), and thus better keeps us within the issues of fair use. There are certainly plenty of places for >300px non-free, but the issue I'm point out that we can maintain the average (this typically being covers of published media) at ~300px by noting that thumbnails max out there. If you increase the maximum size of thumbnails readers can set, that could potentially drive editors to upload at higher resolutions and that starts putting us more at risk, espcially when most art doesn't need to be at that size (per WP:NFCC#3a non-free should only be used at the size that is necessary.) --MASEM (t) 22:59, 22 March 2014 (UTC)[reply]
It is NOT a good size. 300px is too small. 400px or even 500px sizes are still small enough to respect fair use doctrine and they will not break the bank, particularly if they are being generated for the media viewer anyway. Saffron Blaze (talk) 23:27, 22 March 2014 (UTC)[reply]
(edit conflict) There seems to be a level of FUD about this argument to keep the maximum thumbnail size at 300px. It seems daft (to me at least) to impose such a major restriction out of fear and speculation that others could get thumbnail sizes mixed up with our non-free content policies. Even if they did, it can be fixed in the usual wiki way: upload a new copy of the image at a smaller size then delete the old version, while giving the original uploader a talk page message explaining why the original image size was inappropriate. – PartTimeGnome (talk | contribs) 23:39, 22 March 2014 (UTC)[reply]
I tend to agree. Sorry Masem, but of reasons not to allow for larger thumbnail sizes in preferences, I do not find the NFCC argument compelling in the slightest. Resolute 23:51, 22 March 2014 (UTC)[reply]

Stats for audio/ video

What stats can we see, about how many times an audio or video file, such as File:Benedict cumberbatch in front row b00wqfnd-crop.flac, has been played; and from which pages it was launched? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:04, 20 March 2014 (UTC)[reply]

In short: almost certainly none. — This, that and the other (talk) 08:39, 22 March 2014 (UTC)[reply]

"Double" bold

Hi, when a table column heading is made bold

like this

I see a kind of "double bold" formatting that is heavier than ordinary bold. What actually is this formatting? And is it intentional, or is it a random side-effect of something that one is not supposed to do? 86.129.17.138 (talk) 02:36, 21 March 2014 (UTC)[reply]

I notice that works in Firefox but not Chrome. I'd say it's definitely something that one is not supposed to do. Jackmcbarn (talk) 02:49, 21 March 2014 (UTC)[reply]
I suspect it has to do with the styling of the <th> tag and the <b> tag. I checked default styling for Webkit, which seems to use "bolder" for b and "bold" for th. I'm not sure how Gecko does this, and cannot reproduce this problem in Firefox using monobook. πr2 (t • c) 03:02, 21 March 2014 (UTC)[reply]
In the browser I am using, "bolder" seems to display just the same as "bold" (bold text, bolder text), so I don't think it can be exactly that. I'm not sure whether it should be considered a "problem" or not. After all, if something is already bold, and you specify bold again, then making it "double bold" is not unreasonable. On the other hand, you could argue that applying bold formatting again should turn bold off. Really my question is prompted as much by curiosity as anything, but on a practical note I do come across this from time to time, as here, and I'm never quite sure if I should just remove it or if it's there for a reason. 86.129.17.138 (talk) 03:25, 21 March 2014 (UTC)[reply]
Remove it. Just about the only place I've seen it is in the context of tables (either the table caption [<caption>] or a table header [<caption>]), which are already bolded in the default CSS (without the need for a <b>) for the CSS skins in question. These are probably there because people don't know that they don't need to have them, or that the bold+caption was added before wikitable was the normal class. It's only now that some browsers (at least Firefox) have implemented double bolding that we're noticing it for the first time. --Izno (talk) 01:03, 22 March 2014 (UTC)[reply]
Just checked it: Firefox uses a bolded font variant for table headers (e.g. "Arial Bold"). When additionally using bolding on the header Firefox changes this to "Arial Black", the even bolder variant of Arial. This seems to be a very special case though and does not work in all cases (e.g. "Times New Roman" has only one bold style, therefore "double bolding" is not possible and the normal bold font is used in both cases). --Patrick87 (talk) 06:09, 21 March 2014 (UTC)[reply]

The CSS specification allows one to use up to 9 bolding levels, but currently only a few fonts and a few browsers support that. If you "nest" bolding, it is going to get bolder sometimes. :) Below are examples of the 9 styles in order from the lightest to the boldest for the curious. Matma Rex talk 08:35, 21 March 2014 (UTC)[reply]

The quick brown fox jumps over the lazy dog.
The quick brown fox jumps over the lazy dog.
The quick brown fox jumps over the lazy dog.
The quick brown fox jumps over the lazy dog. (this is the default, 'normal' font weight)
The quick brown fox jumps over the lazy dog.
The quick brown fox jumps over the lazy dog.
The quick brown fox jumps over the lazy dog. (this is the 'bold' font weight)
The quick brown fox jumps over the lazy dog.
The quick brown fox jumps over the lazy dog.
I wish I could find the relevant line in the specifications... Would be nice to be able to point to that. --Izno (talk) 01:03, 22 March 2014 (UTC)[reply]
On my setup, there are only three visibly different styles in the nine lines above: normal, bold, and what looks like the same "Arial Black" font that I see in the "double bold" table header, as identified above by Patrick. The last of these is used for both the "800" and "900" weights. It looks as if my system has no concept of different gradations of bold, but just switches to a different font for super-bold, at least for Arial text. 86.160.86.31 (talk) 03:49, 22 March 2014 (UTC)[reply]
See Font boldness: the 'font-weight' property in CSS 2.1 - particularly the sentences "There is no accepted, universal meaning to these weight names. Their primary role is to distinguish faces of differing darkness within a single font family." and "The association of other weights within a family to the numerical weight values is intended only to preserve the ordering of darkness within that family" The equivalent doc in CSS 3, which is currently at the Candidate Recommendation stage, doesn't really expand on that. --Redrose64 (talk) 08:42, 22 March 2014 (UTC)[reply]
Further to this, on my system Firefox displays three different levels as well, but the three levels are different: everything before "normal" is displayed using DejaVu Sans ExtraLight, normal and level-500 are displayed with DejaVu Sans, and the higher levels with DejaVu Sans Bold. Soon enough, Vector will start using only two levels (Arimo and Arimo Bold) on my system. Anomie⚔ 13:36, 22 March 2014 (UTC)[reply]

Issue viewing multimedia objects with Multicol in Safari

I can't figure out how to fix this. Can anybody have a look at Template talk:Multicol#Proposed Edit and see if they can fix this? Meteor sandwich yum (talk) 05:00, 21 March 2014 (UTC)[reply]

  • The Template:Multicol should not be used: There are numerous multiple-column templates which create problems on various browsers, and should not be used. Instead just use a plain wp:wikitable "{|...|}" with multiple columns ("|valign=top|"), and any right-side images will cause the column entries to neatly wrap beside images on various browsers. Also, Template:Autocol can be used to wrap around images since it is based on typical "<table>" tag elements. The one restriction with wikitables (or <table>) is to avoid empty columns containing "&nbsp;" as being trouble for screenreaders. -Wikid77 (talk) 16:14, 21 March 2014 (UTC)[reply]

Special:Contributions and education program

What MediaWiki message is responsible for the "X is a student in Y (Z)" layout that I'm currently seeing at the top of a lot of contributions pages? I've tried CTRL+F through Special:AllMessages to no avail. TeleComNasSprVen (talk • contribs) 18:42, 21 March 2014 (UTC)[reply]

Do you have an example? — Edokter (talk) — 18:50, 21 March 2014 (UTC)[reply]
TCNSV, you can find the name of messages by appending ?uselang=qqx or &uselang=qqx to the end of the query string in the URL. This is almost certainly from MediaWiki:Ep-user-roles-message-main-student (edit | talk | history | links | watch | logs), which is from mw:Extension:EducationProgram. It was added to SpecialContributions interface in gerrit:98183. Cheers, πr2 (t • c) 18:58, 21 March 2014 (UTC)[reply]

Edit notice for Commons-based files

When a user attempts to create or edit the file description page for a file hosted on Wikimedia Commons, the following message is displayed above the editing window:

This file is from Wikimedia Commons and may be used by other projects. Maybe you want to edit the description on its file description page there.

Just out of interest, how is this heading created? Is there a template somewhere, such as an edit notice (like Template:Editnotices/Namespace/File talk), which generates it? A MediaWiki page? SuperMarioMan ( talk ) 19:12, 21 March 2014 (UTC)[reply]

This is from MediaWiki:Sharedupload-desc-create or MediaWiki:Sharedupload-desc-edit. In general, when you do not know where a message comes from, try adding &uselang=qqx or ?uselang=qqx to the end of the URL. Regards, πr2 (t • c) 19:17, 21 March 2014 (UTC)[reply]

vanished tool

I used for a long time a tool: tools:~verisimilus/Bot/DOI_bot/. This migrated to somewhere and it is not clear to where or how to operate it. The list given somewhere on the page gives another citation tool, but this leads to a guy how wants to help with some migration.

I was never interested in programming nor do I want to follow all talks about all server and computer and software movements, but is there a possibility to get the information what hapend and why in a place close to the user?

--Stone (talk) 21:26, 21 March 2014 (UTC)[reply]

See #cite doi automatic completion broken? above. πr2 (t • c) 22:00, 21 March 2014 (UTC)[reply]
You can add this tool to your left sidebar, in the Tools section. Go to Special:Preferences#mw-prefsection-gadgets and select "Citation Expander", then Save your preferences. You should see "Expand citations" under the Tools menu on the left sidebar on any page. Go to any article and click Expand citations.
I apologize if this is not the tool you were looking for. – Jonesey95 (talk) 06:33, 22 March 2014 (UTC)[reply]
THANKS!! The best would make this thing a recomendation in a point where you get when you try to use it. --Stone (talk) 21:21, 22 March 2014 (UTC)[reply]

State of MathJax

The MediaWiki installed version of MathJax is v2.3. Nageh's script is v2.2, but has the added feature of automatically using your local STIX fonts. Does MW's v2.3 has an JS option to use my local fonts? — Edokter (talk) — 22:47, 21 March 2014 (UTC)[reply]

Text align

v2.3 also changed its text-align to center (This is a change to MathJax itself). There an RFC about this about having this changed back, but where is it? (A single line of CSS can fix this.) — Edokter (talk) — 22:47, 21 March 2014 (UTC)[reply]

UTRS has fallen over

I'm getting a 502 error at the usual http://utrs.wmflabs.org/ address, and have been for a couple of hours - anyone know what's going on there? Feel free to point me at the place where this has undoubtedly already been discussed; I'm rarely the first to spot these things... Yunshui 雲‍水 23:52, 21 March 2014 (UTC)[reply]

Andrewbogott added himself to the admins list (see here), so maybe he is trying to fix it. πr2 (t • c) 23:56, 21 March 2014 (UTC)[reply]
This project has been shut down as part of the labs datacenter migration. During the weeks leading up to the migration no one has offered to take responsibility for this project, so I deemed it abandoned. If anyone would like to step up and take ownership, I'm happy to revive it in the new datacenter. A bit of context: http://lists.wikimedia.org/pipermail/labs-l/2014-February/002152.html Andrewbogott (talk) 00:11, 22 March 2014 (UTC)[reply]

Image glitch at Line of succession to the British throne

At 180px
At 220px
At 300px

At Line of succession to the British throne#Line of succession there is an image link to File:Prince Charles.jpg, but rather than displaying that image, the page is displaying an image of what appears to be a wedding cake. The page appears the same after purging and after a null edit, so I'm guessing that some kind of database glitch is responsible, rather than image vandalism. Do others see the same thing, and does anyone know how it can be fixed? — Mr. Stradivarius ♪ talk ♪ 09:02, 22 March 2014 (UTC)[reply]

Not for me. Try clearing the cache at your end. --Redrose64 (talk) 09:11, 22 March 2014 (UTC)[reply]
Hmm. Clearing the cache didn't work. However, the proper image appears when I'm logged out. This prompted me to blank my .js and .css pages, disable all of my beta features, and then clear my cache again, but I still get the cake image while logged in. Here's a screenshot. — Mr. Stradivarius ♪ talk ♪ 11:33, 22 March 2014 (UTC)[reply]
I also just tried the same thing after disabling all of my gadgets, but Line of succession to the British throne is still a cake-only experience. — Mr. Stradivarius ♪ talk ♪ 11:46, 22 March 2014 (UTC)[reply]
I guess you have set thumbnail size to 180 or 300 at Special:Preferences#mw-prefsection-rendering. I see Prince Charles at /media/wikipedia/commons/thumb/2/2e/Prince_Charles.jpg/220px-Prince_Charles.jpg which is what IP's and users with default thumbnail size get. I see the wedding cake at /media/wikipedia/commons/thumb/2/2e/Prince_Charles.jpg/180px-Prince_Charles.jpg and /media/wikipedia/commons/thumb/2/2e/Prince_Charles.jpg/300px-Prince_Charles.jpg, although at another height-width ratio than your screenshot because Line of succession to the British throne#Line of succession generates code to display it at the Prince Charles ratio. I have added the image at 180px, 220px and 300px here. I see cake, Charles, cake, all at Charles' ratio. I haven't tried to purge the images in case others want to investigate. PrimeHunter (talk) 12:35, 22 March 2014 (UTC)[reply]
The cake was moved from that name. [2] shows "18 November 2010 Diego Grez (talk | contribs) moved page commons:File:Prince Charles.jpg to commons:File:Prince Charles wedding cake (1981).jpg". The current Charles image was uploaded 18 July 2012. Maybe some of the sizes have been cached since before then. PrimeHunter (talk) 12:40, 22 March 2014 (UTC)[reply]
I had my thumbnail size preference set at 180px, and when I checked this thread 10 minutes ago I saw cakes in the 180px thumbnail and the normal image in the other two. Then I changed my thumbnail size preference to 220px and cleared my cache, and then all three images on this page displayed as Prince Charles the human rather than Prince Charles the cake. I then changed my thumbnail size preference back to 180px, cleared my cache again, and all three images were still of Prince Charles the human. So this appears to be fixed now for me. I imagine that it would be worth filing a bug to make sure this is fixed for other users in my situation as well. — Mr. Stradivarius ♪ talk ♪ 13:47, 22 March 2014 (UTC)[reply]
The cakes are also gone for me now. Maybe somebody purged the image. PrimeHunter (talk) 13:14, 22 March 2014 (UTC)[reply]
I still see cake-Charles-cake on this page, after purging the image and this page and clearing my browser (Safari) cache.--JohnBlackburnewordsdeeds 14:48, 22 March 2014 (UTC)[reply]
And now it's Charles all down, though I've done nothing here.--JohnBlackburnewordsdeeds 18:30, 22 March 2014 (UTC)[reply]
This type of issue (thumbnails being out-of-date at certain sizes) is often regional in nature, hence some people see it while others don't. On the rare occasions I see it, I find the three steps at commons:Help:Purge#Advanced manual thumbnail purging can fix it.
Technical explanation: When an image is uploaded, moved or purged, a message is sent to the caches in all Wikimedia data centres to remove the old image at all sizes known to have been generated. This message sometimes gets lost, causing old thumbnails to persist at some sizes at some data centres. Subsequent purges do not fix the problem because MediaWiki only purges thumbnail sizes it believes to exist, and it thought it already got rid of those old thumbnails. Re-generating the thumbnail at the problematic size(s) allows MediaWiki to know the thumbnail exists at that size, so the next purge purges it correctly. – PartTimeGnome (talk | contribs) 23:55, 22 March 2014 (UTC)[reply]

Bug fix needed at {{oldid}}

Could someone with templating chops please look at my bug fix request at Template talk:Oldid#Bug: use with .7Coldid.3D_adds .7Ctitle.3DMain Page? It should be a quick one. Thanks. — Scott • talk 13:34, 22 March 2014 (UTC)[reply]

I also responded on the template's talk page. I am posting this here so multiple people don't go looking for a problem in the template code which does not exist, per se.
The template is functioning as designed. The parameters which were provided to the template are invalid per the template documentation. For what was desired, use {{oldid2}} not {{oldid}}. The {{oldid}} template requires that a page name be provided. If no page name is provided it defaults to the Main Page.
Personally, I find that the requirement for a page name makes {{oldid}} effectively useless. I always use {{oldid2}}. {{oldid}} has been this way for years.
Multiple templates in the group which provides information similar to {{oldid}} have various versions which use parameters in somewhat different configurations. For instance, compare: {{contribs}} vs. {{contribs2}} vs. {{contribs3}} and {{history}} vs. {{history2}} vs. {{history3}}, and {{diff}} vs. {{diff2}}.
It looks like there might end up being a discussion about changing/merging {{oldid}} and {{oldid2}} on Template talk:Oldid if anyone wants to participate. — Makyen (talk) 14:51, 22 March 2014 (UTC)[reply]

template:Chart - borked?

as you can see (or at least, as i can see), this template appears to be broken.

if you can't see the problem, let me describe what i see: in the tempalte page, you'll notice, in the demo, that the 3rd generation appears to be squashed: the boxes around

My brother Joe
Me!
My little sister

collapse to a single fat line, that slashes the text in the middle. you can see the effect, e.g., in Template:Genealogy of the Olympians in Greek mythology - nothing special about this one, i chose it at random from the "what links here" of Template:Chart. for your convenience, i'm transcluding it here:

Extended content

is this a known issue? does someone have a solution?

Background: long time ago, we imported the grandfather of Template:Chart, namely Template:Family tree into hewiki. the imported template is borked now, and when looking for a solution i noticed that the original is now deprecated. i thought we'll have to re-import the updated one (not a pleasant task - this template code is so complicated that one can go blind if one stares at it for too long), but then i realized that the not-deprecated template is also borked...

peace - קיפודנחש (aka kipod) (talk) 15:46, 22 March 2014 (UTC)[reply]

Known issue in Chrome, see Template_talk:Family_tree#Rendering_issue and Template_talk:Chart#Lone_boxes_collapsing. Matma Rex talk 15:57, 22 March 2014 (UTC)[reply]
any idea what can be done here? is there some CSS trick that will fix it? or maybe some lua dirty trick that will do it? e.g., create Module:straighten-tables, and use it to package the chart and add the missing TDs? (if i understand correctly, chrome will be happy if we can slap extra TD elements on some of the rows such that all rows will have the same number of cells - maybe i misunderstood here...) peace - קיפודנחש (aka kipod) (talk) 16:35, 22 March 2014 (UTC)[reply]
There is a trick, but I can't remember where I posted it. The table row needs an explicit height (like 1px); that will force Chrome to display all cells with proper height. — Edokter (talk) — 22:01, 22 March 2014 (UTC)[reply]

Page not transcluding correctly?

At WP:PHYS, on the right column is a link to "Wikipedia:WikiProject Physics/Current activity". This should be transcluded, but I can't find the reason for why it's not. The code on the WP:PHYS page is 

<div style="float:right; width:39%"> <!-- This adjusts the margins for the boxes aligned on the "right" -->
{{Portal:Physics/box-header|Current activity|Wikipedia:WikiProject Physics/Current activity}}
{{/Current activity}}
{{Portal:Physics/box-footer|}}
</div>

which should transclude Wikipedia:WikiProject Physics/Current activity. What gives? Headbomb {talk / contribs / physics / books} 16:50, 22 March 2014 (UTC)[reply]

The clue is at the very bottom of WP:PHYS, "Category:Pages where template include size is exceeded". See Wikipedia:Template limits. -- John of Reading (talk) 16:55, 22 March 2014 (UTC)[reply]
Ah I see, thanks. I fixed it now. Headbomb {talk / contribs / physics / books} 17:18, 22 March 2014 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=600804582"