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 (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, 90, 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

Category contents summary

What happened to the summary "preview" of categories? It used to be that one could see a quick summary along the lines of "(12 C, 68 P, 3 F)", indicating that the category contained 12 subcategories, 68 pages, and 3 files. Now, it appears as "(12 categories, 68 pages, 3 files)", leading to a monstrous mass of black text any time that a category contains a large number of subcategories (e.g. Category:Years in baseball). I strongly recommend reverting to the old format. -- Black Falcon ^(talk) 18:37, 24 August 2013 (UTC)

I did that. I found "(12 C, 68 P, 3 F)" to be terribly cryptic, so I wanted to try something more reader-friendly. (I only just discovered there is a tooltip, but that was not very obvious.) Perhaps there is a way to have less text, but not be as cryptic as the original labels. — Edokter (talk) — 19:16, 24 August 2013 (UTC)

i tend to agree with User:Black Falcon. if you think the tooltip is too obscure, maybe you want to underline the letters (or dash-underline them) to signal to the reader that there is a tooltip, like so: 12 C, 68 P, 3 F. peace - קיפודנחש (aka kipod) (talk) 19:33, 24 August 2013 (UTC)

That would have to be done in the software. I can't underline them without destroying the original tooltip. — Edokter (talk) — 19:48, 24 August 2013 (UTC)

(edit conflict) Thanks for responding. I see your point about "(12 C, 68 P, 3 F)" not being readily clear to someone who is not familiar with our category system. However, I don't think that this information (in either its condensend or expanded form) would be useful to such a person. After all, if one is unfamiliar with categories, what is the advantage of knowing that a particular category contains a certain number of subcategories, pages, and files? Or, to put it differently, I think of the labels as being for editors more than for readers. -- Black Falcon ^(talk) 19:34, 24 August 2013 (UTC)

I think that is a totally wrong assumption. Categories are just as important for readers as they are for experienced editors, and it should be easy for readers to readily understand how they work, without having to read yet another help page. Every element of Wikipedia's interface should be as intuitive as possible; there is absolutely no benifit from obsfucating such elements. — Edokter (talk) — 19:46, 24 August 2013 (UTC)

I think that Edokter is right, and I personally haven't found it to be difficult, although perhaps the categories I visit aren't the ones most likely to have the "monstrous mass of black text" problem. WhatamIdoing (talk) 19:57, 24 August 2013 (UTC)

That might be a factor. The visual impact of the change is limited when one looks at a category such as Category:Galloanserae; however, the impact is distracting when one looks at a category such as Category:Military units and formations of the United States Army by type. -- Black Falcon ^(talk) 20:36, 24 August 2013 (UTC)

I don't disagree, but I don't see how this change impacts that. If a reader knows what "category", "page", and "file" mean in the context of categorization on Wikipedia, then he or she could easily understand what "C", "P", and "F" stand for. If he or she does not know what "category", "page", and "file" mean, then listing them in their unabbreviated form is not going to change anything. -- Black Falcon ^(talk) 20:36, 24 August 2013 (UTC)

I tried making it a bit smaller, but these messages do not accept HTML; it leaks through unescaped. — Edokter (talk) — 21:02, 24 August 2013 (UTC)

You could style them via CSS using .CategoryTreeItem span[dir="ltr"] (based on a cursory look at the source code), although it feels hacky. Theopolisme (talk) 15:15, 25 August 2013 (UTC)

Too hacky, yes. The summary should have a class (categoryTreeSummary). — Edokter (talk) — 18:38, 25 August 2013 (UTC)

I understand (6 C, 15 P, 2 F) might be cryptic the first time it is seen, but for any category with more than a couple of subcategories the visual impact is massive, especially when you have the enhanced javascript triangles turned on allowing you to see the tree of subcategories. Mark Hurd (talk) 16:45, 25 August 2013 (UTC)

What do you mean with "enhanced javascript triangles"? — Edokter (talk) — 18:38, 25 August 2013 (UTC)

If the cat has subcats, then each entry under "Subcategories This category has the following x subcategories, out of y total." has toggles for expanding or collapsing the entries. They used to be look like [+]/[−] if expandable/collapsible; now they are ►/▼ respectively. --Redrose64 (talk) 19:46, 25 August 2013 (UTC)

I know that... I made them that way long ago. But they're not "enhanced javascript"; it's "plain old CSS". The expanding/collapsing is by virtue of the CategoryTree extension, which is enabled by default and cannot be turned off. Perhaps I'm thrown off by the comment "especially when you have the enhanced javascript triangles turned on", meaning he simply has the tree expanded? I was worried I might have missed an option for some 'enhanced' category page, like we have for watchlist. — Edokter (talk) — 20:08, 25 August 2013 (UTC)

you can question the use of the word "enhanced", but of course this is JS. saying that this is just "plain old CSS" is just wrong. peace - קיפודנחש (aka kipod) (talk) 20:26, 25 August 2013 (UTC)

The triangles are pure HTML/CSS. Only the expanding/collapsing is javascript. — Edokter (talk) — 20:33, 25 August 2013 (UTC)

Sorry for the confusion. I assumed it was a feature I'd turned on. Mark Hurd (talk) 11:36, 26 August 2013 (UTC)

Aug 25 2013 slowness

Slowness for hours this morning in loading English Wikipedia pages (to fully load, that is, one tab very slowly appears on the page, then the next one slowly appears, slowly, slowly). Also, Commons repeatedly times out before it can load. Wikisource and other languages Wikipedia seem to load fine.— Maile (talk) 15:36, 25 August 2013 (UTC)

Only thing I can see on https://wikitech.wikimedia.org/wiki/Server_admin_log are some low disk space issues. Is this still a problem today? --AKlapper (WMF) (talk) 11:07, 26 August 2013 (UTC)

I was logged off for several hours after I posted this. When I logged on again, everything was OK. Thanks for replying. — Maile (talk) 17:48, 26 August 2013 (UTC)

Putting two ISBNs in {cite book}

What's the way, if any, around this unknown parameter flag, e.g: "Albert Boime (2004). "William Holman Hunt's The Scapegoat: Rite of Forgiveness/Transference of Blame". In Ellen Spolsky (ed.). Iconotropism: turning toward pictures. Bucknell University Press. ISBN 978-0-8387-5542-6. {{cite book}}: Unknown parameter |isbn10= ignored (help)" ? Thanks. Martinevans123 (talk) 20:03, 25 August 2013 (UTC)

Just leave out |isbn10=0838755429. It has never been a valid parameter; the guidance at {{cite book}} is to give just the ISBN-13 in the |isbn= parameter. This is one of those perennial questions at Template talk:Cite book and other pages. --Redrose64 (talk) 22:12, 25 August 2013 (UTC)

Thanks. Apologies for being so annual. Martinevans123 (talk) 07:57, 26 August 2013 (UTC)

Edit conflicts and section editing

Tracked in Phabricator
Task T55446

I noticed recently on Talk:Chelsea Manning that I was getting edit conflicts while section editing, even though the edits that conflicted with mine were to a different section. I don't recall noticing this before, and Help:Edit conflict still says it shouldn't happen. Does anyone know whether something has changed? SlimVirgin ^(talk) 22:15, 25 August 2013 (UTC)

I can confirm this happening to me as well, at the same page. — Scott • talk 22:16, 25 August 2013 (UTC)

I did some manual archiving today of old sections, via section editing, but now that I look at the history, I see that almost no one else made edits while I was doing it, so I've stopped in case I was causing lots of edit conflicts. I got two edit conflicts during the archiving, and both were to sections other than the one I was editing. SlimVirgin ^(talk) 22:25, 25 August 2013 (UTC)

Already noted two days ago. My suggestion: don't post to that page without first reading the rest of it - somebody else is bound to have already said the same thing that you want to say. Are there any other high-traffic pages with this problem? --Redrose64 (talk) 22:42, 25 August 2013 (UTC)

That's the only one I've noticed it on. SlimVirgin ^(talk) 22:52, 25 August 2013 (UTC)

I recall that this happened at Death of Michael Jackson when that story was raging. Tarc (talk) 22:59, 25 August 2013 (UTC)

What's the best way to bring this to the attention of people who can fix it? I experienced seven edit conflicts and two saves that didn't take last night while trying to edit a section of Talk:Chelsea Manning. I would normally have given up but persevered to see how long it would take to get the edit saved. When I checked the history, seven people had indeed edited the article, but only three had edited that section. SlimVirgin ^(talk) 20:27, 26 August 2013 (UTC)

Please report a bug. Superm401 - Talk 08:33, 27 August 2013 (UTC)

Thanks for the link. SlimVirgin ^(talk) 01:42, 28 August 2013 (UTC)

According to Tim Starling:

Section editing has never had any special case to help with edit conflicts -- it was always dealt with using the generic three-way merge feature (...)

Helder 12:05, 27 August 2013 (UTC)

Yes, but if there's a new bug, it could be caused by either the section replacement algorithm, or the three-way merge itself. Superm401 - Talk 21:13, 27 August 2013 (UTC)

I don't understand Tim Starling's post. It's still happening by the way. I've just had two edit conflicts, though the others were posting in other sections, and yesterday I had seven. It's making interaction very difficult. SlimVirgin ^(talk) 01:42, 28 August 2013 (UTC)

Reported SlimVirgin ^(talk) 01:56, 28 August 2013 (UTC)

Nearby & replacing Google Maps' Wikipedia layer

It seems that Google Maps are retiring their Wikipedia layer. I'm awaiting confirmation, but if true, that's very sad. I was involved in liaison with Google to get that set up to use {{Coord}}, some years ago, and people I've showed it to have always found it useful. The problem is, Google kept it hidden away, so I wouldn't be surprised if stats showed that people didn't use it much - at least not as much as they might have done.

It strikes me that we could re-purpose some of the code used to generate Special:Nearby, and get it to spit out KML , whose URL could be passed to Google Maps, or any other KML-aware system.

Is that do-able? Or should we be building our own equivalent of the Google Maps layer, using OSM tiles on our own server? User:Kolossos did something like that, but it seems to be using an out-of-date or otherwise in complete data set - even so, switch (under "Optionen") to English or your language of choice. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:43, 25 August 2013 (UTC)

"The new Google Maps simplified navigation and removed many useful features... Layers like Wikipedia, weather, webcams, photos, videos, previous searches are no longer available, while transit, traffic and bicycling can be found in the "getting around" box." [1] Romaine (talk) 07:52, 26 August 2013 (UTC)

The "Nearby"-function is unusable to show Wikipedia-POI's on a map. The database behind the nearby-function doesn't support relevance-criteria, so you can use it only in highest zoom levels of a map. My database use a relevance-criteria the article-length and have also so additional, reduced databases-table to be fast on low zoomlevel. Last update is two week old, I could update more often if Toolserver would be faster or we would have PostGIS on Toollabs. --Kolossos (talk) 22:43, 26 August 2013 (UTC)

Thank you for the updated URL for your tool; that looks much more complete - a really impressive tool. Would it take the traffic if we publicised it more? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:17, 26 August 2013 (UTC)

I know little of what difficulties are involved, but hope a solution can be found for smartphones. I mostly use Google Maps for Android in the field, looking for unphotographed Wikipedia articles wherever I may be. Few days ago GM updated itself to v7, which is Wikiless. I was cast down into a blue funk until I found that I could revert to the old version. As for whether the need for a Wikimap on a phone screen would best be met by a new Wikimap for Android application, or an improvement of one of the old Wikimedia apps, or by something at the Wikipedia mobile web site end, I have no idea but hope something can be done before the old Google Maps for Android becomes unavailable. Jim.henderson (talk) 23:51, 26 August 2013 (UTC)

You can use my tool also to looking for unphotographed WP articles. It's a nearly unknown feature by using parameter "photo=no". --Kolossos (talk) 21:31, 27 August 2013 (UTC)

My understanding is that people are currently working on an OSM tile server (basically a renderer for OpenStreetMap's data). See bugzilla:33980. Once that is in place, it should be possible to add a Wikipedia layer with some extra work. I don't object to proprietary services using our data (as long as they comply with the license), but I think we should emphasize supporting the open ecosystem, which in this case means OpenStreetMap. Superm401 - Talk 06:22, 27 August 2013 (UTC)

Yes, we should wait for WMF's OSM-tile-server. The idea was also to merge my tool (OSM-Gadget) together with WikiMiniAtlas. We would use Leaflet instead of OpenLayers and would clean-up the interface. Additionally we would take more care for mobile. Any help for this development would be welcome. --Kolossos (talk) 21:31, 27 August 2013 (UTC)

Mobile: 'Title' coordinates not showing

Where we have a {{Coord}} template in an article with |display=title, the coordinates, usually seen at the top of the desktop view, are not visible in our mobile view. (This is also true of the title coordinates when |display=inline,title is applied, but this is less of an issue as the coordinates are displayed elsewhere on the page). For example, compare the desktop view of Casa Milà with its mobile view. How can we fix this? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:48, 26 August 2013 (UTC)

I suggest first thinking of a place where such coordinates should end up. Then file a ticket in bugzilla asking for the devs to take it into account. —TheDJ (talk • contribs) 13:06, 26 August 2013 (UTC)

I note that in the experimental mode of the mobile website, you get a globe, that takes you to Special:NearBy on those pages. Ideally, it would also have a "show on map" entry in there, showing the position of these elements (and the title element of course) in an OSM layer I think. —TheDJ (talk • contribs) 13:30, 26 August 2013 (UTC)

The coordinates span is specifically striped from the mobile view to simplify the interface. Kaldari (talk) 17:44, 26 August 2013 (UTC)

(edit conflict)this is an enwiki specifci thing, not something for bugzilla and "the devs".

the issue stems from the fact that we use a class (named, aptly, "coordinates") that's defined in the site's css (i.e., MediaWiki:Common.css). this CSS is not loaded for mobile view (mobile view uses MediaWiki:Mobile.css), where this class is not defined, so it does not do it's thing (specifically, this class has the "position absolute" that allows us to push it to its place). (added after collision) this may be intentional, if i understood correctly what Kaldari indicates. peace - קיפודנחש (aka kipod) (talk) 17:48, 26 August 2013 (UTC)

Unlike the problem described at #'Listen' template not rendering in mobile view above, the HTML for coordinates with |display=title does appear in the page source, at the point where they would appear if the {{coord}} had been given |display=inline.

<p>
 <span id="coordinates">Coordinates:
  <span class="geo-nondefault">51°44′04″N 1°14′54″W</span> /
  <span class="geo-default">51.7344°N 1.2482°W</span>
 </span>
</p>

- the href= and title= attributes of the <a> <span> tags have been condensed for clarity. So, it's fixable in CSS for this site, without involving the devs --Redrose64 (talk) 18:56, 26 August 2013 (UTC)

I've removed the spans, etc. that have no bearing on the issue, so we would need to define one id coordinates and two classes geo-nondefault and geo-default --Redrose64 (talk) 19:08, 26 August 2013 (UTC)

It is defined: .geo-nondefault, .geo-multi-punct { display: none; } Apparently, .mobile #coordinates is hidden by MobileFrontend intentionally (with the remark "/* TODO: style for mobile */"). Now we have to ask, do we want it unhidden, and so, where do we put it? — Edokter (talk) — 19:17, 26 August 2013 (UTC)

The geo-nondefault class is the least important of the three identifiers that I gave above... it's supposed to be display:none; because {{coord}} outputs both the decimal and dms forms; the one that is intended to be visible is given class="geo-default" and the other gets class="geo-nondefault" which hides them. --Redrose64 (talk) 19:44, 26 August 2013 (UTC)

the essence of what i wrote above was more-or-less true, but not the details: it's not the "coordinates" class, but rather the "coordinates" id, and it's not in MediaWiki:Common.css, but rather in MediaWiki:Vector.css and MediaWiki:Monobook.css (and i guess their ilk also). the essence is still true, though: it's enwiki specific, and the place to handle it is the local Mediawiki:Mobile.css. peace - קיפודנחש (aka kipod) (talk) 20:42, 26 August 2013 (UTC)

MobileFrontend still hides #coordinates, which contains .geo-default. Unhiding it shows coords at the top of mobile view, but is dependend on template placement. All we need to do is find a good spot for it using absolute positioning, and unhide it in Mobile.css. — Edokter (talk) — 10:29, 27 August 2013 (UTC)

I added a globe to the page actions toolbar. Does that make people happy ? —TheDJ (talk • contribs) 13:26, 27 August 2013 (UTC)

The globe looks nice, but the actual coordinates are not visible, and the page it links to is very mobile-unfriendly. — Edokter (talk) — 13:45, 27 August 2013 (UTC)

There is only so much I can do :D —TheDJ (talk • contribs) 14:36, 27 August 2013 (UTC)

Thank you. It's a good interim measure (and probably worth keeping if we can get a mobile-friendly version of the GeoTemplate page; linking to mobile-friendly services), but I would want to be able to see the coordinates, copy them and paste them into my GPS app, or whatever. News of your fallibility is somewhat of a disappointment :-( Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:27, 27 August 2013 (UTC)

In the long term this simply needs work flow design. Like I said, integrate with the Special:Nearby feature or something and push an overlay OSM map on the page. I'm quite sure that this is being worked on by the mobile team, but they are taking the long term view on this, while my change is more of a short term interim fix. BTW. If anyone knows of a mobile (touch) friendly FOSS slippy map without traffic limitations, that we can pass the coordinates to, then i'm in favor of adding that, but I don't know any online service like that. —TheDJ (talk • contribs) 15:45, 27 August 2013 (UTC)

@Andy, TheDJ, et al., RE: It's a good interim measure (and probably worth keeping if we can get a mobile-friendly version of the GeoTemplate page; linking to mobile-friendly services) – Showing a big button at the top of articles (next to contributory buttons that are completely unrelated) but not taking a user to a mobile-friendly view of the page is a confusing and broken user experience; it's not a good interim solution at all. Please remember that you're not just showing this feature to experienced Wikipedians who know what the related page is for; you're showing this to millions of curious readers and taking them to a strange, broken-looking desktop-only page. That's precisely why the mobile team is working on surfacing this information in a mobile-friendly way in the experimental version of the site first, before exposing the functionality globally to all users. This is a huge change to the mobile UI, one that requires much wider discussion. Maryana (WMF) (talk) 00:17, 28 August 2013 (UTC)

@Maryana (WMF): I think the usage of the phrase 'wider discussion' is interesting. As an en.wp user I can't really say that the mobile team has been open to discussion the past months. As a developer, I know where to go, but I'm quite sure that the community is getting a high level of 'mobile team does whatever they want'-vibe. There is nothing wrong with that, actually, I personally think it's going pretty fine and getting us good results (en.wp noise is annoying, filtering it out lets people focus and work). But discussion is only possible with multiple partners, so don't come knocking on the door with that verbiage if people sometimes bypass the team. —TheDJ (talk • contribs) 06:52, 28 August 2013 (UTC)

@Maryana (WMF): Where on en.WP does this discussion tale place? Why do you not simply show the coordinates as text (you're currently hiding article content: with what remit?) and possibly a link to a single, mobile-friendly map source, perhaps OSM, or the native map app for the device's OS?? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:31, 28 August 2013 (UTC)

I think you are underestimating the problems here Andy.

1. The coordinates element is something developed by the Wikipedia communities. And they do 'ugly' things, which are easily breakable depending on the skin. The community has known this for years, so it's our fault for doing hackish stuff in the first place.
2. 'show the content'. Question is where ? display=title often doesn't have a proper position. Do you have a suggestion ?
3. 'mobile friendly' map source. Again, if you know one, you are welcome to propose it.
4. 'native map' unfortunately there is no universal widely supported link format that works to launch a map app. Geo URI is getting there, but it's far from supported.

I'm really hoping someone invests the time to get a proper OSM tile server for wikimedia configured, but I think finishing all that work will still require a lot of time and it's blocking many of the Geo related improvements that various folks have been eyeing. —TheDJ (talk • contribs) 12:54, 28 August 2013 (UTC)

@TheDJ: OSM works fine on my mobile ; and others I've seen. (some colleagues may not be ware that it recently had an upgraded interface). We could link to that, or to a mobile version of GeoTempate which has a link to it, and a geoURI and the "nearby" page. As for the position; why not at the top; or at the bottom; or create a section called "Coordinates"? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:45, 28 August 2013 (UTC)

P.S. Google Maps also renders well on mobile. On my Android device, a link to Google Maps is intercepted and I'm offered a choice of the website ("Internet") or the native app ("Maps"). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:51, 28 August 2013 (UTC)

Jon has hidden the button again, because the mobile team thinks we are confusing 'normal users'. Which I agree with actually. —TheDJ (talk • contribs) 06:42, 28 August 2013 (UTC)

I've now made a non-linked textual element at the top right of the first section (visible in beta mode). In alpha/experimental/dragons mode I restored the button that I added before. I intend to make the beta version the default version soon. —TheDJ (talk • contribs) 13:22, 28 August 2013 (UTC)

FYI there are now two globes in the mobile alpha with slightly different outcomes when you click on them (albeit the alpha one is broken as a patch didn't get merged in time). We should merge these concepts as that is very confusing! I'd suggest we discuss this on mobile-l mailing list as many developers don't follow Village pump? I think the beta solution TheDJ has created is much less prominent as it should be and preferable. My only real concern with the beta (and desktop in general) is not everyone understands what longitude and latitude coordinates are. They should at least be clickable to some mobile optimised map or some kind of explanation before we push that to stable. Jdlrobson (talk) 14:38, 28 August 2013 (UTC)

Preference choices about displaying math not being shown in user's language

Looks like the latest software update has caused the "Math" section (under the "Appearance" tab) in users' Preferences to appear in the local wiki language instead of in the language chosen by the user (for me, that's English). I started seeing this just now in my non-English Wiktionary accounts (I can say it wasn't happening even 24 hours ago), but I see it's also happening in the Russian Wikibooks (an arbitary non-Wiktionary wiki I decided to try). Can someone please verify that this is true for them and then report it at Bugzilla? (I know I could do it myself, but frankly I detest Bugzilla's user interface, and I refuse to use it.) - dcljr (talk) 07:19, 27 August 2013 (UTC)

This looks like a corruption/problem of the translation files. It will probably get fixed the next time translations are synced. —TheDJ (talk • contribs) 09:39, 27 August 2013 (UTC)

I noted the new interface at 'More language settings' and changed the display language to German. The math and other settings display in German as expected. I set it back to English and menus are in English as expected. I come back here and the interface is in German, even after a purge and bypass. I had to use the standard language menu to get it back to English. --  Gadget850 ^talk 09:20, 27 August 2013 (UTC)

The "new interface at 'More language settings'" is actually the mw:Universal Language Selector, and is the same as clicking the cogwheel adjacent to "languages" in the left margin, which has been available for almost two months. It got some comment at the time, but those were swamped by the flood of comments about WP:VE which had gone live just the previous day. --Redrose64 (talk) 10:26, 27 August 2013 (UTC)

The problem I posted about has been fixed (or fixed itself). - dcljr (talk) 06:52, 29 August 2013 (UTC)

pdf table to wikitable

I want to convert some data from a free (NO COPYRIGHT CLAIMED UNDER TITLE 17 U.S.C) pdf table [2] to a wikitable. Is there a tool for?. --Best regards, Keysanger (what?) 09:32, 27 August 2013 (UTC)

The Excel-to-Wiki Converter should work. --  Gadget850 ^talk 09:42, 27 August 2013 (UTC)

It doesn't work. It makes a wikitable-row of every pdf-cell. And the pdf table has also empty cells, thus isn't possible to use it with other auto editors. Any idea?.--Best regards, Keysanger (what?) 09:59, 27 August 2013 (UTC)

Mobile problems

I'm having some problems with Wikipedia using Opera Mini on my phone. Does anyone know what's wrong?

1. Delete all cookies.
2. Type in https://en.wikipedia.org/wiki/WP:VPT?mobileaction=toggle_view_desktop in the address bar.
3. Type in the same address a second time.

The first time I typed in the URL, I got the mobile edition of Wikipedia over an HTTP connection, although I explicitly typed in HTTPS and used the option to disable the mobile edition. The second time, I got the desktop edition over HTTPS as requested. Why didn't I get this the first time too? --Stefan2 (talk) 21:16, 27 August 2013 (UTC)

How to space down 1/2 line

Can I ask a technical question here? If so here's my Q: I'm currently using {{break|1}} in template code to space down a line. But it is spacing down more than I want. And not using {{break|1}} doesn't position where I want either. So it seems something inbetween might be right. So is there any way to space-down half a line? Thanks. Ihardlythinkso (talk) 00:47, 28 August 2013 (UTC)

Where do you wish to do this? --Redrose64 (talk) 08:10, 28 August 2013 (UTC)

Thanks for your Q. I'm spitting out the following sequence when {{algebraic notation|pos=toc}} is specified:

{{TOC left}}

{{break|1}}

{{algebraic notation|pos=left}}

{{clearleft}}

You can see an example of the result here. (And there are hundreds more article applications same as that one.) A project member feels the result would look a lot less annoying if somehow the top of the side box (the "algebraic notation" box) could be made flush with the top of the TOC. ({{break|1}} puts it a bit lower than flush; removing {{break|1}} from the sequence puts it a bit higher than flush.) I know it's picky but we like to please if possible with your help! Thank you, Ihardlythinkso (talk) 09:55, 28 August 2013 (UTC)

Oh, it's inside {{Algebraic notation}}. But why not just leave out the {{break|1}} from that template? --Redrose64 (talk) 13:54, 28 August 2013 (UTC)

Because as mentioned, removing {{break|1}} from the sequence puts it a bit higher than flush. (I kept the break in the sequence because lower than flush looks better than higher than flush. But flush was my first choice and am wondering how to achieve that. Thus this thread.) Here's a simulated example showing result when {{break|1}} is removed from the sequence. (Gulp! -- Comparing that with this, it looks like even half-spacing down won't make the side box flush -- the amount lower than flush is greater than the amount higher than flush.) Ihardlythinkso (talk) 05:34, 29 August 2013 (UTC)

Just left clear the whole disclaimer box, or float it to the right or whatever. What you want doesn't even work in IE7 I think, and neither on small width devices, so why bother. Also, if we export it or do other things with the content then positioning information like this has a large chance of getting lost. On that note, if you need algebraic notation in the lede and therefore this disclaimer so close to the first paragraph, then the article has lost me as a reader. It might be wise to consider the accessibility of what you are writing. The phrase "The Giuoco Piano is the oldest recorded opening" seems like much more relevant information for the lede then half of what is in there currently and the links for alternative openings are much more useful to me than how they are noted down. Good luck. —TheDJ (talk • contribs) 07:09, 29 August 2013 (UTC)

I can get it to within 1px of the correct vertical positioning in Firefox (see here), but it almost certainly varies between browsers. Part of the trouble is that the different boxes use differing structures - <table> or <div>; and differing box-model methods for relative positioning - margin or padding; and different measurement units (px or em); then the border has to be taken into account. --Redrose64 (talk) 19:46, 29 August 2013 (UTC)

Unblock Ticket Request System

This is a notification that the Unblock Ticket Request System will be migrating to WMF Labs on Sept 7th, 2013. A redirect will be set up on the current toolserver account. For any questions, please contact me on my userpage.--v/r - TP 02:00, 28 August 2013 (UTC)

Data too large to save

I'm trying to do a null edit on Template:Infobox officeholder to update its TemplateData but I keep getting

Data too large to save (174,407 bytes, limit is 65,535)

whats going on?--Salix (talk): 06:33, 28 August 2013 (UTC)

Apparently the TemplateData cannot be larger than 65535 bytes compressed, see Template:Bug. You'll have to somehow trim it down. Anomie⚔ 10:20, 28 August 2013 (UTC)

Thanks. Quite easy to cut down in size as a lot of repeated parameters.--Salix (talk): 11:26, 28 August 2013 (UTC)

There's a patch waiting to be merged that will make TemplateData compress the data before storing it, in practice increasing the limit approximately tenfold: https://gerrit.wikimedia.org/r/#/c/75330/. Matma Rex talk 14:59, 28 August 2013 (UTC)

Video template

I guess I have already invented a template for posting official video of our major sporting events. This one:

Official Video

which is on 2013 World Championships in Athletics – Men's Marathon

but there is no Template formatting. With each of these postings, there will always be the topical component of the appropriate video link. So I don't know how to insert topical information within a template.

The reason I am thinking it needs to be a template is because of layout issues (at least as seen from my browser) when the video template aligns with other templates, its smaller margin and lack of template size formatting allows other template and infobox formatting to overlap text as in 2013 World Championships in Athletics – Women's 5000 metres#Records. I would think a force width or better yet a hidden forced width with blankspace would prevent that kind of error from happening, but I don't see anywhere in the code where widths are set. This is more complext Template/Wikiformatting than I understand. Help needed. Trackinfo (talk) 10:05, 28 August 2013 (UTC)

Why aren't you using {{external media}}? WhatamIdoing (talk) 17:25, 28 August 2013 (UTC)

FYI

WP:CfD/2013 August 28 - Category:Wikipedians by gender and subcats is something everyone should read. The decision to participate is all yours and I don't care one way or the other if you do or don't and if you do I don't care if you support or opposed. I'm only posting this here so that you will be aware and take any action you deem appropriate. Thank you. Technical 13 (talk) 15:22, 28 August 2013 (UTC)

What does that have to do with this page? עוד מישהו Od Mishehu —Preceding undated comment added 20:33, 28 August 2013 (UTC)

Help needed with emptying Category:Wikipedians who use Microsoft Windows

Category:Wikipedians who use Microsoft Windows needs to be deleted per Wikipedia:Categories for discussion/Log/2013 August 20#Category:Wikipedians who use Microsoft Windows. Can someone please either empty it, or tell me what to do here? עוד מישהו Od Mishehu 20:28, 28 August 2013 (UTC)

it's explained in the deletion discussion:

"the category's existence basically is incidental to transclusions of {{User:Technical 13/Userboxes/OS}}."

you probably want to discuss this with User:Technical 13, and see if he can fix this page, such that transcluding it will not create those parasitic categories. peace - קיפודנחש (aka kipod) (talk) 23:07, 28 August 2013 (UTC)

• These categories are up at deletion review as I should have been notified of the deletion nominations as creator of some of the categories in question who's soul purpose is that they are {{maintenance category}} and more specifically (although I did not know this until just today) {{Wikipedia category}}. Technical 13 (talk) 23:22, 28 August 2013 (UTC)

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)

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)

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)

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)

Why does the staff keep breaking the wikipedia

Tracked in Phabricator
Task T34013

Tracked in Phabricator
Task T16487

Right now a tool I use is broken by MediaWiki Bug 32013. Why in the world do I need yet another id and logon to report this? Does the WMF want to discourage more editors with this garbage? Vegaswikian (talk) 20:53, 28 August 2013 (UTC)

The wikimedia bugzilla (bugzilla.wikimedia.org) is not in-house software. It's mozilla's (15 years and 2 days old) bug-tracking/feature-request-tracking system - see our article on Bugzilla for details.

The integration of SUL with bugzilla is complicated*, but bugzilla:14487 tracks the progress. *(for a variety of reasons, not least of which is that it displays email addresses openly, for which see bugzilla:148. See this comment in bug:27001 for more problems/links). HTH. –Quiddity (talk) 21:18, 28 August 2013 (UTC)

It's a Catch-22. Users been asking for bugzilla SUL integration since before SUL, no reason why it should be the lowest priority. — Dispenser 16:58, 29 August 2013 (UTC)

If I'm understanding the Bugzilla entry correctly (which I have added a link to at the top of this section), the thing that changed is Internet Explorer, not MediaWiki. Microsoft added a new feature of dubious quality to Internet Explorer 8, which thinks the actions of the affected toolserver tools are an attempt to exploit a security vulnerability known as a cross-site scripting attack, often referred to with the acronym "XSS." Apparently various other things found on the Web have been affected by this feature as well, and it doesn't seem to accomplish its goal very well. The blame here lies entirely with Microsoft. Some people in the Bugzilla entry have requested that Mediawiki add new code to work around the flaw in Internet Explorer, but that's not asking for something in Mediawiki to be fixed; it's asking for Mediawiki to take special action to prevent Internet Explorer from breaking the tools in question.

As a personal recommendation, I would recommend switching from Internet Explorer to a browser that respects your freedom as a user, such as Mozilla Firefox, which can be obtained here. If you're on a system where you're not the administrator, such as a corporate system, that may unfortunately not be an option, although you could consider lobbying those responsible for the computer system to allow the use of other browsers. Frankly, Internet Explorer has a long, long, long history of brokenness and security vulnerabilities, and I consider forcing its usage to be borderline legal negligence, but many people in large bureaucratic organizations are terrified of changing anything they have become accustomed to, no matter how unwise such a choice may be. --108.38.191.162 (talk) 21:39, 28 August 2013 (UTC)

Except that I use Firefox! That is what they broke. See my next post below. Vegaswikian (talk) —Preceding undated comment added 00:28, 29 August 2013 (UTC)

Fixed. The problem was Wikimedia's forced HTTPS-only log in and my tools still respecting the HTTP/HTTPS divide. I've changed my tools to submit HTTPS, but suspect the change 'broke' other things. I had found the divide useful for testing logged in/monobook/gadgets/HTTPS vs anonymous/vector/HTTP. — Dispenser 16:58, 29 August 2013 (UTC)

There's some information on my Help page. Easiest is to add Wikipedia to the Intranet Zone avoiding disabling the XSS filter. Gear icon (top right) > Internet options > Security tab, click Local Intranet, click Sites, click Advanced, typing in *.wikipedia.org then click Add. Now click Close, Ok, Ok, and there you go. — Dispenser 04:39, 29 August 2013 (UTC)

Thanks everybody for explaining Bugzilla in this thread while I was asleep in my timezone. Appreciated! :) So if Firefox is in use here and *if* this is really the same problem, then a short (technical) comment on that Bugzilla ticket would be appreciated with version and operating system info. --AKlapper (WMF) (talk) 10:39, 29 August 2013 (UTC)

What now? (Firefox specific) Drop down menus gone from Tab view

Modern Skin, Firefox 23.0.1, Windows XP. Visual Editor temporarily disabled. The drop down menus on the tabs at the top are completely gone. When I pull up a page, the viewing tabs at the top do not populate across the page the way they used to. We used to have "Page" tab, with a drop down menu. Now it's just "History", and you have to actually click on History to go to another view and see tabs for what used to be in the drop down menu. Most annoying, when I'm on my own user page, I no longer see a "User" tab with the drop down selections, such as Userspace, Contributions, etc. and I don't see any way of quickly accessing those options. That's what's the most annoying, because it was a handy way to jump to one's own user subpages. What has happened now? If I open in Opera, the drop down menus are there as they should be. This is specific to Firefox. — Maile (talk) 23:06, 28 August 2013 (UTC)

Those menus are not part of the vanilla software. Did you install a gadget or userscript that is adding them perhaps ? —TheDJ (talk • contribs) 07:25, 29 August 2013 (UTC)

I don't know exactly what this refers to (as TheDJ already wrote, this seems to be some custom software), but if this is functionality which is loaded from an external server via http (an unsecure connection) and you are using Wikipedia via https (a secure connection), then latest Firefox versions block unsecure content. Just a guess, though. --AKlapper (WMF) (talk) 10:43, 29 August 2013 (UTC)

@Maile66:. Got it. —TheDJ (talk • contribs) 11:25, 29 August 2013 (UTC)

The DJ, thank you so much for your help. Works fine now. — Maile (talk) 11:32, 29 August 2013 (UTC)

You import User:Haza-w/cactions.js in User:Maile66/modern.js. I suggest you instead enable "Add page and user options to drop-down menus on the toolbar" at Special:Preferences#mw-prefsection-gadgets. That will use MediaWiki:Gadget-dropdown-menus.js instead. It may be more maintained. PrimeHunter (talk) 11:52, 29 August 2013 (UTC)

Done. Thank you for your advice. — Maile (talk) 11:55, 29 August 2013 (UTC)

Malfunction on that one, PrimeHunter. What it did was give me two tabs of "Page". On the "History" selection in the Drop Down on one Page, it told me no such page existed (including my own personal user page). The second Page, the "History" took me to the Wikipedia article History. Must be some kind of conflict going on. But since I could not access my modern.js to revert The DJ's edit (I could pull up the js page, but it told me no page existed when I tried to edit), I just disabled the Gadget. Other suggestins? — Maile (talk) 12:15, 29 August 2013 (UTC)

I did say "instead". Don't run the same or similar code in both personal js and a gadget. Maybe the conflict prevented you from editing User:Maile66/modern.js. If you remove the import there or ask an admin like TheDJ or me to remove it then you can try the gadget. PrimeHunter (talk) 14:21, 29 August 2013 (UTC)

Yeah, you did say that, didn't you? Anyway, thanks for the advice. I've taken care of it (I think). — Maile (talk) 14:34, 29 August 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)

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 m: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)

Secure site breaks X!'s Edit Counter

Resolved

 – Wasn't the secure login feature, it was a simple mixed content issue, which is now fixed. Legoktm (talk) 19:09, 29 August 2013 (UTC)

• https: gives a half-baked report, but
• http: still works

— I'm on Google Chrome, Windows 7. – Wbm1058 (talk) 01:11, 29 August 2013 (UTC)

This has nothing to do with the secure login changes deployed today or talked about above. The tool should be fixed to not include insecure resources when served over HTTPS (protocol-relative URLs make this easier). ^demon^{[omg plz]} 01:16, 29 August 2013 (UTC)

What ^d said. Pinging User:Cyberpower678 to fix it :) Legoktm (talk) 03:16, 29 August 2013 (UTC)

That's all very well and good but surely such things should be checked with tool maintainers before deployment. We rely on volunteer tools - in no small part because, for whatever reason, WMF won't take on many of our most useful tools - and breaking them is a big deal but there seems to be no process in place to check this before deployment. Relying on volunteer maintainers to spot changes and then make the necessary updates, in their own free time, hardly seems the best way to help maintain the encyclopaedia. Dpmuk (talk) 04:49, 29 August 2013 (UTC)

Actually, this has nothing to do with the https deployment, this issue has existed in the edit counter for a while now. You're probably only noticing it now because a) you're probably clicking on HTTPS links due to protocol-relative ones, and b) Firefox recently made an update so any non-secure content on a secure page is no longer loaded, whereas it used to give you an option to load the non-secure stuff anyways. See [3] for some details about that. Legoktm (talk) 06:43, 29 August 2013 (UTC)

I don't see it.—cyberpower ^Chat_Online 10:35, 29 August 2013 (UTC)

I'm afraid I don't follow the argument "this has nothing to do with the https deployment". As I stated above, I'm using Chrome, not Firefox. I definitely, not probably, noticed this because the link · Edit count · at the bottom of Special:Contributions/Wbm1058 changed from this to this. Was changing that link not part of https deployment? Can I change that link in my user preferences? What does Cyberpower678 have to do with that tool? The X!'s Edit Counter home page says that it is a "Script maintained by the xlabs team" (whoever that is). Can that team fix their script to make it secure? Ideally, that should have been done before the link was changed, to make the change transparent to end-users. Wbm1058 (talk) 15:03, 29 August 2013 (UTC)

I am the head of the xlabs team. Quite frankly, the tool was never intended for https, although, I still don't see any differences. Can you provide a screenshot.— Preceding unsigned comment added by Cyberpower678 (talk • contribs) 15:32, 29 August 2013 (UTC)

Oh I see:

• Wikipedia:Village pump (technical)/Archive 112#Toolserver issues
• Wikipedia:Village pump (technical)/Archive 113#X!'s Edit Counter – To address the issue of the tool's 'owner', I maintain that I inherited the and do not own them and I've taken part in the process, led by Cyberpower, to migrate these tools to labs. I've joined a team, of sorts, that Cyber has termed xlabs and so as these tools move to labs, I am abdicating any sort of psuedo ownership I gained while hosting open source tools that I didn't even design and barely maintained. I'm definitely okay with any changes to the tools as long as it's a team decision and I've address that with Cyber already.--v/r - TP 02:23, 5 June 2013 (UTC)

—it would be nice if I didn't have to dig to find this information about who is maintaining this high-visibility tool. – Wbm1058 (talk) 15:42, 29 August 2013 (UTC)

@Cyberpower678: I was about to try making a screen shot, but now the report is really messed up. A recent attempt to fix something? Now I get this:

Warning: mysql_close() expects parameter 1 to be resource, boolean given in /data/project/xtools/public_html/counter_commons/Database.php on line 71

—Wbm1058 (talk) 16:03, 29 August 2013 (UTC)

It was kind of implied at who maintains it. I'll make it more obvious. Nothing has been changed, if you ask me, labs broke down again. Something is spidering the servers.—cyberpower ^Chat_Online 16:21, 29 August 2013 (UTC)

Back tracking a bit, I also don't agree with the "this has nothing to do with https deployment". Yes that may not be what directly broke it but clearly a lot (most?) users were previously using http and are now using https and so the link breaks for them. Thus as far as the users are concerned it is https deployment that broke it. Most users won't care about the technical reasons for the break only that before deployment it worked, after it didn't. Hence this should still have been checked before deployment. Dpmuk (talk) 16:52, 29 August 2013 (UTC)

@Cyberpower678: Hey, I see now that "Wbm1058&lang=en&wiki=wikipedia does not exist." Apparently someone took down my data to protect me from myself ;) Maybe we should debug this in a less visible place? My bot's reports still work, but maybe it's not safe to upload screen shots? Wbm1058 (talk) 16:22, 29 August 2013 (UTC)

Debugging should be public so others can report what they see.—cyberpower ^Chat_Online 16:23, 29 August 2013 (UTC)

 Fixed – Well, the problem seems to be fixed now. If you had anything to do with that, I thank you very much. The mysql_close/does not exist problem I reported above wasn't really a problem—someone just vandalized the link I posted. Wbm1058 (talk) 17:30, 29 August 2013 (UTC)

• However, per wikitech:Nova Resource Talk:Xtools#Edit counter seems to be broken on Commons there still seems to be a problem with the tool over on Commons. – Wbm1058 (talk) 18:08, 29 August 2013 (UTC)

  Fixed the https problem. I have made a mass change tool wise to accomodate https. It should work now. Commons still needs new namespaces.—cyberpower ^Chat_Offline 18:54, 29 August 2013 (UTC)

https change breaks Citation Expander gadget?

The https change, or something else, appears to have broken the Citation Expander gadget, at least for me, at least on Firefox for Mac. I have unchecked the https setting, logged out, logged back in, quit Firefox and started it again, but I have still been unable to make the Citation Expander gadget work. I have reported this bug.

Is it working/broken for anyone else? Is there something I can do to fix it for myself? – Jonesey95 (talk) 05:10, 29 August 2013 (UTC)

Where can I find the Citation Expander gadget? I'd love to look at its code. (Very wild guess, I might be completely wrong: Latest Firefox blocks "unsecure" (http) content on "secure" (https) pages.) --AKlapper (WMF) (talk) 10:45, 29 August 2013 (UTC)

Special:Gadgets links to MediaWiki:Gadget-citations.js. User:Citation bot links to Source code repository. PrimeHunter (talk) 11:14, 29 August 2013 (UTC)

The bot's maintainer has set the bot's account to not use SSL for now, as a workaround. – Jonesey95 (talk) 13:41, 31 August 2013 (UTC)

Resolved

Questions for the next Executive Director

Open call for questions. Cheers, Ocaasi ^{t | c} 12:39, 29 August 2013 (UTC)

RfC: Are the Category:Wikipedians and its subcategories appropriate for Wikipedia

There is an ongoing RfC going on at Category talk:Wikipedians#RfC: Is this category and current subcategories appropriate for Wikipedia that readers of this Village pump may be interested it. Technical 13 (talk) 12:45, 29 August 2013 (UTC)

Hiding ProcseeBot in block log

Tracked in Phabricator
Task T21322

Could there be a way to hide bots from view in the block log? This has been mentioned once before by User:Jasper Deng, but nobody ever replied. Thanks, Insulam Simia (talk · contribs) 15:09, 29 August 2013 (UTC)

bugzilla:19322 Legoktm (talk) 16:43, 29 August 2013 (UTC)

I agree 100%! I would like to browse the blocks too, but ProcseeBot makes it very annoying. Also, this problem doesn't exist only on en.wiki. Ginsuloft (talk) 16:51, 29 August 2013 (UTC)

Yep: fi:Toiminnot:Loki/block. --Stryn (talk) 19:23, 29 August 2013 (UTC)

Sandbox still attached to last article

Could I please get Palmetto Education Association decoupled from my sandbox. I want to start drafting a new article, and when I make edits in my sandbox they also edit the article. — Preceding unsigned comment added by Eirefrance (talk • contribs) 18:23, 29 August 2013 (UTC)

 Done Ginsuloft (talk) 18:41, 29 August 2013 (UTC)

I have blanked it to remove all but the sandbox template. All of that text was in the version moved to the article space so leaving it in the sandbox is just confusing.--ukexpat (talk) 19:03, 29 August 2013 (UTC)

Broken scripts on pages whose names begin with a period

On articles like .hack, .NET Framework, .htaccess, and .com, the Vector sidebar's sections sometimes fail to be collapsible, and User:Js/6tabs-vector always fails to work (actually, I am using a version modified to handle the VisualEditor tab, but switching back to the official version makes no difference). My vector.js itself is loading fine, as demonstrated by making it add a dummy link to the toolbox.

When viewing the offending pages, Firefox's Error Console shows a message like

Error: mw.Title: Could not parse title ".htaccess"

https://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=ext.centralNotice.bannerController%7Cext.uls.i18n%2Cime%2Cinit%2Cinterface%2Clanguagenames%2Cpreferences%2Cwebfonts%7Cext.uls.webfonts.repository%7Cext.visualEditor.viewPageTarget.init%7Cext.wikimediaShopLink.core%7Cjquery.client%2Ccookie%2CdelayedBind%2Ci18n%2CjStorage%2Cjson%2CmwExtension%2Ctipsy%2Culs%2Cwebfonts%7Cjquery.uls.data%2Cgrid%7Cmediawiki.Title%2CUri%2Capi%2Cnotify%2Cuser%2Cutil%7Cmediawiki.legacy.ajax%2Cwikibits%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.startup%7Cskins.vector.js%7Cwikibase.client.init&skin=vector&version=20130829T195454Z&*

Line: 262

Discussion elsewhere suggests that this is related to the secure login feature, but I'm not sure how that applies to me: I had already been using the secure server (enforced by HTTPS Everywhere), I'm not getting any mixed-content warnings, and other pages don't have the problem. What should be done about this? --SoledadKabocha (talk) 20:10, 29 August 2013 (UTC) (+ 20:27, 29 August 2013 (UTC))

So, as best I can tell this has nothing to do with HTTPS. I spoke with Roan, and he said it's known and Krinkle's working on a fix. ^demon^{[omg plz]} 22:13, 29 August 2013 (UTC)

(edit conflict) This isn't related to secure login. There's a bug in mw.Title (a JavaScript library in MediaWiki core) causing it to believe that all page names starting with a dot are invalid. So when you're on a page like that and some piece of JavaScript tries to get information about the page (which VisualEditor does, because it needs to figure out if the page is in the right namespace and what not), mw.Title blows up in its face. --Catrope (talk) 22:16, 29 August 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)

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).

Watchlist issues?

This may be a temporary problem, but I can't watchlist or de-watchlist any page right now. Clicking on the star, either an error message box appears (saying an error occurred when trying to change the watchlist settings) or the star just spins forever and nothing happens. I use the regular Wikipedia server (i.e. the non-secure one). I tried clearing the browser cache, but that didn't help. Heymid (contribs) 21:16, 29 August 2013 (UTC)

Somethings happened. When pressing the enable feedback button it comes up saying an unknown error has occurred and also my twinkle rollback links have disappeared as well.Blethering Scot 21:20, 29 August 2013 (UTC)

Issue known and being investigated on #wikimedia-operations on Freenode as we speak. Matma Rex talk 21:28, 29 August 2013 (UTC)

Issue has been fixed – thanks for acting quickly! :) Heymid (contribs) 21:44, 29 August 2013 (UTC)

Internal link not working

I had a very weird experience on page Motorik. There is a link to play a MIDI file from Commons that led to file upload wizard when I first opened the page. I thought about removing it since it leads to a dead file, but checked the history and saw it was added 3 days ago. I tried to go to the file directly (), but it didn't appear in the suggestions in the search bar. I went to Commons then and found it. So I edited the original page and clicked Show preview. Link was still dead. I then copy-pasted the title from the Commons page (Motorik rhythm.mid) into the corresponding template on the Motorik page. Clicked Show preview and, hey presto, it works! I clicked Show changes and Wiki didn't find any differences, so I clicked Save, checked the history and my edit didn't appear. The link was now working, however, and it still is now (at least for me). Why in the world could this happen?! 93.139.59.230 (talk) 01:18, 30 August 2013 (UTC)

Monthly and yearly pageview stats

Given the newly created Wikipedia:Million Award, how can we request that the page view stat tool present monthly and yearly pageview totals? It will save everyone lots of work totalling month by month data.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 01:59, 30 August 2013 (UTC)

Error report in RFA

When I click "Report" at Wikipedia:Requests for adminship I get the following error:

get('//en.wikipedia....', Array) #1 /data/project/xtools/Peachy/Init.php(153): Peachy::wikiChecks('//en.wikipedia....') #2 /data/project/xtools/public_html/rfa/index.php(36): Peachy::newWiki(NULL, NULL, NULL, '//en.wikipedia....') #3 {main} thrown in /data/project/xtools/Peachy/HTTP.php on line 175

Is this the right place to report this error? (I don’t have a bugzilla account). Thanks in advance, XOttawahitech (talk) 03:26, 30 August 2013 (UTC)

Full error from the html view-source:

Extended content

<!--Loading Peachy (version 2.0 (alpha 5))... Fatal error: Uncaught exception 'CURLError' with message 'cURL Error (3): <url> malformed' in /data/project/xtools/Peachy/HTTP.php:175 Stack trace: #0 /data/project/xtools/Peachy/Init.php(182): HTTP->get('//en.wikipedia....', Array) #1 /data/project/xtools/Peachy/Init.php(153): Peachy::wikiChecks('//en.wikipedia....') #2 /data/project/xtools/public_html/rfa/index.php(36): Peachy::newWiki(NULL, NULL, NULL, '//en.wikipedia....') #3 {main} thrown in /data/project/xtools/Peachy/HTTP.php on line 175

HTH. –Quiddity (talk) 03:42, 30 August 2013 (UTC)

User:Cyberpower678: ping. Legoktm (talk) 08:30, 31 August 2013 (UTC)

Urgh. More https crap. I'll fix it later today.—cyberpower ^Chat_Online 14:47, 31 August 2013 (UTC)

On little viewed articles

Hello, I am an active wiki editor on Ancient Egypt subjects and work a lot on articles that typically do not garner much views, for example on obscur pharaohs of the first and second intermediate periods (typical example Mersekhemre Ined or Intef I). Being curious about the number of views such articles get and how this depends on the number of links to these articles, I regularly use the Page View Statistics tool to access the number of views. I noticed that for very rarely visited articles, even orphan or near orphan articles (e.g. see Helwan retouch and its page view stats), the number of daily visits always fluctuates around at least 2-3 a day. Now this is rather striking: are there really 2-3 people a day researching the Helwan retouch ??

Instead, I believe that much of these views are actually bots accessing the page (maybe from google or other search engines, or from wikipedia itself). Thus, I can summarize my question as follows: for articles with very little views, can we distinguish bot views from real humans accessing the article? Is it possible to estimate the real traffic that these articles garner?

I tried to find studies on articles with very few visits but did not find any (so many pages are devoted to the most visited wikipedia articles and so little is devoted to the numerous articles with very few visits). In particular, this "bot view noise" obscurs the real impact of these articles and does not help increase their visibility (how awesome would it be to be able to distinguish which wiki-link led a reader to a given article). Because of this, in the end, I can't even say if there is at least one human per month interested in e.g. Pepi III or Senusret IV... Iry-Hor (talk) 09:06, 30 August 2013 (UTC)

• I always assumed this was people who clicked the "random article" link... --Randykitty (talk) 13:00, 30 August 2013 (UTC)

Well with about 4 millions articles on wikipedia, assuming the prob distr of getting one is uniform, 3 visits a day mean the button was clicked around 12 millions time a day. Now the wiki main page has around 10 million visits a day so it would mean that nearly every person coming to the main page click the random article button. Furthermore, this should hold for all article with 2 -3 visits a day. So just Helwan retouch plus Pepi III require every person to click the button a couple of times a day. Including the many other articles with 2 - 3 visits mean everybody must be nevrotically clicking the random article button tens od thousands of times a day... Iry-Hor (talk) 13:38, 30 August 2013 (UTC)

Your initial 12 million clicks is about right, but there's no reason, once you've assumed a uniform distribution, that getting 2-3 hits on 2 articles will require twice as many clicks as getting 2-3 hits on 1 article. Also, anyone clicking "random article" is probably going to click it more than once, so maybe a million people clicking 12 times a day is a little more realistic. Probably still too high to be the full explaination though (is it possible to get the usage stats for the random article button)? MChesterMC (talk) 15:18, 30 August 2013 (UTC)

Apparently we can! It shows about 2 million hits a day to special:random, so that only accounts for about half a hit per day per article. (though looking back through the history, it has previously been much higher. People ver clearly bored in October 2010) MChesterMC (talk) 15:30, 30 August 2013 (UTC)

Yes you are right my mathematical argument was botched for several articles. So what's the mean number of visits received by an article if people use the random button 2 million times a day ? It seems to me that since there are 4 millions articles on wikipedia and since, by assumption, all are equally likely, then each article receives on average 1/2 a visit a day (or a visit every two days). That's indeed pretty far from the 3.37 visits a day such a small, near orphan, article as the Helwan retouch gets on average (soon this is going to go up with my always going to Helwan retouch to study little viewed articles...). If we accept that most of these visits are from bots, then we have the additional problem that bots visit a page more or less often depending on the number of links to it. Thus both Senusret IV (with 9.7 visits a day) and Helwan retouch (3.37) might get all their visits from bots, with the apparent difference in frequentation only due to more links to Senusret IV than Helwan retouch. This is terrible: in spite of the fact that 9.7 is arguably more than 3.37, we can't even say that one article gets more real people than the other !! Furthermore, what's the minimum number of human visits required for such visit to dominate over the bot noise ? (this question is really hard considering that the more visited an article is, the more likely it is to have many links to it and thus the more bot visits it might receive) Iry-Hor (talk) 16:05, 30 August 2013 (UTC)

• There's a rough estimate for bot traffic (from mid-2012) as 10-15%, half of which are from google. However, it's clear that this 10-15% is probably disproportionately higher on low-traffic pages and a much smaller proportion for very high-traffic pages. Getting "non-bot" figures for individual pages has definitely been discussed in the past, but we'd have to screen the hits before recording them, and of course anything that involves looking at individual hits, even in an automated fashion, starts opening up the potential for privacy complications. User:west.andrew.g has done quite a bit of work on the traffic stats and might be able to give some more experienced advice. Andrew Gray (talk) 10:47, 31 August 2013 (UTC)

HTTPS

Hi. I'm having some trouble using Wikipedia through HTTPS. Whenever I visit a new page, I get the following message: "WikiPage: Couldn't parse page name from url 'https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)'". I can still view & edit the site, but this dialogue box pops up for every page, and I need to close it before I can continue. Does anyone know why this happens and how I can fix it?Thanks, ItsZippy ^{(talk • contributions)} 10:56, 30 August 2013 (UTC)

It's probably caused by the User:Quarl/wikipage.js script in your vector.js. Issues with it were already mentioned above and @^demon: claimed to have fixed them, though, so I guess this script is even more broken than it seemed. Matma Rex talk 11:39, 30 August 2013 (UTC)

Same issue here. Only by burning my cache, all cookies, and history to the beginning of time was I able to get Chrome not to go back to https. RJC ^Talk_Contribs 12:04, 30 August 2013 (UTC)

Hmm, since this morning, I've not had so many issues - perhaps this is fixed. I'll keep an eye out. ItsZippy ^{(talk • contributions)} 16:03, 30 August 2013 (UTC)

Regex editor

I have a useful tool in my sidebar toolbox called Regex editor, which I use to store a lot of commonly used stuff like template code and so on. I have no idea how I got it. Since about yesterday none of my stored regexes appear. Can anyone tell me where the tool comes from, or who made or maintains it, or where it stores the stuff saved in it, or whether I have any chance of recovering my saved stuff? Thanks, Justlettersandnumbers (talk) 11:53, 30 August 2013 (UTC)

You probably want the "Add a sidebar menu of user-defined regex tools, with a dynamic form for instant one-use regex (documentation)." option on Special:Preferences#mw-prefsection-gadgets. --Krenair ^{(talk • contribs)} 12:27, 30 August 2013 (UTC)

(Edit conflict) Its probably Regex menu framework added via the gadgets tab in your preferences. I guess its yet another tool broken by the switch to https. You might find meta:User:Pathoschild/Scripts/TemplateScript which is a updated version works better. Wait for it to be fixed by the developer, or use http (see discussion above).--Salix (talk): 12:36, 30 August 2013 (UTC)

(edit conflict)Thanks to both for your replies. Salix guessed right from my imperfect description. What a mess. Uncheck the preference box, log out, log in, it all still loads as https. However, deleting the unwanted "s" in the url and reloading the page brings back my regexes. So it still needs fixing, but thanks to you I've at least found a workaround. Justlettersandnumbers (talk) 13:15, 30 August 2013 (UTC)

I've notified the developer. (I also fixed the interwikis above, TemplateScript is worth investigating).--Salix (talk): 08:05, 31 August 2013 (UTC)

Hello Justlettersandnumbers. The regex editor works fine in HTTPS, but it saves your settings in your browser's local storage which isn't transferred between protocols. You'll need to recreate your settings in HTTPS mode. If you have complex patterns, that might be troublesome; you can save time by transferring the actual storage data.

If you're using the Chrome browser, you can do that like this:

1. Install the HTML5 LocalStorage Manager extension.
2. When visiting Wikipedia in HTTP mode, open the storage manager by clicking the icon in the URL bar.
3. For each entry with a key that starts with "tsre-sessions", copy the key and value into a text file. (Make sure to copy the one just called "tsre-sessions" too!)
4. Switch to Wikipedia in HTTPS mode and open the storage manager again.
5. Add the entries you just copied.

Your saved patterns should show up now. Let me know if that fixes it for you. (I also saved this answer as an FAQ, in case this comes up for anyone else.) —Pathoschild 20:01, 31 August 2013 (UTC)

Thank you for your reply. I've probably got about thirty templates and other things stored in your excellent regex editor. It would not be unthinkable to copy them over to the https version by simply copy-pasting between pages. However, if you happen to be able to give me similar guidance on where to find the data in Safari 5.1.9 (OS 10.6.8), then that would save me some time. Either way, thank you. Justlettersandnumbers (talk) 20:48, 31 August 2013 (UTC)

Unfortunately I can't find an equivalent extension for Safari. Let me know if you find one. —Pathoschild 21:33, 31 August 2013 (UTC)

In Safari you can enable the 'Developer' menu. Then go to wikipedia using http mode (set the preference option, log out, log in). from Menu choose ->Developer -> Show Web Inspector. In the new window, at the top left you'll find a row of 8 icons. The first looks like a file, the 2nd as 3 discs. Choose the second. You now have a list of "Cookies, Local Storage, Session Storage". You want the one with "Local Storage". Now follow the steps as described by Pathoschild about copying the entries. Change the preference back to https, log out, log in, and navigate to the same Local Storage screen and enter all the keys again as described. —TheDJ (talk • contribs) 22:27, 31 August 2013 (UTC)

Cite toolbar is not fetching any information

I have never gotten it to work fetching info for a book from an ISBN but it always fetched data for journal articles from DOIs and at least the titles of webpages from URLs. Now, nothing at all. I am using Firefox 23.0.1, if that makes any difference. -- Brainy J ~✿~ (talk) 13:11, 30 August 2013 (UTC)

See this section above. Graham87 05:20, 31 August 2013 (UTC)

Improved diff has vanished

Recently the Green Delta to link to the improved diff display has vanished from my diff pages. When searching for instructions about "Improved diff" to see if there was an error in my setup, I found that there apparently aren't any instructions in the Wikipediea: or Help: pages. Two questions:

Is there any explanation as to why the improved diff link has recently vanished?

Why isn't there documentation for the improved diff somewhere on Wikipedia?

SteveMcCluskey (talk) 15:54, 30 August 2013 (UTC)

what you call "improved diff", if i understand correctly, is the "wikEd diff" gadget. you want to make sure this gadget is actually selected in your preferences (i think that if you use "wikEd", it automatically includes wikEd diff, but at least one of these two must be selected for wikEd diff to work for you). if you have one of those two active, and you still do not see the "improved diff button", i think the place to seek help is either User:Cacycle/wikEdDiff, or the associated talk page (i just checked, and it *does* work for me. i do not use wikEd, but i *do* use wikEd diff). peace - קיפודנחש (aka kipod) (talk) 16:47, 30 August 2013 (UTC)

What is your skin and browser? I see you import wikEdDiff in both User:SteveMcCluskey/monobook.js and User:SteveMcCluskey/vector.js. The latter says http and not https. You can try changing that if you use Vector but I suggest you remove both versions and instead enable wikEdDiff at Special:Preferences#mw-prefsection-gadgets. That method is more likely to be stable. PrimeHunter (talk) 20:12, 30 August 2013 (UTC)

Thanks for the advice; following PrimeHunter's recommendation I was able to get the WikEdDiff running by using the preference page (once I knew where to look and what I was looking for).

May I suggest that someone who knows something about WikEdDiff add a discussion about its properties and how to set it up at Help:Diff. Both newbies and old timers could benefit from such documentation. I'm an editor who'd used it for such a long time that I totally forgot how I installed it. SteveMcCluskey (talk) 19:53, 31 August 2013 (UTC)

I have added a see also link [4] to User:Cacycle/wikEdDiff, and described there how to install it as a gadget.[5] PrimeHunter (talk) 20:47, 31 August 2013 (UTC)

Edit summary no longer providing previously used summaries

Since a few days ago, the Edit Summary field no longer provides previously used summaries. These previously used would show up as I started to type characters in the Edit Summary field that matched previous summary beginning characters. Did something change in WP or was it because I had a regular Microsoft Windows fixes and patches installed on my machine? How can I get this memory of summaries back? Hmains (talk) 17:55, 30 August 2013 (UTC)

As far as I know, these edit summaries are stored on your computer, not anywhere on Wikipedia. Changes to your web browser's settings, like clearing the Auto-fill cache or other similar changes, will erase your previous edit summaries. – Jonesey95 (talk) 18:07, 30 August 2013 (UTC)

The HTTPS switch would have done this. Werieth (talk) 18:13, 30 August 2013 (UTC)

(e/c) Because of the switch to the https protocol (as discussed higher up on this page), you're used summaries might no longer be connected with this website, or are no longer stored by your browser on your computer as a privacy measure. If you can tell which browser and version you are using, we might be able to let you know if and how you can restore the storage of such information. —TheDJ (talk • contribs) 18:16, 30 August 2013 (UTC)

Windows v 7; Internet Explorer v 10. Even new summaries I type now do not show up minutes later when I want to use them again. Hmains (talk) 19:04, 30 August 2013 (UTC)

An IE9 user reported the same at Wikipedia:Help desk#Always use secure connection - checked off by default now? Autocomplete of stored edit summaries still works for me in Firefox 23. PrimeHunter (talk) 20:05, 30 August 2013 (UTC)

I read the help desk entry. But not being very PC literate, I don't know precisely where to look for what settings. Hmains (talk) 20:30, 30 August 2013 (UTC)

• Does all this mean there is no hope to again have autocomplete of stored edit summaries with IE and that I have to go to Firefox to get them again? Hmains (talk) 15:57, 31 August 2013 (UTC)

I haven't found a way to get autocomplete in IE at https with the current setup on Wikipedia's side. If http is acceptable to you then you can disable "Always use a secure connection when logged in" at Special:Preferences, log out, close IE, start IE again and log in at http://en.wikipedia.org. PrimeHunter (talk) 16:50, 31 August 2013 (UTC)

That works for me. Thanks Hmains (talk) 20:32, 31 August 2013 (UTC)

Template syntax question

I have a couple questions about templates, plus a meta-question - is this the best place to ask about template syntax?

The template {{CBB roster}} has a field for weight. While there is no rule against listing weights for women, in practice it isn't done (I just manually checked almost all uses of the template for women's teams) I'd like to add an option to suppress this field, and think the best way to do it is to use the existing parameter for sex, and suppress the field when sex=w.

I think I should use the #switch option. (or maybe #ifeq, because I only have two options?) I need to read up on how to do that, but before I do, I wanted to see if there was a preferable way of handling such a situation.

The second question is related. If I suppress the weight column in the header template, I need to do something with the Player template {{CBB roster/Player}}. That template doesn't have the sex parameter so my question is, do I have to add a parameter and make sure they are coordinated, or is there a way for the Player template to use a parameter passed to the Header template (The Player template will never be used in practice without a header template)--SPhilbrick(Talk) 20:13, 30 August 2013 (UTC)

• Well, WP:WikiProject Templates would probably be the best place for a question like this. As a general rule, I would suggest checking with the applicable wikiproject (in this case, Basketball), but I agree, since weight has nothing to do with the practice of the sport (they don't have formal weight classifications) it is inappropriate. For the technical aspect, I would suggest using a switch, as this allows several inputs to be treated equivalently, eg {{#switch:{{lc:{{{sex|}}}}} | w | f | woman | women | womyn | dames | girl | girls | sugar and spice and everything nice | γυνή | xx | ♀ | female = for god's sake, don't put a woman's weight on Wikipedia!}} VanIsaac_{WS Vex}^contribs 23:24, 30 August 2013 (UTC)

Thanks, I guess I was thinking of switch versus ifeq incorrectly, I was thinking I have only two outputs, so why not ifeq, but the key is the number of inputs, and there are several. --SPhilbrick(Talk) 02:35, 31 August 2013 (UTC)

Can't edit my javascript page

When I tried to add a script to my javascript page, the WikEd toolbar appears but there's no edit window to use (OS Windows XP, browser FF 23.0.1). No change when I purge the cache, and I've opted out of VE. Thanks and all the best, Miniapolis 23:41, 30 August 2013 (UTC)

Pehaps WikEd is in conflict with the newly deployed Code Editor? — Edokter (talk) — 00:35, 31 August 2013 (UTC)

You may be right. I finally got to full-screen mode (my WikEd default everywhere else) when I found the button on the right of the toolbar, but the code wouldn't preview (or save) until I turned Code Editor off. Thanks for the quick response to you both and all the best, Miniapolis 01:18, 31 August 2013 (UTC)

I have no issues editing my .js pages with wikiEd and the new code editor... Technical 13 (talk) 00:42, 31 August 2013 (UTC)

wiked has a little switch to the right of "log out" at the top of the screen that lets you turn it off. i think what you probably want to do is turn off wiked when editing .js pages. it's one click to turn off (on .js page), and one more to turn it back on when you want wiked back. peace - קיפודנחש (aka kipod) (talk) 01:36, 31 August 2013 (UTC)

EasyBlock

Resolved

Anyone who uses the EasyBlock script having issues? Mine doesn't seem to be working, though a computer reboot or cache clear I'm thinking may do the trick (if it's just me). Or could it be the https update that is doing it? – Connormah (talk) 07:20, 31 August 2013 (UTC)

Hm, same here. [01:13:05.478] TypeError: (intermediate value).block is undefined @ https://en.wikipedia.org/w/index.php?title=User:Animum/easyblock.js&action=raw&ctype=text/javascript:347 I'm investigating... Legoktm (talk) 08:13, 31 August 2013 (UTC)

Ok fixed. Has nothing to do with the HTTPS upgrade. &gettoken=1 was removed from the API. Legoktm (talk) 08:23, 31 August 2013 (UTC)

Thanks so much! – Connormah (talk) 15:35, 31 August 2013 (UTC)

Code Editor doesn't work with zoomed text — accessibility problem

Tracked in Phabricator
Task T55634

The new Code Editor is badly broken. I use Firefox with text zoomed to +225%, witch makes the Code Editor utterly unusable, yet there is no obvious way to turn it off. I also often use an external editor (via It's All Text), but the CE makes even that unworkable by randomly moving its icon around.

Between this and VE and the upcoming Flow crapfest, I've had enough. WMF can go fuck itself for all I care. I'm out if here. (At least until things shape up, start functioning properly and let me choose the way I edit.) —Wasell^(T) 07:30, 31 August 2013 (UTC)

Please read m:CodeEditor which has clear instructions on how to disable it. Legoktm (talk) 08:12, 31 August 2013 (UTC)

New Page Review - No Curation Bar

Hi,,

I have been directed to here after asking about this on live chat. The things they said to do which did not result in a fix are as follows:

Look on the side for the small minimised tab Look under the toolbox for curate this page I have also tried with another browser.

Why is there no curator bar for me?

Thanks :) MrBauer24 (talk) 15:12, 31 August 2013 (UTC)

Possibly silly question - have you tried going directly to Special:NewPagesFeed and following one of the links from there? The page curation toolbox sometimes needs "triggered" by that page. Andrew Gray (talk) 16:10, 31 August 2013 (UTC)

Page curation is only available to autoconfirmed users. Your account will be autoconfirmed three days from now. PrimeHunter (talk) 16:19, 31 August 2013 (UTC)

URL converter script not working

The url converter script user:js/urldecoder.js is no longer working. It works if I take the "s" out of the "https" at the start of the url. The author has not edited since May 2012, so I'm not sure posting on his talk page will be of any use. Thanks, -- Diannaa (talk) 18:22, 31 August 2013 (UTC)

@Diannaa: I have fixed the script I think. It might be required to clear your browser cache. —TheDJ (talk • contribs) 22:08, 31 August 2013 (UTC)