Wikipedia:Village pump (technical)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

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

The technical section of the village pump is used to discuss technical issues about Wikipedia. Bugs and feature requests should be made at Bugzilla (see how to report a bug). Bugs with security implications should be reported to securitywikimedia.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.

« Archives, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216

Secure site only?

Suddenly every page visited takes me to the secure site, and attempts to preview edits bring up nothing - just the edit window of the full page - what gives? - The Bushranger _{One ping only} 20:43, 28 August 2013 (UTC)

I can preview edits again now, but I am sent to the secure site (on both latest Firefox and Chrome) no matter what page on the non-secure site I enter a URL for? - The Bushranger _{One ping only} 20:46, 28 August 2013 (UTC)

If I'm logged out, the normal site works, but while logged in, I'm sent to the https:// no matter what I do. - The Bushranger _{One ping only} 20:49, 28 August 2013 (UTC)

You're not alone. Ginsuloft (talk) 20:51, 28 August 2013 (UTC)

I'm having all sorts of troubles, too. Editors must have an option to turn secure protocol off. I understand the benefits and all, but for some this mandatory secure connection would do more harm than good if it cannot be turned off. Please, fix.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); August 28, 2013; 20:52 (UTC)

There is a preference. It's on the first page of your preferences, see "Always use a secure connection when logged in." ^demon^{[omg plz]} 20:56, 28 August 2013 (UTC)

That fixed it, thanks. However, that begs the question as to why, all of a sudden, it became enabled without my having checked it. If there was a decision to change that to 'on by default' where was the discussion? - The Bushranger _{One ping only} 20:58, 28 August 2013 (UTC)

Thank you kindly. Of course, getting to it was a challenge in my situation, since the sudden switch to secure access by default rendered everything inoperable in my situation (so the Preferences are inaccessible too). Thank goodness for mobile technology; all is well now.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); August 28, 2013; 20:59 (UTC)

...and I've just discovered that the said checkbox needs to be unticked separately in every language edition of Wikipedia and in sister projects... that's a lot of fiddling with the phone for me today :(—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); August 29, 2013; 13:25 (UTC)

It also begs the question, did any other preferences turn on/off spontaneously as a result of this little update? A list would be nice, thanks. Ginsuloft (talk) 21:02, 28 August 2013 (UTC)

Pedant Alert! "Begging the question" is actually something completely different; you both mean "invites the question". — Scott • talk 14:12, 2 September 2013 (UTC)

No, no other preferences were changed. And neither was this one, for what it's worth. What you're seeing is a *new* preference that was coded in MediaWiki core to be true by default when $wgSecureLogin is enabled. As we rolled that out today (which has been mentioned in many places over the last few weeks), this preference became live for all users who aren't geotargetted as not having reliable SSL access. ^demon^{[omg plz]} 21:09, 28 August 2013 (UTC)

Well, with all due respect, apparently it needed to be mentioned a few additional places, as I'm sure I'm not the only user who suddenly found themselves wondering what new and exciting way their computer had suddenly decided to break... - The Bushranger _{One ping only} 21:14, 28 August 2013 (UTC)

I don't know how many other places it could have been announced. Oh, and we ran a sitenotice for logged in users last week. ^demon^{[omg plz]} 21:24, 28 August 2013 (UTC)

Maybe I've just had my brain tune out sitenotices... - The Bushranger _{One ping only} 21:32, 28 August 2013 (UTC)

I have disabled secure login in my preferences but I am still being taken to the secure server and this is effing up all my gadgets and scripts, and giving me "cannot parse" errors...--ukexpat (talk) 21:15, 28 August 2013 (UTC)

Did you try logging out and back in again? The preference in combination with special:login does some weird things with cookies. We added a help message there but perhaps it was unclear. ^demon^{[omg plz]} 21:24, 28 August 2013 (UTC)

Yes several times. The problem is isolated to Firefox. Works OK on Chrome.--ukexpat (talk) 21:27, 28 August 2013 (UTC)

It's a cache issue then. Should fix itself after a while. (Do not change the preference repeatedly on and off, as this will only make Firefox cache the wrong preference.) Ginsuloft (talk) 21:34, 28 August 2013 (UTC)

It may be a caching issue, yes. I've been unable to replicate the problem just yet, but I'll keep having a look since this behavior isn't ideal :) ^demon^{[omg plz]} 21:38, 28 August 2013 (UTC)

Ok, thank you! I think it's useful since the only reason I wasn't using https before was because of browser auto-complete and blue links, but it's nice to have it auto-redirect. Hopefully this won't be suddenly disabled/changed when I've finally clicked enough links to make them purple again (and my browser remember them to auto-complete them). Ginsuloft (talk) 21:17, 28 August 2013 (UTC)

This was previously announced and discussed at m:HTTPS. I think that it was also discussed at some other places, such as mw: and bugzilla:. There was also an announcement to all village pumps (in all languages) on Commons, various places on Meta and at least some of the village pumps on this project. --Stefan2 (talk) 21:22, 28 August 2013 (UTC)

Is there any way for people without https access to disable this, given that they won't be able to log in to change their preferences? The content-control software for a lot of public libraries, schools, and military facilities, for instance, blocks https by default, so this could potentially hit quite a lot of people, who won't necessarily have the savvy to find WP:VPT. Mogism (talk) 21:43, 28 August 2013 (UTC)

So, this issue did come up during the initial technical RFC but we decided not to act on it just yet. To be perfectly honest, logging in over HTTP on a public connection like a library is a really really bad idea, but I digress. We're always open to further iterations on this--it's an ongoing process after all--so any suggestions on how to help more users who are inconvenienced would be welcome. ^demon^{[omg plz]} 22:00, 28 August 2013 (UTC)

Since I use the secure login by default, this change made life easier for me. Thank you. I did notice the announcement some weeks ago; the sudden reactions just now might be due to other deployment conditions, because I just stick to firefox; I use chrome rarely, using IE only in a library setting (but I never login at the library). --Ancheta Wis   (talk | contribs) 23:12, 28 August 2013 (UTC)

My feeling on this is that we should not allow insecure login, especially on networks like these. We're really doing a disservice to users in Iran and China by allowing insecure login, but we'd be disenfranchising such a large number of users that it's hard to do otherwise. In this case, you should be complaining loudly to the people blocking HTTPS because it's an incredibly insecure thing to do. If a library, of all places, is doing so they should be shamed. This of course is my specific opinion and there may be enough people that disagree with me to allow something insecure.--Ryan Lane (WMF) (talk) 23:49, 28 August 2013 (UTC)

I agree on all counts, but what they're doing is probably that they only allow outgoing TCP traffic to port 80 (with the intention of disabling/throttling torrents and such) but forget to allow port 443, ironically making their network less secure. Ginsuloft (talk) 00:02, 29 August 2013 (UTC)

In my experience, public and semi-public (corporate etc) networks tend to be run by people with legitimate reasons to have an extreme risk-averse mentality, but not that much technical knowledge - they didn't become librarians, internet cafe owners etc to tinker with filter options. So, they install Webmarshall (or whatever), and leave all the default boxes checked (including "block all https"), rather than tinker with settings they don't really understand. I can assure you from experience that the "Error: all https blocked on this terminal" message isn't an unusual experience on a public terminal. I think this will come up enough that allowing a "log on using the insecure server" box ought to be added. (With an appropriate warning if necessary, although I can't quite see what we're hiding from - I'm sure if the CIA care strongly enough about what I post they could crack my account somehow.) Mogism (talk) 00:31, 29 August 2013 (UTC)

Who's to say some of these places aren't harvesting user names and passwords of their users to sell or try on bank sites and such? Places like this are basically the entire reason to force login over HTTPS.--Ryan Lane (WMF) (talk) 02:09, 29 August 2013 (UTC)

An operator of public terminals could just as well install keylogging and similar software to steal passwords and other key information at the source, in which case HTTPS offers no benefit at all (and might even create a false sense of security). SSL can help reduce the likelihood of a compromise when using public wifi, but if you are going to actually use a public terminal then HTTPS isn't much protection at all. Dragons flight (talk) 09:01, 29 August 2013 (UTC)

• Changing the prefs and clearing the cache does not work (Firefox 23.0.1, MacOS 10.8.4). This is extremely annoying to the point of putting me off editing. If it's having that effect on me, we're going to lose some users and that's not conducive to editor retention. Any devs watching this please take notice, because filing glitches at Bugzilla these days has very little effect in prompting any action. Kudpung กุดผึ้ง (talk) 22:08, 28 August 2013 (UTC)

I said I was looking into this :) ^demon^{[omg plz]} 22:10, 28 August 2013 (UTC)

Please do, because it's now actually freezing my computer, needing FireFox to be keystroke force quitted (alt+cmd+esc) to , unfreeze the desktop. What I'm getting are messages like this: WikiPage: Couldn't parse page name from url 'https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=570591325' and a spinning wheel that does not stop spinning. Hope this helps. If it's happening to me, it's possibly happening to tens of thousands of others. Thanks. Kudpung กุดผึ้ง (talk) 23:02, 28 August 2013 (UTC)

Checking 'Always use secure connection while logged in' and clearing the cache does not help either. Kudpung กุดผึ้ง (talk) 23:24, 28 August 2013 (UTC)

I'm having a heck of a time trying to replicate this (and I've been trying since it was first reported!). Is there any chance you could list, step-by-step, the process you were using to login, whether you were on HTTP to HTTPS at the time, and where exactly things went wrong? I'm hoping we're just miscommunicating here and there's an easy solution at hand :) ^demon^{[omg plz]} 23:37, 28 August 2013 (UTC)

I have disabled this in my preferences, as the default left me totally unable to edit, or even view, Wikipedia. (Every time I clicked on a link, or even typed in a url, I was switched to an https url, with a popup window "couldn't parse page name from url...". Previously, if directed to an https page, I have had to remove the s in order to open the page, but the new change made this impossible. Eventually I managed to open my preferences, find the relevant entry, and uncheck the tick; now everything works smoothly again. I have no idea what is causing the problem; whether it is my Wikipedia gadgets, my Firefox add-ons, or my security settings. Nor do I feel inclined to experiment and see what tweaks, if any, would resolve the problem. But it is clear to me that this change should not become a default, or be made mandatory, since this would certainly lock out readers and editors. RolandR (talk) 00:22, 29 August 2013 (UTC)

Hmm, that's a weird error message I've not seen before. Do you happen to have User:Quarl/wikipage.js installed? Googling sent me there. If so, I can definitely see why this user script is failing (and we can fix it). ^demon^{[omg plz]} 00:35, 29 August 2013 (UTC)

I would have done a screen shot, but with my desktop frozen I couldn't even do that. Anyway, you'll be pleased to know, at least from me, that the problem appears to have abated; I am now using 'secure connection' in my prefs but I'm not sure it's that which has done the trick. Kudpung กุดผึ้ง (talk) 03:18, 29 August 2013 (UTC)

I've just checked - I do indeed have importScript('User:Quarl/wikipage.js'); in my vector.js page, but without looking, I can't actually remember what it does. Kudpung กุดผึ้ง (talk) 03:22, 29 August 2013 (UTC)

Your problem probably abated because I fixed the script :) :) ^demon^{[omg plz]} 04:35, 29 August 2013 (UTC)

Thanks :) Kudpung กุดผึ้ง (talk) 05:44, 29 August 2013 (UTC)

I know that Firefox has this weird quirk in that if you have visited a secure version of any website it will force that one to be the choice the next time you visit the site. You have to go into the browser history and delete every https version of the website and then it will fix itself. That being said, it's a real pain in the ass when some new change is made to the MediaWiki software and it's set as default on in preferences for already registered users.—Ryulong (琉竜) 06:28, 29 August 2013 (UTC)

Yes, I was aware of that as a long-time user of FF - the solution was to clear the cache and load the page again, but this Wikipedia issue took me by surprise because I tried everything and it didn't work. I met one of the FF devs at Wikimania in Hong Kong and I'll give him a ping. Kudpung กุดผึ้ง (talk) 06:44, 29 August 2013 (UTC)

I don't have Quarl's script installed, so whatever ^demon altered has not helped me. Nor has clearing my Firefox cache.RolandR (talk) 11:14, 29 August 2013 (UTC)

You did. I removed it for now, assuming that there was still something wrong with it. If you install userscripts, you need to be aware that they might break at any time. If you don't want such problems, don't install userscripts. —TheDJ (talk • contribs) 12:35, 29 August 2013 (UTC)

@^demon: what does it mean to have "users [...] geotargetted"? — Preceding unsigned comment added by Nabla (talk • contribs) 08:09, 29 August 2013 (UTC)

It is explained somewhere in the mush above - it means users in some countries like China where https use automatically triggers suspicion from the authorities are being automatically exempted from this. Mogism (talk) 08:19, 29 August 2013 (UTC)

Just to further expand on this. It's not that it triggers suspicion, it's that China and Iran actively block HTTPS access to the site. So we setup some stuff in MediaWiki & wmf-config that skips the redirect from HTTP or HTTPS if your IP address originates from China or Iran. This is in contrast to our original plan, which was to just disable secure login for the various zhwikis and fawikis (which would have kept Chinese and Iranians from editing say...Commons or Meta). ^demon^{[omg plz]} 14:53, 29 August 2013 (UTC)

Thank you. I'd say, then, you are (geo)targeting regions, not users, i.e. not specific users. I did not thought it was so, but it sounded like it, but that is possibly fault of my not so good English language skills. Again, thanks. - Nabla (talk) 21:13, 29 August 2013 (UTC)

Ah thought it was just me, but as it's easily fixed, I'm OK. Carry on. Lugnuts ^{Dick Laurent is dead} 10:35, 29 August 2013 (UTC)

Seriously stop flaming the devs. They announced this change in multiple places. I saw announcements about it in Wikiepdia. My understanding was the login would be a secure page, but after that, you would be send to a regular wiki page. That doesn't seem to be happening and , yes, Firefox hates it, no the proposed fix doesn't work. I.E 9 appears to be ok with the change, and Chrome appears to be ok with the change. Switch over to Chrome for the moment and the devs will address the problem with Firefox.  KoshVorlon. We are all Kosh ...  11:44, 29 August 2013 (UTC)

That is an extremely arrogant response. In the first place, I certainly saw no such notification. I'm not denying that they were posted, but I'm sure that I can't be the only editor who was unaware that this would be happening. Secondly, I doubt that anyone realised the possible implications, the bugs and incompatibilities which make the new system a nightmare for some editors. And thirdly, why should I be obliged to change my preferred browser for one I do not wish to use, in order to compensate for the shortcomings of this change? I hope it doesn't come to this, but if forced to chose between Firefox and Wikipedia I would chose Firefox every time. RolandR (talk) 11:51, 29 August 2013 (UTC)

If you mean my response, it's not intended to be arrogant. I'm a webmaster as well, so I understand the dev's position (somewhat), I also understand why changes have to be made without discussion. Perhaps because of this, I'm more apt to see notices from the devs. I also know flaming the devs won't fix this issue either.

I've monkeyed around in Firefox, including (about:config) and what it looks like is Firefox doesn't handle SSL requests correctly (firefox 23.0.1 ) It DOES have TLS avaialable in about:config, TLS 0 = SSL3, but it doesn't appear to process correctly, event the site itself doesn't seem to render correctly that way (nor will it when a range of TLS max = 3 Min =0 is given ).

Devs - If I may suggest, next time a software change is needed, ask for testers (and yes I'll volunteer ) to vet your changes before they're released. That way most of the major problems can be caught ahead of time.  KoshVorlon. We are all Kosh ...  13:25, 29 August 2013 (UTC)

• I'm another poor sap who despite multiple daily visits was blissfully unaware of the switch to https. Anyway, here's another unforeseen side-effect: Reflinks and Citationbot don't work any more. I've tried changing my preferences to switch off https (I don't give a flyf... whether the NSA or anybody else tracks my edit record). Unfortunately, nothing changes and I keep being thrown to https. Why can such changes not be opt-in instead of opt-out? Using https has always been something that the paranoid among us could choose if they wanted to. If it means not having Reflinks and Citationbot any more, I don't want it. Thanks. --Randykitty (talk) 14:35, 29 August 2013 (UTC)
  • The community supported tools will get fixed, it might just take the volunteers a day or two. If you want to be insecure, you can choose to do so in your preferences. It requires logging out and back in (for every specific wikimedia wiki). I'd call that being dumb, but do what you want in that regard. Also the login process itself will always be secure now, to protect your password. —TheDJ (talk • contribs) 14:47, 29 August 2013 (UTC)

As stated below and in my post above, that doesn't work. And why am I being dumb? I've used http for years now and (apart perhaps from clogging up the NSA's files) I have never experienced any problem, never had any password hacked, etc. --Randykitty (talk) 15:06, 29 August 2013 (UTC)

I've accidentally left my front door unlocked a couple of times when I've been out all day, yet have never been burgled. Nonetheless, I try to remember to lock the door anyway. The potential for someone to crack your account still exists, even though no-one has yet done so to your knowledge. (I respect your right to make an informed decision on the best balance of security vs. convenience for yourself. I am commenting here so yourself and others are better informed when making their decision.) – PartTimeGnome (talk | contribs) 17:14, 1 September 2013 (UTC)

Actually, That doesn't work DJ. I tried that and I still get to https versions of the wiki :)  KoshVorlon. We are all Kosh ...  14:52, 29 August 2013 (UTC)

@KoshVorlon: We did, I'm sorry you missed the notice! We enabled this on various test wikis & mediawiki.org earlier in the week and called for testers. We definitely did get people to test this, it wasn't just a small group saying "well it works for me so let's go." :) ^demon^{[omg plz]} 14:57, 29 August 2013 (UTC)

No problem. I'll man up and take partial responsibility for missing any message that was sent via the interface.

I've disabled them, so any that were sent were missed because I have that setting on. Anyrate, it looks like only Firefox is affected as it can't handle SSL 3. (In case anyone's wondering, a javascript is involved with the SSL change over This one . Turning off javascript won't solve the problem as the re-direct is on wiki's side  :)  KoshVorlon. We are all Kosh ...  16:44, 29 August 2013 (UTC)

If you've disabled messages or have developed a case of banner blindness, then you might want to subscribe to meta:Tech/News. Whatamidoing (WMF) (talk) 16:55, 29 August 2013 (UTC)

Actually I just set up a collapsible box for the sitenotice on my page , but | THIS caught my eye on the list since it shows HTTPS being forced, possibly it could be un-forced :)  KoshVorlon. We are all Kosh ...  17:52, 29 August 2013 (UTC)

looks like the https switchover broker something in wiki:

Timestamp: 8/29/2013 2:57:19 PM Error: ReferenceError: hookEvent is not defined Source File: https://en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-popups.js&action=raw&ctype=text/javascript&570545406 Line: 7678

 KoshVorlon. We are all Kosh ...  19:02, 29 August 2013 (UTC)

• I guess the https is also wreaking havoc at WP:UAA, where HBC AIV helperbot5 seems to have disappeared. Also, I used to have an improved diff displayed automatically, but now have to expressly click it, otherwise it won't come up. I may be dumb (see above), but I really don't like wasting time on trivialities like this. --Randykitty (talk) 19:25, 29 August 2013 (UTC)

I investigated in searching why I was still redirected to https even after having unchecked the checkbox and disconnected-reconnected many times; it is due to the presence of two cookies (names enwikiforceHTTPS) and only one is deleted, so you are still redirected to https (bugzilla:53536); this happens with Firefox and Opera, I suspect Chrome delete the two cookies (which make the un-https working). Perhaps the second sub-thread here (Kudpung 22:08, 28 August 2013 (UTC)) is partly due to this bug (at least the problem to un-https).
A temporary solution is:

1. uncheck the preference;
2. delete the two cookies named enwikiforceHTTPS (domains en.wikipedia.org and .wikipedia.org; in Firefox: Edit > Preferences > Privacy > Delete cookies or Display cookies, search these cookies and delete them),

and you should stay on http. ~ Seb35 [^_^] [fr] 01:19, 30 August 2013 (UTC)

This isn't working for me. I don't have these cookies at all. And every so often, despite having the preference properly set, I get taken to the secure site.—Ryulong (琉竜) 18:09, 4 September 2013 (UTC)

You mentioned Firefox earlier: is this the browser that you are using? --Redrose64 (talk) 18:14, 4 September 2013 (UTC)

Tracked in Phabricator
Task T16950

What is truly galling about this is that there appears to be no way to have a universal opt-out of HTTPS. Everytime I go to a different foreign language wiki, or a different project, it slams me into HTTPS again and I have to go the preferences section of that project to undo it. I don't need the security advantages of HTTPS, which I will admit are real, and it adds a minor irritant when I copy a link in a foreign language wiki and have to manually edit the link before I have the website translated. (Google Translate does not support HTTPS.) Carolina wren (talk) 04:44, 30 August 2013 (UTC)

This isn't just a problem for the HTTPS opt-out, but for all preferences. With the exception of your e-mail address, just about everything in Special:Preferences must be set separately on every wiki. Bug 14950 has been around for a while. – PartTimeGnome (talk | contribs) 17:14, 1 September 2013 (UTC)

I had the same "couldn't parse page name" error as others above, and I've realised the reason we all had Quarl's script installed was due to the Deletion sorting tool, used at AfD. I've made a note there that this script conflicts with secure log-in. Fences&Windows 23:14, 9 September 2013 (UTC)

Every time I go to the reflinks tool I get forced onto the HTTPS version of the site. What's up with that?—Ryulong (琉竜) 19:49, 10 September 2013 (UTC)

Who is in charge

Yes, I'm venting, but does anyone in charge know what they are doing? The facts say no. The change to switch all links to https has broken the browser history for many of us. I guess the super smart technical decision makers don't use the browser history. For those of us who do, this is again another one of a series of stupid changes for the sole purpose of making it difficult for editors to use Wikipedia. Vegaswikian (talk) 00:32, 29 August 2013 (UTC)

Uncheck "[_] Always use a secure connection when logged in" inside Special:Preferences (which was also broken/unbroken last week). Working with volunteers, with no certification of abilities, can be frustrating. Think: "software duhvelopment" or "you get what you pay for". The best idea has been an enduser "union of Wikipedians" to pre-screen planned changes (and recommend, "Hell no!"). I am thinking essay, "wp:Beware user-interfere changes" to alert users to impending doom, and list prior upgrade disasters as for how to avoid catastrophic changes (losing large edits in VE, or 1-hour delay to edit) and where to go for emergency help. Numerous people have mentioned the word "firing" but working within a volunteer organization requires more-complex protections from their antics. -Wikid77 (talk) 14:07, 29 August 2013 (UTC)

If you really want to use the insecure site you can set the option in your preferences. As for who is in charge of this project: it was a joint effort by members of both operations and core MediaWiki developers (myself among them). I'm sorry that your browser doesn't store history when browsing secure sites, but really out of the many many things we worked on to get this right for as many people as possible browser history was the least of our concerns. ^demon^{[omg plz]} 01:20, 29 August 2013 (UTC)

You can read about the reasonings/motivations that made HTTPS the defealt on the Wikimedia blog entry for it. The change was necessary to protect users' privacy. While it may be a temporary inconvience to you, worries about browser history as pretty minor objections. Jason Quinn (talk) 01:35, 29 August 2013 (UTC)

That's the problem, you folks don't know what you are doing or talking about. My browser does remember secure site URLs. It does not remember when YOU change my account from normal access to secure access! I did not change anything. I had my preferences set up the way I wanted them. You changed them not me. Vegaswikian (talk) 01:39, 29 August 2013 (UTC)

The change has nothing to do with me. I didn't do anything so please be keep the conversation civil and cool down. I posted a link with some info where you could read more. You haven't even really explained your problem in detail. You started by claiming the change "broken the browser history". From my perspective, that's acceptable collateral damage in exchange for providing more secure editing. This was something of an emergency event and necessitated big quick, responsive change. Luckily, HTTPS access had been under research for a while by the WMF. It's perfectly acceptable to try to convince me and others otherwise but type-shouting isn't a substitute for a convincing argument. Jason Quinn (talk) 19:34, 29 August 2013 (UTC)

Jason, are we living on the same planet? "acceptable collateral damage in exchange for providing more secure editing"? Are you serious? I want to use https when I check my bank account. But editing WP really, really, REALLY doesn't figure anywhere in my online safety concerns. The NSA and anybody else who wants to are free to look at my editing behavior if they want to waste time. I really, really, REALLY detest the paternalistic attitude of "we do this for your own good". I'm an adult. Please, let me decide for myself what's good for me or not. You can adivice me, but if you start making decisions for me for my own good, then you're in for a fight. --Randykitty (talk) 20:01, 29 August 2013 (UTC)

The WMF has a responsibility to ensure privacy of its editors and readers. End of story. With the NSA scandal, it became clear that a move to HTTPS was necessary to provide this. The vast majority of users no idea about the technical aspects of online privacy (how to use HTTPS and so forth). This does not dismiss the WMF's obligation to their privacy but enhances it. Maybe privacy doesn't enter into your editing concerns is fine but that doesn't mean the move to default HTTPS was wrong. The WMF must act in a way that provides the best service to all its users within its means. As for the "planet we live on", it is already known through the leaks that the NSA was watching Wikipedia editors. I don't know if you were aware of that. Plus, this gathered data is almost certainly being factored into now-known programs like Xkeyscore. This data has real-world implications, for instance, it is used to determine hiring for government jobs needing clearance. In other words, in the real world, this data could mean a person might not get hired for a job for which they are qualified. In the face of consequences like that, something had to be done. Jason Quinn (talk) 00:18, 30 August 2013 (UTC)

I'm soooo glad that Big Daddy is watching over me lest I inadvertently poke out one of my own eyes! You're absolutely wrong, the WMF has absolutely no obligation to make sure that editors use https. WMF does need to provide that possibility (as it already did), that's all. And far as I can see, the people who really need to be protected from their governments are automatically excluded from using https. In any case, let me be absolutely clear about this: I'm an adult with adult responsibilities. Protecting my online privacy is my responsibility, not yours or anybody else's and I don't want anybody to take me by the hand and lead me "for my own good". End of story. --Randykitty (talk) 09:45, 30 August 2013 (UTC)

That's crap. If your account gets hacked who are you going to blame? The WMF obviously because they didn't protect your account and your data. The WMF has an obligation to protect the private data of its editors, as spelled out in the privacy policy (only certain users can see private info, blah blah). This change doesn't just protect your privacy, it protects EVERYONE's privacy. So if you don't like it, change your own settings. But for everyone else who actually want's this change, stop complaining. Legoktm (talk) 09:58, 31 August 2013 (UTC)

In a civilised society, people look out for those who don't have the knowledge or skills to properly protect themselves. (A cynical part of me says we don't live in such a civilised society, but it is an ideal to work towards.) Using HTTPS by default is one example of this – a lot of people are not aware it is relatively easy to hijack an HTTP session. Educating people about the risks so they can protect their own privacy is a good thing, but next to impossible to do for everyone. Hence the devs have chosen a sane default that maximises security and privacy for those who do not have the technical knowledge to set this for themselves. For those sufficiently technical to make their own decision, there is also an opt-out. (Admittedly, there are some glitches getting the opt-out to work, as others have noted.) – PartTimeGnome (talk | contribs) 20:20, 1 September 2013 (UTC)

You're right, that's what civilized societies do, they make sure that nobody takes advantage of children, mentally handicapped persons, or people suffering from dementia. Thanks for putting me in one of those categories (I hope I fall in the category "children", that way at least there is still some hope for me). The paternalistic arrogance being displayed in this thread is really insufferable! For chrissakes, I'm not handling my bank account here, I'm editing Wikipedia... What privacy? If I understand correctly, the NSA already knows the real life identities of all WP editors. And they may in future not be able to read my contributions directly from my hacked browser, but then, all they have to do is to check my contributions, and presto! all my subversive edits are visible for the whole world to see. This whole thing is a paternalistic overreaction to a non-problem and even if it were a problem, as I just said, it doesn't solve it. --Randykitty (talk) 21:01, 1 September 2013 (UTC)

Civilized societies attempt to make sure that nobody takes unfair advantage of anybody. That's why financial institutions are regulated, even if they only deal with adults who all ought to be able to protect themselves from fraud and theft. That's why barbers and cosmetologists have to get licensed, even if they only deal with adults who all ought to be able to tell whether the scissors were adequately cleaned in between customers and whether the bottle of shampoo contains safe ingredients. That's why building codes exist, even if they're only being sold to adults who all ought to be able to decide for themselves if it's designed and built properly.

Notice, too, that this change is really not about you. It's about the rest of the 129,675 people who edited last month. If you believe that every single one of them really is capable of dealing with their own internet security, then I suggest that you go spend a few hours at Special:RecentChanges, and then come back and tell us whether you still believe that every single user here is so spectacularly competent that we should assume they're all competent to analyze their security risks, too. WhatamIdoing (talk) 01:33, 2 September 2013 (UTC)

You get it exactly right: financial institutions are regulated so as not to take advantage of people that are perhaps not well informed, but nobody forbids those people to buy stock of take that way-too-large mortgage. There's a difference. And I'm really glad that somebody is watching out for those apparently incompetent 129,675 editors. I'm not so much complaining about the https change as about the mindset of some people talking down to me here telling me things were done for my own good. But I do recognize that I'm not convincing anybody, so let's get back to work. I'm taking this off my watchlist now. --Randykitty (talk) 06:48, 2 September 2013 (UTC)

You probably won't read this, but I think you misread my comment. I didn't say you were in any group. For the record, I was thinking of you in the "sufficiently technical to make their own decision" group when I wrote the comment. Also, no one is forbidding you from using HTTP; you have the option in preferences. – PartTimeGnome (talk | contribs) 21:41, 7 September 2013 (UTC)

What browser are you using? Are you using IE? Which version? If using IE, do you have the following checked in the "Advanced" section? "Do not save encrypted pages to disk"? If so, please uncheck that.--Ryan Lane (WMF) (talk) 02:04, 29 August 2013 (UTC)

I think those questions pose a security risk, but hey feel free to state your personal ID number and banking account passwords here – it's safe now because we're running https (just kidding). The overall concept has been called, "penny-wise and pound-foolish" to dwell on small, micro-improvements when the real security risk is stating private information here. Another analogy is to double-padlock the front door and leave the backdoor unlocked. To really improve security, then have short warnings to remind users how everything written into a page can be read by anyone and many IP-addresses can be traced to town/building locations unless using a username. The rush to force to https seems too "penny-wise" as numerous browsers had problems running https transactions. -Wikid77 (talk) 17:45, 29 August 2013 (UTC)

I do find the "The Wikimedia Foundation believes strongly in protecting the privacy of its readers and editors" a bit odd. Everyone can see a complete record of what I have edited, https won't stop that, but not what pages I have read. I'm sure spooks are more interested in the former than the latter. I've a feeling this is more a political gesture that an attempt to improve the encyclopedia. --Salix (talk): 11:00, 30 August 2013 (UTC)

Just because you and I publish our real names, doesn't mean everyone wants to/can do that... We still have true pseudonymous authors. Also, editing is a much more conscious step for users than cursory reading I think, they have a better understanding of how an edit might affect them, than how a read page might affect them. —TheDJ (talk • contribs) 11:15, 30 August 2013 (UTC)

TLS provides quite a bit more to Wikipedia users than personal privacy (which is being overestimated for other reasons). I would hope critics that argue HTTPS is unnecessary have never tried editing Wikipedia from an open Wi-Fi access point, or via Tor. --Fran Rogers (talk) 09:33, 31 August 2013 (UTC)

• It is simply incomprehensible that this platform-wide change was not announced over and over in the most visible way possible -- using a top of the page banner -- so that it would not go unnoticed by anybody. Like many other editors who are busy improving the content, I have no reason to check in on any of the places where it was mentioned.

@Jason Quinn: As a long-time editor here, I have to say I am disturbed by your dismissive attitude, as evidenced by your replies above. I quote: "...worries about browser history as pretty minor objections." AND "From my perspective, that's acceptable collateral damage... " Are you serious?? Those remarks sound like the words of the proto-typical military/corporate bureaucrat -- the sort of thing I would expect to encounter at the Pentagon or on Facebook -- but NOT here on Wikipedia! :(

Let me tell you something, Jason: My browser history is absolutely integral to how I do things on the internet. When my browser history first disappeared, I assumed that the problem was somewhere on MY end of things. I racked my brain, I checked everything -- all to no avail. I had no idea that Wiki had switched over to secure pages, so I was really at my wits' end until I just by chance finally noticed that little "https" in the URLs. <Light bulb goes on> I then spent an hour googling a variety of search strings in hopes of finding something that would help resolve the problem. Again to no avail. Finally, I came here to see if anybody had raised the issue. What a relief it was to discover that it was already being discussed! Though in the first section, nobody mentioned the loss of browser history. So I was very happy indeed to spot Vegaswikian's remarks above, and the ensuing discussion. That is, until I got to your remarks. It's bad enough that you went into this with that kind of attitude. But to post remarks like that **after** having been told by another editor how upsetting this was is really very appalling. I hope in the future you will refrain from making remarks like that -- and more importantly, that you won't have that attitude in the first place. Sincerely, Cgingold (talk) 05:06, 31 August 2013 (UTC)

You must have missed the CentralNotice that ran for a week before this was enabled. Notices were posted on every pump, via mailing lists, the Wikimedia blog, etc. Legoktm (talk) 08:35, 31 August 2013 (UTC)

• I missed it, too. Some of us are here to edit and I, for one, don't follow the Villagepump, am not on any email lists, do not read any blog (except Retraction Watch), etc. In addition, even if I had seen those notices, how could I have foreseen all the problems that this change would cause? The paternalistic "we know better than you, it's all for your own good" attitudes here are indeed something I'd expect from some overzealous civil service, not from WP editors. As for your earlier "stop complaining" edit summary: I feel you still don't get what I exactly are complaining about. I don't complain that https is available now, I complain about it being forced upon people (except, of course, those in China and Iran that need it most) and that I'm being told like a child what is good for me. THAT is what I complain about. Offering https as an option, fine. If I don't use it and my account gets hacked, that's my fault, why would I blame WMF for that? But tell me, in the past years http was standard and the vast majority of editors must have used that. Exactly how many accounts were hacked every year (not counting people who accidentally left their session open on a shared computer)? Anyway, at least the https opt-out now seems to work also for Firefox, so I can get back to work again. And don't worry, once all the mess is sorted out and https actually works with the tools I need, I may perhaps some day uncheck the opt-out. --Randykitty (talk) 10:38, 31 August 2013 (UTC)

It was indeed a CentralNotice and I definitely saw it when it was up. The message is at HTTPSswitchovercoming. If you don't wish to piece together the code, the text was:

We will be making changes to make browsing Wikipedia more secure on 28 August at 20:00 UTC. Read more.

AFAICT it went up at 21:29, 21 August 2013 (UTC) and was up until 00:00, 29 August 2013 (UTC). --Redrose64 (talk) 15:07, 31 August 2013 (UTC)

This is how it always works. You put up a banner at the top of the page. Then someone complains, "You should have put up a banner at the top of the page! How dare you not inform me!" And then you say, "You mean this banner right here?" But the response is never "Huh, must be a problem on my end, since you obviously took all the reasonable steps to publicize this".

It doesn't really matter how many messages you post. There were literally more than one hundred messages on high-traffic pages about VisualEditor posted, including three top-of-page banners to all users, and people still said that it wasn't enough. Only one person, after seeing the list of VE-related announcements, had a suggestion for another way to reach users, and I doubt that anyone else would accept his suggestion (he wanted messages spammed to the talk page of every single one of the 19 million accounts registered on the English Wikipedia, including inactive ones). WhatamIdoing (talk) 01:40, 2 September 2013 (UTC)

An obvious way to avoid these complaints is to make all such changes opt-in instead of opt-out. postdlf (talk) 01:53, 2 September 2013 (UTC)

It's not actually possible to do that for every change. I think a more reasonable approach is to develop a shared understanding of what's appropriate (e.g., post to these three pages for smaller changes, but to these twelve plus a one-week banner for big ones) and for everyone to accept that even if these appropriate notices are performed flawlessly, they will not reach everyone. WhatamIdoing (talk) 04:54, 2 September 2013 (UTC)

Given that the use of https is set up as a preference that an editor can check or uncheck, and the change made the use of https selected by default, that obviously was one that could have been made opt-in. So we don't need to talk about what can or can't be done for "every change," when it clearly can be done for this and many other changes. postdlf (talk) 16:54, 2 September 2013 (UTC)

I want to sincerely thank everyone in this thread, civil or not, logical or not, because I came here to figure out why I stopped getting a dropdown box each time I needed my own useful edit-summary suggestions. As a result of this thread, I unchecked the now default HTTPS, and Lo and Behold! My edit-summary dropdown box returned! So, thank you, Big Daddies, but – No Thank You. Joys! – Paine Ellsworth ^CLIMAX! 18:11, 9 September 2013 (UTC)

Why is it so horrible to nominate for deletion on Wikipedia, when it's so easy on Commons?

Note: See commons:Help:Nominate for deletion and commons:Help:QuickDelete for the tool mentioned below.

I was just talking with a new user, who hesitated to try to AfD an article because the procedure's so off-putting, and I can certainly see their point. I have been here since the Ark, and I find it off-putting too. By contrast, I nominated an image for deletion on Commons a day or two ago, and was awed by how easy that was. Smooth as silk! Why can't we have that too? Please? Would somebody like to take a look at how it's done on Commons and give us something similar? Or is there some reason we actually need the confusing, jargon-ridden, template-infested, multi-step, instruction-creepy procedure that we have? (MfD is no better, and CfD, at a quick glance, seems worse.) Bishonen | talk 20:30, 29 August 2013 (UTC).

In my opinion, Twinkle isn't much more complex than the "nominate for deletion" link on Commons. The manual instructions (Commons:Commons:Deletion requests/listing a request manually, WP:AFDHOW) seem to be about equally complex on both projects. --Stefan2 (talk) 20:40, 29 August 2013 (UTC)

Given how many articles are routinely sent to AfD without going through WP:BEFORE or the like, I'd say we should make the process harder, not easier...--cyclopia^speak! 20:51, 29 August 2013 (UTC)

I can't believe what I'm hearing. "If new users think it's complicated, just tell them to get Twinkle"? Is that it, Stefan2? Can you really not see the difference between getting Twinkle and learning how to use it, versus an actual, working link next to the article which you click in order to nominate it? And Cyclopia, I hope you're joking, with your implication that everything would be better around here if only the tech-savvy got to do things like nominating for deletion. I do realize this, the "technical" branch of the Village Pump, is principally frequented by tech guys. But surely there are some of you out there who have some empathy for the other half. Bishonen | talk 21:05, 29 August 2013 (UTC).

Personally speaking i found it easier here than i did working out what the hell to do on commons. Twinkle isn't a hard tool at all to learn, and i kind of agree its easy enough to nominate now and we get very poor nominations. In my opinion making it easier could do more harm than good.Blethering Scot 21:18, 29 August 2013 (UTC)

User:Blethering Scot: We should aim for more and for more informed editors participating in nominations. Putting technical hurdles in place helps with neither — it merely weeds out editors who are not stubborn enough to overcome them. This is not always a good thing. I made a proposal on WP:VPPRO to address the informedness part. Not sure how it would work out, but feel free to comment. Keφr 15:51, 6 September 2013 (UTC)

I've added a topnote pointing to the commons-documentation for the tool in question. –Quiddity (talk) 21:58, 29 August 2013 (UTC)

I've never nominated any file for deletion on the Commons but have done two AfD...the first one I stumbled through by looking at others and copying codes/markup language. But I couldn't remember what I'd done and I messed up the second one. Luckily, two more experienced editors came to my Talk Page and walked me through the steps. But I probably need to refer to that conversation thread if I nominate another AfD.

For one thing, the instructions are not obvious. Now, probably someone will come by and give me the link to the instructions which appears somewhere on the AfD main page but it should be more prominent, not hidden two thirds of the way down the page. It's easy to find pages that give you criteria for deletion but the "how to" (what templates you use, notifying the creator, where you post the rationale, creating a separate discussion page, etc.).

In contrast, I think CfD is pretty straight-forward. There is one page and you add to the list, just post the category you're interested in deleting, merging or renaming, post your rationale and post a very obvious CfD template on the relevant category page. Done. Liz ^{Read! Talk!} 13:23, 30 August 2013 (UTC)

Oh yes, I expect CfD may well be straightforward if you just trust your intuition and fly by the seat of your pants. But have you looked at the instructions? They're a babylonian nightmare, a tl;dr labyrinth. I especially dislike the all-but-explicit hint that if you don't use Twinkle, you have only yourself to blame. Bishonen | talk 14:44, 30 August 2013 (UTC).

Bish: completely agreed. The manual process here has gotten so awful and convoluted that my workflow for nominating a page for deletion now involves enabling Twinkle temporarily, nominating the page, and then disabling Twinkle. It's terrible.

I think we need some kind of "Twinkle Lite" script that's auto-enabled for all editors that allows for simple, basic actions. It'd be good if it used real words in the user interface and not the fucking mess that Twinkle brings along (xfd, csd, blergh). In my ideal world, there would be a delete tab that everyone (including regular editors and admins) would hit that would advise CSD, prod, or XFD. And if CSD is selected, the admin could then delete the page immediately rather than tagging it. Otherwise, the script would auto-tag and auto-notify (similar to how Twinkle behaves, if you can find the appropriate link to click...). --MZMcBride (talk) 23:24, 31 August 2013 (UTC)

Thank you, MZMcBride. The first time I used Twinkle for the purpose of AfDing an article, I accidentally nominated WP:ANI for deletion instead.[1] I've rarely been more congratulated on an action, but it goes to show that if you're stupid enough, even Twinkle isn't so transparent as all that. And I'd sure prefer not to have to use it. Twinkle Lite that talks English sounds good to me. But, meanwhile, I still don't get why the "normal" nomination procedure has to be so much like.. er.. [insert your own favorite piece of dangerous, antiquated, cumbersome, clanging, needs-oiling machinery here, preferably with image]. Bishonen | talk 00:04, 1 September 2013 (UTC).

B: In many ways, the existence of tools such as Twinkle enable the problematic behavior and delay implementation of a better alternative. That is, when you have something like Twinkle that makes everything so easy, but the manual process remains difficult, everyone with sufficient resources and leverage (i.e., power-users) forget about the issue. Similarly, if the category rename bot or archive bots stopped working, power-users would care a lot more about how awful talk pages and category renaming are. For now, editors are content because bots/scripts make the overall process less painful. In other words, everyone who gets annoyed with the manual process (which is just about everyone) just enables Twinkle or doesn't nominate pages for deletion.

I imagine the process is so convoluted due to it growing over time without direction or purpose. It grew in the wiki way, which is fine for articles (to a point), but often doesn't lead to great software. Deletion processes need a major overhaul, but inertia is cruel. Implementing a "Twinkle Lite" option is the fastest solution because Twinkle is tested and field-ready (people use it every day here). But in addition to making the processes simpler with better user-facing tools, there are a number of inconsistencies and stupidities in the deletion process architecture itself (e.g., some use /day subpages while others don't). Rather than relying on Twinkle, which just abstracts away the underlying mess, we really ought to address the underlying architecture/design mess as well. We should try to make the processes as consistent as possible (between categories, stubs, miscellany, articles, templates, and files) and figure out what the user should be focusing on (e.g., writing a valid deletion rationale) and figure out what the scripts should be focused on (knowing whether to add the new entry to the top or to the bottom of the index, decoding exactly which subst incantation is needed with or without a signature, etc.).

mw:Flow is supposed to accomplish this major overhaul one day, but not for several years. Flow barely exists now and it remains to be seen whether it'll be the next "LQTv5" (a riff on LiquidThreads and ArticleFeedbackv5, two particularly adored Wikimedia Foundation initiatives). --MZMcBride (talk) 00:21, 1 September 2013 (UTC)

Hear, hear !!! —TheDJ (talk • contribs) 08:13, 1 September 2013 (UTC)

Is there any possibility that this conversation here would lead to a reconsideration of the Byzantine methods for manually nominating an AfD? Liz ^{Read! Talk!} 14:51, 1 September 2013 (UTC)

I think that WP:Flow is likely to improve the AFD process, but not until next year (at the earliest). WhatamIdoing (talk) 04:57, 2 September 2013 (UTC)

You should mix "VisualEditor" somewhere in there, MZ. Keφr 15:51, 6 September 2013 (UTC)

• +1 to all of this. The deletion processes should have been "wizard"-ized a long time ago, and in fact the instructions for manually making nominations are pretty much pseudocode already (open this page, add this template, fill out some fields, open that page...). Questions: (a) Who would we need to recruit to build a test version? The QuickDelete gadget on Commons appears to be maintained by Rillke (commons:User:Rillke). (b) What level of approval would be needed to switch it on here when it was ready, community or WMF? — Scott • talk 17:00, 9 September 2013 (UTC)

  (a) Any community member with JavaScript skills who is interested in helping. (b) Enabling gadgets only requires community consensus. The WMF do not need to be involved. – PartTimeGnome (talk | contribs) 22:11, 9 September 2013 (UTC)

I shall outline a somewhat more general problem, another which Twinkle partly alleviates — article tags. Currently they are normal templates, placed next to article content itself. This generates a yet another potential for misuse and misinformation: falsely dating maintenance templates, breaking markup, inserting false protection icons. Templates like {{pp-semi}} should not exist: protection icons should be provided by the MediaWiki software. {{unreferenced}} should not be a template put inside the page markup, it should be a feature of MediaWiki which actively keeps track of maintenance issues. Same goes with AfD notices. Nothing stops vandals or spammers from removing or backdating them, besides page protection, but this is obviously discouraged. If we had a system which understands tags and can put some restrictions on their use, that would

They say that Flow is about to fix the discussion issues — good. About the bloody time. But I think it will miss the point if we do not also recognise problems in the larger picture. Twinkle is a patch around the general technical ineptitude of Wikipedia's software. Ideally, it would not exist at all. Keφr 15:51, 6 September 2013 (UTC)

What's messing with Citation templates?

As of this morning, and not before, I noticed red errors about "Missing or empty URL" and "|accessdate= requires |url=" all over the reference sections of both Audie Murphy and Audie Murphy honors and awards. On the honors and awards page, the very first reference that has the red error about the missing URL, this is the exact citation:

cite web|title=Memo from Major General Kenneth G. Wickham, listing Murphy's awards and decorations|publisher=U.S. National Archives and Records Administration|date=October 20, 1966

Even on some of the red-errored citations in the main article, if I go in and delete the blanks for URL and Accessdate, it still shows up as errors. Given that these articles have been in 2013 subject to scrutiny by Peer Review, GA Review, and a fairly recent A-Class Review at Military History project, this would have been noticed. I monitor these articles everyday. This just showed up today.

And yet, as I write this the article Audie Murphy filmography does not have the red errors. But it did about half an hour ago. What is going on with the citation templates? — Maile (talk) 17:32, 1 September 2013 (UTC)

One thing I am noticing, not only on the above pages, but even this one typing on, and all articles right now. Below where it usually tells you the hidden categories and templates used in the page and pages transcluded...it's all blank. — Maile (talk) 18:00, 1 September 2013 (UTC)

Error display was recently enabled for citation templates, see Help:CS1 errors. {{cite web}} is not the right template if there's no URL available. Rjwilmsi 18:01, 1 September 2013 (UTC)

So what is the correct template? Please advise A lot of editors are going to have to redo some articles. — Maile (talk) —Preceding undated comment added 18:04, 1 September 2013 (UTC)

• Combination of cite design flaws and CSS bugs: The severe rules for {cite_web} now demand a "url=" with a "title=" parameter, even if the URL is an unrelated website (can be nonsense) or else get "Missing or empty URL" in the footnotes. So, when coding a {cite_web} with unknown URL, then set "url=http ://callmemaybe.com" or whatever. There is an unrelated bug which sometimes omits those red-error messages, probably due to handling of the related CSS class which styles the messages. Try re-redisplaying the page, and the CSS class might be reset to again show those red messages for wp:CS1-cite errors. -Wikid77 (talk) 18:07, 1 September 2013 (UTC)

  If you don't know the URL of a website, you clearly are not referring to it therefore should not be using it as a reference. – PartTimeGnome (talk | contribs) 20:32, 1 September 2013 (UTC)

We have been incrementally enabling error checking on the Citation Style 1 templates. Some of these errors were enabled this week.

Here, is a citation using {{cite web}} without linking a web site:

"Memo from Major General Kenneth G. Wickham, listing Murphy's awards and decorations". U.S. National Archives and Records Administration. October 20, 1966. {{cite web}}: Missing or empty |url= (help)

From the linked help page:

Missing or empty |url=

This error message is reported only by {{cite web}} CS1 citations where |url= is blank or omitted. The |url= parameter is required so that |title= can link to the web resource. To resolve this error, provide a value for |url= or use a more appropriate CS1 citation.

|accessdate= requires |url=

The |accessdate= is the date that the web resource addressed by |url= was added to the article. If |accessdate= has been included in the citation without |url= then this message appears. If the citation does not use a web link, then |accessdate= is redundant and should be removed.

--  Gadget850 ^talk 18:09, 1 September 2013 (UTC)

Pardon me while I get confused by "a more appropriate CSI citation". I don't know which one that would be. Are you telling me that if I pick any cite template but cite web, it will resolve it? Or what? — Maile (talk) 18:14, 1 September 2013 (UTC)

{{Cite web}} is intended for a web site, but the citation has no website linked. {{Cite book}} may be more appropriate. --  Gadget850 ^talk 18:19, 1 September 2013 (UTC)

Cite book also triggers the error. As do the others listed on CS1 citations, because they all have a blank for the URL. And if there's no URL, there's an error message. — Maile (talk) 18:25, 1 September 2013 (UTC)

OK, it's a little tedious going forward, but I think maybe I got it. Use the Cite book template, then go back afterwards and manually delete "url=" that it puts in there. Seems a step backwards for Wikipedia. Just wondering how many articles out there are now showing all these red errors when the original editor was confident they did it correctly. And how many errors are going to be triggered by new edits done by editors who don't know all these nitpicking tricks that have to be done on the cite templates. — Maile (talk) 18:31, 1 September 2013 (UTC)

There were over 50,000 articles which had similar errors. -Wikid77 (talk) 19:24, 1 September 2013 (UTC)

Blank |url= does not cause this error. --  Gadget850 ^talk 18:52, 1 September 2013 (UTC)

Ok. But taking it out resolved it. — Maile (talk) 18:54, 1 September 2013 (UTC)

Lua has made it much easier to detect these little errors that have gone unnoticed for years. They vary from the inappropriate that worked after a fashion (such as {{cite web}} for a printed source) through typos (such as |dtae= for |date=) to the completely unimplemented (such as |printer=). Detection of all of these problems was implemented several months ago; most error messages were hidden but opt-in. Periodically, some of them have been revealed to all users, with the latest batch being a couple of days ago, which is why you're suddenly seeing them; whereas those (like me) who opted in already will have been seeing those messages for some time. --Redrose64 (talk) 18:56, 1 September 2013 (UTC)

This was the last set of error checking to be enabled, so you don't need that CSS to see them anymore. --  Gadget850 ^talk 18:59, 1 September 2013 (UTC)

Thanks to all of you for your help and guidance on my resolving this where I have noticed it.— Maile (talk) 19:06, 1 September 2013 (UTC)

Thank you for realizing how using {cite book} was the fastest fix, until we get time to recheck those 130 cites which displayed the 90 wp:CS1 red-error messages in the major article "Audie Murphy" (1,640 pageviews per day). I can understand it was quite a nightmare in a highly visible article which had been improved for years. -Wikid77 (talk) 19:24, 1 September 2013 (UTC)

The citations you see on that article now are mostly mine, with some exceptions. Revamping the article starting in Feb 2013 necessitated researching and replacing almost all the existing citations. I didn't do it alone, but it was a step through the looking glass, and everything I had learned before at Wikipedia seems minor in comparison. — Maile (talk) 21:00, 1 September 2013 (UTC)

I have already asked, elsewhere, for these warnings to be turned off while the proposed bot fixes the existing errors. They can then be turned on again to warn when new instances of the error occur. @Redrose64: @Gadget850: How's that going? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:07, 1 September 2013 (UTC)

Why me? I stopped watching Help talk:Citation Style 1 over a week ago. I have little interest in WP:BOTREQ, mainly because I have no bot to operate, nor have I ever made a bot request. I have also never made an edit to Module:citation/CS1 or its submodules. Compared to Wiki markup, Lua code is a nightmare to trace through (I have few of the Modules on my watchlist, mainly for their talk pages), so I have no idea how or where to turn off the error messages. --Redrose64 (talk) 22:46, 1 September 2013 (UTC)

I'm savvy with template markup, but not Lua. I'm just applying changes made by the very few Lua programmers involved since the pages are edit-protected. --  Gadget850 ^talk 08:23, 2 September 2013 (UTC)

Fix Module:Citation/CS1/Configuration to reset each hidden=true

The numerous excessive red-error messages, in the wp:CS1 cites, can be re-hidden by fixing Module:Citation/CS1/Configuration to reset each newly activated message, back to "hidden=true" (set "false" on 26 August 2013 by User:Gadget850, see: dif410). For example, the message named by anchor = 'cite_web_url' (which displays "Missing or empty |url=") can again be hidden, as during the past 5 months, by setting the associated variable as "hidden=true". Do a similar reset to hide other messages which are flooding major articles with annoying messages about fixing dozens of URL parameters or other tedious busywork. -Wikid77 (talk) 21:23, 3 September 2013 (UTC)

Am I reading this correctly? That if an Admin fixes this at CS1, that will take care of the existing ones? Because I'm noticing these errors all over the place as I'm browsing. Whatever the GF discussions behind what has recently unleashed this across Wikipedia, it's not logical to think there are enough knowledgeable editors with the initiative to go through and correct each and every one. Especially not the casual new editors Wikipedia is trying to attract. — Maile (talk) 21:31, 3 September 2013 (UTC)

Indeed, Maile66, the cite error messages can be quickly re-hidden to match the consensus, the way many people use cite templates; see below: "#Consensus in usage prefers cite errors". -Wikid77 (talk) 00:16, 4 September 2013 (UTC)

If you hide error messages, the problem won't go away - you're just sweeping it under the carpet. The error messages help, because they expose everyday typos and so a fix can happen within minutes instead of a year or two down the line. Remember, Helpful Pixie Bot (talk · contribs), which detected and fixed many of these within weeks, is permanently out of commission. --Redrose64 (talk) 22:20, 3 September 2013 (UTC)

In a perfect world, or at least one where Wikipedia was as up-to-snuff as any other online fill-in process:

(a) That bot's daddy would be brought back from the Land of the Blocked, sins forgiven and totally rehabilitated

(b) All citation templates would have red-lettered "Required" next to the items that must be filled out. On a drop-down menu, the "Insert" button would not work unless the "Required" was filled out. Manually inserting a template otherwise without the "Required" information would not work.— Maile (talk) 22:47, 3 September 2013 (UTC)

Some perspective from someone who has been working on cleaning up these errors for three months:

• These errors point out minor problems with citations, each of which takes less than a minute to fix, on average.
• Yes, they are red.
• When I started working on the backlog of these errors, there were more than 140,000 of them in total (see Category:Articles with incorrect citation syntax).
• I have fixed more than 10,000 of them by myself in three months.
• The total number of errors is now about 120,000.
• A bot could fix another 45,000 of them in a single category (accessdate without url) in a very short time.
• As far as I know, there are fewer than ten editors, probably more like three or four, working to resolve these errors in large numbers.
• If we had a couple dozen editors working to resolve these errors, along with a clever bot or two, we could get the total number of errors down to a few thousand in a couple of months.

If all of the people who are complaining about these errors would dedicate some time to fixing them instead, they would be gone in relatively short order. Let's get the red out! – Jonesey95 (talk) 06:03, 4 September 2013 (UTC)

• Cleanup will span years, showing WP's glaring errors: If 20,000 corrections took 3 months, then 120,000 more will likely span ~2 years. I was also hopeful, 5 months ago, to imagine, "Wow, once 2 million readers see all those glaring red-error messages, surely they will rush to fix them within a month!" However, not so. We counted the cleanups, over about 2 months, and it was the typical few here and there. Just like those top, grandstanding tag-boxes, "This page is an orphan" or such, few people wanted to rescue the poor-child pages, adopt them with wikilinks, or spend time on "care and feeding" of text. Everyone knows, "Do not air dirty laundry in public" (hint: they will not rush to wash it). Instead, people expected someone else would see the problem, and the red-error messages continued to scar thousands of pages for another year, showing the "horrible" red marks of Wikipedia's failed text, where someone appended the date, when they read a source, and it was severely noted as hidden, extra text after a cite (OMG, what could that date possibly mean at the end a cite?!?). Then the date is marked in red, which yells, "Invalid text (help)" help me!!! I mean seriously, who would even understand how a date, after a cite, was even a mystery problem needing "help"?? Listen, we do not need a Bot to fix these, because Lua is fast enough to auto-correct many problems during reformat: so with extra text after a cite, just show it there, no red. If someone misspelled "auhtor=" just use as "author" and keep moving. We will likely find 90% of errors to be auto-corrected by Lua checking the text, as roughly 108,000 of 120,000 auto-corrected, to leave 12,000 pages for human, manual inspection, as 12,000 possible major problems because the 90% of easy problems would be auto-corrected by Lua. Meanwhile, we see another obvious fix-it cleanup rate: the missing-URL cases are being fixed nearly 10-per-day, so among 9,000 pages, expect that fix-it rate to span over 2.5 years of red-error messages. We need to shutoff the red messages, and talk (again) about auto-correcting the parameters in the Lua code. -Wikid77 (talk) 09:00, 6 September 2013 (UTC)

Some alternative math: There are 117,000 articles left (about 3,000 have been fixed in the last two days, in other words). A bot can fix 45,000 quickly, leaving 72,000. One dedicated editor eliminated 10,000+ articles from the error categories in three months. A dozen dedicated editors could completely clear out the error categories in two months, assuming that the errors are fixable in approximately the same average time as the ones I have been working on. Judicious use of bots to fix problems like the "auhtor" parameter above would shorten that time even more.

This second part is anecdotal, but in my experience, much fewer than 90% of the problems can be auto-corrected. It's probably more like 50 or 60%, including the 45,000 articles with accessdate errors. Because there has been no error-flagging in the past, all manner of crazy stuff has been put into citation templates. – Jonesey95 (talk) 13:23, 6 September 2013 (UTC)

Consensus in usage prefers cite errors

We had extensive discussions in April/May 2013, about not showing all those wp:CS1 red-error messages in thousands of major articles, because people were not fixing the errors quickly, even after weeks of watching for cite updates. An ongoing survey of articles with cite-errors confirmed how thousands of editors were actively ignoring the cite-error conditions and merely kept coding {cite_web} or {cite_book} despite the error restrictions having been carefully explained for years in the template /doc pages. In fact, get this:  even with the glaring red-error messages showing a cite-error with a big message, some editors were still actively adding cite templates with invalid parameters, willfully refusing to fix the cites to avoid the red-error messages. The result of the discussion was clear: there was no consensus to show the wp:CS1 red-error messages, which did not herd the users to fix the cite parameters, and in fact, the consensus of usage was to allow the "invalid" parameters as a choice of the editors working on each page. People simply did not buy-in to the "you cannot think that way" restrictions in cite parameters. The alternative procedure, to trim the flagged cite parameters, was to quietly log the invalid cases into maintenance categories which some concerned Wikipedians could laboriously update to one-by-one fix the questionable cite parameters in thousands of pages (over 50,000 flagged pages in April). For example, one category where people keeping calling {cite_web} without a "url=" parameter still had over 9,000 pages by August 2013:

• Category:Pages_using_web_citations_with_no_URL - current count, 0 pages

The consensus of usage by thousands of editors was basically, "We do not care about mandatory URL parameters" and people kept coding many cite templates with only title, date, author or publisher, plus accessdate (etc.). It is just counterproductive, to fight the consensus of usage, and try to force people to set unwanted parameters by scarring their edits with glaring red-error messages which some of them ignore. -Wikid77 (talk) 00:16, 4 September 2013 (UTC)

• Since there is a clear and overwhelming consensus I will remove all error checking. Without error messages, there is no need to fix issues, so I will delete the categories. --  Gadget850 ^talk 00:27, 4 September 2013 (UTC)

Can a script be created, or does one exist, to check an individual article for citation errors? Without being alerted that an error exists it will be considerably harder to find and fix them, for those of us in the minority who would rather fix the errors.—John Cline (talk) 00:38, 4 September 2013 (UTC)

Messages can be re-hidden, as during past 5 months, then set personal custom CSS to show messages in pages. For example, edit your User:XX/vector.css pages and insert the line:

.citation-comment { display: inline !important; color: red; }

Users with custom citation messages can edit according to the warnings; however, prepare to discuss updates with editors of each article, who might prefer parameter settings considered as "invalid" and some users dislike cite templates totally and want to replace all with literal cite text. -Wikid77 (talk) 05:29, 4 September 2013 (UTC)

Perhaps something like User:GregU/dashes.js, only for citations instead of dashes. What the dash.js does, is add an itsy bitsy tab at the top of any article, and you just click the dash tab. — Maile (talk) 00:50, 4 September 2013 (UTC)

@Editor Gadget850: Do not.

—Trappist the monk (talk) 00:46, 4 September 2013 (UTC)

At this point I am retiring from the task of maintaining the citation system. There should be enough notes in the cite error messages and the citation templates for others to pick up. Over the past few years this has literally been a thankless task. Discussions ramble all over the place and become pointless and useless and we end up with multiple claims of consensus. I'm tired and this is no longer fun. --  Gadget850 ^talk 01:01, 4 September 2013 (UTC)

Please accept my belated thanks for your service to this encyclopedia, over the years. You were one of the first wikipedians, let alone administrators, who I interacted with when I was a new editor. I continued editing to this day as a direct result of those interactions. You earned my respect long ago, and will always be esteemed by me.—John Cline (talk) 01:13, 4 September 2013 (UTC)

This is regrettable. I for one am sorry to see you leave. You did much good work here and even though most editors ever hardly gave your labors a second thought, I suspect that they, as I do, appreciate all of the good work you did.

—Trappist the monk (talk) 01:21, 4 September 2013 (UTC)

Thanks. Time to take a break, then find something I can be passionate about again. And after cleaning out MediaWiki messages, templates, categories and other citation related pages, my watchlist is 1141 pages lighter. --  Gadget850 ^talk 01:49, 4 September 2013 (UTC)

IMO, the red is of little use for readers, but it's useful for editors who can correct these errors. i think that it should not be all that difficult to make it so registered users will still see red/warnings, and anons will have the warnings hidden (maybe using Mediawiki:Group-users.css ? i'm not 100% sure, but i think it should be possible, without even depending on JS). peace - קיפודנחש (aka kipod) (talk) 06:31, 4 September 2013 (UTC)

That is an interesting idea. Is there a css that applies only to logged-in users? If not, how difficult would it be to create such a css? And if there is, how difficult would it be to add css that would do what Editor קיפודנחש (aka kipod) has suggested?

—Trappist the monk (talk) 15:20, 6 September 2013 (UTC)

(untested): i believe the page in my message (redlinked, for now) should work. we do use MediaWiki:Group-sysop.css for CSS that only affects sysops. again, i did not test this feature, but it is my understanding that the same thing can be done for any user group, and i think all registered users belong to the group "Users". peace - קיפודנחש (aka kipod) (talk) 17:07, 6 September 2013 (UTC)

Just so I have clarity. The goal is to hide Citation Style 1 error messages from anonymous readers but show the error messages to logged in users. To do that we must:

1. Set citation_config.error_conditions ['error message'].hidden=true in Module:Citation/CS1/Configuration. This then makes the error messages have this styling: <span style="display:none;font-size:100%" class="error citation-comment">$1</span>
2. Create Mediawiki:Group-users.css, hoping that this is a valid page name.
3. Add this css to show all CS1 error messages to logged in users: .citation-comment {display: inline !important;} /* show all Citation Style 1 error messages */

Have I got this right? I know that I can tweak Module:Citation/CS1/Configuration/sandbox so that once Mediawiki:Group-users.css is created and the css added, this can be tested. Any idea where one goes to ask if this is possible? Any admins out there willing to assist in this experiment?

—Trappist the monk (talk) 23:22, 6 September 2013 (UTC)

Sadly this won't work. Neither MediaWiki:Group-user.css nor MediaWiki:Group-users.css are recognised by MediaWiki. If they were, those links would be blue. Pages in the MediaWiki namespace are blue links if MediaWiki recognises the name, even if local admins have not created the page. (E.g. MediaWiki:Group-bot.css is a blue link, though the page does not exist here.) For something close you could use MediaWiki:Group-autoconfirmed.css instead.

It seems the "user" group is a special case that doesn't get its own CSS page. The "*" group (all users, including IPs) is another special case, but at least it makes sense not to have CSS for that since MediaWiki:Common.css also applies to all users. – PartTimeGnome (talk | contribs) 13:32, 8 September 2013 (UTC)

So conceptually it will work right? The only difference is that newly registered editors who haven't met the 4-day, 10-edit criteria don't see the CS1 error messages. The list of stuff to do then changes to this:

1. Set citation_config.error_conditions ['error message'].hidden=true in Module:Citation/CS1/Configuration. This then makes the error messages have this styling: <span style="display:none;font-size:100%" class="error citation-comment">$1</span>
2. Add the following css to MediaWiki:Group-autoconfirmed.css:

.citation-comment {display: inline !important;} /* show all Citation Style 1 error messages */

Can be quickly tested in the same manner as I described above. Does this work? Any admins out there who will help me test this?

—Trappist the monk (talk) 19:28, 8 September 2013 (UTC)

Yes, that should work as you describe. I can't try it myself, not being an admin here. (And if I were an admin, I'd probably want to see a wider consensus before implementing a site-wide change.) – PartTimeGnome (talk | contribs) 21:19, 9 September 2013 (UTC)

Understood. There seems to be a necessary order of things. First figure out if the proposition is technically possible. Second, make a brief test to prove that it works without inappropriate side effects. Third, some sort of wide-spread RfC to figure out if the proposition is really needed.

—Trappist the monk (talk) 09:09, 10 September 2013 (UTC)

RfC

Should we turn of the latest batch of error messages, temporarily, until this bot (or another) has completed fixing those that can be automatically resolved? Please comment at Help talk:Citation Style 1#RfC. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:49, 5 September 2013 (UTC)

About the system ssl

It would be possible to move to the SGC system or the system SSL 3.0 or maybe XMPP? João bonomo (talk) 15:40, 2 September 2013 (UTC)

Moving what exactly? And why? --AKlapper (WMF) (talk) 11:19, 3 September 2013 (UTC)

to make the site safer. João bonomo (talk) 17:06, 6 September 2013 (UTC)

Server gated cryptography is obsolete; enabling it would only benefit people with very old browsers.

SSL 3.0 is already supported by Wikipedia. However, it is an old protocol (circa 1996); modern browsers will prefer the newer TLS protocol, also supported by Wikipedia.

XMPP (formerly known as Jabber) is an instant messaging protocol; it is not useful for serving a website. Did you mean XAMPP? This package makes it easy to set up servers running Apache HTTP Server, MySQL and PHP. Wikipedia already uses all of this software, and I'm sure the ops team have systems in place for setting up new servers. – PartTimeGnome (talk | contribs) 22:16, 7 September 2013 (UTC)

They use puppet. Anomie⚔ 14:01, 8 September 2013 (UTC)

Better SSL suggestions

Wikipedia does not currently use perfect forward secrecy (PFS). If anyone is recording Wikipedia HTTPS traffic (e.g. dodgy governments) and Wikipedia's long-term private key becomes compromised, all the recorded traffic can be decrypted. PFS allows each connection to be encrypted with a different key; should a key be compromised, only the communication over that one connection is revealed.

Additionally, Wikipedia is using the RC4 cipher algorithm. Given the news this is possibly compromised,[2] I'd recommend switching to AES for browsers that support TLS 1.1 or later. (AES should not be used with TLS 1.0 because that combination is vulnerable to BEAST attacks.) – PartTimeGnome (talk | contribs) 22:46, 7 September 2013 (UTC)

See this post on wikitech-l, the configuration is being worked on. And the change for enabling GCM ciphers is in gerrit now. As for BEAST, I've read that for openssl it's not possible to use AES with TLS 1.1 but not TLS 1.0 (you could disable TLS 1.0 entirely, but that would lock out older browsers). Anomie⚔ 14:01, 8 September 2013 (UTC)

Thank You. João bonomo (talk) 14:55, 9 September 2013 (UTC)

Template is creating a hanging line break

Template:Infobox Minor League Baseball On pages where it is used as an infobox (e.g. Great Lakes Loons), it creates an extra line hanging above the text and I can't seem to get rid of it. Can someone help? —Justin (koavf)❤T☮C☺M☯ 01:00, 5 September 2013 (UTC)

Great Lakes Loons looks fine to me, as do the others that I looked at. --Redrose64 (talk) 11:32, 5 September 2013 (UTC)

Are you seeing this in VisualEditor, or when just reading the page? Whatamidoing (WMF) (talk) 16:57, 5 September 2013 (UTC)

Display I'm just using a standard MonoBook rendered with SeaMonkey but you're right: it looks fine now. Thanks. —Justin (koavf)❤T☮C☺M☯ 16:45, 9 September 2013 (UTC)

templates on mobile site

Hello, I am using the Mobile Wikipedia site but I don't see any templates anymore. I used to see them before and they were useful for navigation for me. Is there any way to enable templates on the mobile Wikipedia site? Skronie (talk) 03:22, 6 September 2013 (UTC)

Which templates are those? Please give an example of a page which is not working as you feel that it should; also an indication of which bits are missing. --Redrose64 (talk) 11:08, 6 September 2013 (UTC)

Hi! This is a similar, and possibly the same, problem.

In the mobile view of Oocyte, for example, the template succession box, which is at the end of the article text, is hidden by the last (collapsed) section. The succession box rightly should always be visible.

Is there a way to make it always visible? Or, is there a way to "break out" of the sections?

Thanks. Saintrain (talk) 13:17, 7 September 2013 (UTC)

It's "hidden by the last (collapsed) section" because it's part of the last section. Each section extends from a section heading to the next heading of the same or higher level, or to the end of the page. --Redrose64 (talk) 15:34, 7 September 2013 (UTC)

Thanks @Redrose64:. I know that's the problem. Is there a solution?

Is it possible to "end" the sections? Succession box implies a continuation, so putting it at the head of the article, above the sections, doesn't quite make sense. Hiding it in an unrelated section doesn't help either. Hence my questions.

Is it possible to form a section that doesn't collapse? Some sort of template maybe? Saintrain (talk) 04:10, 8 September 2013 (UTC)

In mobile view, the sections are defined as a series of <div>...</div> elements. The software that converts the wiki markup into HTML inserts the appropriate tags as follows:

<div id="content_0" class="content_block openSection"> after the page heading

</div><div class="section"> before each level 2 heading

</div> at the end of the article

I suspected that it might be possible to force early closure of a section by adding a </div> into the wiki markup (as here, but that's unbalanced, so it's removed by software that tidies up unbalanced closing tags, so it doesn't survive into the final page as served. --Redrose64 (talk) 10:44, 8 September 2013 (UTC)

Thanks again @Redrose64:. Oh well. Probably not even worth a feature request to MW. Such is life. Saintrain (talk) 18:25, 9 September 2013 (UTC)

any template that shows up fine on the desktop site like Template:Hindu philosophy shows up as blank on the mobile Wikipedia site. Any idea why? Can I reenable them somehow? Skronie (talk) 16:48, 7 September 2013 (UTC)

see this: [3] any answers? Thanks Skronie (talk) 03:32, 8 September 2013 (UTC)

I looked at it yesterday and again today: it's showing for me. The only issue that I notice is that it's full-width - but I believe that boxes always are in mobile view. --Redrose64 (talk) 10:44, 8 September 2013 (UTC)

Really? The template content does not show up for me even in my desktop browser. I'm using Chrome on both mobile and desktop. It seems OK on firefox though. Skronie (talk) 04:03, 9 September 2013 (UTC)

You didn't actually state your browser before this, so I've tested on Chrome 29.0.1547.66 m - and it's all there, just as it is in Firefox 23.0.1 --Redrose64 (talk) 12:45, 9 September 2013 (UTC)

This very same issue occurs on all archived/closed discussions (RfA, XfD, ANI, you name it); the closing template, along with the contents of discussions do not appear. hmssolent\^{You rang?} _{ship's log} 11:59, 9 September 2013 (UTC)

I'm talking about *any* template here, not just archived/closed discussions. I should've mentioned I was using the chrome mobile Browser before. This is a screenshot of how the template looks for me. Im using the latest chrome.Skronie (talk) 16:02, 9 September 2013 (UTC)

I think we need to get User:Maryana (WMF) or someone else from her team to join this discussion. Whatamidoing (WMF) (talk) 18:04, 9 September 2013 (UTC)

Thanks. I have requested her on the talk page to have a look. Skronie (talk) 15:15, 10 September 2013 (UTC)

Hi Skronie -- it sounds like there's two things here: 1) a bug with templates not showing up in Chrome. I'll raise it with the devs and we'll investigate. And 2) you've got a feature request to force open certain non-lead sections of an article in the mobile view. That might require some wider discussion on the pros and cons. Doing this on an ad-hoc per-article basis wouldn't scale across all the languages and projects we have, so we'd need some programmatic way to detect the templates in question. There's also the question of whether this really improves the user experience or not. My guess, based on the behavior of most readers, is it probably won't make much difference. We know that most mobile readers follow links to Wikipedia from Google or somewhere else on the Internet, only read that one article, and usually only make it through the lead section. I'm guessing the kinds of users who would be interested in seeing that template are experienced editors, and they're able to find it even if it's in a collapsed section because they know exactly where to look. Maryana (WMF) (talk) 16:47, 10 September 2013 (UTC)

@Skronie and Maryana (WMF): This would be due to this change. The best place to discuss would be either MediaWiki talk:Mobile.css or in the bug thread. Kaldari (talk) 18:12, 10 September 2013 (UTC)

Possible software glitch for collapsed text

Hopefully this Teahouse question won't be archived before someone looks at it. I couldn't see the text on the right when I clicked on "show". I asked about this thinking there was some glitch in how it was added to the page. User:PrimeHunter said there should be a scrollbar but there wasn't. He asked my browser, which is Internet Explorer 9.— Vchimpanzee · talk · contributions · 21:44, 6 September 2013 (UTC)

I looked at it for 10 minutes but gave up. I call it one more example of IE stubbornness. —TheDJ (talk • contribs) 13:19, 8 September 2013 (UTC)

Is it possible the software doesn't know to have a scrollbar because the text starts out collapsed and there's no need for it?— Vchimpanzee · talk · contributions · 17:16, 9 September 2013 (UTC)

By the way, I did see the missing text in the edit box.— Vchimpanzee · talk · contributions · 20:33, 9 September 2013 (UTC)

It's IE, it should be doing a whole lot of things that it isn't doing :/ (Like store autocomplete entries in a secure store instead of throwing them away without telling the user if he is using https). —TheDJ (talk • contribs) 20:37, 9 September 2013 (UTC)

User:VeblenBot/C/GAR/56

This archive page is not displaying all archived Good Article Reassessments very well. In fact, 50 percent is displayed, and the rest... are just templates or something like that? I tried discussing this to bot operator, but he is busy at this moment and will be back on November. Also, I tried in WP:AN, but the message I left will be archived in hours soon because almost no one responded there except me and bot operator. I'm hoping a fixture. --George Ho (talk) 05:18, 7 September 2013 (UTC)

This page is running into the template limits, specifically the Post expand include size-limit. —TheDJ (talk • contribs) 10:02, 7 September 2013 (UTC)

Archive 56 is getting too large. It contains 45 items spanning ten months. Archive 55 contains just 14 items over three months. I think it's time to start a new archive and move some stuff from the current archive into the new one. I'm not too sure how this archive system works. I notice User:Aircorn was the last person to update the archive number in Template:GARarchive, so I've asked them to comment here. – PartTimeGnome (talk | contribs) 14:14, 8 September 2013 (UTC)

Sorry, this is a busy time of the year for me and I have overlooked maintaining the archives. For reference some instructions on what needs doing are at Wikipedia talk:Good article reassessment/Maintenance. I will go through now and update everything. AIRcorn (talk) 22:27, 8 September 2013 (UTC)

Font changed

Tracked in Phabricator
Task T55734

Hi, what has changed in the last day to cause a change in the font of the text in the editing box. The box opens with the text in the font that it has been for some time then changes as the page loads to a thinner lined font. There is no change on Commons so must be something in the wikipedia set-up. Also how do you stop the change happening? Keith D (talk) 13:33, 7 September 2013 (UTC)

I saw this happening yesterday - just once - can't remember where (but yesterday, on one of the sister projects, I found that all of my preferences had been reset to default). There are two things to check:

• Preferences → Editing → Edit area font style: - I have mine set to "MediaWiki:Editfont-default".
• your browser's default monospace font - mine's set to Courier New. --Redrose64 (talk) 15:45, 7 September 2013 (UTC)

This is probably Template:Bug, aka "ULS strikes back". Matma Rex talk 16:55, 7 September 2013 (UTC)

I have set that option now. But interesting the browser default gives different results on Wikipedia and Commons. Keith D (talk) 17:39, 7 September 2013 (UTC)

I've just had that happen to me when logged out, when trying to work out some system messages when the edit window is open. It's replicable: this uses default language and is in monospace font; but this has uselang=qqx to reveal the message names and is in the sans-serif proportional font. This is in both Firefox 23.0.1 and Opera 12.16 --Redrose64 (talk) 19:07, 7 September 2013 (UTC)

Something, probably ULS, is injecting an inline CSS declaration (font-family: sans-serif;) into the textarea. This should probably only happen with some languages. — Edokter (talk) — 09:37, 8 September 2013 (UTC)

I'm having the same issue. Things look fine when logged out, but when I log in I get huge text in the edit box. I've tried all the obvious fixes - it happens regardless of which skin I use, which gadgets I enable/disable etc. 'Edit area font style' setting is already 'Browser default'. Modest Genius ^talk 22:00, 7 September 2013 (UTC)

OK, try this. At Preferences is the Language set to either "en-CA - Canadian English" or "en-GB - British English"? If so, alter it to "en - English". --Redrose64 (talk) 22:32, 7 September 2013 (UTC)

Ah yes, I'm on en-gb. Switching to simple en does fix it, thanks, though is clearly just a temporary solution and one I would prefer not to leave on permanently. Modest Genius ^talk 00:10, 8 September 2013 (UTC)

en-gb is discouraged because many en messages have been customized at the English Wikipedia, but usually not the en-gb messages. The setting only affects interface messages. See Help:Preferences#User profile. PrimeHunter (talk) 08:00, 8 September 2013 (UTC)

That sounds like poor practise in the customisation system, not a good reason to discourage the use of the language options. I speak en-gb, not en-us. What exactly do you mean by 'have been customized' anyway? Modest Genius ^talk 12:45, 8 September 2013 (UTC)

Our MediaWiki software is used by thousands of wikis and comes with hundreds or thousands of default interface messages in up to hundreds of languages (not all messages have been translated to all languages). The English Wikipedia can customize the messages, for example linking to relevant tools, help and process pages at the English Wikipedia. As an example, if an unregistered user or a user with the default "en" tries to edit a page they don't have permission to edit, or click "View source", then they see the customized MediaWiki:Protectedpagetext (it displays a little differently on fully protected pages). Users with en-gb see MediaWiki:Protectedpagetext/en-gb. The lack of a history tab means it hasn't been created at the English Wikipedia so it shows the default Mediawiki message: "This page has been protected to prevent editing or other actions." At Wikipedia:Village pump (technical)/Archive 115#Erroneous message on Watchlist I made a short list of the British spellings you get with en-gb. I personally think that either en-gb shouldn't be a language option at the English Wikipedia, or it should automatically display customized "en" messages when there is no customized en-gb message. Same for en-ca (Canadian English). PrimeHunter (talk) 13:36, 8 September 2013 (UTC)

Thanks for the explanation. I agree with the latter of those two possible solutions. Indeed, if anyone with en-gb set were to see a notice written in en-us, that would encourage them to 'translate' it as required. At the moment if they just don't see it, it never gets done because they aren't aware that there's another message. Finding some way for non-admins to do it would also help. Modest Genius ^talk 17:48, 8 September 2013 (UTC)

I believe that translations for the interface (various buttons) happen at https://translatewiki.net and that translations for documentation happen at https://mediawiki.org For example, if you want to create en-gb translations for VisualEditor, then go to this page on Translatewiki (you'll need a separate account) or start with this page on Mediawiki (your Wikipedia username/password should work there). Whatamidoing (WMF) (talk) 22:55, 8 September 2013 (UTC)

Translatewiki.net is only for translating MediaWiki's default interface messages. AFAIK, they do not deal with translations of our customised messages. If we are using a different message from the MediaWiki default, its translation should be done only on Wikipedia. (For a US message at MediaWiki:message, the British translation should be put at MediaWiki:message/en-gb.) – PartTimeGnome (talk | contribs) 21:46, 9 September 2013 (UTC)

• Out of curiosity, are there any actual uses of/for the en-gb and en-ca settings, here on English Wikipedia?

It's always seemed like a good way for tripling the amount of work that has to be done in keeping things updated... And if we're going to make a split for en-ca, why not en-aus, en-nz, en-sa, etc?

Apart from "centre, color, gray, organisation", it doesn't seem like we'd have much to worry about, and we might just use ENGVAR ourselves, instead of having these problems regularly...

Just a thought. –Quiddity (talk) 18:13, 8 September 2013 (UTC)

• I use en-gb and Monobook, and my font in edit windows looks to have changed to something very hard to read quickly. I haven't changed any default fonts anywhere. Is there any way I can get rid of this monstrosity? (The grey box at the bottom looks different, somehow, too. I can't describe it without having an earlier version available to me.) BTW there are (or were) differences in the display of en-gb. If this is a change to the US version, I want an alternative. This is ghastly. Differences I can describe include colons that are higher than the body of an e, and extra large = signs. I'm finding it hard to count the colons at the start of a line as the dots are almost invisible. Peridon (talk) 19:41, 8 September 2013 (UTC)

  Afaik, it's a change from monospace to sans-serif - you can fix it temporarily by changing to language "en". I'm not sure how they're planning to fix things, or how long it will take. As I noted above, I don't think you'll see any real difference by using "en", except you'll be guaranteed to get all fixes/updates.. –Quiddity (talk) 01:03, 9 September 2013 (UTC)

(Why do I usually get so angry when I come here?) Why the hell do they have to change things from something clear to read to this crap? I'd rather have Comic Sans, and that's saying something. I was sticking to Monobook and en-gb to AVOID the 'updates' (= 'downgrades' to my mind.). If it's a bug, you have my apologies (and my gratitude when it's fixed). If it's been done on purpose, those responsible are likely to be the objects of my curses. Sans-serif is good for headlines. For body text, a seriffed font is far clearer to read. Sans-serif may be more fashionable, but for easy reading, serifs beat sans-serif hollow. Peridon (talk) 17:21, 9 September 2013 (UTC)

I'm certain it's not intentional. It's definitely a bug, and it's being tracked on Bugzilla. – PartTimeGnome (talk | contribs) 21:53, 9 September 2013 (UTC)

Font changes in the source editor

Instructions to reproduce:

1. Edit any text in source. Note the monospaced, serifed font.
2. Go to Special:Preferences. Under "Internationalization", switch to "En-GB". Save the settings.
3. Edit any text in source. Text will be in a non-monospaced, sans-serif font. [There may be a slight delay]

This behaviour is apparently dependant on JavaScript.

The hell? Adam Cuerden ^(talk) 08:29, 8 September 2013 (UTC)

Discussed above at #Font changed. PrimeHunter (talk) 08:42, 8 September 2013 (UTC)

Thank you for template transclusion previews

I'm not sure how long it's been around for, who's responsible for it, or where it may have been requested or discussed, but I just noticed the template transclusion preview feature and I'd like to thank any and all who made that happen. I've been wishing for a feature like that for some time and this is a nice solution. For anyone interested, I made a script to add the feature to any namespace page, as transclusions often occur outside Template space: User:Equazcion/UniversalTransclusionPreviews. Equazcion ^(talk) 18:57, 7 Sep 2013 (UTC)

i think this is part of mw:Extension:TemplateSandbox, that was introduced less than a year ago, and which also brings us the Special:TemplateSandbox page (even stronger version than the preview, because it allows you to test changes to several templates at once, something that is sometimes needed when using sub-templates). peace - קיפודנחש (aka kipod) (talk) 19:16, 7 September 2013 (UTC)

You wanna thank Brad :) Matma Rex talk 19:20, 7 September 2013 (UTC)

Thanks Brad :) I can't quite fathom how the sandbox page works from the description (it could use some linked documentation) but it looks interesting. Equazcion ^(talk) 19:32, 7 Sep 2013 (UTC)

You're welcome! BJorsch (WMF) (talk) 14:12, 8 September 2013 (UTC)

• Example with Special:TemplateSandbox: For example, to test your own version of protected page Template:Cite_web, then create a page as "User:Equazcion/sandbox/Template:Cite_web" and run a Special:TemplateSandbox to preview any page using {cite_web}, or else enter whatever wikitext, with any pagename as filler (such as: WW, revision: 565418025), and the wikitext will override the display of page "WW" and only format that text with the templates under the name prefix "User:Equazcion/sandbox/". Otherwise, protected templates cannot be edited by normal users to run-preview the changes. Only Special:TemplateSandbox allows a run-preview for altering protected templates. -Wikid77 (talk) 05:21, 8 September 2013 (UTC)
  • Ah ok, I think I get it. Thanks for the explanation :) The page could really use some additional explanation. Maybe I'll write something up and propose it. Equazcion ^(talk) 06:57, 8 Sep 2013 (UTC)
    • Please do! There's a start at some documentation at mw:Help:Extension:TemplateSandbox, but it could probably use much improvement. BJorsch (WMF) (talk) 14:12, 8 September 2013 (UTC)

also, please note that the same "TemplateSandbox" can (and should) be used to test changes in Lua modules, not just templates. peace - קיפודנחש (aka kipod) (talk) 17:31, 8 September 2013 (UTC)

@BJorsch (WMF): I put together a little something at User:Equazcion/sandbox that I think might make the page more intuitive. My vote is to use the top line as a replacement for everything currently above the form, and add the collapsed help section below the form. It's collapsed so that when the preview shows up it isn't pushed down too much on the page. Equazcion ^(talk) 21:30, 8 Sep 2013 (UTC)

Question about VisualEditor

So, my question is, is VisualEditor part of the MediaWiki software package? If not, is it going to be at some future release? Or is it some sort of an extension that you can add on if you want to, turning it on and off at will? Say, for instance, that someone on another wiki wanted to install VE (crazy, I know). Could they do that? ~Adjwilley (talk) 02:02, 8 September 2013 (UTC)

See mw:Extension:VisualEditor. It isn't part of the "core" software, but available as an optional extension. Legoktm (talk) 02:55, 8 September 2013 (UTC)

Many things at the English Wikipedia are extensions. See Special:Version#Installed extensions. PrimeHunter (talk) 07:11, 8 September 2013 (UTC)

Thank you both: that answers my question. ~Adjwilley (talk) 03:53, 10 September 2013 (UTC)

JS editing interface changes

I've just discovered that sometime in the last couple of weeks (since 28/8), the interface for editing .js pages (eg MediaWiki:Geonotice.js has switched from a "normal" edit window to a blue-tinted one with line numbering and a smaller, lighter-weight font. I can see the benefit for many use cases, but I personally find this distracting - any idea how to suppress it and return to the normal editor?

I'm using Chromium 28.0.1500.71 on Ubuntu 13.04, for what it's worth. (Note that this is not the same as the font discussion a few threads above - it's specific to .js pages, and does not involve a non-monospaced font) Andrew Gray (talk) 14:41, 8 September 2013 (UTC)

The leftmost button on the upper toolbar switches back to the regular edit box. I believe the setting is saved from edit to edit. Equazcion ^(talk) 14:46, 8 Sep 2013 (UTC)

Got it. I was skimming the toolbars but I think assumed anything new would appear at the right, not left - thanks! Andrew Gray (talk) 14:52, 8 September 2013 (UTC)

The button graphic makes it look like a tool to insert js comments, which is why at first I didn't notice it either. You're welcome :) Equazcion ^(talk) 14:55, 8 Sep 2013 (UTC)

• Extension:CodeEditor is where you can find the skimpy documentation on this new extension. You can file bug reports and feature requests (like a way to disable) on Bugzilla under MediaWiki Extensions as component CodeEditor Technical 13 (talk) 15:06, 8 September 2013 (UTC)

i love the ACE editor for code (both js and lua) and CSS, and i've been using it for years (by using a small snippet i copied from Brion's personal script page).

the only known "defect" is that it is not possible anymore to dit .js pages using the "old" toolbar: even if you check "Enable enhanced editing toolbar" off, js and css pages will show now the enhanced toolbar. personally i do not miss it one iota, but some people might (note that the old toolbar doesn't give you any value whatsoever on js and css pages. on the "enhanced" toolbar you can at least get some value from the search/replace tool). peace - קיפודנחש (aka kipod) (talk) 17:40, 8 September 2013 (UTC)

Nastaliq template broken?

Is the Nastaliq template broken? When I tried to load pages using it, I saw a flash of Nastaliq script and then it changed to the browser's "sans serif" font for Arabic. I looked at the HTML source and the template was fine there, but when I opened it in Firefox's Inspect Element the markup was rendered <span title="Nasta'liq" style="font-size: 125%; font-family: sans-serif;" xml:lang="und-Arab" lang="und-Arab">(contents)</span>. This problem manifested in FF 24 beta, IE10, and Chrome 30 beta. 140.182.204.229 (talk) 17:27, 8 September 2013 (UTC)

This may be related to Template talk:Script/Nastaliq#Edit request on 6 September 2013. --Redrose64 (talk) 22:29, 8 September 2013 (UTC)

CfDs in mobile view

It's rather difficult to navigate between CfD pages using the mobile view, as the header tab which contains the links to the previous and next days' pages doesn't appear in the mobile view. Any idea how to fix this? – Philosopher ^{Let us reason together.} 22:42, 8 September 2013 (UTC)

The navigation links at top of Wikipedia:Categories for discussion/Log/2013 September 8 are apparently made with substitution of {{CFD log day}}. The code says class="boilerplate metadata vfd". http://noc.wikimedia.org/conf/highlight.php?file=InitialiseSettings.php says:

'wmgMFRemovableClasses' => array(
	'default' => array(
		'base' => array(
			'div.stub',
			'div.sister-project',
			'.portal',
			'.boilerplate',
			'.hiddenStructure',
			'.medialist',
		),
		'HTML' => array(
			'.topicon',
		),
		'WML' => array(
			'.metadata',
		),
		'extracts' => array(
			'.metadata',
			'span.coordinates',
			'span.geo-multi-punct',
			'span.geo-nondefault',
		),
	),
)

I think this means that both boilerplate and metadata removes {{CFD log day}} from the mobile view. PrimeHunter (talk) 09:04, 9 September 2013 (UTC)

Watchlist "since last visit"

On my watchlist, new edits since I last looked in on a page are showing with a count followed by "since last visit". I've found this to be very helpful and it has made my editing more efficient. Thanks to whoever or whatever made that change. 03:37, 9 September 2013 (UTC)

That would be me. I'm glad that there's at least one more person that uses this! :D Matma Rex 10:24, 9 September 2013 (UTC)

Make that two more.... I noticed this yesterday (i think), and spent an hour or more puzzling over whether it really was new or just a result of my poor observation skills. Thank you, Matma Rex. Cheers, Lindsay 14:27, 9 September 2013 (UTC)

• Can one make it go away? its rather annoying and breaks reading the page due to some pages having it and others not. Werieth (talk) 18:30, 9 September 2013 (UTC)

Add the following to your common.css page:

PS. See Wikipedia:Customizing watchlists for info on letting your watchlist mark updated pages for you. The "updated since" tags are part of that watchlist feature, but most of them were disabled by community consensus.

My CSS page already had something similar I added what you suggested and its still appearing. Werieth (talk) 18:42, 9 September 2013 (UTC)

Are you sure you're using the Monobook skin? Try adding the code to your common.css page instead and see if that does it. Also remember to bypass your cache.

I am 100% sure that I am using monobook, I have bypasses my cache several times with no luck. I am still seeing (2 changes | 1 since last visit | history) on some items on my watchlist. Werieth (talk) 12:49, 10 September 2013 (UTC)

I don't see this feature instead. What should I look for? --CyclopiaCyclopia 12:55, 10 September 2013 (UTC)

Enable "Group changes by page in recent changes and watchlist (requires JavaScript)" here and "Expand watchlist to show all changes, not just the most recent" here. Matma Rex 13:34, 10 September 2013 (UTC)

Many thanks! --CyclopiaCyclopia 09:36, 11 September 2013 (UTC)

• Any updates on how to hide this annoyance? Werieth (talk) 12:32, 13 September 2013 (UTC)
  • Okay I think I see what you mean. You can add to your common.js page. This will remove the "since last visit" links. Only thing is, it will leave an empty "" where the link was supposed to be. Shortly after these "since" features were introduced, the developers were beckoned to add code that would make customization easy, and they did -- but you're using a non-default option to "expand" watchlist changes via your watchlist preferences; something that was neglected during these fixes. As a result there's no easy way (that I can see) to cleanly do what you want, but maybe someone else will come along and say there is, since I'm so often wrong.

Book tool PDF bugs and lack of support

I am unsure if this the right place to report this but the Book tool's PDF export function has been producing incorrectly rendered notes and references for several months, maybe over a year. For example, see meta:Book tool/Feedback#Bug: Notes and References all end up as Notes (it's worse than title implies).

I made this post at the above meta page: "This bug is still present, and is worse than described in that many notes and references do not appear at all in the PDF. Try w:Book:Overview of the Solar System and w:Book:Leonardo da Vinci." but I then suspected no one who can help is looking at that page.

The pediapress support links at meta:Book tool/Feedback all appear dead.

This bug maybe relevant but it is assigned to nobody. Or this one, over a year old and still unassigned. -84user (talk) 13:42, 9 September 2013 (UTC)

I think this is the same as Wikipedia:Village pump (technical)/Archive 116#PDF output of Wikipedia Page is Missing its References. --Redrose64 (talk) 16:26, 9 September 2013 (UTC)

You likely found the right bug reports, congrats. :) The "Collection" extension which provides this functionality is maintained by the Pediapress folks. As usual with open source projects they likely miss (wo)manpower which is a pity. I think that Wikimedia Foundation is aware of the problem and discussing a bit how to improve the situation in the long run. --AKlapper (WMF) (talk) 17:11, 9 September 2013 (UTC)

unencrypted page in login process

Tracked in Phabricator
Task T54206

I tried to view my watch list, but the site told me I was not logged in. I followed the link to log in, [4], and when I entered my account name and password, the site redirected my browser to http://wikimediafoundation.org/wiki/Special:CentralLogin/start?token=1239298853ccbe9a17ca0a2f1f9e1e10 (not the real token). While I don't understand the login mechanism, the redirection to a non-SSL page may indicate a weakness. —rybec 21:07, 9 September 2013 (UTC)

I have informed the proper developers of this potential problem —TheDJ (talk • contribs) 09:02, 10 September 2013 (UTC)

This sounds like bugzilla:52206. --AKlapper (WMF) (talk) 01:51, 11 September 2013 (UTC)

A bit concerned about revert notifications.

I recently edited the page for Crossfire, soon I recieved a rather alarming notification that my edit had been reverted, which was shcoking because it was generally good information (I thought), anyway upon going to the page it seems that someone had deleted only a single line of what I wrote but left the rest. In actuality this wasn't a revert, although the notification system seemed to think it was. While I'm thick skinned enough to deal with the changing nature of Wikipedia, I often hear that newcomers are often intimidate about pages constantly being reverted, I think that will only hamper participation especially if there's a difference between actual revertion and what the system thinks is revertion.

Deathawk (talk) 23:51, 9 September 2013 (UTC)

The person who reverted your edit may have clicked the undo button but only removed one line. As long as they click undo and submit, the system thinks its a revert. -- ^t numbermaniac ^c 03:06, 10 September 2013 (UTC)

@Deathawk: To expand a bit: an editor can click "Undo" and then do further editing to the article. In this case, the editor apparently deleted the standard text that "undo" will put into the Edit summary field, on the basis that he/she wasn't simply reverting you. But, as Numbermaniac pointed out, the MediaWiki software doesn't know that, so it assumed that this was just a full revert, and notified you accordingly. [Notifications are new at Wikipedia, so the proper etiquette for reverts probably needs some publicizing.] -- John Broughton (♫♫) 15:45, 10 September 2013 (UTC)

This sounds like a bug/flawed design to me. Can we disable it? Biosthmors (talk) 15:48, 10 September 2013 (UTC)

Pages randomly refuse to display

IE8, Windows 7, Monobook. In the last few days, occasional pages have started not to appear: I go to a page, the elements appear as they're downloaded, but as soon as everything's downloaded, the screen goes white. Completely white, as if the page had no code on it at all! At the same time, I know that things are downloading and not simply cached, since the little bar at the bottom right of the browser says "Downloading imagenamehere.png", "Accessing http://en.wikipedia.org/wiki/pagenamehere", etc., until it displays "Done" once completed. I can view the history page and the edit page fine (although I have to go directly to the URLs, since the tabs don't appear), but if I preview an edit, the screen goes completely white. I have no clue what's causing this, because it's rare — I've only encountered this on four pages, and all of them are just in the last few days:

• Commons:COM:ADMIN
• Commons:COM:VP
• Norway
• CAT:CSD
• Japanese yen Added at 02:26, 10 September 2013 (UTC)

At first, I thought it was something weird at Commons, so I asked for help at their VP (using Firefox, which didn't have a problem with either Commons page) but was given a snarky response and nothing that helped to resolve the problem. Now that I've encountered it on two vastly different pages here, I have no clue at all what's happening. Nyttend (talk) 23:57, 9 September 2013 (UTC)

These are the typical effects of a document.write statement being used somewhere in an async executed Javascript. You hardly have any JS installed on this wiki as far as I can tell, so my suspicion is a broken browser extension (which are also JS normally). —TheDJ (talk • contribs) 08:48, 10 September 2013 (UTC)

Blocking VisualEditor

Is there a means of preventing Visual Editor being used on a page? Something like {{nobots}}. Every time VisEd is used on Morse code the preformatted text gets screwed. SpinningSpark 00:39, 10 September 2013 (UTC)

See {{disable VE top}} and {{disable VE bottom}}, but I'm not sure if it's working at the moment. Don't forget to put up an editnotice so people kow that you're deliberately "breaking" it. Also, if you haven't already, then the problem with preformatted text needs to be reported/checked to see whether it's already in Bugzilla:. I don't recall running across that one myself. Whatamidoing (WMF) (talk) 01:18, 10 September 2013 (UTC)

Don't forget to chime in on Template:Bugzilla to remind WMF of how important it is to have an officially supported mechanism to do this.—Kww(talk) 02:12, 10 September 2013 (UTC)

I have added the template and it seems to work, even when the whole page is edited. @User:Whatamidoing (WMF) I added it as an example to Template:Bugzilla to which it seemed to be related. Please advise if a separate bug should be opened. SpinningSpark 09:21, 10 September 2013 (UTC)

User:Spinningspark, I'm pretty sure you've got a typo in that bug number. That one's about some plugin. Whatamidoing (WMF) (talk) 16:40, 10 September 2013 (UTC)

Whatamidoing (WMF), your right. Try Template:Bugzilla instead. SpinningSpark 16:57, 10 September 2013 (UTC)

Since there are already several different problems listed in that bug report, then I think adding this one there is acceptable. If it's not, then someone over at Bugzilla will split them off. Whatamidoing (WMF) (talk) 04:33, 11 September 2013 (UTC)

What happened to my common.css?

Last time I edited my common.css, apparently I added this, although I have no memory in doing so:

.mw-editsection-link-secondary { visibility: visible !important; }
.mw-editsection-divider { visibility: visible !important; }
.mw-editsection-bracket { visibility: hidden !important; }

What exactly does this do? Also, now there seems to be this syntax highlighting thing for the common.css, what's that? Thanks, -- ^t numbermaniac ^c 03:03, 10 September 2013 (UTC)

This was probably to do with the animated [ edit | edit source ] links that were provided by VisualEditor. The only one of these rules still having any noticeable effect would be the final one, which hides the square brackets surrounding the section edit links. — This, that and the other (talk) 07:12, 10 September 2013 (UTC)

Ah yes, now I remember I added that to stop the animated section edit links because they were breaking my iPad. -- ^t numbermaniac ^c 05:24, 12 September 2013 (UTC)

HTTPS Automatic When Logged Out

This happens even when I'M NOT LOGGED IN. This began happening two days ago and happens with EVERY article page I visit. Is there any way to prevent this from happening? Please help, thanks Ponorinc (talk) 03:50, 10 September 2013 (UTC)

Are you saying that you're logged in on https when you're logged out on http? -- ^t numbermaniac ^c 05:26, 10 September 2013 (UTC)

I'm confused by your question. What I'm saying is that when I'm logged out (and logged in as well) all Wikipedia pages I visit are Https automatically. Ponorinc (talk) 05:52, 10 September 2013 (UTC)

There are some browsers that remember (based on browser history) if you visited a domain using https, and will automatically direct you to https on subsequent visits. The way around that is to go to the url bar and explicitly edit the url to use http. You can also disable this in the preferences of said browsers, requires a bit of googling to figure out where exactly. —TheDJ (talk • contribs) 08:44, 10 September 2013 (UTC)

@Ponorinc:, which browser are you using? --Redrose64 (talk) 12:11, 10 September 2013 (UTC)

Redrose64 I use SRWare Iron which is basically a version of Google Chrome from what I know.

So here's what is happening now. I cleared all my cookies and cache and Wikipedia is no longer automatically using HTTPS when I'm not logged in. However when I'm logged in HTTPS is still automatic (is that normal by the way for every Wikipedia member)? The weird thing that is happening now is google.com (main search engine I use) is automatically HTTPS even when I am not logged in to Gmail or a Google account. This never happened before, Google was only HTTPS when I was logged in. Anyone have an idea why this might be happening? As you can probably tell I am not very knowledgeable about this stuff and want to ask anyone who knows what are the benefits of HTTPS vs HTTP (especially since every google page is now using HTTPS)? Also is there any way I can stop HTTPS from automatically being used on google? I appreciate any advice or answers. Ponorinc (talk) 15:55, 11 September 2013 (UTC)

HTTPS is used by default when you are logged in to Wikipedia; this is normal. If this causes you a problem, you can turn it off in Preferences → User profile → Basic information → Always use a secure connection while logged in. You will need to log out and log in again (and possibly clear your cookies) for the change to take effect.

I noticed Google.com are also HTTPS-by-default a little while back (I don't have a Google account). I don't know how to disable this (it doesn't bother me), though someone else might know. This is unrelated to Wikipedia using HTTPS. Google are probably doing it for similar reasons, and might have been inspired by our own switch to HTTPS-by-default.

As for the benefits of HTTPS... Your connection to Wikipedia passes over lots of other computers before it reaches Wikipedia, including your ISP's systems and the Internet core routers. These systems are controlled by many different organisations, any of which can easily capture the data you exchange with Wikipedia (possibly at the behest of the NSA or other government organisation). Furthermore, if you are using open wifi, anyone in range can capture the data you exchange with Wikipedia. There are also various attacks (e.g. DNS spoofing) that can divert your connection via some other computer.

HTTPS provides two main benefits: firstly, it authenticates that the website you are connecting to is who it claims to be. If someone tries to divert you to a fake Wikipedia site and you are using HTTPS, your browser will warn you. Secondly, HTTPS encrypts your communications so none of the computers between you and Wikipedia can understand them.

Why should you care who can see the data you are exchanging with Wikipedia? There are two very sensitive pieces of information you send to Wikipedia. The most obvious is the password you use to log in. Anyone who knows this can impersonate you, and can also see your e-mail address if you have set one. Less obvious is your login token. This is a very long number that Wikipedia sends to your browser when you log in. Your browser sends this to Wikipedia with every page you request, to confirm that you are logged in. Anyone who discovers this token can use it to impersonate you on Wikipedia until you log out. (For regular editors like yourself, someone else using your account would be an annoyance. In the case of administrators, someone else using the account could cause serious harm.) Less obviously, you might not want others to be able to track the pages you view; one can discover a scary amount about a person from their viewing habits.

Of course, there are also benefits to using plain HTTP. It's faster for a start, though depending on your computer and network connection you might not notice this. Some browsers handle HTTPS in ways that can be annoying; using HTTP can avoid these annoyances. E.g. there have been reports here that Internet Explorer doesn't include HTTPS pages in its browser history, nor does auto-completion of form fields work in that browser.

If HTTPS does not inconvenience you any way, keep it turned on. If it causes you problems, you need to weigh the inconvenience against the risks I outlined above and come to your own decision.

Sorry for the long reply, but I hope I have answered most of your questions. – PartTimeGnome (talk | contribs) 20:41, 11 September 2013 (UTC)

Thank you so much PartTimeGnome for the response. I have just two more questions and I'm done: I already use an antivirus and firewall for security (AVG), do I really need the "extra" protection of HTTPS if I already use an antivirus program? When you say HTTPS can run websites slower does that affect only websites using HTTPS (i.e. Google, Wikipedia, Facebook - these are the only 3 sites that are using HTTPS-by-default for me) or will it slow down EVERY website I'm accessing on my browser? Again, thanks for the information on this issue!! Ponorinc (talk) 03:56, 12 September 2013 (UTC)

I would think an antivirus/firewall protects info entering and leaving the computer; if someone intercepts your password on the way from your computer to the server, the virus/firewall program wouldn't really do anything. Just for the record, HTTP sends plain passwords, HTTPS encrypts them first. -- ^t numbermaniac ^c 05:33, 12 September 2013 (UTC)

HTTPS isn't virus protection... it's to hinder The Man. Of course, any attempt to tighten personal security is going to look suspicious, so the Feds will open a file on you the instant they detect https - "what are they hiding?" --Redrose64 (talk) 12:45, 12 September 2013 (UTC)

Numbermaniac and Redrose64 are quite right: anti-virus/firewall software and HTTPS protect against different things. Anti-virus and firewall software protect your computer. HTTPS protects your information after it has left your computer.

To your other question, only websites using HTTPS are slower. Plain HTTP websites are unaffected.

RedRose64, using HTTPS by default means there are too many people using it for the Feds to pay close attention to all of them. To my mind, HTTPS is more useful for protecting your data from criminals than from the government. There are ways a government can work around HTTPS if they really want to see your data. For example, the US government could pressure Wikimedia or their CA to release the private key (enabling perfect forward secrecy would make that useless, though). They could get a CA to issue a fake certificate and use it for a man-in-the-middle attack. There are suspicions the NSA has cracked the cipher algorithm used on Wikipedia [5]. Your government could require you to give up your passwords or face jail (the UK has such a law), or use rubber-hose cryptanalysis (torture). All that takes effort of course, so HTTPS at least discourages casual government snooping. – PartTimeGnome (talk | contribs) 20:53, 12 September 2013 (UTC)

I'm pretty sure Redrose was being somewhat facetious. --Izno (talk) 23:49, 12 September 2013 (UTC)

It is possible that a site gets faster instead of slower with HTTPS if the server uses the SPDY protocol (which is negotiated in the HTTPS handshake). --cesarb (talk) 11:38, 13 September 2013 (UTC)

Attached KML/Ladrillero Channel

I added a {{Attached KML}} to Ladrillero Channel. The route of the Channel is shown, but near the Antarktis. Can any one tell me what is wrong?. I took Adelaide Avenue as example and changed the names and the coords. --Best regards, Keysanger (what?) 16:36, 10 September 2013 (UTC)

Well, I guessed right, and KML is "longitude,latitdue,altitude", not "latitude,longitude,altitude" like one would expect. Seems to work now. Chris857 (talk) 16:48, 10 September 2013 (UTC)

• Possibly related to the above - there is a problem with {{GeoGroup}} described at Wikipedia talk:WikiProject Geographical coordinates#GeoGroup Template URL encoding errors. I think it might be a double {{urlencode:}}. --Redrose64 (talk) 17:06, 10 September 2013 (UTC)

Thanks, I thought there were some (hidden) offsets for the coords, but now Google and Bing maps display the route at the right place. Why not WikiMiniAtlas?. --Best regards, Keysanger (what?) 22:18, 10 September 2013 (UTC)

The data in WMA must be updated. That is the reason. Thanks to all. --Best regards, Keysanger (what?) 08:05, 11 September 2013 (UTC)

Android app: Contact Us link not working

Tracked in Phabricator
Task T54474

In the Wikipedia Android app (v 1.3.4), the Contact Us link in the app does not work. It tries to navigate to http://en.wikipedia.org/w/index.php?title=Special:MobileFeedback&feedbacksource=WikipediaMobile%2F1.2, which says "No such special page". Could this be fixed? I had intended to follow this link to leave some feedback about the app itself, specifically the persistent loading of the Article of the Day page upon startup, which can be annoying. Thanks. --Jameboy (talk) 20:24, 10 September 2013 (UTC)

The problem you are reporting sounds like a potential issue in the code of the MediaWiki software or the server configuration. If the problem is reproducible, it would be nice if somebody who has this issue could send the software bug to the 'Bugzilla' bug tracker by following the instructions How to report a bug under product "MediaWiki extensions" and component "MobileFrontend". This is to make developers of the software aware of the issue. If you have done so, please paste the number of the bug report (or the link) here, so others can also inform themselves about the bug's status. Thanks in advance! --AKlapper (WMF) (talk) 01:56, 11 September 2013 (UTC)

I was just gonna file this, but I notice it was already reported a month ago. I've linked the ticked here and gave the devs a gentle nudge. —TheDJ (talk • contribs) 18:17, 11 September 2013 (UTC)

RFC on a new user right for trusted template coders

An RFC is under way to determine whether or not to create a new user right that would allow trusted template coders to edit fully protected templates: Wikipedia:Requests for comment/Template editor user right. equazcion ^(talk) 10:08, 11 Sep 2013 (UTC)

Accounts merged, signature not correct.

On 1/12/13 two accounts of mine were merged. User:Kevinrbing & User:Fortmac were merged in this edit: https://en.wikipedia.org/w/index.php?title=User:Fortmac&diff=532770745&oldid=532544335. However, when I go to create a signature on a talk page using \~\~\~\~ kevinrbing appears as the signature instead of fortmac. See here: https://en.wikipedia.org/wiki/Talk:Katherine_Sheehan or here: Kevinrbing (talk) 13:15, 11 September 2013 (UTC)

Signed, Kevinrbing (talk) 13:15, 11 September 2013 (UTC)

In preferences, check the User Profile / Signature section to see what you've got it set to. -- WOSlinker (talk) 13:20, 11 September 2013 (UTC)

Indeed. It's not really correct to say that your accounts were merged though, as that is impossible on Wikipedia. One of them was just moved out of the way. Graham87 06:46, 12 September 2013 (UTC)

Fantastic, thanks for the help. Fortmac (talk) 16:37, 12 September 2013 (UTC)

Edits to en showing up on de contributions

Hi all, Not sure if I am going mad, or if I have found a bug. I was looking at My de contributions, and a few of my EN edits show up on there. Anyone able to shed any light on this? Thanks, --Mdann52talk to me! 14:03, 11 September 2013 (UTC)

This is normal. It happens when an article (including its revision history, to satisfy the licence) is imported for translation.—Emil J. 14:19, 11 September 2013 (UTC)

Citation expander for ISBN/URL

There was a bit of talk here about Citation expander not working properly--from what I understand (see Wikipedia:Village pump (technical)/Archive 116) this is the thingy that fills in the blanks in the cite book template on the basis of GBooks URL or ISBN. A comment was made there, "The bot's maintainer has set the bot's account to not use SSL for now, as a workaround", but I have no idea what that is supposed to mean--whether a workaround means it's supposed to be working or not. Whatever it is, something's not working, and it's a drag: when that thingy was working it saved me eons of time and RSI. Can someone PLEASE fix this? Thank you. Oh, and while you're at it, can some smart person make something that allows the blanks to be filled in for the cite journal template based on a JSTOR stable URL? It would make my life almost complete. Drmies (talk) 17:47, 11 September 2013 (UTC)

Please fill out two bug reports / feature requests at User_talk:Citation_bot. The bot's developer is working on a revamped version of the bot, and he has been responsive to my bug reports in the last month or so. – Jonesey95 (talk) 18:38, 11 September 2013 (UTC)

Thanks--but the page says new feature requests are no longer accepted... Drmies (talk) 19:05, 11 September 2013 (UTC)

Actually, |jstor= support is supposed to be an existing feature. Do you have an example of it not working? LeadSongDog come howl! 19:58, 11 September 2013 (UTC)

I don't understand the question, sorry. Drmies (talk) 23:25, 11 September 2013 (UTC)

Tool to calculate total number of articles user has edited

Is there any tool on Labs or Toolserver where an editor can find out how many articles they're contributed to? Not the total edit count per editor, but the article count per editor and/or project article count by editor. I've seen on some user pages where there are claims such as, "I've contributed to over 30,000 articles" or "I've contributed to 7,000 articles on this project" and wonder if that's a personal calculation, or there is some tool that calculates that for them? If there is no tool available to verify such a claim, it seems to me one could claim anything they want about their editing history.— Maile (talk) 12:53, 12 September 2013 (UTC)

http://tools.wmflabs.org/xtools/pcount/ might be what you're looking for. equazcion ^(talk) 12:56, 12 Sep 2013 (UTC)

Thanks. — Maile (talk) 13:06, 12 September 2013 (UTC)

That tool gives you total edits in article space as well as all the other namespaces. He wants an article count. Betacommand has informed me that a tool to serve this purpose will be up shortly.—cyberpower ^Chat_Offline 13:44, 12 September 2013 (UTC)

When this tool debuts, can someone please post here at the Pump so users will know it's available. Thanks. — Maile (talk) 14:32, 12 September 2013 (UTC)

Well, it does give you a "unique pages edited" count, but true it does currently include all namespaces and not just article space. equazcion ^(talk) 14:04, 12 Sep 2013 (UTC)

The temporary link to this tool is http://tools.wmflabs.org/betacommand-dev/refs/article_count.py?user=Maile66 . This function will be integrated into the edit counter in the near future.—cyberpower ^Chat_Online 15:18, 12 September 2013 (UTC)

Got it. Thanks. That certainly is a different figure than the Edit Counter's "unique pages edited" (whatever that terms means?). — Maile (talk) 15:25, 12 September 2013 (UTC)

Here's what I have been using: X's Edit Counter - old server —Anne Delong (talk) 16:14, 12 September 2013 (UTC)

Unique pages edited is the number of different pages in all namespaces where you have made at least one edit. It's probably easier to verify if you reduce the sample size - for example, at French Wikipedia, I have made 13 edits in all namespaces, and of those 13, three (two to fr:Utilisateur:Redrose64 and one to fr:K8) were not my first edit to that page. That leaves ten; and X!'s Edit Counter states "Nombre d'articles différents édités: 10". Taking article space alone, I have 9 edits in total, of which one was a second edit, so I've edited 8 different articles. --Redrose64 (talk) 17:04, 12 September 2013 (UTC)

Misplaced tabs when zoomed in

Dear editors: Because of poor eyesight I often view web page text a little larger than usual by using the "Control +" feature in Firefox. I've been doing this successfully with Wikipedia for months. In the last couple of days, though, when I use this key combination the tabs at the top of each article or talk page display correctly for a moment, and then everything after the "Talk" tab shifts down and completely obscures the title of the article, while the first two tabs remain in the correct locations. I think what previously happened instead was that the search box would be shortened or some of the options would appear as dropdowns, but I can't remember exactly. This seems like a bug. —Anne Delong (talk) 12:55, 12 September 2013 (UTC)

I have Firefox 23.0.1 and use the View/Zoom In option from the menu bar. What I see on the menu selection is that the Zoom In is the equalivant to "Control ++", and I assume that's what you are referring to. I haven't noticed anything new or different. Generally speaking, the page zoom remains permanent from login to login at all Wikipedia articles unless I decide to change it. — Maile (talk) 13:03, 12 September 2013 (UTC)

I just tried this out, and it does seem that when the right and left tabs meet due to a high zoom level, the right Vector tabs move under the left tabs. I don't have any way of knowing if this was always the case or what may have occurred in the past, though, and I'm not sure how it could be corrected if unintended. equazcion ^(talk) 13:06, 12 Sep 2013 (UTC)

I don't get this in either Vector or Modern skin, so maybe there is another contributing factor that makes it happen for you and Anne Delong. It seems to me that a year or so ago, I was getting a phenomenon with article title coordinates dropping down into the text, and somebody fixed that. — Maile (talk) 13:16, 12 September 2013 (UTC)

It has always been this way, ever since Vector was introduced. I'm positive there is a bug ticket for this, but i can't find it right now. —TheDJ (talk • contribs) 13:43, 12 September 2013 (UTC)

Well, since it seems that it doesn't happen consistently, perhaps I've been doing something differently. I notice that when I rotate my laptop/tablet to portrait mode, I actually have to zoom out substantially before the page tabs look normal. In any case, it's not a problem for me; if I want to see the article title I can always zoom out temporarily; the title text is certainly large enough even when other text is small. I just thought if it was new it should be reported. —Anne Delong (talk) 15:14, 12 September 2013 (UTC)

It depends a lot on the available space. So if the tabs or something grew by just 1 pixel, that might perhaps be enough to put it over the edge at your preferred zoom level in combination with your specific screen width. —TheDJ (talk • contribs) 17:15, 12 September 2013 (UTC)

Yes,I understand that; I have written software myself. However, in the past when there wasn't enough space, more sensible things happened, such as moving some items to a pop-down list, making the search box narrower, etc., rather than covering up the title of the article. Anyway, I was not complaining, just pointing out a possible bug. —Anne Delong (talk) 21:38, 12 September 2013 (UTC)

Question re. embedding third-party fonts on wp pages

here. Yaan (talk) 17:04, 12 September 2013 (UTC)

Scrolling past the bottom of the page...

I've never encountered this before but whenever I go to the PRISM (surveillance program) article I am able to scroll past the bottom of the page. I've closed my browser and opened it back up and manually went back to the article and the problem is persistent so it was not a one time deal. I took a screenshot where you can see that I'm at what should be the bottom of the page but the scrollbar on the far right you can see that I can keep on scrolling but nothing is there but white. Anyone have any clue as to what is going on or if this is a bug or something that can be rectified? Thanks, — -dainomite   03:58, 13 September 2013 (UTC)

• The current version of the page works fine for me in Firefox for Mac 23.0.1. As always with reports of this sort, it helps to know what web browser you are using. It also helps to tell us which version of the page you were viewing by pasting in a link from the History page, if you know how to do that (right-click or ctrl-click on the date/time stamp in the View History page and choose Copy Link, then paste it the way I did at the beginning of this response). – Jonesey95 (talk) 04:17, 13 September 2013 (UTC)
  • This is happening for me too on multiple pages, including that one, with Chrome 29.0.1547.65. Other example pages where it happens: Roy Lichtenstein, Carolina Panthers. I already looked at the wikicode for both of those pages, as well as the nav footers used on them; whatever it is, it's not something obvious. Maralia (talk) 04:32, 13 September 2013 (UTC)
    • It occurs for me also on those same pages you linked Maralia. — -dainomite   04:40, 13 September 2013 (UTC)
  • (edit conflict) My browser is SRWare Iron, version 27.0.1500.0 (201000). Actually that version history of the article it does it still, scrolling below the end of the article that is. If I have to provide anything else please let me know. thanks, — -dainomite   04:33, 13 September 2013 (UTC)
    • I think it has something to do with the {{reflist}} template. Removing those from the page eliminates the issue. PS. Tested in Chrome 29, I do experience it on that page, when the reflists are there. equazcion ^(talk) 04:51, 13 Sep 2013 (UTC)
    • PS. That particular page (PRISM (surveillance program)) has two reflists, and the main one (not the "notes" group) needs to be removed to fix the issue. Also note you can test this by merely previewing. equazcion ^(talk) 04:54, 13 Sep 2013 (UTC)
    • PPPPS. (or whichever one I'm up to) This seems to occur on every page with a long reflist -- and the longer the list of refs, the more space shows up below the page. It also does not occur when using the plain <references/> tag, but only when using the {{reflist}} template. equazcion ^(talk) 05:01, 13 Sep 2013 (UTC)
    • Inspecting the <ol class="references"> element in Chrome shows a height of 11656.015625px in the computed styles, which seems to be the reason for the long space. Not sure exactly what the cause of all that extraneous height is yet though. equazcion ^(talk) 05:22, 13 Sep 2013 (UTC)
• (edit conflict) I see this in Chromium 29.0.1547.57. It appears that Chrome has a bug in its handling of -webkit-column-width where it is processing the absolute positioning of the 'cite-accessibility-label' elements before applying the actual wrapping of the references list, which means that these elements wind up well off of what would otherwise be the end of the page. These elements appear to have been added in this change to the Cite extension (as an attempt to fix Template:Bug) which was deployed today along with 1.22wmf16.
  @Graham87 or anyone else who knows a11y: is there a sane way to do this rather than having a span with complicated CSS to try to take it out of the page flow? Anomie⚔ 05:38, 13 September 2013 (UTC)
  • Yes, by using WAI-ARIA labels, but that behaves inconsistently with screen readers and doesn't work with NVDA. I've been in contact with Marius about these accessibility changes; we first tried the ARIA labels until we found the aforementioned problems, which is why CSS was used. As an aside, do any such problems occur with changes to Template:Sfrac, where I used similar techniques? Graham87 06:53, 13 September 2013 (UTC)
    • If the template gets used in one of the later references on the page and a multi-column reflist is used, probably. That seems rather unlikely though. But does "1/2" read correctly? And display correctly for other browsers? Anomie⚔ 14:17, 13 September 2013 (UTC)

how to download all (but only) the articles that transclude a certain template

Hi, I need to download all the articles that transclude a template.

Is that possible? Or do I need to download the whole 9GB database dump?

The template I'm talking about is transcluded in approx 35K articles, so a lot less than 1% of the total.

So it feels like a huge waste of resources to download the whole database...

Does anybody know if this can be done and how?

Thanks a lot!

Azylber (talk) 04:43, 13 September 2013 (UTC)

Well you can use the "what links here" on the template, change the number to as big as possible and the scroll through all the pages of transclusions. You can do this with wget, but you have to ignore the robots policy to actually use it. And Wikipedia will not be very happy with you downloading 35000 pages in a few seconds, so do it slowly if you crawl the site. Graeme Bartlett (talk) 09:52, 13 September 2013 (UTC)

A better option would be to get a list of pages and then feed that in chunks to Special:Export. Werieth (talk) 12:31, 13 September 2013 (UTC)

You can use the API (help: mw:API) to download data about multiple pages at once. Matma Rex talk 12:52, 13 September 2013 (UTC)

Accidental double moves by pressing Back button

This seems like something that should be reported on Bugzilla, but the instructions say to report the matter here first when in doubt. So, that's what I'm doing.

In any event, I've noticed a problem when moving pages that I don't believe I've noticed before, or at least believe should be fixed. If I navigate away from the Move succeeded page that is displayed after performing a move and then press the back button, the move is attempted again. If the original move didn't require deleting the target page, there's no problem, as you get a screen notifying you that the target article has a history, which requires a confirmation of deletion. However, if the original move did require deleting the target page (so this only comes up if you're an admin), the confirmation to delete the target page is carried over even after you press the back button. The end result is that the article you just moved is now deleted and replaced by a self-referencing redirect.

If that was confusing, let me try to explain that this way:

Say you're trying to move an article from Location A to Location B, which has a history. You might do the following:

1. Attempt to move article to Location B.
   • Receive a warning (as an admin) notifying you that Location B has a history and asking you to confirm that you want to delete that to make way for the move.
2. Confirm deletion, and attempt move again.
   • Receive notice saying "Move succeeded".
   • History of unwanted page at Location B deleted. Article originally at Location A is now at Location B. Location A is now just a redirect to Location B.
3. Navigate away from the page.
4. Press the back button.
   • Receive notice saying "Move succeeded".
   • History of desired article at Location B deleted. Redirect originally at Location A is now at Location B (producing a self-referencing redirect). Location A is also just a redirect to Location B.

Unfortunately, fixing the mistake caused here can be a nightmare. You now have the history of two pages merged in the deleted history. You have to pick out the diffs corresponding to the article you want and restore those. God forbid if both of the articles involved have extensive histories or were of similar sizes (making it hard to pick out which diffs belong with each article). An example of where I made this mistake is at the Lui Chong article (see the deletion log; note two consecutive deletions marked as "Deleted to make way for move").

What should happen is, after you press the back button, you should get some sort of warning that your action will cause the deletion of the article that you just moved to Location B. That could come in the form of the standard red-box warning indicating that the target location [now occupied by the article you just moved] has a history or it could come with a browser-level "Please confirm that you want to resubmit this form" dialog box. However, the way this is handled now doesn't work.

Feedback on this issue, and whether I've posted it in the correct venue, would be greatly appreciated. -- tariqabjotu 05:17, 13 September 2013 (UTC)

For what it's worth, I've experienced this a few times over the years under Internet Explorer, but I can't remember which pages it occurred on ... I do remember that it was indeed very annoying. Graham87 06:39, 13 September 2013 (UTC)

Yeah and I have had it doing a requested move after someone else already did it. But all you have to do is move the recently moved page back and then restore the blatted one. So it's annoying but not as messy as you suggest. Usually the last mistakenly moved page is a redirect, so you lose nothing by scrapping that. Graeme Bartlett (talk) 08:48, 13 September 2013 (UTC)

@Graeme Bartlett: I don't believe we're talking about the same thing. It sounds like you're referring to situations where Location B, before any moves were performed, didn't exist, and where you have willfully requested the deletion of the target page when performing your move. In this case here, Location B, prior to all moves, already exists, with a history that needs to be deleted. So, at the end of the error, there is only one undeleted version at Location B (the redirect that was just at Location A). The histories of both the original page at Location B and the recently moved article from Location A have, by that point, already been merged through the pair of deletions. As far as I know, the only way to fix that is to select the diffs of the article you actually want (or the inverse of that) and restore accordingly. -- tariqabjotu 13:35, 13 September 2013 (UTC)

Global contributions

On the user contributions page there is a link to global contributions on the tool server. However that rarely works now. Is the a substitute on the WMFlabs? How do we find the new tools? Graeme Bartlett (talk) 08:42, 13 September 2013 (UTC)

Pop-up box when hovering over article title

When hovering over an article title, a pop-up box appears giving options (edit, history etc.) and the beginning of the lede. If there is an image, the options are moved down the page, the image inserted in the top LH corner and the options then move back up to the underside of the image. This makes selecting an option difficult, as the options are jumping about. When trying to click edit, I frequently hit, and open the image, or the article, as the options are moved down, or "what links here" as they move back up.

About 10 days ago the pop up box changed, moving the image to the right and stabilizing the options, albeit that they were moved to drop down menus requiring a second hover and a click.
About 2 days ago it reverted to the original jumping option. Why was this changed back? Is the stable version going to return? Can it be selected via some code?
Finally why do the options still include "Editors" which leads to a page stating "This tool no longer exists."
Arjayay (talk) 09:15, 13 September 2013 (UTC)

It sounds like you have installed WP:POPUPS and are using IE where you have used some pages with Compatibility mode, which would affect the capabilities that popups would have. —TheDJ (talk • contribs) 11:06, 13 September 2013 (UTC)

The answer in one - I had accidentally clicked compatibility view (which is far too close to the refresh button), but oddly, it wasn't showing up as selected. Thanks Arjayay (talk) 12:26, 13 September 2013 (UTC)

Last change

Dear editors: When I first joined Wikipedia, when I received a message on my talk page a large orange notification banner would appear. This has more recently been replaced by a smaller notification (an improvement, since it takes less screen real estate). The old one, however, had a "last change" link. I find with this new notification I often have to search the page history looking for the new message, since the notification doesn't include a last change link and clicking on it doesn't lead to the section of my talk page which holds the new message. Is there a setting that can fix this? If not, is something planned for the future to replace this useful feature? —Anne Delong (talk) 12:19, 13 September 2013 (UTC)

My notifications have a "view changes" link for each, which does the same thing. It's a small link in the lower-right. Is that not showing up for you? equazcion ^(talk) 12:22, 13 Sep 2013 (UTC)

Thank you. Even though I have a 16:9 screen, in order to keep the page header tabs from messing up ( see above), I have been leaving my browser zoomed out when navigating between pages so that I can see the page titles. At that zoom level the little words under the notification are unreadable to me. However, by zooming in I see that my solution has been there all along. I kind of thought that it was too useful a feature to have been omitted. Thanks again. —Anne Delong (talk) 13:47, 13 September 2013 (UTC)

Searching in version diffs, Version FAQ, Differences FAQ

Hello all,

I seem unable to find a place where this has been answered (if any) and I've been getting an unmanageable number of hits (all way off answering my question) for all keyword combinations I could think of. So in case this had been ansered elsewhere, sorry and could somebody kindly point me to that place.

I am looking for a way to search an article's version log for where a given portion of text was introduced. Example: Who added <ref>[http://www.br-online.de/bayern2/radiowissen/australien-aborigines-ayers-rock-ID1265712254426.xml Ayers Rock – Der Computer rettet Felsmalereien]</ref> to de.wikipedia.org/wiki/Uluṟu ? (or, for simplicity, when was Leung, Chee Chee (23 September 2003). "Lulu the kangaroo hops to the rescue". The Age (Australia). Retrieved 10 January 2010. added to Kangaroo ?, purpose being in a range of useful advanced actions such as quickly finding the contributor to discuss a detail or ask a question, determining the time a now broken link was added (such as in the de: example) in order to narrow the search for the original source, etc.

I'd like to suggest the answer to my question be entered on the WP search FAQ and/or WP versions FAQ (with creation of said FAQs if they don't exist), and adapting the current FAQ index. As it is, it is hard to tell from the FAQ index which FAQ to look in for the answer in the first place.

Any help appreciated, TIA --217.81.188.73 (talk) 13:32, 13 September 2013 (UTC)

Shortly after posting, I found that Help:Diff#Searching_diffs_to_spot_a_particular_change provides some kind of initial answer but makes it inconvenient, except for the hint to WikiBlame that makes it semi-convenient. I also found that finding this information took a fair amount of both creativity and luck (it was a fine-print link on Help:Searching that finally led me there). I wonder whether there's a realistic chance for further improvement. --217.81.188.73 (talk) 13:37, 13 September 2013 (UTC)

Template:Infobox person

Something interesting has happened to this template. —Anne Delong (talk) 14:07, 13 September 2013 (UTC)