Wikipedia:Village pump (technical)/Archive 123

...or am I doing something wrong? {{#time:j M Y|first friday August 2014}} returns 8 August 2014 instead of 1 August 2014. This only happens if the first occurence of that day falls on the 1st. What causes this, and how can I fix it? — Edokter (talk) — 13:12, 26 January 2014 (UTC)

I don't know the specifications but {{#time:j M Y|first friday of August 2014}} gives: 1 Aug 2014. PrimeHunter (talk) 14:16, 26 January 2014 (UTC)

@Edokter: Using {{#time:j M Y|first friday of August 2014}} seems to give the expected result. #time internally uses PHP's DateTime class, whose constructor accepts one of a whole lot of different formats, and in particular a "ordinal space dayname space 'of'" one. There's no mention of a variant without 'of' – you might want to file a PHP bug if you really want it ;) Matma Rex talk 14:19, 26 January 2014 (UTC)

Thanks! The 'of' part caused me trouble in the past, but it works now. — Edokter (talk) — 14:31, 26 January 2014 (UTC)

"first friday August 2014" is being interpreted as "August 2014" (which is interpreted as 2014-08-01) then the "first friday" after that date. It's mentioned in one of the big grey note boxes near the bottom of [1]. Anomie⚔ 01:07, 31 January 2014 (UTC)

When I'm logged in to Wikipedia using Firefox 26.0 and go to my Contributions page and click on the "Articles created" link in the footer, I get an error stating "No input file specified." When I do the same using Internet Explorer 11, I get a 404 Not Found error. Anyone know what's causing this, and how to fix it? Thanks! GoingBatty (talk) 15:39, 27 January 2014 (UTC)

Also noticed the same issue with the "Edit count" link. GoingBatty (talk) 15:40, 27 January 2014 (UTC)

https://tools.wmflabs.org/xtools is down. https://tools.wmflabs.org/ says it's maintained by User:TParis and User:Cyberpower678. It has been reported at User talk:TParis#xtools problem and User talk:cyberpower678#xtools problem. PrimeHunter (talk) 15:48, 27 January 2014 (UTC)

•  Fixed—cyberpower ^Chat_Absent 20:18, 27 January 2014 (UTC)

@Cyberpower678: The good news is that I'm not getting the error above. The bad news is I now getting a 502 Proxy Error: "The proxy server received an invalid response from an upstream server. The proxy server could not handle the request GET /xtools/pages/index.php. Reason: Error reading from remote server." GoingBatty (talk) 20:54, 27 January 2014 (UTC)

Works for me!—cyberpower ^Chat_Absent 21:05, 27 January 2014 (UTC)

I also see, after a long delay:

(502) Proxy Error

The proxy server received an invalid response from an upstream server. The proxy server could not handle the request GET /xtools/.

Reason: Error reading from remote server

— Wbm1058 (talk) 02:31, 28 January 2014 (UTC)

xtools got DDoS'd. It crashed.—cyberpower ^Chat_Absent 04:27, 28 January 2014 (UTC)

• UPDATE:Alright, DDoS should be resolved and xtools should be back online.—cyberpower ^Chat_Absent 04:30, 28 January 2014 (UTC)
• UPDATE: xTools is down again. I am very annoyed, as it is interfering with school work.—cyberpower ^Chat_Absent 12:24, 28 January 2014 (UTC)

 Resolved DDoS has now been taken care of. Tools have been re-activated.—cyberpower ^Chat_Absent 21:12, 28 January 2014 (UTC)

@Cyberpower678: The "Edit count" link works great now, but I'm still getting the 502 proxy error for the "Articles created" link for my user ID, but not for your user id. Does it just not support editors with a lot of edits? GoingBatty (talk) 01:26, 31 January 2014 (UTC)

Requests at https://tools.wmflabs.org/xtools/pcount/index.php?name=STSHOES&lang=en&wiki=wikipedia are reporting:

Proxy Error

The proxy server received an invalid response from an upstream server.

The proxy server could not handle the request GET /xtools/pcount/index.php.

Reason: Error reading from remote server.

Kudpung กุดผึ้ง (talk) 03:13, 28 January 2014 (UTC)

See #Articles created link generates error thread above. ~HueSatLum 03:24, 28 January 2014 (UTC)

In the article Prime number, when the link requires excluding is clicked from the article itself, it takes me where it's supposed to but when ever I clicking that same link in an editing preview, it instead takes me to the page Editing Prime number, which I was already on. Blackbombchu (talk) 02:20, 29 January 2014 (UTC)

Well, that's because it's supposed to take you there; that link links back to the Prime number page (a specific section of it, to be precise), so it will never take you to a different page, whether you're in preview or not. Working as intended. :) Writ Keeper ⚇♔ 02:34, 29 January 2014 (UTC)

I made a mistake. The way it really works is opening that link in a new tab automatically goes to the page Editing prime number and left clicking it automatically goes to the article itself regardless of whether the link was clicked from the preview or the article. I didn't realize it because I almost always left click a link when I'm reading an article and almost always open a link in a new tab when I'm editing an article to not lose editing progress. Blackbombchu (talk) 17:21, 29 January 2014 (UTC)

Here's what's happening:

1. Edit the page (in source mode) and preview it.
2. Find the piped link and click to open it in a new tab.
3. Discover that the piped link took you to https://en.wikipedia.org/w/index.php?title=Prime_number&action=submit#Primality_of_one rather than to https://en.wikipedia.org/wiki/Prime_number#Primality_of_one

This is "working as designed". The piped link is not to Prime number#Primality_of_one; it's to the #Primality_of_one section of whatever page you happen to be on. If you are on https://en.wikipedia.org/w/index.php?title=Prime_number&action=submit when you click that link, then it will take you to that section on https://en.wikipedia.org/w/index.php?title=Prime_number&action=submit, not that section on https://en.wikipedia.org/wiki/Prime_number (which it believes is a completely different page).

If you didn't want to have this function, then you would change the link to specify not "whatever page I happen to be on", but specifically the Prime number article. That is, you would change the link from #Primality_of_one to Prime number#Primality_of_one. Whatamidoing (WMF) (talk) 01:51, 30 January 2014 (UTC)

Hi. Can someone help me in making this template work properly here? I can't seem to figure out what went wrong... Rehman 14:05, 29 January 2014 (UTC)

Reh, it would certainly be helpful if you could tell us what you perceive as not working properly. Otherwise, it will be very difficult to assist you. Technical 13 (talk) 16:59, 29 January 2014 (UTC)

Technical 13, The majority of the template (first link) is not transcluding properly (second link). Rehman 00:04, 30 January 2014 (UTC)

That is because you are passing in empty parameters and the core Infobox template excludes empty parameters simply speaking. Technical 13 (talk) 00:47, 30 January 2014 (UTC)

Woops. I actually transcluded the wrong template version. Thanks anyways. Rehman 13:54, 30 January 2014 (UTC)

Heya, firstly, let me apologize if you're already aware and working on this. I have noticed bots going around and correcting deprecated "month" and "day" parameters from {{cite}} templates used in articles, but I've also noticed while editing that the super-convenient built-in fill-in-the-blanks tool we editors use for adding citations (Edit window --> pull-down Cite menu --> Templates --> cite web) still encourage entry of "month" and "day" data. Should they be updated? Thanks! Cyphoidbomb (talk) 17:18, 29 January 2014 (UTC)

Traditionally, there is a lack of communication between those who add or deprecate template features, and those who write tools to manipulate those templates. What makes it worse is that there are more than one fill-in-the-blanks tool for refs. If you know the name of your tool - or even better, the actual javascript file that drives it - you can check a page history to see who the chief maintainers are, and ask them to update the tool. --Redrose64 (talk) 17:28, 29 January 2014 (UTC)

While the WMF is off spending who knows how much resources studying and trying to change our editor demographics and developing software tools we may not need, our basic editing features have been sitting and rotting. Our default cite toolbar feature is in desire need of update. I wrote a replacement that I think with some more work could be awesome but I tried and failed to get it to work with WikiEditor because WikiEditor is pretty miserably documented. I literally spent a few wasted, frustrated days on it. I left messages for the devs asking some questions on how to use WikiEditor but never got a reply. WikiEditor is supposed to be extensible but in reality it's only so for simple things and even that requires more thought and effort than should be necessary. The software seems to work but using it is just a pain in the butt because of the documentation. What a waste to write a cool thing and then make it half worthless by not bothering with good documentation! The assigner and overseeer of projects at the WMF needs to remember that good documentation is part of finishing a project and the devs should spent good paid time to write it. Also, they need to remember that the devs need to maintain the project long after the main coding is done. In essence, our entire default editing interface (WikiEditor+Reftoolbar2.0) is abandonware. It's reprehensible that we are in such a situation. It's on my todo list to try again to get my cite tool working. I've just been too short on time lately to focus on something like that.

More generally, I think, as a whole, the editors need to start being rather conservative about changing certain features like in cite templates. Plus we need to start embracing the idea of putting some responsibility on those who proposing feature changes with actually updating the site and implementing the changes. There's an imbalance between how much effort is required to make a change (virtually none) and how much it takes to implement a change (potentially thousands of editing hours). This can result in a growing backlog of undone work. Jason Quinn (talk) 20:03, 29 January 2014 (UTC)

There used to be a time where volunteers just helped out and did stuff (like build Reftoolbar 2.0, which yes, quelle surprise, was built by a volunteer). It seems that these days the only thing we do is complain about stuff that the WMF should do, and we are too lazy to take care of ourselves. If you have questions, ask them. If there is no answer where you ask them, ask them in places where you do get answers WP:VP/T and IRC for instance. It might take a while for the right person to surface, but i've NEVER had a question go unanswered. And stop complaining that everything is hard, it is. It's not a simple project that we are doing. —TheDJ (talk • contribs) 07:22, 30 January 2014 (UTC)

From some history digging, it seems you were trying to create a dialog. That is one of those functionalities that was never really finished and thus stayed rather undocumented indeed. Some starting points are the createDialog function in the never released template editor for WikiEditor or of course MediaWiki:RefToolbar.js. You need to make sure that the user has the dialogs enabled. The logic for dealing with 10 levels of deprecated stuff that everyone is still using regardless is located at the bottom of MediaWiki:Common.js/edit.js, where the various versions of ref toolbar are loaded. —TheDJ (talk • contribs) 07:58, 30 January 2014 (UTC)

That doesn't happen for me; if I enable in my preferences either the edit toolbar or enhanced edit toolbar, I get a box that is just labeled "publication date". I'm afraid you will have to tell us all about your preferences before we can reproduce the problem. Jc3s5h (talk) 17:34, 29 January 2014 (UTC)

@Jc3s5h: I don't see 'publication date' in any of the RefToolbar code. You ahve mentioned this before. Get with me and lets figure this out. --  Gadget850 ^talk 21:27, 29 January 2014 (UTC)

We have two pieces here: The Citation Style 1 templates, which are actively maintained, and RefToolbar which is not well maintained. To compound the issue, RefToolbar went from a script, to a gadget, to a default. New discussions on the talk page get no response. Our options are to either dump it or get some editors involved to refresh it. I think I could at least fix part of the current issue. --  Gadget850 ^talk 21:21, 29 January 2014 (UTC)

Is it this: MediaWiki:RefToolbarLegacy.js? This code has fields for publication date (and coauthors, also deprecated) for some of the various cite types and has fields for date and fields for date or year in at least one.

If it is, then the publication date and plain date fields could be changed to date or year. I might even suggest that the code be further changed to emit only |date= and not emit |year= at all; this because date encompasses years and will allow for the eventual deprecation of |year= from CS1. I'm ignoring the possibility of disambiguated CITEREF not currently supported by |date= in {{cite map}} which has not yet been fully migrated to Module:Citation/CS1.

—Trappist the monk (talk) 21:58, 29 January 2014 (UTC)

You know, I designed the script so that things like this would be a rather trivial thing to change, but apparently no one can be bothered to read the documentation. You don't even really need to know JS to fix it. Mr.Z-man 23:27, 29 January 2014 (UTC)

Hey, sorry all, I'm not slick with the technical backbone of Wikipedia. I was referring to the built in default citation editor, which unfortunately is not clearly labeled in a way that I could easily refer to it. If I inspect the element I see <div id="citetoolbar-web">. Googling that, I found this pdf, which looks exactly like what I am talking about. So I guess "cite toolbar" is what I mean. Thanks, Cyphoidbomb (talk) 06:10, 30 January 2014 (UTC)

All Wikipedia pages are very slow to load today. Each page view is taking maybe 30 seconds or more to complete, even on pages like the login page and my watchlist. This also happens when I am logged out, so it's not the edit filter issue discussed above. Other sites are loading fine. Is anyone else having the same problems? I'm editing from Sapporo, Japan, which may explain why others haven't mentioned this here yet. I understand that geographical location plays a big part in who sees problems and who doesn't. — Mr. Stradivarius ^{♪ talk ♪} 02:10, 30 January 2014 (UTC)

Things seem to have have returned to normal now. — Mr. Stradivarius ^{♪ talk ♪} 04:32, 30 January 2014 (UTC)

I'm noticing a bit of slowness too, today, but it may be because I'm traveling and using someone else's computer. The slowness I notice is just at Wikipedia, not at any other websites. --Tryptofish (talk) 19:31, 31 January 2014 (UTC)

I seem to remember a few users way back had sports teams scores updated on their wikipedia user pages, at the time it looked like these were dynamically updated through code and not edited by the user. Anyone know if that is possible? Thanks a million. ^{Market St.⧏} _{⧐ Diamond Way} 07:13, 30 January 2014 (UTC)

I'd guess that it was a template that was manually updated with the scores and was transcluded onto people's pages. WhatamIdoing (talk) 00:40, 1 February 2014 (UTC)

Thanks for the feedback, I was afraid that was the case. ^{Market St.⧏} _{⧐ Diamond Way} 13:11, 1 February 2014 (UTC)

Is there any automated or quick way of adding an archiveURL to a {{cite}} template when writing a reference. I sometimes take the trouble to look up a URL on the WaybackMachine but it is pretty fiddly having to copy & paste a URL, then sit there waiting and waiting for the WaybackMachine to come up with something, and then have to copy & paste all the info back again! Is there Wikipedia a bot or plugin that can do some sort of auto-lookup? Would be really helpful! Cnbrb (talk) 15:09, 30 January 2014 (UTC)

See WP:Reflinks. --  Gadget850 ^talk 15:10, 30 January 2014 (UTC)

Reflinks. I never use it: I've seen too many other people using it to put utter trash into a cite template, as here. |author=Published Friday, Nov 5 2010, 10:06 GMT - say what? --Redrose64 (talk) 16:02, 30 January 2014 (UTC)

I don't think WP:Reflinks adds archiveurls. Did you mean WP:Checklinks? GoingBatty (talk) 00:50, 31 January 2014 (UTC)

I just tried Checklinks - thanks for the suggestion but it doesn't seem to work for me. How does it work? Cnbrb (talk) 00:46, 1 February 2014 (UTC)

There appears to have been a recent change to the interface involved in the Education Program which results in a listing of user roles at the top of the contribs page of involved editors: see for example Special:Contributions/Keilana. However, this seems to have caused some sort of error in my case: attempting to view Special:Contributions/Nikkimaria results in the error message "PHP fatal error in /usr/local/apache/common-local/php-1.23wmf11/extensions/EducationProgram/includes/UserRolesMessage.php line 250: Using $this when not in object context". This error has persisted for several hours, but hasn't appeared in the contribs pages of anyone else involved in the EP as far as I can tell. Anyone have any idea why? Nikkimaria (talk) 05:54, 31 January 2014 (UTC)

Thanks for reporting. This seems to be tracked in bugzilla:60641 — Preceding unsigned comment added by AKlapper (WMF) (talk • contribs) 12:35, 31 January 2014 (UTC)

When I go to the contributions page for an editor, then click on the tool to find out what articles he has created, I get a long delay then a Yahoo page which says "The requested URL "https://tools.wmflabs.org/xtools/pages/index.php?hsimp=yhse-001" cannot be found or is not available. Please check the spelling or try again later." I tried this a couple of times with no success. Is there an alternative way to learn what articles a user has created, other than paging through every contribution? Edison (talk) 17:02, 31 January 2014 (UTC)

Well, now it's back to working. Edison (talk) 17:07, 31 January 2014 (UTC)

Yeah, xtools has been dealing with some attacks lately and has been going down as a result... Usually the quickest way to get it looked at is to post on the maintainer's talk page (User talk:Cyberpower678). Happy editing! Technical 13 (talk) 17:28, 31 January 2014 (UTC)

T13: Do you have a citation for the claim that the tool is "dealing with some attacks lately"? That sounds made-up. --MZMcBride (talk) 19:36, 31 January 2014 (UTC)

MZMcBride see User_talk:Cyberpower678#xtools_problem Technical 13 (talk) 20:32, 31 January 2014 (UTC)

T13: Thanks for the link. Having now read through the discussion, the issue still sounds made-up. I imagine this is misdiagnosis on the part of Cyberpower678. Unless Cyberpower678 or someone else can provide actual evidence of an DDoS, I'll simply assume the issues are the result of poor coding and/or Labs stupidity. --MZMcBride (talk) 21:34, 31 January 2014 (UTC)

Talk about failing to assume good faith in your fellow volunteers. Seriously.Blethering Scot 21:37, 31 January 2014 (UTC)

Whether or not its an intended DDoS, a poorly coded spider can have the same result. The issue is the tools are being hit by a mass of unwanted, non-human traffic that is placing excessive stress on the that project which is causing a disruption of services. Werieth (talk) 21:43, 31 January 2014 (UTC)

Werieth: Sure, misbehaving spiders can cause denial-of-service-like symptoms and that may be the case here. I don't know of spiders engaging in distributed denial-of-service attacks, however.

Do you have a Labs account? (I don't see a "werieth" account off-hand, but I may be looking in the wrong place.) How, specifically, are you reaching the conclusion that "tools are being hit by a mass of unwanted, non-human traffic that is placing excessive stress on the that project which is causing a disruption of services"? Has this been reported/discussed elsewhere? That sounds fairly serious. --MZMcBride (talk) 22:05, 31 January 2014 (UTC)

MZMcBride I tend to just read around the different lists and IRC channel logs, all labs IRC logs. From what I read up on the issue is caused by a spider from phonifier.com. Due to labs's structure of having separate lighthttpd servers on a per tool setup if any one is overloaded it doesnt effect the others. From what I was reading I dont think its a DDoS, just a DoS. Werieth (talk) 23:31, 31 January 2014 (UTC)

Blethering Scot: Should I instead assume bad faith on the part of anonymous users around the world? :-) I'm familiar with both Labs and Cyberpower678's coding abilities. It's possible that Labs was/is being subject to a distributed denial-of-service attack, but given various other factors at play here and the lack of credible evidence to suggest that it is, I think it's safe to assume a misdiagnosis. I don't want to see citation-less (mis)information spread around the wiki (jumping from a user talk page to a technical village pump). If anyone believes that Labs is under attack, there's a capable operations team that can investigate. --MZMcBride (talk) 22:01, 31 January 2014 (UTC)

• Meh, that's kind of why I was trying to be fairly generic and was hoping the issues would quickly blow over... Oh well... Later. Technical 13 (talk) 22:56, 31 January 2014 (UTC)

• MzMcBride's concerns are justified based off of the Blacklisted Links task of Cyberbot II. A note to MzMcBride though, my coding skills are of no concern here my skills in PHP are quite sound, and my diagnosis is roughly 90% correct of all diagnosis made. What is a concern, which I am working on is my attitude and approach. During the blacklisted links incident, I was incredibly frustrated, and suffered a blow to my head from a fallen roof gutter. So my judgement and mindset wasn't all there during that incident. Back to xtools however, there was a DoS, and now the webserver is acting very weird. Coren can personally verify that he blocked 3 IP ranges that linked to the spiders. Scfc_de on IRC blocked a domain belonging to phonifier.com. Activity has dropped now and the tools should be working, but for some unknown reason, the webserver is still failing. scfc_de hasn't been able to figure it out yet, nor have I. I plan to branch the tools into separate tool accounts. And to prove that this isn't a misdiagnosis, the tools haven't been altered in any way for the last several weeks whereas the problem started a few days ago. Also the access log should extremely high activity for xtools. I hope this helps.—cyberpower ^Chat_Absent 00:42, 1 February 2014 (UTC)

Is there any way to count how many pages links to a certain page or translude a certain template? (Something like magic word PAGESINCAT) --XXN (talk) 21:40, 24 January 2014 (UTC)

No magic word, but you can get an on-the-fly count of transclusions by using the "Page information" link in the sidebar, and look for "Pages transcluded on". --Redrose64 (talk) 22:17, 24 January 2014 (UTC)

For template ”infobox officeholder” number of transclusions is not displayed. XXN (talk) 20:38, 30 January 2014 (UTC)

Indeed; that seems to be a bug, because there are certainly at least 50. --Redrose64 (talk) 20:58, 30 January 2014 (UTC)

@XXN: Seems to be working again. --Redrose64 (talk) 22:45, 30 January 2014 (UTC)

• You can also get this information from the API (mw:API:Alltransclusions) if you are writing yourself a userscript perchance that needs the information. Technical 13 (talk) 22:35, 24 January 2014 (UTC)

Thank you. But total number of pages what links to a certain page? Do any feature count it? (i.e. for page River?) //XXN (talk) 00:01, 25 January 2014 (UTC)

• Older tool: http://toolserver.org/~jarry/templatecount/index.php?lang=en&namespace=10&name=Infobox+officeholder Werieth (talk) 21:10, 30 January 2014 (UTC)
• You can also get the information yourself from page information for River. This doesn't really help you with an automated method. Technical 13 (talk) 21:47, 30 January 2014 (UTC)

All that {{Transclusion count}} does is create a link to an anchor on the "Page information" page. It doesn't calculate anything additional. --Redrose64 (talk) 22:45, 30 January 2014 (UTC)

• That is correct Rose. Was pointing to the page, not suggesting using the template. Technical 13 (talk) 23:02, 30 January 2014 (UTC)

The "Page information" pages for some reason don't show the number of transclusions anymore. A new section about this has just been started. SiBr₄ (talk) 13:02, 2 February 2014 (UTC)

I don't know if this is a bug or a technical issue but templates don't get updated automatically. For example, at this page you can't see the title of the episode added on the template even though it was added to it. I know that if I purge the page the update will happen but, someone can't purge ALL the pages the template is everytime a new info is added to it. The same thing happens with infoboxes that contain templates in them and also at this page, the episode is also not linked even though the page that has to be updated is updated. These were no happening before...why are they happening now? Can anyone help? Thanks TeamGale 07:40, 2 February 2014 (UTC)

• Please read job queue. Technical 13 (talk) 15:24, 2 February 2014 (UTC)

Thanks. It's just that about a month ago they were being updated automatically and I was wondering. Or maybe I didn't notice the delay...? I don't know. I'll wait to see how long they need. Thanks again TeamGale 20:25, 2 February 2014 (UTC)

Some time last year, the transclusion count was added to the page information for templates and modules, and perhaps other pages too. However, in the last week or so, the transclusion count seems to have disappeared. For example, https://en.wikipedia.org/w/index.php?title=Template:Ubxdisplay&action=info#mw-pageinfo-transclusions used to link to the "transclusions" section of Template:Ubxdisplay's info page, but now there is no such section. Does anyone know why it isn't showing up? — Mr. Stradivarius ^{♪ talk ♪} 12:40, 2 February 2014 (UTC)

The count appears to have been removed from display when "miser mode" is enabled in gerrit:107903 (and an underlying query was removed in gerrit:109710). Given the summaries, presumably it was determined these were causing too much load. Anomie⚔ 16:06, 2 February 2014 (UTC)

Sometimes it's there, sometimes not. See #Count transclusions/links. --Redrose64 (talk) 16:35, 2 February 2014 (UTC)

I imagine that this is due to old versions of info pages still being cached. I'm struggling to find any pages where the transclusion count is displayed at the moment. — Mr. Stradivarius ^{♪ talk ♪} 22:40, 2 February 2014 (UTC)

• Added the tracked for the specific Bugzilla:60740 ticket by MZMcBride and gerrit:110299 is where it is already being worked on getting fixed from my understanding. Technical 13 (talk) 17:44, 2 February 2014 (UTC)
  • T13: gerrit:110299 is completely unrelated. --MZMcBride (talk) 20:05, 2 February 2014 (UTC)

Moved to Wikipedia:Village pump (policy)/Archive 112#RFC: Indefinitely blocked IP addresses — Preceding unsigned comment added by TeleComNasSprVen (talk • contribs) 02:48, 3 February 2014 (UTC)

08:30, 3 February 2014 (UTC)

I think we have fixed most templates so mixed numbers hide a space after the whole-number portion (to allow screenreaders to separate fraction portion). The next issue is the over-tall fractions, where superscript+subscript format could be reduced as superscript+small denominator; compare:

1. superscript+subscript format: ²⁷⁄₃₂, ³⁄₄ as ³&frasl;₄
2. superscript+small format:      ²⁷/32, ³/4 as ³/<small>4</small>

By avoiding subscripts, ₄, then the line-height seems to remain consistent to better align with text not containing fractions. Except for being a new fraction format, can anyone think of technical problems which might occur by keeping the denominator inline as small-font text? People have complained for years about over-tall fractions, but no hurry on this. -Wikid77 (talk) 12:13, 3 February 2014 (UTC)

Reformatting of fractions is discussed every year or so. If any change is made, it must consider MOS:ACCESS. --Redrose64 (talk) 12:34, 3 February 2014 (UTC)

<small> may not render in the same fontsize as <sup>, so I would advice against it. And to be frank... I don't see any 'issue' here. — Edokter (talk) — 13:14, 3 February 2014 (UTC)

• Main issue is interline spacing as font size similar: Although the font-size difference is an issue, I think the difference is one pixel, as a smaller difference than the current slash "/" versus fraction &frasl "⁄". However, the way fractions shift the line spacing downward seems to be about 10 pixels, which is a "horrific" order of magnitude greater than a 1-pixel font difference, and that has been the main complaint about over-tall fractions for years. By comparison, using the small-font denominator (here: ³/4) would barely affect the interline spacing and certainly not lower a line by 10-pixel downward shift or such. As an example, note above how in the 2 numbered examples, the downward shift in line "1." is much greater than the shifting in line "2." above. -Wikid77 21:22, 3 February 2014 (UTC)

Being buried in list items does not show the issue, and inline (²⁷⁄₃₂ v.s ²⁷/32) certainly does not show the 10 pixel displacement you claim (I only see 1px displacement). Screenshots would help here, but I'm afraid it won't help much; minor displacement is inherent to sub- and super scripts. You'd still see the the above line being displaced upward due to the superscript. The &frasl; entity was also chosen to be semantically correct, which the slash is not. The proposed format looks horrid to me; very badly typeset and out of alignment. — Edokter (talk) — 19:27, 4 February 2014 (UTC)

I entered "Brolin" in Wikipedia search and instead of a list of search results I was taken straight to this page: http://en.wikipedia.org/wiki/Brolin

This seems to be a serious flaw in Wikipedia. "Search" does not mean "Redirect me to a page that matches the search term."

If I google "Brolin" the first page of results shows 3 Wikipedia pages, including the one I was looking for. Wikipedia search, meanwhile, seems more like Google's "I'm feeling lucky" option, although I think most people would feel pretty unlucky if Google sent them to a page about Famotidine...

What's gone wrong with Wikipedia search? Dadge (talk) 13:18, 3 February 2014 (UTC)

Did you click the magnifying glass icon (Vector skin) or the Search button (Monobook skin), or did you just press ↵ Enter? --Redrose64 (talk) 13:37, 3 February 2014 (UTC)

I think Brolin is a bad redirect. It should probably be a disambig since there's also results under Josh Brolin, Tomas Brolin and James Brolin. If you do the Google test, most of these people will return higher than the current target of Famotidine. Heck, the redirected word doesn't even appear in the article :\ ^demon^{[omg plz]} 18:32, 3 February 2014 (UTC)

This is by design. Below the search box there should be a drop-down box saying "containing..." Click that to get a list of search results instead of going directly to a matching page name or redirect. Otherwise you hit a redirect [21] from Brolin to Famotidine. Instead of "containing..." you can also start with a blank search and then use the other search box at Special:Search. PrimeHunter (talk) 18:50, 3 February 2014 (UTC)

• To force search, use "~Brolin" to avoid redirect: There is a documented trick by using a prefix tilde "~" to turn the wp:wikisearch back into an actual search-mode operation. Every few years, the exact-page match had been suppressed, to retain the typical search-mode results, and then someone decided how a non-searching-exact-match is somehow better rather than being a massive warping of the concept of searching for all pages matching a word. Without a doubt, the exact-match redirect is a horrendous problem which can leave new users totally stunned with how to actually "Search" for all pages which contain various words. Yet, so many wikiwarp problems in Wikipedia have been overlooked (or ignored, such as wp:edit-conflicts) with the lazy excuse, "the users will learn to cope" as a way to rationalize the release of poor software. But think how easy to just set the wikisearch software to just always "search" (duh) or to auto-merge edit-conflicts to adjacent lines (set diff3.c line-count delta from 1 to 0). There is a fine line between "smart software" and "smart-ass software" and we should try to be on the better side of that line. -Wikid77 (talk) 21:22, 3 February 2014 (UTC)

Hi everyone. So we've finished indexing all of the English Wikipedia and we're ready for more of you to give the new search engine a try. So we've made it a beta feature that you can enable. Just click "New search" and all of your searches (prefix and full text) will go via the new search engine Cirrus. I hope you'll give it a try, and if you have any feedback please feel free to file a bug in Bugzilla or leave some feedback on the project talk page. Thanks! ^demon^{[omg plz]} 17:51, 3 February 2014 (UTC)

• Cirrus matches exact spelling, singular/plural, but no markup: I have also confirmed how CirrusSearch does not automatically match both singular and plural forms, but the biggest difference is not "seeing" the markup at all during a search. A CirrusSearch for "align center" will only match those words in the rendered text (rare), and similarly searching for {{convert}} parameters "abbr on" will not match the markup with CirrusSearch. Obviously, we now need to keep both types of search, and call the current MediaWiki search as the "markup-search" feature which can also search template parameter names/values, spantags, nowiki tags, and other markup before rendered. -Wikid77 14:45, 4 February 2014 (UTC)

  Obviously we don't. Please use AWB's Database Scanner to search for specific markup. It's not like you could ever search for ''' using the search, I don't see why you would want to search for align=center. Matma Rex talk 15:02, 4 February 2014 (UTC)

  I'm finding that folks use search for wiki maintenance quite a bit and while searching rendered text has its upsides it makes that more difficult. As for exact Cirrus not searching plurals can you post an example? If you put text in quotes then it'll require a more exact match. I've just updated the documentation to be more clear. NEverett (WMF) (talk) 16:26, 4 February 2014 (UTC)

  I'm obviously clueless - click "new search" where? Dougweller (talk) 18:51, 4 February 2014 (UTC)

In the previous sentence, there is a link to it. --Redrose64 (talk) 20:16, 4 February 2014 (UTC)

Thanks. Dougweller (talk) 21:38, 4 February 2014 (UTC)

Matma Rex: bugzilla:43652 :-) --MZMcBride (talk) 01:21, 5 February 2014 (UTC)

To see what I want to use requires going to the photo's page. I would like to enlarge a portion of the photo to use on the article.— Vchimpanzee · talk · contributions · 20:32, 3 February 2014 (UTC)

Someone who knows how would have to do this.— Vchimpanzee · talk · contributions · 20:52, 3 February 2014 (UTC)

You would need to create a new image based off the old one, as there's no way that I know of to "thumbnail" an image in that fashion. --Izno (talk) 21:03, 3 February 2014 (UTC)

(edit conflict) A couple of days ago, I wanted a coat-of-arms for this article section. So I went to this image, downloaded the original file to my PC, loaded it into an image editor, cropped off the unwanted sections, and saved the image without enlargement or any other resizing. Then I uploaded the result to File:Great Central Railway Coat of Arms.jpg preserving the licensing etc. of the original. At commons:Commons:Upload, the link a derivative work of one or several files from Commons can be used for this. --Redrose64 (talk) 21:04, 3 February 2014 (UTC)

Thanks. I don't have the software or know how to use it.— Vchimpanzee · talk · contributions · 21:06, 3 February 2014 (UTC)

The specific image editor that I used was Microsoft Office Picture Manager 12; it came free with Microsoft Office 2007 Home & Student Edition, but isn't listed on the box. --Redrose64 (talk) 21:28, 3 February 2014 (UTC)

What portion of the image should be retained after the rest is cropped off? --Redrose64 (talk) 21:11, 3 February 2014 (UTC)

I want the two stop lights on the left side.— Vchimpanzee · talk · contributions · 21:23, 3 February 2014 (UTC)

I'll have a go. It might take more than one attempt, if I crop off too much or too little. --Redrose64 (talk) 21:28, 3 February 2014 (UTC)

Thanks.— Vchimpanzee · talk · contributions · 21:30, 3 February 2014 (UTC)

 Done, see File:Mint Museum in uptown Charlotte, North Carolina crop.jpg --Redrose64 (talk) 21:41, 3 February 2014 (UTC)

For images on Commons, there is an excellent cropping tool Commons:Commons:CropTool. I run it directly at http://tools.wmflabs.org/croptool/ Thincat (talk) 21:45, 3 February 2014 (UTC)

Thanks. Here is the result I wanted.— Vchimpanzee · talk · contributions · 23:07, 3 February 2014 (UTC)

(edit conflict) alternatively, you can use Template:Cropped image. if the original image is very large, and the portion you want to show is small, then this might be wasteful, otherwise it may be a good solution. (after conflict: i am not sure this is a good use-case...) peace - קיפודנחש (aka kipod) (talk) 23:12, 3 February 2014 (UTC)

About 15 months ago I had my username changed from Basemetal00 to Basemetal.

On the English Wikipedia all my contributions were transferred from one username to the other: when you display Contributions by Basemetal on the English WP you also see those edits made under Basemetal00 and when you try to display Contributions by Basemetal00 on the English WP you get nothing. This is as it should be.

But, despite SUL, this does not happen on Wikipedias in other languages. There (I'll demonstrate what happens on the German Wikipedia) Contributions by Basemetal on the German WP and Contributions by Basemetal00 on the German WP show separately and of course edits made under Basemetal00 do not show up under Basemetal.

How come, despite of SUL, something like this can happen? Can this be fixed? Should this be considered a bug?

It's not so much that I really care about two old edits not showing up. It's more that I'm concerned about the technical implications of this in terms of the robustness of the software.

Contact Basemetal here 21:09, 3 February 2014 (UTC)

It's not a bug; it happens because, right now, renames are purely local: any account that is renamed is renamed only on that one wiki, not all the others. Renaming an account thus detaches the local account from the SUL. So, for you, when you were renamed, your Basemetal account here was detached from your Basemetal00 SUL, which is why your other accounts don't link up. In order to fix this, you'll have to go to all your other local accounts on the other wikis and ask the local 'crats to rename each account to Basemetal and to merge the accounts under the Basemetal SUL. This is planned to change by making all renames be global, not local, but the project has not been done yet, and there isn't an ETA for it yet. Writ Keeper ⚇♔ 21:15, 3 February 2014 (UTC)

(edit conflict) It's a known problem, and the MediaWiki devs were hoping to address it in mid/late 2013 but there have been delays. Essentially what you need to do for the time being is to file a separate user rename request at every individual wikipedia language, commons, meta, etc. that you have ever edited on. --Redrose64 (talk) 21:16, 3 February 2014 (UTC)

Greetings everyone. After much processing has been brought to bear, I've aggregated all the page view statistics for 2013 (I'm the guy who does WP:5000 on a weekly basis). I thought these would likely be of broader interest, so I decided to post here. For a more analytical discussion about what drives these statistics, see our older Signpost article.

• The 10,000 most popular pages of 2013 (be patient with load time!)

ARTICLE            | VIEWS
--------------------------------------
[[Main_Page]]      | 3,895,581,597
[[Facebook]]       | 30,608,777
[[Deaths_in_2013]] | 21,246,624
[[Breaking_Bad]]   | 17,389,161
[[Google]]         | 16,759,294
[[World_War_II]]   | 16,676,636
[[Wiki]]           | 16,285,560
[[YouTube]]        | 15,938,076

• Articles with most views in a single hour

ARTICLE                  | UTC DATE          | VIEWS     | REASON
----------------------------------------------------------------------
[[Jorge_Bergoglio]]	 | March 13, 2013    | 1,460,586 | Papal ascension
[[Shakuntala_Devi]]	 | November 4, 2013  | 766,256   | Google Doodle
[[Paul_Walker]]	         | December 1, 2013  | 752,770   | Death
[[Grace_Hopper]]	 | December 9, 2013  | 621,694   | Google Doodle
[[Nelson_Mandela]]	 | December 5, 2013  | 484,966   | Death
[[Jodie_Foster]]         | January 14, 2013  | 451,270   | Came out at Golden Globes
[[Beyonc%C3%A9_Knowles]] | February 4, 2013  | 378,923   | Super bowl halftime
[[Nicolaus_Copernicus]]  | February 19, 2013 | 336,836   | Google Doodle
[[Seth_MacFarlane]]      | February 25, 2013 | 320,999   | Hosted the Oscars
[[Daniel_Day-Lewis]]     | February 25, 2013 | 318,839   | Oscars
[[Society_of_Jesus]]     | March 13, 2013    | 287,568   | Papal ascension
[[Mindy_McCready]]       | February 18, 2013 | 282,679   | Death
[[Hermann_Rorschach]]	 | November 8, 2013  | 276,072   | Google Doodle
[[Edith_Head]]           | October 28, 2013  | 263,915   | Google Doodle
[[Raymond_Loewy]]	 | November 5, 2013  | 258,301   | Google Doodle
[[Margaret_Thatcher]]    | April 8, 2013     | 252,906   | Death
[[Pope_Francis]]         | March 13, 2013    | 248,753   | Papal ascension
[[Peter_Capaldi]]        | August 4, 2013    | 244,667   | Announced as next Dr. Who

Thanks everyone! West.andrew.g (talk) 21:24, 3 February 2014 (UTC)

What's with the 2MASS_J04414489 etc articles in the raw data - script anomaly? — Preceding unsigned comment added by Andrew Gray (talk • contribs) 23:04, 3 February 2014 (UTC)

It's not the fault of my aggregation script, but very likely to be someone else playing with the API or a misconfigured bot. When compiling WP:TOP25 from my raw data on a weekly basis, there is often a struggle to determine what is ("legitimate") human traffic versus machines. For example, I know in 2009 that the "Jyllands-Posten Muhammad cartoon controversy" article was subject to a DDOS attack and got 5.3 million views in one hour. West.andrew.g (talk) 02:41, 4 February 2014 (UTC)

A discussion has begun on the possibility of creating a Live Feed to enhance the processing of Articles for Creation and Drafts. See Wikipedia:WikiProject Articles for creation/RfC to create a 'Special:NewDraftsFeed' system. Kudpung กุดผึ้ง (talk) 05:14, 4 February 2014 (UTC)

Hi, I was wondering if one of the template experts that hang around here :) could help with this problem on Commons:Help desk#Template:Sisterheader. The group of templates: Sisterheader and Sisterend do not "clear:right;" or "clear:both;" at the bottom, so Categories on Commons that have this set of templates (see here for backlinks: [22]) need a {Template:-} after Sisterend to not run into the "Subcategories" listing, such as in this old version of Category:Coffee. Thanks in advance! Funandtrvl (talk) 00:31, 5 February 2014 (UTC)

I connected with the IRC channel expecting to be able to type in a question and get someone's typed reply. I saw a grey screen with instructions telling me to type in my question at the bottom of the page, followed by a bunch of "gibberish computer stuff." But nothing happens when I type. I do not see any of my text. Am I supposed to? I viewed the page on using the IRC, which seems to say that I should be able to use it with an up to date web browser. I am using the latest version of Firefox. — Preceding unsigned comment added by Meta Self (talk • contribs) 01:20, 4 February 2014 (UTC)

• You may need to click on the little white input box on the bottom of the screen to get the cursor there, you should then be able to type (you'll see your message) in that one line bar. When you are done, hit enter and watch the big gray box above. If someone replies directly to you, you should here a ping and there username will appear red. If you have more troubles, perhaps one of the help methods on the Questions will be better or you can ping me here or on my talk page for personal direct help (although this will be much slower than IRC). Good luck! — {{U|Technical 13}} ^{(t • e • c)} 02:25, 4 February 2014 (UTC)
• Thanks. Yeah, I found that white input box. Meta Self (talk) 11:39, 5 February 2014 (UTC)

I need a template capable to swap two words. For example:

{{Swap|AAA BBB}}

should produce

BBB AAA

Is there any template capable to do this? If not, can anyone help me to create one? Thanks. —  Ark25  (talk) 03:19, 4 February 2014 (UTC)

Assuming you always want to swap at the first space, you can use {{First word}} and {{Remove first word}}: {{Remove first word|{{{1}}}}} {{First word|{{{1}}}}}. Example: {{Remove first word|AAA BBB}} {{First word|AAA BBB}} produces BBB AAA. PrimeHunter (talk) 04:32, 4 February 2014 (UTC)

• Created Template:Swap: New Template:Swap runs 200x per second, as a combination of the Lua #invoke's for {Remove first word} and {first word}, plus decomma with {formatnum:|R} to swap first word to last, or reorder names from last-name-first: {{swap|Doe, John James}} → John James Doe. Thanks to all for ideas on rapid design, now in Category:Wikipedia formatting and function templates. -Wikid77 16:16, 4 February 2014 (UTC)

Thank you both! Another question: If I use {{subst}} and {{PAGENAME}} in combination with this template in an article, for example at Mihai Eminescu, how can make it so that, after saving my modification, to get in the source of the page the string "Eminescu Mihai" ? I tried with {{subst:swap|{{PAGENAME}}}} and {{subst:swap|{{subst:PAGENAME}}}} but it doesn't work. —  Ark25  (talk) 22:08, 4 February 2014 (UTC)

Well, it sort-of worked but added a load of extra markup into the page. I've updated the template to be subst-safe. {{subst:swap|{{subst:PAGENAME}}}} will now result in just "Eminescu Mihai" on that page, without the extra markup. – PartTimeGnome (talk | contribs) 22:59, 4 February 2014 (UTC)

Ohhh this is so sweet! You are both magicians of templates! Thanks!! Now I can simply add {{DEFAULTSORT:{{subst:swap|{{subst:PAGENAME}}}}}} to any page about people having just one birth name and one family name (many of them do). Pretty please, can you make another template {{Swap1}} or so, to add a comma between the two words? i.e. "Eminescu, Mihai". —  Ark25  (talk) 01:28, 5 February 2014 (UTC)

Remember there are exceptions to the {{DEFAULTSORT:Lastname, Firstname}} rule - see WP:SUR. GoingBatty (talk) 02:34, 5 February 2014 (UTC)

Well, I made such a template at ro:Template:Swap2 - seems to be working. The vast majority of Romanians have only one family name and the majority have only one birth name. It's cool to fix the DEFAULTSORT for them in a single click. If possible, someone please check it for possible errors. Thanks. —  Ark25  (talk) 03:33, 5 February 2014 (UTC)

Recently, I have begun working on STiki, and have noticed a lot if IP's have put their signature in the articles while changing some small bit of information. One example is here, although there are others that I have reverted that do essentially the same thing. Does anyone know if we have a way of combating this, or should maybe create an edit filter to fix this? Thanks! Kevin Rutherford (talk) 17:36, 4 February 2014 (UTC)

Right now, just revert and {{subst:uw-articlesig}}. Maybe we could create a filter to look for links to user or user talk space from mainspace. Jackmcbarn (talk) 18:30, 4 February 2014 (UTC)

Special:AbuseFilter/149? Helder 18:45, 4 February 2014 (UTC)

That only finds external links. We'd want something like lcase(added_lines) rlike "\[\[ *(user( +talk)? *:|special *: *contrib(ution)?s/)" (untested, beware) to find this. Jackmcbarn (talk) 18:50, 4 February 2014 (UTC)

Also, 149 only applies to registered users, not IP addresses. – PartTimeGnome (talk | contribs) 21:48, 4 February 2014 (UTC)

I've also noticed registered users occasionally signing articles with ~~~~ by mistake. --Stefan2 (talk) 23:04, 4 February 2014 (UTC)

See also CHECKWIKI error #95. — Preceding unsigned comment added by GoingBatty (talk • contribs) 02:37, 5 February 2014 (UTC)

Recently I am doing a simple experiment to compare the efficiency between "wiki-pipe" table markup, div and html table elements. I have no knowledge of preprocessor and am amazed that the preprocessor counts of div and html elements grows as the table content expands but the wiki-pipe markup doesn't. Would anyone kindly explain this mystery? Thanks. -- Sameboat - 同舟 (talk) 03:42, 5 February 2014 (UTC)

Part of the preprocessor is the HTML sanitizer; it processes the raw HTML so that it may integrate with the HTML that is generated by the parser (which turns the wikimarkup into HTML). Raw HTML is rarely used for tables. Only in cases where tables built with wikimarkup that interferes with template code and such is it better to use HTML. Otherwise, wikimarkup should be used. As you notice, wikimarkup takes less time to process. — Edokter (talk) — 09:48, 5 February 2014 (UTC)

Hi all, on this Portal subpage: Portal:Pittsburgh/On_this_day there is this text: "I dont like the Bengals" between January and February, it is NOT listed in any date subarticle nor is it findable with CNTRL+F on the portal subpage article. Wondering where exactly this text was entered and if we can delete it (it very much does not belong). Thank you. ^{Market St.⧏} _{⧐ Diamond Way} 10:42, 5 February 2014 (UTC)

Fixed. Bencherlite^Talk 10:55, 5 February 2014 (UTC)

Many thanks! ^{Market St.⧏} _{⧐ Diamond Way} 13:13, 5 February 2014 (UTC)

There's been a longstanding system bug by which some soft redirects to other wikis (e.g. Wikisource or Wiktionary) get erroneously picked up as "uncategorized articles" by the various uncategorized page detection tools. Most commonly this occurs after someone has converted a Wiktionary redirect into a dicdef article and then somebody else has reverted it back to a soft redirect — however, with the recent creation of {{Wikisource redirect}} a few days ago, it's now beginning to also happen to many pages on which the new template has been added as a replacement for {{softredirect|wikisource}}.

The problem is that once this erroneous automated pickup has happened, the only way the page can ever be removed from the uncats list again is to be permanently added to the internal Category:Temporary maintenance holdings category; just in the few days since the new template's creation I've had to so "categorize" Allende's last radio message, As some day it may happen, Chinese proverb, Chinese proverbs, Declaration of the Breakdown of Chile’s Democracy, Executive Order 13026, Executive Order 13072, French proverbs, German proverbs, Hungarian proverbs, Icelandic proverbs, Indonesian proverbs, Korean Air Lines Flight 007 transcripts, List of misquotations, List of Polish proverbs, Phil the Fluther's Ball, Portuguese proverbs, The Interest of America in Sea Power, Present and Future and The River Merchant's Wife: A Letter. In other words, I've had to add twice as many articles to that bugtrap "category" in the past week alone as have ever had to be added to it in the entire previous three years combined, and the problem's only going to get worse as the usage of that new replacement wikisource template expands further.

I've asked before if there was anything that could be done to fix this, but it keeps happening nonetheless. Can anybody assist in figuring out how to ensure that soft redirects stop getting improperly detected as uncategorized pages? Bearcat (talk) 01:37, 31 January 2014 (UTC)

• I just pulled Allende's last radio message out of Category:Temporary maintenance holdings to see what happens after I edited {{Wikisource redirect}} to try something. To be clear, you're saying these pages end up in Special:UncategorizedPages without this holding category? If so, we'll need to wait for the next update of that page to see if it reappears. You sure the bug hasn't been fixed? Technical 13 (talk) 02:08, 31 January 2014 (UTC)

This link is the primary tool I've been looking at. So far, both Allende and "As some day it may happen" have already immediately reappeared on the list; the "proverbs" pages that you pulled out as part of the test haven't, but those were tagged a few days ago and thus might potentially reappear tomorrow when the new daily batch rolls over, and the "deaths" ones were never part of this issue at all (the 2012 one was a similar but not directly related issue over a year ago; the 2013 one appears, from what I can tell, to have been added only because the 2012 one was in there and so whoever converted the 2013 list to a redirect erroneously assumed that was standard process in all cases.)

And just for the record, that tool doesn't pick up most soft redirects as a rule; it successfully avoids the vast majority of them overall, and only specific quirks like the situations I've talked about here (dicdef reversions, conversion of wikisource redirects to this new template) seem to trip it up, which means that there's something about the pages' status in our database that isn't correctly reporting rather than something in the toolserver coding. Bearcat (talk) 02:21, 31 January 2014 (UTC)

• (edit conflict × 2) I think I know what is going on, but it will take a little more time for stuff to process through to be sure. Have you tried contacting that tool's operator, JaGa to find out if it is something in the tool itself?

What I'm guessing is that the tool is only doing one check on the page props that looks like:

• https://en.wikipedia.org/w/api.php?action=query&prop=categories&format=xml&clshow=!hidden&cllimit=10&titles=Allende%27s+last+radio+message

API query response

<?xml version="1.0"?>
<api>
  <query>
    <pages>
      <page pageid="983737" ns="0" title="Allende&#039;s last radio message" />
      </pages>
    </query>
  </api>

The tools should be doing a second query that looks like:

• https://en.wikipedia.org/w/api.php?action=query&prop=categories&format=xml&clshow=hidden&cllimit=10&titles=Allende%27s+last+radio+message

API query response

<?xml version="1.0"?>
<api>
  <query>
    <pages>
      <page pageid="983737" ns="0" title="Allende&#039;s last radio message">
        <categories>
          <cl ns="14" title="Category:Redirects to Wikisource" />
        </categories>
      </page>
    </pages>
  </query>
</api>

The second query would pick up the fact that it is in a hidden category which it is currently missing. If the tool maintainer doesn't respond directly, I'll see if I can find the tool's code and find a way to submit a pull request to fix it. Technical 13 (talk) 02:51, 31 January 2014 (UTC)

Okay, I'll ask him about that. But I suspect that the tool is already coded for that, because as I noted above it successfully avoided soft redirects to Wikisource using the old template, which wouldn't have been the case if the toolserver wasn't already coded that way. Bearcat (talk) 02:57, 31 January 2014 (UTC)

• I've pinged him here, left a {{Talkback}} on his talk page pointing here and sent an email through the system... I've been playing in the Special:ApiSandbox and it seems that it can be done in one request like https://en.wikipedia.org/w/api.php?action=query&prop=categories&format=xml&cllimit=10&titles=Allende%27s+last+radio+message which returns
  API query response

<?xml version="1.0"?>
<api>
  <query>
    <pages>
      <page pageid="983737" ns="0" title="Allende&#039;s last radio message">
        <categories>
          <cl ns="14" title="Category:Redirects to Wikisource" />
        </categories>
      </page>
    </pages>
  </query>
</api>

So, I guess we'll just have to wait for the tool operator to respond.  :) Technical 13 (talk) 03:02, 31 January 2014 (UTC)

Well, just for the record I think the missing hidden category that you identified and added was the problem. I thought not at first, because the pages didn't drop from the list right away after you added it, but then I remembered that there's been a problem lately with pages lagging in picking up changes to their transcluded templates — so I null-edited both of the pages again, and that succeeded in dropping them. So it's still worth seeing if JaGa has anything helpful to contribute, but I think you've already fixed the problem. So thanks for that :-) Bearcat (talk) 03:14, 31 January 2014 (UTC)

Never mind. They both dropped on first refresh but then returned again on a second one, so the problem's still active and we'll definitely need JaGa's input. Bearcat (talk) 03:16, 31 January 2014 (UTC)

I'm totally not familiar with this, but just out of curiosity: what would happen if instead of manually adding Category:Temporary maintenance holdings at the bottom [23] you added Category:Redirects to Wikisource -- the text that is supposed to be being added by the template? In other words, is it the transclusion that doesn't work, or the category it's put in? Wnt (talk) 03:40, 7 February 2014 (UTC)

• Wnt, according to the bot operator's note on my talk page, Hey, FYI, I just went through the code and it does exclude certain hidden categories, such as Category:Redirects to Wiktionary, and didn't have an entry for Category:Redirects to Wikisource. I've now added it, so the problem should go away with tomorrow's run (but not with a user-triggered update). Please let me know if you still see the problem tomorrow! Thanks, --JaGa^talk 00:22, 8 February 2014 (UTC)

What is the user preference that causes the big blank space down the right-hand side of this screenshot? This is in relation to Template talk:Multiple issues#Default to collapsed? where it causes lateral compression of a banner, and hence the banner expands vertically. I have never had that blank space, so it must be something that GliderMaven (the user concerned) has set for themselves - I thought that it might be one of the new "beta" things, but it's not listed there, and I can't find where else it could be set. --Redrose64 (talk) 09:54, 31 January 2014 (UTC)

Yes its caused by the mw:Typography refresh beta feature.--Salix alba (talk): 10:25, 31 January 2014 (UTC)

• Also worth noting, I tried digging into it myself yesterday and there are two userscripts added to GliderMaven's User:GliderMaven/vector.js. When I tried loading them, the top one, Dr pda's User:Dr_pda/prosesize.js, refused to run and crashed my browser. It is very outdated code and could badly use an update. The second one, tools:~magnus/wysiwtf/wysiwtf.js, is a script by Magnus Manske that is hosted on the all but dead toolserver, will refuse to run on most browsers due to a mixed mode compatibility issue, the importScriptURI() calling it is a part of the deprecated wikibits.js and has been replaced with mediaWiki.loader. I'm sure that these two scripts in their skin.js is also causing them many other issues. Technical 13 (talk) 12:37, 31 January 2014 (UTC)

Any news on this? I get squeeze effects in places like Template:Periodic table, where content page width matters. If the page margins change, there will be some place to get information? The mw:Typography refresh suggestion mentioned by Salix alba did not explain this (unsurprisngly, given that topic). -DePiep (talk) 13:29, 1 February 2014 (UTC)

All I could see there was that the image captioned 2nd iteration - Since January 6th also shows the big blank space. No explanation of why it's there. --Redrose64 (talk) 14:56, 1 February 2014 (UTC)

Indeed, it appears the documentation does not mention this. The best I can refer you to is a previous announcement on this page and bugzilla:59815. – PartTimeGnome (talk | contribs) 16:49, 1 February 2014 (UTC)

PartTimeGnome gave the right links. That page also provides a link to the mw:Talk:Typography_refresh#max-width:_715px for comments. (Content page width was set to maximum of 715px). Indeed part of the mw:Typography refresh Beta that Salix mentioned. I am very unhappy. -DePiep (talk) 18:23, 1 February 2014 (UTC)

There is a fix but it requires adding something to your vector.css (like I have here User:Spudgfsh/vector.css). That will override the maximum width => Spudgfsh (Text Me!) 18:35, 1 February 2014 (UTC)

... or switch off that beta option. -DePiep (talk) 07:40, 2 February 2014 (UTC)

• Just a note, the tracked template reports it as "resolved", for clarification that is "RESOLVED WONTFIX". I'm curious why we can't apply a global fix to some MediaWiki:??.css or MediaWiki:??.js page... Technical 13 (talk) 18:56, 1 February 2014 (UTC)

It appears to have been a deliberate policy decision in the refresh. What I thought would be better if it could be made optional somehow (even if the what they'd decided was the default option).=> Spudgfsh (Text Me!) 19:05, 1 February 2014 (UTC)

See the last post in the bug: "Won'tfix" because it is considered a "feature not a bug" (in a Beta test environment). They let the idea linger on in the Beta. See discussion at mw:Talk:Typography refresh. -DePiep (talk) 07:37, 2 February 2014 (UTC)

Something that squeezes Wikipedia:Featured_pictures/Places/Panorama and two-column WP:DIFFs should probably be called a misfeature. WhatamIdoing (talk) 23:52, 5 February 2014 (UTC)

Extension:DynamicPageList appears to have been rejected before, as it doesn't appear to scale. Would we like to use Extension:DynamicPageListEngine instead? It could be infinitely useful for managing WikiProjects work, such as to show fresh category members. --Gryllida (talk) 07:33, 2 February 2014 (UTC)

Related discussion can likely be found in existing bug reports. --AKlapper (WMF) (talk) 15:40, 3 February 2014 (UTC)

In short, no. Extension:DynamicPageListEngine is much better written than the real DPL extension, however it still doesn't solve the underlying problem of self-joins on the categorylinks table to do category intersections is inefficient. In order to make something that would scale to wikipedia levels, it would have to use a different backend (Such as Solr/lucene search). Bawolff (talk) 01:08, 7 February 2014 (UTC)

The new Flow extension is being deployed to enwiki today. It is being deployed to only two wikiproject pages as a test run to get real users trying out the new interface constructs so they can be tweaked or completely changed based on real world usage until we arrive at a discussion system that can serve the needs of wikipedians.

Because Flow is in such an early stage, with many things uncertain, the API modules it enables are a shim exposing the internals which is sufficient only for the existing ajax calls. These will change without notice, and I encourage you to not yet build out integrations with these APIs.

We have a regular integrated mediawiki API in the works which bots and scripts will be able to integrate with, we expect to have this merged and deployed well before expanding from our initial test runs in the wiki project space. Flow integrates with a number of mediawiki constructs such as recent changes, watchlists, contributions, etc. Feel free to file bugs for anything those integrations might break that previously worked.

EBernhardson (WMF) (talk) 17:44, 3 February 2014 (UTC)

See tests: Use "WT:Flow/Developer test page" not the 2 live wp:WikiProjects. -Wikid77 22:30, 6 February 2014 (UTC)

What are the two pages? How are we supposed to comment on it if you won't tell us where we're meant to be looking? Mogism (talk) 17:50, 3 February 2014 (UTC)

(edit conflict) No mention of just which two wikiproject pages. One, I suspect, is WT:WikiProject Hampshire. --Redrose64 (talk) 17:52, 3 February 2014 (UTC)

The other page is WT:WikiProject Breakfast. I encourage any testing to be done on either mw:Talk:Sandbox or if testing within enwiki is necessary, WT:Flow/Developer test page. Note that the enwiki pages are not enabled yet, they will be in the next four hours. EBernhardson (WMF) (talk) 18:09, 3 February 2014 (UTC)

So does this mean that Flow-enabled pages will basically be non-editable by bots and user scripts until the API is done? Documentation on this is all very sparse and poorly organized. Nor is it very clear where the community should provide feedback. Mr.Z-man 18:35, 3 February 2014 (UTC)

Yes. The initial project pages flow is being released to were chosen in part because they see very little, if any, bot activity. There is no documentation for the API because we do not want anyone developing against the Flow API at this time. The API that has been exposed is not an API in the classic mediawiki sense, it is a shim that exposes the internals of Flow's implementation. It requires knowledge of these internals to construct a proper request currently, and is only intended for use with the AJAX requests used by the web interface.

If you wish to provide feedback on Flow in general i can suggest mw:Talk:Sandbox for testing and mw:Talk:Flow for feedback. The release to enwiki is incredibly limited and targeted, If you are not a member of the two wiki projects we are testing with you wont have a chance to use Flow on enwiki. We kindly ask that users do not disturb the wikiprojects from their normal workflow's by going off-tangent about flow in their project pages. If you are a member of a wiki project that was not chosen and would like to propose the project for being converted to Flow in the future User:Quiddity is our community point person, but I'm not sure we will be expanding from the current group of two pages too soon. We expect to find many things, based on this initial test group, that will need to change before its worthwhile for anyone to build a bot or user script integrating with flow.

EBernhardson (WMF) (talk) 19:42, 3 February 2014 (UTC)

• Looks good. It'll be easier for new editors. Older editors may need to change habit if this is installed in all talk pages. In MediaWiki sandbox I tried it, my text was included in nowiki. Tito☸Dutta 19:52, 3 February 2014 (UTC)

• Hmm! URL is broken above when I tried to link using [full-url text] Tito☸Dutta 19:53, 3 February 2014 (UTC)

Known issue, we have a fix in code review right now that will remove the square brackets from urls. EBernhardson (WMF) (talk) 20:01, 3 February 2014 (UTC)

See also Help:Link#Disallowed characters and percent-encoding. --Redrose64 (talk) 20:11, 3 February 2014 (UTC)

Everything delivered to a user is properly encoded, unfortunatly some web browsers try and be helpful and decode the links for you when copy/paste. EBernhardson (WMF) (talk) 21:13, 3 February 2014 (UTC)

Is there a description somewhere of how the proposed API might work or where bot/script authors can provide feedback on that specifically? I'm just wanting to make sure that this won't be like WikiEditor, where documentation to help us rewrite our tools for it lagged behind deployment. Mr.Z-man 21:48, 3 February 2014 (UTC)

bugzilla:57659 and bugzilla:58361 cover the API and its documentation. Quiddity (WMF) (talk) 01:51, 4 February 2014 (UTC)

How is it supposed to work in the watchlist? Since the old talk pages were moved to the archives, I see 13 entries for Wikipedia talk:WikiProject Hampshire, and 7 for Wikipedia talk:WikiProject Breakfast. The familiar "diff" and "hist" links have mostly gone, to be replaced in some cases by "topic" and "post" (in two cases "history") links. These links ("history" excepted) don't tell you what the actual change was, they just take you to the current version of the page, so I cannot see what the change was. The edit summaries are mostly the non-intuitive "added a comment" - yes, but what was the comment? Some of the entries have no links at all on the left - the edit summary is either "created the board header" or "edited the board header", but again, there is no way of finding out what the exact change was. Only two of those (timed at 21:17 and 21:19) have the familiar "diff" link - and it doesn't work as expected, it just does the same as those "topic" links. Only the "history" links seem to do anything different - but how can a page with 13 edits have only three entries in the history? --Redrose64 (talk) 22:35, 3 February 2014 (UTC)

The entries for RC/watchlists/contribs are being overhauled very soon. You can see the target layout at mingle card 631. This will include a slightly clearer automatic edit-summary. A few people have suggested adding automated excerpts as additional edit-summary context (also per the editsummary guideline's recommendation). (Further feedback on that is welcome, but ideally at WT:Flow where everyone interested is watchlisting. :)

The Board-history and the Topic-history are currently separated (A vs B); iirc, there are plans to merge their display (to prevent this confusion), but I'll have to check how far along that is. If it will be long, I'll see if we can get a note added to the page-history header, asap.

HTH. Quiddity (WMF) (talk) 01:51, 4 February 2014 (UTC)

Why reintroducing old LQT bugs? Helder 13:10, 4 February 2014 (UTC)

on my tablet, (motorola xoom) the watchlist page , although completely functional... has recently been grayed out...it's the only page on wikipedia that behaves this way... i was wondering if this is a known issue, or something I did that i need to fix..Nickmxp (talk) 01:01, 5 February 2014 (UTC)

Might be something to bring up on mw:Mobile/Feedback. --AKlapper (WMF) (talk) 15:32, 5 February 2014 (UTC)

@Nickmxp: Looks OK to me (although I'm not in Europe). What exactly do you mean by "grayed out"? Are you in beta mode? Kaldari (talk) 18:27, 5 February 2014 (UTC)

Note that in the 'modified' sorting, the mobile watchlist does show mostly gray and black text, and it might not be clear what's clickable... but it works on my Galaxy Tab 10.1, which is running some Android 4.0.something. Is your Xoom running 4.0 as well? Can you switch between alpha & mobile sorting? Does tapping on an individual entry show you a diff, or does it do nothing? --brion (talk) 18:55, 5 February 2014 (UTC)

Mines running 4.1.2 I'm using the desktop browsing setting.. I'm pretty sure it's something I did, as it was working fine originally.....Nickmxp (talk) 01:44, 6 February 2014 (UTC)

And oddly if I put the search on templates it apparently shows all my pages, and they are not grayed out... but if I switch back to all.. it goes gray againNickmxp (talk) 01:54, 6 February 2014 (UTC)

and it's not really gray as in color.. it's just the colors are washed out.... the only thing that doesn't gray out is the search box...everything is functional... and if I do selective searches the page looks normal..but the default page ya get when ya touch watchlist is gray. Nickmxp (talk) 03:19, 6 February 2014 (UTC)

Don't know why , but the watch list is back to normal! Nickmxp (talk) 02:25, 8 February 2014 (UTC)

Getting the following message when trying to access "Contributors" on the History page of any article.— Maile (talk) 01:40, 5 February 2014 (UTC)

Bad Gateway

An error occurred while communicating with another application or an upstream server.

There may be more information about this error in the server's error logs.

If you have any queries about this error, please e-mail ts-admins@toolserver.org.

Back to toolserver.org homepage [ Powered by Zeus Web Server ]

Exact steps to reproduce welcome, especially as this sounds like Toolserver territory instead. --AKlapper (WMF) (talk) 15:32, 5 February 2014 (UTC)

Corrected now, and I also believe it was a Toolserver error. But the steps were: Pull up any article. Page/History/Contributors— Maile (talk) 18:05, 5 February 2014 (UTC)

When I edit a section of an article and then "Cancel" I'm taken to the top of the page.

When I edit a section of an article and then "Save" I stay at the section that was edited.

The latter is the more logical behavior in my opinion and it should also be what happens when you "Cancel".

Contact Basemetal here 15:55, 5 February 2014 (UTC)

This is true. But I never use the "Cancel" link; instead I use the "back one page" facility of my browser. Depending upon browser, this may be one or more of: a button at upper left showing a left-pointing arrow; the ← Backspace key; the sequence Alt+Left arrow. --Redrose64 (talk) 19:53, 5 February 2014 (UTC)

Hi,

Is there a simple way to hide the admin tools, or a subset?

The one I most want to hide is delete/undelete of revisions. This adds clutter to the page history and I will hardly use it.

Obviously, if this hiding was relatively easy to toggle on and off that would be good, to allow me to use the tools when they are needed.

Yaris678 (talk) 00:47, 6 February 2014 (UTC)

Do you have those links in page histories? I have them in user contributions but not page histories. They can be removed from contributions and possible from other places with this in Special:MyPage/common.css:

.mw-revdelundel-link {display: none;}

PrimeHunter (talk) 01:17, 6 February 2014 (UTC)

In page histories, I get check boxes for each revision and a grey button marked "del/undel selected revisions". That's what I want to hide. I don't get anything like that in user contributions, but I do get a link to "deleted user contributions". I've added the bit of code to User:Yaris678/common.css but it hasn't hidden any of the above. Yaris678 (talk) 11:35, 6 February 2014 (UTC)

• You can get rid of the button with .historysubmit .mw-history-revisiondelete-button{ display: none; } in User:Yaris678/common.css but you have to use JavaScript/jQuery to get rid of the checkboxes $('input[type="checkbox"][name^="ids"]').css("display", "none"); in your User:Yaris678/common.js should do it. — {{U|Technical 13}} ^{(t • e • c)} 12:40, 6 February 2014 (UTC)

Why do it in javascript? CSS can be used to hide the checkboxes:

input[name^="ids"][type="checkbox"] { display: none; }

This of course assumes that your browser respects the substring matching attribute selectors introduced with CSS 3. --Redrose64 (talk) 14:30, 6 February 2014 (UTC)

Thanks guys. The check boxes are now gone but the button is still there. Yaris678 (talk) 21:58, 6 February 2014 (UTC)

Try .mw-history-revisiondelete-button {display: none;}. My earlier code was for big "(del/undel)" link to the left of the time stamp for each entry on contributions pages. You shouldn't see it after adding my code but I'm surprised if you didn't see it before. PrimeHunter (talk) 22:36, 6 February 2014 (UTC)

Technical 13's suggestion of

.historysubmit .mw-history-revisiondelete-button { display: none; }

should have worked to remove the button. Was there a problem with that? --Redrose64 (talk) 22:54, 6 February 2014 (UTC) No, it wouldn't have worked, because elements with class mw-history-revisiondelete-button are not children of elements with class historysubmit --Redrose64 (talk) 23:01, 6 February 2014 (UTC)

Ah, I've worked out what Technical 13 was trying to do.

.historysubmit.mw-history-revisiondelete-button { display: none; }

works to remove the button: the only significant difference is the absence of a space between the two class selectors. --Redrose64 (talk) 09:05, 7 February 2014 (UTC)

Thanks guys. It's all working now in the normal interface.

It doesn't seem to be working in the mobile interface. Specifically, I get del/undel links on my contribs in mobile mode. I've used tools to check and the links are in the same class in mobile mode.

Does custom css not work in mobile mode?

Yaris678 (talk) 10:09, 7 February 2014 (UTC)

Wikipedia:Village pump (technical)/Archive 111#Applying custom user common.css to mobile site (m.wikipedia.org) from May 2013 says custom css in mobile mode is not possible. I think this is still the case. There is a request at bugzilla:46247 PrimeHunter (talk) 12:06, 7 February 2014 (UTC)

OK. I guess I'll just have to put up with the clutter in mobile mode. At least the normal interface is clutter free.

Thank you everyone!

Yaris678 (talk) 12:17, 7 February 2014 (UTC)

When trying to view User contributions for new accounts with 500 edits per page, this keeps leading to a database error on both Firefox 27.0 and Chrome 32.0. The exact text given is "A database query error has occurred. This may indicate a bug in the software. Function: IndexPager::buildQueryInfo (contributions page unfiltered) Error: 0".

Is this a known bug, or should I report it at bugzilla.wikimedia.org? I have done a quick search at bugzilla and did not find anything, but it may well have been filed in a way I didn't think to search for. AddWittyNameHere (talk) 10:19, 6 February 2014 (UTC)

It's been happening for weeks, see e.g. Wikipedia:Village pump (technical)/Archive 122#Database error in filtered new users' contributions search. Don't file a new bugzilla, but feel free to add to the existing one with any additional relevant details. --Redrose64 (talk) 10:43, 6 February 2014 (UTC)

Hi, is there a single API query for a given wikipedia wiki that will list the available protection levels for that wiki? (levels e.g. sysop, autoconfirmed) I ask because I'm told that different language wikipedias can have custom protection levels different to en-wp. Already know that I can check the protection level of a given page, this is not what I need. Checked mediawiki API documentation, could not see how. Thanks Rjwilmsi 12:47, 6 February 2014 (UTC)

@Rjwilmsi: It would appear there isn't one, or at least I can't find any – it should probably be added. In the meantime you can see the settings for all wikis at https://noc.wikimedia.org/conf/highlight.php?file=InitialiseSettings.php, under the key of wgRestrictionLevels (reproduced below for posterity, as the settings might change). Matma Rex talk 15:06, 6 February 2014 (UTC)

'wgRestrictionLevels' => array(
	'default' => array( '', 'autoconfirmed', 'sysop' ), // semi-protection level on
	'arwiki' => array( '', 'autoconfirmed', 'autoreview', 'sysop' ), // bug 52109
	'ckbwiki' => array( '', 'autoconfirmed', 'autopatrol', 'sysop' ), // bug 52533
	'enwiki' => array( '', 'autoconfirmed', 'templateeditor', 'sysop' ), // bug 55432
	'hewiki' => array( '', 'autoconfirmed', 'autopatrol', 'sysop'), //bug 58207
	'plwiki' => array( '', 'autoconfirmed', 'editor', 'sysop' ), // bug 46990
	'ptwiki' => array( '', 'autoconfirmed', 'autoreviewer', 'sysop' ), // bug 39652
	'testwiki' => array( '', 'autoconfirmed', 'templateeditor', 'sysop' ), // bug 59084
),

I have submitted a patch for review to add this to the API, as action=query&meta=siteinfo&prop=restrictions: [24]. Comments welcome. Matma Rex talk 15:36, 6 February 2014 (UTC)

And it's merged already, thanks Anomie! You should see this feature live here on 20 February 2014, per the schedule: mw:MediaWiki 1.23/Roadmap. Matma Rex talk 16:00, 6 February 2014 (UTC)

[25] has just given me "PHP fatal error in /usr/local/apache/common-local/php-1.23wmf12/extensions/Math/Math.hooks.php line 50: Call to undefined method ParserOptions::getMath() ". Repeatably, four times, in between loading other pages OK. Looks like somebody broke something... Wnt (talk) 22:15, 6 February 2014 (UTC)

Just started working now though, before I even had a chance to go look... Wnt (talk) 22:17, 6 February 2014 (UTC)

This is happening all over the place, including articles like Earth. It's due to the Math extension. Steven Walling (WMF) • talk 22:18, 6 February 2014 (UTC)

Hmmm, it looks like this was fixed on January 2 in a branch that I thought was live... but I guess I'm still a little hazy about which version really is live. Wnt (talk) 22:40, 6 February 2014 (UTC)

This problem was also mentioned below. Graham87 04:23, 7 February 2014 (UTC)

That's not the same problem. I was getting the PHP error with the Blue Page Of Death "Wikipedia has a problem", not just a red message where the formula is supposed to be. Wnt (talk) 05:36, 7 February 2014 (UTC)

Latest Math version seems to have a few problems, see the list under "Depends on:" on bugzilla:60997. The "Wikipedia has a problem" was logged under bugzilla:60970. --AKlapper (WMF) (talk) 11:40, 7 February 2014 (UTC)

Ah, I see that the latter thread has a comment on 2-6 that "everything has been reverted back to wmf11". That explains why line 50 appeared again. Perhaps I saw the error during mid-revert, because whatever it referenced hadn't been reverted yet. Wnt (talk) 17:19, 7 February 2014 (UTC)

Sorry about this folks. There was some incompatibilities between the Math extension and MediaWiki core and I deployed broken Math code yesterday in the process of trying to fix some downtime we were dealing with. Things should all be back to normal now, again sorry! ^demon^{[omg plz]} 17:25, 7 February 2014 (UTC)

Thanks! In possibly-related news, do you know anything about the "Math aligned environments failing to parse" issue below? Melchoir (talk) 19:01, 7 February 2014 (UTC)

Hey all, this is announced as part of the normal Tech News newsletter (see Tech News: 2014-06 above), but I wanted to give folks an extra notice that some important forms will have a change of button color and style. This includes login, account creation, search, and some other forms. We did this as part of UI standardization work across teams, so that for instance, we can move closer to a place where all buttons (at least in Vector, at first) will look the same across forms, Flow, guided tours, mobile, etc. Steven Walling (WMF) • talk 22:17, 6 February 2014 (UTC)

Can someone tell me why The Lego Movie is showing "Failed to retrieve Rotten Tomatoes information. Please contact Theopolisme." on the Critical Reception header? Theopolisme is very inactive, so I don't think I'd get a response from him for months, so I think it'd be better to ask here. Ten Pound Hammer • ^{(What did I screw up now?)} 23:38, 6 February 2014 (UTC)

Theopolisme has discussed the template only four days ago so it seems odd to give up contacting him and posting here without notifying or pinging him. The message is caused by an edit [26] by User:Technical 13 to the template. A bot operated by Theopolisme is supposed to create a data page for a movie after the template has been added to an article. If the bot hasn't done this within an hour of the latest edit to the article then Technical 13's edit displays the error message you saw in the article. I don't think articles should tell the reader to go to a named editor's talk page. The template has been removed from the article so the message isn't displayed currently. The message is never displayed in preview because {{REVISIONTIMESTAMP}} returns the current time in preview, but if the data page is not created at Rotten Tomatoes score/1490017 Template:Rotten Tomatoes score/1490017 then the message can be seen in old revisions of the article such as [27]. PrimeHunter (talk) 01:56, 7 February 2014 (UTC)

• I've forced a current result as a placeholder for this movie until Theo can figure out why the movie hasn't been found on the API. There are apparently a few little glitches to work out in the template and I monitor both the template's talk page and Theo's for anyone that asks a question about the template or bot. (I'm also watching here at VPT). I can change the error message to say to leave a message on the template's talk page, if other's think that would be more appropriate. I just used the wording that the bot uses if the movie isn't in the api by the IMDb number. Anyways, I'm going back to bed. I'll be looking for responses here in the morning. :) Happy editing. — {{U|Technical 13}} ^{(t • e • c)} 03:47, 7 February 2014 (UTC)

Yeah, I'm hardly "very inactive" -- although I may not be editing frequently, I check in pretty much daily. :) It looks like Wikimedia Labs which the bot runs on was having some trouble, so I just manually prodded it and Template:Rotten Tomatoes score/1490017 now exists. No problems with the bot or the API AFAICS, just the infrastructure it runs on, which is out of my control. Theopolisme (talk) 02:49, 8 February 2014 (UTC)

There are currently two logs activated by activities related to newpage patrols: curation and patrol. This can make reviewing these logs difficult - for example, when I tagged an article yesterday and inadvertently marked it as reviewed, the review and unreview were marked on different logs: [28], [29].

Is there any reason the functionality of these two logs cannot be merged? VQuakr (talk) 00:30, 7 February 2014 (UTC)

It would, to my knowledge, create a lot of duplication; patrolling something in the page curation interface also patrols it from a Special:NewPages point of view (and vice versa), but they're different actions, and so one patrol appears in both logs. I also don't know if we have any energy on the engineering side for this at the moment: people are working on quite a few things. Ironholds (talk) 17:33, 7 February 2014 (UTC)

Thanks for the reply. It seems to me that Special:NewPages and Curation could (and should) be different interfaces to the same back-end database, and it should be the back end that generates the log entries. If there is no bandwidth available to streamline this right now, maybe it can go in a "solve someday" queue? VQuakr (talk) 18:06, 7 February 2014 (UTC)

Resolved

 – Redrose64 (talk) 07:31, 7 February 2014 (UTC)

Portal:Current events is currently showing "February -7, 2014 (Error: Invalid time.)" I'm guessing the "invalid time" is related to the (invalid) date of "February -7" but I don't know now to fix it. Can someone knowledgeable please fix it? Thanks. DH85868993 (talk) 06:50, 7 February 2014 (UTC)

This edit fixed it at source; I did a WP:PURGE of all transcluding pages so that it displays correctly. --Redrose64 (talk) 07:31, 7 February 2014 (UTC)

Thanks. DH85868993 (talk) 08:41, 7 February 2014 (UTC)

Hi. I'd like to do the following.

Add this block of code to MediaWiki:Common.css:

.display-for-user {
	display: none;
}

Add this block of code to MediaWiki:Group-user.css

.display-for-user {
	display: inline;
}

Then create a wrapper template similar to testwiki:Template:Hide from anons. This will have the effect of allowing us to show content only to logged-in users. Thoughts? --MZMcBride (talk) 07:02, 31 January 2014 (UTC)

@MZMcBride: What is the use case for this? Wikipedia is not really set up to have truly private information that isn't visible to readers. Yes, we can noindex things and remove them from default search settings, but the wiki is public to all readers for good reason. I'm not sure we want people creating content that should be absolutely hidden from unregistered users... Steven Walling (WMF) • talk 17:40, 31 January 2014 (UTC)

S: Yes, I'm deeply familiar with how both Wikipedia and CSS operate. This isn't intended to be used with trade secrets or personally identifiable information. :-)

One suggested use-case was hiding the scary-looking links at the bottom of MediaWiki:Anontalkpagetext as they're off-putting and probably only intended for logged-in users.

I think having a generalized, trackable way of hiding information based on logged-in status would be useful. You make a good point that we would need to clearly document that the information is only hidden and not deleted, however. --MZMcBride (talk) 18:57, 31 January 2014 (UTC)

If that content is in a MediaWiki message, why don't we hide that content by stripping out the IP inspection tools in to a separate message and hide that conditionally within MediaWiki proper? Similar tools are available on some wikis (en, es, fr) but not others. It might be appropriate to provide some default IP inspection tools, which people could customize. If the use case was merely in templates which are entirely specific to English Wikipedia, I'd support adding these classes. But hiding content from logged out users is the kind of thing that we usually do within core or an extension. Steven Walling (WMF) • talk 20:35, 31 January 2014 (UTC)

S: I don't think modifying MediaWiki core is needed here, but feel free to file tickets in Bugzilla as you see fit. As I understand it, MediaWiki hasn't had the ability to customize the user experience based purely on logged-in status (using CSS) until very recently. (Previously JavaScript could be used.) This is partially why traditionally MediaWiki extensions or modifications to MediaWiki core have been used instead. By using CSS, the content is still transferred to the client, but parser cache fragmentation is reduced and there's no JavaScript dependency. This seems like a reasonable trade-off to me. --MZMcBride (talk) 21:40, 31 January 2014 (UTC)

"By using CSS, the content is still transferred to the client, but parser cache fragmentation is reduced and there's no JavaScript dependency. This seems like a reasonable trade-off to me." Agreed, that's entirely reasonable. I guess I'm just a little worried about people abusing this whenever they want to hide content. Steven Walling (WMF) • talk 22:08, 31 January 2014 (UTC)

You're thinking about a censorship problem, like someone using it to hide "bad words" in articles, without any indication of their removal or anyway for the reader to override it? I don't mind people being able to hide disturbing material from themselves, but I do object to it being done to them with no notice and no way to override it.

In practice, though, I think we could easily have a policy against that, although a small number of abuses in low-traffic articles might get overlooked. It might also be possible to design it so that it did not work in the mainspace. WhatamIdoing (talk) 00:47, 1 February 2014 (UTC)

WhatamIdoing, Steven: The use of a wrapper template allows us to track (mis|ab)use. We can also add in namespace restrictions at the CSS level or the template level, as necessary and appropriate. I'd personally prefer to take a "wait and see" approach.

Broadly, the idea here is less prone to abuse than its opposite, I think. That is, if content could be hidden from only logged-in users, it might allow vandalism and other bad content to be exposed to anonymous users for a longer period of time. However, in the proposed scenario, the abuse vector seems much smaller. --MZMcBride (talk) 23:36, 3 February 2014 (UTC)

But if it exists, there's no way to prevent someone from calling it directly or substing the template, and thus not being able to track it (in our ample free time), right?

I don't actually feel that strongly about it. If it became a nightmare, it could (in theory) be removed. But I am a little nervous about it. WhatamIdoing (talk) 00:05, 4 February 2014 (UTC)

I don't like this idea at all. To hide any text from anons seems like a bad precedent, and to hide that text seems out and out dishonest. There's something incredibly creepy about the notion of not merely tracking the anons by IP address and using it to look up all this stuff about them, but not letting them know you're doing it. Secrecy, in-groups ... it's the beginning of a long, long road that ends somewhere around NSA headquarters. Let's not take that trip. Wnt (talk) 02:01, 9 February 2014 (UTC)

I feel similarly to User:Wnt. I wouldn't really mind hiding admin-only links, like delete, from us normal users, but I can't really think of anything to hide from IPs, unless, perhaps, there are some links causing them confusion... —PC-XT+ 04:15, 9 February 2014 (UTC)

PC-XT and Wnt: We already differentiate between logged-in and non-logged in users in various parts of the user interface (e.g. "view source" instead of "edit" or CentralNotice banners that only display to logged-in users). These CSS tweaks would just allow us to make a distinction at a more fine-grained level. Whether MediaWiki:Anontalkpagetext should be friendlier is an orthogonal point, I think. I think there are additional use-cases for implementing this capability. --MZMcBride (talk) 04:20, 9 February 2014 (UTC)

Showing "view source" instead of "edit" provides information specific to the class of user, not just IPs. (Most of us see "view source" on pages protected at a certain level or higher.) I don't mind that kind of differentiation. I also don't mind the CentralNotice banners, as far as I am aware. I'm not sure if the finer grain is needed, but if so, I would prefer that it differentiate between all classes, if that is possible, rather than only those logged in/out. Some text is only really useful to admins, like I said above, and other users don't really need to see it. Showing some of these things openly does seem to be a part of the Wikipedia scene, but a few areas feel a bit crowded with stuff I don't need, even though I am logged in. I wouldn't object, but possibly support, if the stuff to be hidden is useless to IPs and does not have anything to do with them. This is just my opinion. I'd like to hear what some IPs think... —PC-XT+ 04:49, 9 February 2014 (UTC)

Ideally articles are not generally protected, and "view source" is meant to be as close to "edit" as it can be without confusing the person into thinking he can edit. Admittedly there are other options which admins see differently from other users, but that really isn't desirable either. I mean sure, I suppose that showing every editor grayed-out block and delete buttons would use too much bandwidth resource to be financially justifiable, but given our choice we ought. The ideal should be that everything is out in the open. Wnt (talk) 06:28, 9 February 2014 (UTC)

Note: We already have admin-only text, using the sysop-show class. For example: You (the person reading this) are an administrator, though others reading this are not an administrator. View the source to see what I did there. – PartTimeGnome (talk | contribs) 21:46, 9 February 2014 (UTC)

Here are some other examples where we could differentiate between logged-in and logged-out users:

• Anywhere we invite a user to create a page, this does not make sense for IP addresses because they cannot do so. We should instead invite them to request the page's creation (e.g. via AfC). MediaWiki already does this on the search results page (MediaWiki:searchmenu-new vs. MediaWiki:searchmenu-new-nocreate).
• Any help pages that instruct someone to change their preferences or edit a page in their user space could include an extra instruction to register or log in first for IP address users.

However, both of the above require that we not only be able to hide information from IP address users, but have alternative messages for them that don't show to registered users. Unless some mechanism existed to tightly control who could write such hidden messages, this would present a high vandalism risk since vandalism could be hidden from registered editors. – PartTimeGnome (talk | contribs) 21:46, 9 February 2014 (UTC)

I agree that, ideally, there should be a way to see all of the text. Due to IPs not really having preferences for such things, it could be a touchy issue. (There could be a button in some corner of every page to display all hidden text, for that matter. [Some way of selecting the page view at a certain level may be better.] If I wanted to do that, I could make a userscript, but that wouldn't help IPs. It should be available by default, and preferences could turn it off.) User:PartTimeGnome gave the information I wanted from a balanced view. If this included a way for anyone to see all of the forms the page could take by tweaking some control on the page, (which in turn could be removed by a gadget or something, if desired,) I would support this. —PC-XT+ 02:10, 10 February 2014 (UTC)

There's some interest in a script that will draw a little red box (as User:Ucucha/duplinks.js does) around words and phrases of interest that come from a regex list. I know the regex bit, but I don't know how to adapt Ucucha's script. Any help? - Dank (push to talk) 18:47, 2 February 2014 (UTC)

• Dank, I'd love to try and help you, but I'm afraid I'm going to need some more information.

1. Do you want this script to run automagically or only if you click a link?

   Clicking a link in the left-hand column, as duplinks does. - Dank (push to talk)

2. Which namespaces do you want it to run in? Surely there is no need for it in Talkspaces?

   Articlespace and userspace (for testing)

3. Where is your ReGex list? If it's not already on a page, could you put it on User:Dank/Highlighter/list for me please?

   Done. Comma-space-delimited, because I want to optimize it for readability by, you know, humans, but I can massage it if you like.

I think knowing these things, we can start to write you a script to highlight stuffs.  :) — {{U|Technical 13}} ^{(t • e • c)} 19:52, 2 February 2014 (UTC)

All done, thanks much. - Dank (push to talk) 20:43, 2 February 2014 (UTC)

• Great! I'll work on this over the next couple days and leave a message on your talk page when it is done. (Library is closing for the day or I'd work on it tonight, should be able to do in less than a day...) :) — {{U|Technical 13}} ^{(t • e • c)} 21:57, 2 February 2014 (UTC)

Note: it's regex, or regexp. Not "ReGex". — Scott • talk 22:39, 2 February 2014 (UTC)

OK, I just spent half an hour putting together Module:Highlight. See Module talk:Highlight/highlight for a usage example. You can omit the page name if you start (or just preview) a page with the name of the page you want to mark up + "/highlight". No Javascript needed :) Is this good for you? Wnt (talk) 02:37, 9 February 2014 (UTC)

Just saw this, thanks so much, I'll have a look in the morning. I'm looking for one more thing ... if you're interested, see User_talk:Technical_13#One small tweak. The regex list might be long, on the order of the typo list at WP:RETF. - Dank (push to talk) 05:25, 9 February 2014 (UTC)

well, I'm thinking I could set up a parameter to let you choose a file of regexes to use, rather than submitting a regex directly, and those files could be individualized. I suppose adding an option of doing a find and replace with that file, then highlighting the replacements rather than the finds, is also feasible. And, of course, the module could output wiki source rather than processed text, so you could copy and paste it. But not tonight... Wnt (talk) 07:00, 9 February 2014 (UTC)

I should, however, note that Lua has some limitations that may make it unsuitable to replace the Javascript functions like AWB for comprehensive lists. First and foremost, it has limited execution time, and we'll have to see how many regexes * text it can do at once. Then there's the problem that the Javascript regex list from WP:RETF isn't going to work directly in Lua - there are deficiencies in alternation (|) and counts ({1, 3}). It would be possible to build a tool to autotranslate nearly all of the list, I think, but I'm already amid one autotranslate idea that I keep dragging out... And last but not least, there's the annoying inability of Wikitext (which Lua/Scribunto outputs) to access the mouseover property via inline CSS. There ought to be some way to set up custom .css/.js that gives Wikitext some access to mouseover capability without burdening normal page display, but it'll take some thought, and unless merged into the common. files, it wouldn't be usable by everyone. Wnt (talk) 15:01, 9 February 2014 (UTC)

i cannot see how a lua module makes sense here. i think the idea is to allow individual readers to highlight what they choose, no? as far as i understand, lua module is something the *editor* can use to highlight what she wants, but she does not really need a module for that, does she? she can control the appearance of the page directly.

regarding the JS thing: i hope you guys are aware of the fact that mw contains the "textHighlight" plugin, which makes it pretty easy (though i'm not sure it supports full regex - i did not fiddle with it much).

e.g.: this section contains the words "interest", "automagically" and "lua". to highlight those words on the page, hit F12, and type into the console:

mw.util.$content.highlightText('interest automagically lua');

and see the magic.

if nothing happens, you may need to run this line first:

mw.loader.load('jquery.highlightText');

but i do not think it's really needed - it works for me without loading the plugin explicitly. maybe one of the gadgets i'm using loads this plugin, but i tend to think that it loads for everyone on enwiki. you can control the actual appearance of the highlighted text. the default is plenty good enough for me. peace - קיפודנחש (aka kipod) (talk) 16:42, 9 February 2014 (UTC)

• I am using FireFox 27 kipod and even

mw.loader.load('jquery.highlightText');
mw.util.$content.highlightText('interest automagically lua');

does nothing for me (I go to the console directly with CTRL+⇧ Shift+K). I just need to have a half an hour to toy with it, and I should be able to have it quickly highlight any match (I'll need to reformat the list page a little to make it work with the extras added like popups). It won't be right now as I am too busy, but soon. — {{U|Technical 13}} ^{(t • e • c)} 16:55, 9 February 2014 (UTC)

Since that functionality is already in Mediawiki, it's possible it will run faster and less buggily that hand-coded stuff, so I'm very interested. When I paste mw.loader.load('jquery.highlightText'); into the console, it returns "undefined". mw.util.$content.highlightText('interest automagically lua'); does make those 3 words bold ... that is visible enough for me, though others may want something more visible. You're right that the general goal is to allow users to highlight any words they want. Specifically, I want to make it easier for users to catch common mistakes. They probably won't need to know that "tyop" is a typo, but if I highlight "except" because it appears they actually meant "accept", and they don't get the difference, I want to make it easier for them to find out why the word "except" was highlighted ... a link to a section of a page that explains the difference would be nice, or maybe a script could generate a page with explanations for all of the words that were highlighted on their target page. Any idea how to do that? (And btw, does Kipod mean "hedgehog"?) - Dank (push to talk) 17:08, 9 February 2014 (UTC)

Dank: if you inspect the highlighted element, you'll notice that calling "highlightText" bracketed it in a span with class "highlight". you can then access those elements through $('.highlight'), to add more stuff (e.g. a tooltip. either by directly setting the "title" attribute or through the "tipsy" plugin. something like:

mw.loader.using(['jquery.highlightText', 'jquery.tipsy'], function() {
    mw.util.$content.highlightText('interest automagically lua');
    $('.highlight').tipsy({
        title: function() { 
            return 'the word ' + $(this).text() + ' is highlighted';
        }
    });
});

as to your "btw" question, the answer is yes. peace - קיפודנחש (aka kipod) (talk) 17:57, 9 February 2014 (UTC)

That does just what I want, except it has a bug: after I loaded it into my monobook.js, it deleted the word "interest" everywhere it appeared every time I saved an edit! Btw ... how do I get it to search for a two-word phrase? - Dank (push to talk) 20:28, 9 February 2014 (UTC)

@Dank: you probably want to gate the whole thing to reading a page, e.g., by preceding the "using" statement with something like

if (mw.config.get( 'wgAction' ) === 'view')

or somesuch, so it won't interfere with editing... peace - קיפודנחש (aka kipod) (talk) 21:56, 9 February 2014 (UTC)

@קיפודנחש: That worked. But I've tried everything I can think of, and can't get it to match any two-word phrase. (\ , \\ , \s, "two words", etc. aren't working for the space) - Dank (push to talk) 22:49, 9 February 2014 (UTC)

@Dank: i do not think patterns with spaces are possible with the highlightText plugin. as far as i could see, this plugin is home-grown (i.e., developed as part of mediawiki, rather than brought in from some known plugin), and the changes required to make it understand patterns with spaces and regexes is minimal, so you can ask for this on bugzilla if you have a good use-case. peace - קיפודנחש (aka kipod) (talk) 05:20, 10 February 2014 (UTC)

@קיפודנחש: That module is currently used by the search suggestions code, to do the bolding in suggestions lists, so it should be loaded for everyone – but, as always, this might change in the future – there are some plans to either load the module only after the user starts typing instead of on page load to increase page load performance, or even axe this feature client-side entirely and do the highlighting server-side, as the new CirrusSearch is smarter and can do this better. If you need some module, always do mw.loader.using(['jquery.highlightText'], function(){ /* code to run after the module is loaded */ }). Matma Rex talk 17:30, 9 February 2014 (UTC)

To be clear, I had (and still have) little idea of what this regex highlighter would be used for; when I made the module I was picturing ongoing collaborative tasks, such as highlighting sections at the Science Refdesk that only contain one signature, i.e. no answers. (though it's not really pretty for that purpose as of yet, not sure how to make it neatly circle a paragraph) Wnt (talk) 20:35, 9 February 2014 (UTC)

In a script, I need to check if titles have articles. That is, I need to determine for each link in an article whether that link is a redlink or not.

How can this be done? The Transhumanist 16:51, 4 February 2014 (UTC)

I don't know if scripts support parser functions, but if they do, the #ifexist parser function could help. SiBr₄ (talk) 18:09, 4 February 2014 (UTC)

Can't you just see whether the link has class "new"? Jackmcbarn (talk) 18:19, 4 February 2014 (UTC)

Moved from User talk:Jackmcbarn

 – Jackmcbarn (talk) 04:08, 9 February 2014 (UTC)

Where would I look for that in order to see it? The Transhumanist 03:54, 9 February 2014 (UTC)

See T13's reply below. Jackmcbarn (talk) 04:08, 9 February 2014 (UTC)

See mw:API:Query#Missing and invalid titles. Helder 18:47, 4 February 2014 (UTC)

Thank you. This looks promising. The Transhumanist 03:06, 9 February 2014 (UTC)

Okay, I looked it over and tried some calls. Making such a call for every link on a page, when there are hundreds of links and then scraping the results pages of each, would be rather cumbersome. I think it would be simpler and faster to get the whole page in some format with redlink=1 codes on it and search for all instances of links followed by that code. Thoughts? The Transhumanist 05:40, 9 February 2014 (UTC)

• Doesn't work that way... Your code might look something like:

$('a').each(function(){
    if($(this).hasClass('new') === true || $(this).is("[href$='&redlink=1']") === true ){
        $(this).css("border", "1px solid #F00");
    }
});

This should put a red border around RedLinks but not Blue ones (try it in your console ;)). — {{U|Technical 13}} ^{(t • e • c)} 06:30, 9 February 2014 (UTC)

You don't have to make a separate API call for every link to check. You can supply up to 50 titles per request, separated by %7C. You don't need to "scrape" API results, since they are designed to be machine-readable. E.g. the JSON format (format=json) is natively readable by JavaScript. Other formats are available depending on your needs. Though as others have said, if you only need to check links on the current page, you are better scraping the current page since that doesn't involve any extra server requests. – PartTimeGnome (talk | contribs) 22:02, 9 February 2014 (UTC)

• If there are links to the pages in question on the page that you want to check from, I usually either look for typeof($(this, '.new')) === 'undefined' like Jack suggested. I've noticed there are some odd instances where they are redlinks and they are not using .new, in those cases I look for typeof($(this, "[href$='&redlink=1']")) === 'undefined'. If you are checking pages not linked to from the current page, you'll have to use the API (which of course is much slower). Happy editing and good luck! — {{U|Technical 13}} ^{(t • e • c)} 03:49, 9 February 2014 (UTC)

• Do you mean scrape the html source? I don't see any typeof($(this, '.new')) or typeof($(this, "[href$='&redlink=1']")) strings in there. Instead, there's something like this:

<li><a href="/w/index.php?title=Geology_of_Afghanistan&action=edit&redlink=1" class="new" title="Geology of Afghanistan (page does not exist)">Geology of Afghanistan</a></li>

I look forward to your reply. The Transhumanist 04:13, 9 February 2014 (UTC)

• See:

• https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/typeof
• http://api.jquery.com/each/
• http://api.jquery.com/multiple-selector/
• https://learn.jquery.com/javascript-101/this-keyword/
• http://api.jquery.com/class-selector/
• http://api.jquery.com/attribute-ends-with-selector/

Somewhat of a crash course there on JavaScript and jQuery, but I think that is all you need to know for this question. The crash course for accessing the information through the API is somewhat more complex (which is part of the reason it is slower). Let me know if you have any further questions. — {{U|Technical 13}} ^{(t • e • c)} 04:51, 9 February 2014 (UTC)

See the orthogonal teahouse thread here.[30] See the now-closed tangentially-related AN/I thread here.[31]

   Question: Is there a way to see the history of a category's contents, i.e. what articles were in the category a year ago, for instance? Can we find the removal-events, and the insertion-events, and who was responsible for each? I realize that one can visit Chuck Norris (may he live ten thousand years) and see that the master is currently in Category:American martial artists.

  But consider the horrific possibility, that some internet heretic might one day dare create Category:people tougher than Chuck Norris. This person will be known, from the edit-history of the category itself. But what if others have added names like Bruce Lee to this blasphemous category? Obviously, those edits will quickly be reverted. If there *is* ever Category:people tougher than Chuck Norris, it will be an empty set, if friends of Chuck Norris have anything to say about it.

  But what of the Bruce Lee heretics? They may escape punishment, if we cannot get a list of exactly when an article was added to a category, by whom. Additionally, we should reward the defenders of the honour of Chuck Norris! Therefore we need to know exactly when an article was removed from a category, and by whom. See insertion-example below. Along the same lines, ColinFine mentioned that it would also be nice to be able to get the links to the articles, which are being inserted to a category, at the time of insertion. Same applies for a link to the version of the article that was removed from a category, at the time of removal. So for example:

"Chuck Norris was inserted[32] into Category:American practitioners of Brazilian jiu-jitsu by Jackmcbarn as of 22:57, 27 August 2013."

  Note that the diff shows what the Chuck Norris article looked like when he was inserted. Is there a Special:category-content-history-page, which shows a bunch of rows like this, for a given category? (As opposed to, for a given article.) Plus possibly, optionally, all the subcategories thereof? (Chuck Norris may never have been inserted into the toplevel Category:Martial Arts but he belongs in any insertion-and-removal-history of that category methinks.)

  Is there a way, currently, to accomplish this sort of functionality? With some series of API calls perhaps, or some view-changes-to-category-page that I do not realize already exists? If not, can this feature be implemented? It is commonly problematic with musical genres as applied/unapplied to BLPs, and also with political categories (politician BLPs and also nation-labelling). I thank you for your input on this important matter, and for improving wikipedia.  :-)

  p.s. And, in case they may still care about category-histories, ping the good editors PrimeHunter, Lightbreather, Mike_Searson, Gaijin42, Drmies, and Lukeno94. Methinks that Liz may also have an interest in this categorization question. — 74.192.84.101 (talk) 22:39, 6 February 2014 (UTC)

• As far as I am aware, no, there isn't. It isn't unfeasible to write a script to go and hunt for the historical additions and removals of a given category, but it would be an incredibly slow script, I would guess, and even more so if it began going through deleted edits. Lukeno94 (tell Luke off here) 22:46, 6 February 2014 (UTC)

• It sounds like you are looking for a technical solution, 74.192.84.101, and I can't help you there. In one of your questions, the only way I know of to see past contents of a category is if one or a few editors in particular are working, organizing it, and you look in their contributions to see what articles they have added or removed categories from. This can be a guessing game but often editors focus in specific area so, for example, you might know who would create and populate that Category:American martial artists.

Otherwise, as far as I know, the only other record of category additions or subtractions is on each article's page history. The assignment of an article to a category is not noted on the category's page history although, I agree, that would be useful information to have. Liz ^{Read! Talk!} 22:54, 6 February 2014 (UTC)

• We have bugzilla:4366 opened about this. Jackmcbarn (talk) 23:40, 6 February 2014 (UTC)

• Thanks much Jack. 74.192.84.101 (talk) 00:11, 7 February 2014 (UTC)

From the bugzilla entry, which was first opened in 2005 (re-opened 2006 / 2007 / 2012 and now 2014 also)...

That kind of information is not stored in the database, and is not likely to be added. The membership set changes based on edits to other pages, not edits to the category, and has no independent history of its own. —Brion VIBBER, 2005-12-24 00:17:49 UTC ...What I suggest is that every category has a log attached to it. It would only require Number_of_category additional pages to the database (my guess is that it is just a fraction of the overall size, isn't it?) When an edit is made to an article that add category C1 and removes categories C2 C3, Mediawiki would log this information in the logfile of the categories C1, C2, and C3. ... —Jmfayard 2006-04-11 09:19:54 UTC

There is already a logfile for e.g. abuseFilter actions,[33] which are regex-based detectors as I understand it. Can an edit-filter be written, which detects the insertion of a category (not sure that can be done for the deletion of a category thataway) which triggers an entry into the CategoryEventLog? Or, does somebody have a better way to build such a thing? 74.192.84.101 (talk) 00:11, 7 February 2014 (UTC)

Not all pages are placed in categories by adding e.g. [[Category:Foo]] to the page. A lot of templates will categorise a page; the two main groups that spring to mind are maintenance templates and stub templates. For example, {{fact|date=February 2014}} will place the page into both Category:All articles with unsourced statements and Category:Articles with unsourced statements from February 2014; {{Laos-footy-bio-stub}} will place the page into Category:Southeast Asian football biography stubs, Category:Laotian people stubs and Category:Laotian sport stubs. An edit filter would also need to detect such usage. Categorisation by template get pretty subtle; for example, Category:Articles with incorrect citation syntax has a number of subcategories, the membership of which is triggered by certain combinations of circumstances when the Citation Style 1 templates are used. A change to any of these templates can cause articles to move in or out of categories without the article itself needing to be touched; even a simple thing like the calendar ticking to the next day can cause category membership to change, see for example the membership of Category:Expired proposed deletions. --Redrose64 (talk) 07:59, 7 February 2014 (UTC)

So, you are saying that edit-filters cannot see the parsed content of a final page? In which case, we would need a mediawiki extension, right? See also the CategoryWatch thing, below. 74.192.84.101 (talk) 16:18, 7 February 2014 (UTC)

What I'm saying is that edit filters check the wikitext of the page being edited. If an edit to an article adds a template, the edit filter does not expand that template to see what's inside it. If an edit to a template changes the categorisation of those articles which transclude that template, there is no way for an edit filter to spot that change in article categorisation. --Redrose64 (talk) 16:40, 7 February 2014 (UTC)

So, for a non-kludge solution, the edit-filter isn't sufficient. (We could use an edit-filter to catch a large chunk of cases i.e. the ones that were simply "Category:$cat" wiki-text changes... and that might be valuable... but it would be a kludge.) To do better, we either need an extension that uses PageContentSaveComplete hook (3/4ths answer), or we need a tool that polls periodically (2/4ths answer). But to get the full 4/4ths solution, we'd need some kind of DB-level upgrade, to start tracking category-insertion-and-removal-events in a new log-table, it seems. How does the Category:People generate a list of pages-currently-in-this-category, on the fly? What SQL does it use, specifically, if somebody can link to the codebase? 74.192.84.101 (talk) 17:01, 7 February 2014 (UTC)

The code that performs the database query is in CategoryViewer::doCategoryQuery(). It is a join over the categorylinks, category and page tables. The categorylinks table is the one that lists current category members. It is normally updated whenever an article is edited.

If categories are added or removed by editing a transcluded template, categorylinks is not immediately updated. Instead, a job is added to the job queue for later processing. It typically takes a day or two for categorylinks to update after a template edit, though it has been known to take weeks. Editors can force the category membership for a single article to be immediately updated by editing the article (including null edits). Bots can also use the purge API's forcelinkupdate parameter for the same effect.

Where a template changes the categories it adds based on the date, MediaWiki does not update the categorylinks table. We instead have Joe's Null Bot, which makes null edits to pages in time-sensitive categories at appropriate times, forcing the table to update.

It probably wouldn't be difficult to keep a log of changes to the categorylinks table, but such a log might not be that useful. MediaWiki couldn't meaningfully link to an edit or show who caused the change – one person could edit a transcluded template, but the category link update could be triggered by someone else editing the transcluding page. Thanks to the job queue processing updates, the time of the addition or removal could be a long time after the edit that caused it. – PartTimeGnome (talk | contribs) 01:06, 8 February 2014 (UTC)

Interesting. If a log were kept, would it be possible to log the revision id of the category being added/removed? That is all the info neede to link to that particular edit. — Edokter (talk) — 01:49, 8 February 2014 (UTC)

The revision ID of the category page? That would remain the same for most additions to and removals from a category – a category's revision ID only changes when someone edits the header text at the top of the category. If you meant the revision ID of the page being added or removed, that could be a completely unrelated edit if the addition or removal was caused by an edit to a template or the passage of time. – PartTimeGnome (talk | contribs) 17:28, 8 February 2014 (UTC)

Sorry I meant the latter. Would there be no way to know if the added category originated from a template edit? — Edokter (talk) — 00:24, 9 February 2014 (UTC)

Well, all category updates via the job queue are due to template (or Lua module) edits. However, if someone edits a page affected by a template change before the job queue gets there, the category update occurs as part of that edit, even though the latter edit didn't touch categories (it could even be a null edit). MediaWiki won't be aware the category change is due to a template edit in this case; it just knows the categories for the submitted text don't match those in the categorylinks table, so the table is updated. – PartTimeGnome (talk | contribs) 21:12, 9 February 2014 (UTC)

i do not know of a way to detect removal of articles from a category. however, the API *does* provide addition to category timestamp. if this is of interest, you can look at he:מדיה ויקי:סקריפטים/71. it is not too long, and the one language-dependent function there is "ago" which translates the timestamp to more convenient strings such as "3 minutes ago", "5 weeks ago" or "2 years ago". just ignore this function, and you have the skeleton for a gadget/script that tells you when existing category members were added to the category. if addition is significantly less interesting than removal, feel free change this section title to "quarter answer". peace - קיפודנחש (aka kipod) (talk) 00:57, 7 February 2014 (UTC)

This is useful code; it makes an API call to https://www.mediawiki.org/wiki/API:Lists/All#Categorymembers , and then gets the timestamp-property of when each article was added to the category. Using it to track insertions and removals would require an external tool, which polled every category of interest periodically (every 24 hours or so maybe... categories that were added-but-then-quickly-removed would be missed by this polling-driven rather than event-driven approach). 74.192.84.101 (talk) 16:18, 7 February 2014 (UTC)

https://www.mediawiki.org/wiki/Extension:CategoryWatch "Extends watchlist functionality to include notification about membership changes of watched categories." Which is not quite as good as a log-page, but would still be a big improvement.

  Known to work with versions of MediaWiki from 1.11 thru 1.21, at which point the ArticleSaveComplete hook[34] was renamed PageContentSaveComplete.[35] Code is GPL, last updated 2011. Some people are using it as of 2014,[36] but not by the WMF. (We *do* use plenty of extensions,[37] including e.g. CategoryTree[38] which started life as an external wiki-tool.) The extension-author who created CategoryWatch in 2008 just posted in December 2013,[39] so they are still around.

  Is is possible to enable this extension (prolly after somebody swaps the deprecated call for the newer one), and take CategoryWatch from 3rd-party status to third-party-which-is-used-by-the-WMF-status? Alternatively, can the techniques used by CategoryWatch be used to create the CategoryEventLog stuff, which was the original suggestion? 74.192.84.101 (talk) 16:18, 7 February 2014 (UTC)

I updated two articles Girona railway station and AVE with the new international train services. This is mix of AVE and TGV services. The templates do not provide for this. Unfortunately there is no easy way to bypas the templates without rewriting whole articles. Can someone look at this?Smiley.toerist (talk) 12:27, 9 February 2014 (UTC)

I created Template:S-line/AVE right/, giving it the same contents as Template:S-line/TGV right/. Hopefully that helps. I did not look closely at the details of how these templates work. Wbm1058 (talk) 13:54, 9 February 2014 (UTC)

Given the string

{{Orphan/sandbox|date=August 2013}} {{Unreferenced|date=January 2009}} which is passed into a template as parameter {{{1}}}, I want to replace that string with

{{Orphan/sandbox|multi=multi|date=August 2013}} {{Unreferenced|date=January 2009}}, i.e., add another parameter |multi=multi.

My attempt to do this with

{{Replace|{{{1|}}}|Orphan/sandbox|Orphan/sandbox{{!}}multi=multi}} did not work, as it seems that {{!}} breaks the desired template parameter construction so that the syntax isn't recognized. Of course I need to template the pipe character so that it isn't confused for the terminus of the string parameter in the {{replace}} template.

Digging deeper, I see that

{{#invoke:String|replace|{{{1|}}}|Orphan/sandbox|Orphan/sandbox{{!}}multi=multi}} is equivalent to the above template usage, as module:String is the underlying module that is used, and I get the same results with that syntax.

The documentation at Module:String#replace offers some hope, in that there is a plain parameter which is a "Boolean flag indicating that pattern should be understood as plain text and not as a Lua-style regular expression." It defaults to plain-text. Can someone provide either a plain-text or Lua-style regular expression solution for me? Looking at the module:String source code might offer some additional documentation or insight into how it works. I only have a bare-bones understanding of how php regex works, and no knowledge of Lua or how Lua regex differs from php regex. Thanks, Wbm1058 (talk) 14:35, 9 February 2014 (UTC)

Can't be done, unfortunately. The issue is that in template call {{foo|{{bar}} }}, the bar template would be expanded before being passed to foo. You'd have to do a modification of the expanded content of the template to do what you're trying to do. Jackmcbarn (talk) 17:04, 9 February 2014 (UTC)

Now I get it. Thanks for pointing me in the right direction :) Wbm1058 (talk) 19:46, 9 February 2014 (UTC)

@GTBacchus, Isaacl, Jayen466, Obiwankenobi, and Sam and anyone else who might be interested:

Discussion on category intersections seems to have ground to a halt last May. What do we have to do to get this effort moving again? — Scott • talk 14:36, 9 February 2014 (UTC)

Please check MediaWiki talk:Deletedtext#Weird_glitch?. I don't know if the weird behaviour I encountered is related to parser functions or to transcluding a too template-heavy talk page, but I would like to know what happened there. —Kusma (t·c) 19:23, 9 February 2014 (UTC)

Core CSS has been migrated to use LESS, and the Vector skin has had some updates, ie. it now uses SVGs for the small icons (watch, arrow, user icon). It also uses a linear-gradient for the page background, but they forgot to use a PNG fallback for browsers that do not support gradients (IE8/9). That is why the background behind the tabs may look funky. I have submitted a bug. — Edokter (talk) — 11:59, 7 February 2014 (UTC)

IE does support some form of linear gradient, but still not using the beta-standardized method. There are workarounds. But for now linear gradients should not be essential for the presentation of MEdiaWiki, if they are not rendered a plain background color should be enough. Linear gradients are fun, but not required. You should avoid them for coloring large buttons, they can only be used to create pseudo-3D lighting effects to an existing background color (for example a grey button should look OK even if it's plain gray, without the gradients of shades of grey that create the 3D lighing effect. verdy_p (talk) 12:55, 10 February 2014 (UTC)

The move is towards making the Vector skin completely image independent from background images, so eventually, the page background and tabs will be rendered solely using CSS gradients. Still brewing on a suitable fallback, perhaps using IE filters, but eventually I think it will be CSS-only in the future. — Edokter (talk) — 15:57, 10 February 2014 (UTC)

Hi Seasons greetings. On mr-wikisource we intend to use a hide and show collapsible template s:mr:Template:इतरभाषीउतारा to hide the content which is in other than marathi language (and the template content is translated below on the same wikisource article page) When the reader clicks show it is supposed to show display the content inside. We are coming across three defficulties.

• The said template s:mr:Template:इतरभाषीउतारा is based on s:mr:Template:Navbox and currently used on this article namespace page at mr-wikisource.

The Defficulties we are coming across are as follows

1) When I am not signed in Template remains in closed form but when I click on show it does not show up the content but it remains closed.

2) When I sign in What I see is that template remains open and does not close For signed in or not what we need is template content should remain default hidden and should show up when we click show

• Simmiller other template based on same concept works well on mr wikipedia.I use win 7 and Firefox latest auto updates.

3) In the same template I want to use 5 more sets simmiller to of |group2 = इतरमजकूर |list2 = {{{इतरमजकूर}}} |group3= मजकूर |list3 = {{{मजकूर}}} the requirement headings which did not work are shown on talk page of the template

We wish and request some one help us out since mr-wikisource community is small and further trial and error from our side will take more time to accomplish the task.

Thanks and warm regards

Mahitgar (talk) 15:20, 9 February 2014 (UTC)

If I enter {{Template:इतरभाषीउतारा}} at s:mr:Special:ExpandTemplates and copy the produced code to the English Wikipedia then the navbox becomes collapsible. This makes me suspect the problem is somewhere in the code for collapsible tables in s:mr:MediaWiki:Common.js versus MediaWiki:Common.js, but I haven't compared the code. PrimeHunter (talk) 02:28, 10 February 2014 (UTC)

I belive I have fixed all three issues. I used jQuery.makeCollapsible instead of the code in common.js, so that should no longer be the issue here. I probably will take a look at this issue again tomorrow, right now I am a little sleepy.--Snaevar (talk) 02:55, 10 February 2014 (UTC)

Hi Thanks the Collapsible issue is now sorted out so point no 1 and 2 are addressed. For third point I copy pasted Snaevar' improvements from template talk to main template page s:mr:Template:इतरभाषीउतारा page the template behaviour is bit improved but at this article namespace page content filled in tabulated manner is still not visible. Both of you are taking so much efforts its realy nice of you.

warm regards

Mahitgar (talk) 06:45, 10 February 2014 (UTC)

I don't know the mr script and that makes it hard to examine but some of your parameter names are not identical in the template call and the templates own code. I don't know which version is correct so I'm not fixing it but if you copy-paste from one to the other then you should get identical names and avoid issues like a zero-width non-joiner and spaces versus underscores. PrimeHunter (talk) 14:02, 10 February 2014 (UTC)

This is a simple curiosity. I'm not sure this question belongs to here, but anyway. If Wikipedia is able to block whatever proxy, TOR (not sure about this) and other methods, how china, Iran and others countries are not? Hóseás (talk) 22:01, 9 February 2014 (UTC)

I don't know how TOR blocks work, but we have a bunch of volunteers who check for open proxies. I'm pretty certain there are a lot of open proxies we don't block because we don't know about them. Such unknown proxies will probably be discovered and blocked as we start getting suspicious edits from them, or if they appear on a public list of open proxies that one of our volunteers checks. – PartTimeGnome (talk | contribs) 22:13, 9 February 2014 (UTC)

• With TOR you have two points, access nodes and exit nodes. When you connect to TOR you access one of the access nodes, and are then routed through several other nodes until you can access a exit node, Identifying and blocking the editing from exit nodes is fairly straight forward on our end. But governments and other entities that want to block access to TOR would need to know all the access nodes and block access to those, that information is not easily obtained, while exit node information tends to be more public. Werieth (talk) 22:18, 9 February 2014 (UTC)

I don't think that Tor is an issue if we only block from editing the IP of its exiing node. But we will want that registered users connected to their account (which provide them non-public tracking by China, Iran or Syria, and allow contributors from these countries to benefit of freedom of use of Wikimedia sites.

So it's OK to block Tor proxies as long as users can register an account from Tor, and then use it, getting a but more sure that their account will not be tracked by dictatures to the time when they registered their publicly visible account. Of course, these users won't be able to connect anonymously with the IP of the Tor exist nodes. But there's nothing wrong if they logon via Tor to their account, and then use their account to read/write contents in confidence within Wikiemdia sites. We wil still monitor these users like any other regular registered user, with their effective IP hidden and kept private (nobody should know publicly that this user was contributing or visiting Wikiledia via Tor, just like nobody has to know the IP used by regular connected users).

Tor is good for Wikimedia projects in my opinion, and we should even promote it for users residing in countries in severe political troubles, or that fear social/political/religious harassment (e.g. LGBT users and independant reporters in Russia or Iran, or defenders of Fallun Gong in China, or Tibetan supporters in China, or women interested in other education resources in Islamic countries, such as control of birth, or even basic sexual education for young people, or simply reading news from foreign sources not censored by their government).

Using Tor with a registered account does not mean that the connected user can do everything on Wikimedia. They have to follow the same policies as any other registered user because there's strictly no difference.

However Tor may be used by regular users to create sock puppets; But Checkuser Admins can identify them (it's not up to the normal community to check this). If there are clear signs that sock puppets are created and used via Tor by some user that has been blocked on Wikimedia (this does not concenr a lot of people) in an abusive way, the registered account created and used via Tor will be blocked like any other account. verdy_p (talk) 12:48, 10 February 2014 (UTC)

The problem of course is that if the sockpuppeteer is using Tor, then there is no way to block them from creating more accounts. This is why we currently prevent all editing from Tor, not just anonymous editing; at least on the English Wikipedia. Users with a legitimate reason for using Tor can get IP block exempt on their account. This has been discussed quite a bit on the mailing list recently. The problem is that to sufficiently mitigate the potential for abuse, we need to be able to associate Tor user accounts with some form of unique-ish identifying information other than an IP, but doing that kind of defeats the purpose of using Tor in the first place. Mr.Z-man 14:40, 10 February 2014 (UTC)

If I wish to configure a firewall to only allow those TCP ports that are needed to access Wikipedia, Wikimedia, Wictionary, etc. how many ports do I need to leave open? Obviously I need to allow Port 443 (HTTPS) and Port 80 so HTTP traffic can be redirected to HTTPS, but are there any other ports that we use?

I did a port scan (not definitive, especially on large systems with load balancing and caching servers), and according to the scan, en.wikipedia.org appears to use:
TCP Port 80 (HTTP)
TCP Port 179 (Border Gateway Protocol)
TCP Port 443 (HTTPS)
TCP Port 8649 (Ganglia) [40]
I don't think that an ordinary user has any need to access 179 or 8649. --Guy Macon (talk) 02:46, 10 February 2014 (UTC)

Correct. You only need 80 and 443. — Edokter (talk) — 10:04, 10 February 2014 (UTC)

09:30, 10 February 2014 (UTC)

Hey there. Yesterday, I made a new article on an asteroid called 2013 JX28, and was waiting for it to be reviewed, when another user edited it, oblivious of the fact that it was pending review. Typically, I think that it takes 10-30 minutes for a person to review an article, but because he'd edited but not reviewed it, I think it threw the whole process off. Now the article seems 'broken' in an inter-stage between creation and review. I've contacted the person who made the edit and we're trying to fix the problem, but meanwhile I don't have much more than a basic knowledge of programming/coding, and don't know if there's a protocol for this sort of thing. Can anyone help here, or give suggestions on what to do to fix this sort of problem? Thanks for your help. exoplanetaryscience (talk) 18:04, 9 February 2014 (UTC)

I don't think there's a problem. -- Ypnypn (talk) 19:54, 9 February 2014 (UTC)

I guess you're talking about the new pages patrol; reviewing is something else. I don't see anything that would stop your article being patrolled. It is still marked as awaiting patrol in the new pages list. What did you think was broken?

If it's just that the page is still un-patrolled, remember that patrollers are volunteers, each with their own interests and ways of working. This means that the time it takes for a new article to be patrolled can vary by a lot. I can see articles from 11 January that are still un-patrolled, while one created 2 minutes ago has already been patrolled. – PartTimeGnome (talk | contribs) 23:01, 9 February 2014 (UTC)

Ha! While I was typing that, User:Huon patrolled the page! – PartTimeGnome (talk | contribs) 23:06, 9 February 2014 (UTC)

Some pages that are apparently patrolled very quickly might not have actually been independently patrolled at all. If a user with the autopatrolled right creates a new page, it's still entered into the list at Special:NewPages but does not have the yellow background which denotes an unpatrolled page. The way to distinguish it from a new page that was patrolled quickly is by looking in Special:Log/patrol, to see if it's also listed there as "automatically marked revision x of page Foo patrolled"; it will also credit that action to the page's creator. --Redrose64 (talk) 09:55, 10 February 2014 (UTC)

Good point, I forgot about that. I can't remember which article was "created 2 minutes ago", so I can't go back to check it. Ignoring auto-patrolled pages, I currently have to go back 24 minutes to find a page that was manually patrolled. – PartTimeGnome (talk | contribs) 01:28, 11 February 2014 (UTC)

Please participate in the discussion. Thanks. --Gryllida (talk) 22:34, 10 February 2014 (UTC)

Over the past 30 minutes or so, I have been barraged with a bizarre array of errors, including "site down" (due to too many connections), "service unavailable (HTTP 503)", an internal PHP error, and an internal database error. Is the site undergoing some form of attack? Or is someone just testing code patches on the live site? WikiDan61^ChatMe!_ReadMe!! 22:38, 10 February 2014 (UTC)

I got all those messages also. Happens now and then over the last few months. — Maile (talk) 22:40, 10 February 2014 (UTC)

Yes, I got some WMF servers not available messages just several minutes ago. And some odd database errors. ~ J. Johnson (JJ) (talk) 22:53, 10 February 2014 (UTC)

According to the Operations team there was a database lockup around 2014-01-11 22:10 UTC - the root cause is still investigated. Sorry for the inconvenience and thanks for reporting it here! --AKlapper (WMF) (talk) 09:25, 11 February 2014 (UTC)

I realize that this is a small error, but I'd like to get it fixed: there are files showing up at Category:NA-Class Bacon articles when they should be showing up at Category:File-Class Bacon articles. I seem to recall having this problem in the past, but I don't recall what the solution was. Northern Antarctica (talk) Previously known as AutomaticStrikeout 04:03, 11 February 2014 (UTC)

We have a WikiProject for bacon? {{WikiProject Bacon/class}} has file=no. I don't know the purpose of this but removing it should make the category change you want. PrimeHunter (talk) 04:47, 11 February 2014 (UTC)

Well, I've made the change, but it still doesn't seem to be working. Maybe it doesn't take effect immediately. Northern Antarctica (talk) Previously known as AutomaticStrikeout 04:55, 11 February 2014 (UTC)

Actually, I think the problem is fixed. Thanks for your help. Northern Antarctica (talk) Previously known as AutomaticStrikeout 05:00, 11 February 2014 (UTC)

Hey. Could someone help me with {{Infobox power station/sandbox}} (sample usage)? The template has 6 options (the six types of power stations). I am trying to use an IF function to do this: For example, if the "Wind farm" section is filled, the template colour (and thus the template header and footer sections) would switch to the colour of the "Wind farm" section (blue). I understand that we would then have to put in the name of the colour in two places (which won't be an issue). Thanks! Rehman 13:36, 11 February 2014 (UTC)

• Why not use #switch:? — {{U|Technical 13}} ^{(t • e • c)} 13:56, 11 February 2014 (UTC)

Can you help in putting that in? I'm not really familiar with that... Rehman 14:13, 11 February 2014 (UTC)

{{Infobox power station}} shows a lot of parameters but I don't see one for type. Is the template supposed to say "If at least one parameter in the wind farm section is used then it's a wind farm", and so on? It appears so from the current code where I see stuff like {{#if:{{{wind_turbines|}}}{{{turbine_manu|}}}{{{turbine_model|}}}{{{hub_height|}}}{{{rotor_diameter|}}}{{{rated_wind_speed|}}}. And that's only to determine one of the types. It looks like it would require a giant test in two places to choose the color. Maybe it would be simpler and more stable to make a subtemplate and pass all parameters there, plus one extra parameter which deduces the type. Then the subtemplate could also use that parameter instead of its own type determining code. But it seems the template should have been designed with a type parameter from the start. PrimeHunter (talk) 14:17, 11 February 2014 (UTC)

Exactly, it's the case of "If at least one parameter...". The series of code you quoted is basically an IF situation where the section label gets generated if one of those is filled. Is it possible for the colour function to be derived directly from these labels instead? Hope I make sense. Rehman 14:43, 11 February 2014 (UTC)

• Okay, now that I've actually had a moment to look the template over, why not add a |station_type= which would allow you the ability to simply change the header/footer color to {{#switch:{{{station_type}}}|wind=this color|solar=this color|...=...|#default=orange}}? — {{U|Technical 13}} ^{(t • e • c)} 16:06, 11 February 2014 (UTC)

There should be no pipe right after #switch:. The challenge is the template already has 1874 transclusions. We would need a bot (or very patient editor) to go through them and add the right type parameter. PrimeHunter (talk) 16:29, 11 February 2014 (UTC)

• I have AWB and no issue with updating the transclusions one at a time once the new code is tested. — {{U|Technical 13}} ^{(t • e • c)} 19:24, 11 February 2014 (UTC)

Following The update to the MathJax code means MathJax display equations are now centered as opposed to Texvc equation and previous versions which were left-aligned. Should display equations be left-aligned, centered or configurable using the displaystyle feature? An WP:RFC has be started at Wikipedia talk:WikiProject Mathematics#Should display equations be centered?.--Salix alba (talk): 14:28, 11 February 2014 (UTC)

For some reason every image I upload is now on my watchlist. I've removed them but can somebody tell me how to disable it, I can't seem to find the box in my preferences.♦ Dr. Blofeld 14:33, 11 February 2014 (UTC)

@Dr. Blofeld: Special:Preferences#mw-prefsection-watchlist, uncheck "Add pages I create and files I upload to my watchlist". Matma Rex talk 14:57, 11 February 2014 (UTC)

The odd thing is that none of the boxes are ticked yet the images I uploaded today all went on my watchlist..♦ Dr. Blofeld 15:14, 11 February 2014 (UTC)

From what I can tell, German user Hedonil is the adminstrator of the new Wiki ViewStats pageview tool, which started in 2013. It seems to be more robust than the Stats.grok.se which started in 2007 in the sense of having generally higher pageview counts. However, I have noticed that on pages with the apostrophe character (') like Victoria's Secret or Sinéad O'Connor its totals are lower. Has anyone else noticed other problematic characters? Not even the diacratic of just the word Sinéad is a problem for the tool so I am not sure what the tool's problems are. Hedonil is ignoring me for some reason so I am unable to communicate this problem. If anyone is able to make contact with that German user, please call his/her attention to this problem (which may be one of many).--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 09:07, 31 January 2014 (UTC)

I should note that Stats.grok.se continues to have problems with the question mark (?) in articles like Who Dat?.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 15:00, 31 January 2014 (UTC)

With the changeover to a new month, I just noticed that the View stats is a rolling 90 day database. It does not do older months as they age.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 07:43, 2 February 2014 (UTC)

• I finally have gotten a reply from Hedonil. ViewStats does not currently aggregate variants. See this example of variants stats.grok.se aggregates variants and ViewStats just presents the primary result. As you can see in the case of apostrophes, the difference is rather large.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 05:31, 5 February 2014 (UTC)
  • I am not sure why the tool is not currently aggregating variants, but it might be because it is improperly identifying some redirects as variants such as this example.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 05:48, 5 February 2014 (UTC)

Wiki ViewStats is pulling up a blank for me today. However, at some point in the future is this going to replace Henrik's tool site-wide? — Maile (talk) 23:16, 9 February 2014 (UTC)

I am guessing that they were testing a lot of things and are now redoing the data. Now Jan 1 to date is back up. However, I have just reported a problem with disambiguation pages like Frank Underwood (House of Cards) and House of Cards (season 2), which are reporting numbers lower than stats.grok. All pages are currently appearing to have lower totals than stats.grok--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 08:43, 11 February 2014 (UTC)

Pages now higher.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 22:46, 11 February 2014 (UTC)

I used to use the checkbox for always hiding tables of contents (in Monobook) but Tech news 2014-06 and bugzilla inform us that this feature has been deemed to be too unimportant to continue cluttering up the code base, and removed. They also inform us that it can easily be simulated by custom CSS, but they don't inform us what the CSS is. Has anyone else taken the effort to figure this out yet, and if so how does one go about making tables of contents always invisible? —David Eppstein (talk) 03:10, 7 February 2014 (UTC)

Do you mean that you don't want to display the TOC at all? If so, add

#toc {display:none;}

to your common.css. If you want to have the "hide" option selected on load, add

$('.toc').addClass('tochidden');

to your common.js. (I haven't tested this out, so I don't know if it works.) ~HueSatLum 03:18, 7 February 2014 (UTC)

I meant the first one. Thanks! —David Eppstein (talk) 05:00, 7 February 2014 (UTC)

I used to have the "Contents" section turned off, but now it's showing up in articles and I can't find the switch to turn it off. Was this feature removed? Maury Markowitz (talk) 12:58, 7 February 2014 (UTC)

I see above that it was indeed removed. Nice that they didn't tell anyone through channels that mere mortals would ever see (buzilla, seriously?). I also see that I now have to edit my css files to fix this, another ability well beyond the average user. Was it really too much to ask first? Maury Markowitz (talk) 13:02, 7 February 2014 (UTC)

Quoting from mw:Requests for comment/Core user preferences#New dataset:

The ability to disable the Table of Contents feature (used by 86 users).

Helder 13:13, 7 February 2014 (UTC)

I can understand why these options were removed; they were turning into development hell. Each new feature would have to be tested against all the possible rendering scenarios that were available, while their use base was negligable. Going for a more consistent default user experience makes sense. — Edokter (talk) — 13:17, 7 February 2014 (UTC)

See also the List of user preferences in MediaWiki to be removed. Helder 13:19, 7 February 2014 (UTC)

Last night, out of the blue, text justification stopped working (about 14 hours ago) and all articles suddenly appeared with staggered text. I don't like it. I seem to recall that justification was a personal preference, but no such option shows up in Preferences (any longer...?). Since I'm fed-up with searching for a solution and I have work to do, I'm asking here: Is someone fooling around with skins again or what? André Kritzinger (talk) 10:35, 7 February 2014 (UTC)

It does seem that option has been removed; it used to be under the Appearance tab. — Edokter (talk) — 11:00, 7 February 2014 (UTC)

• I've reopened the ticket on Bugzilla (tracked ⇒) as this was supposed to have the option still available as a gadget before it was removed from core. — {{U|Technical 13}} ^{(t • e • c)} 11:08, 7 February 2014 (UTC)

  Several options formerly at Preferences → Appearance → Advanced options have gone west in the last few months, some quite recently. These include: Format links to non-existent pages like this (alternative: like this?); Show table of contents (for pages with more than 3 headings); Disable browser page caching; Enable "jump to" accessibility links; Justify paragraphs; Enable collapsing of items in the sidebar in Vector skin; Exclude me from feature experiments; Enable font embedding (Web fonts). --Redrose64 (talk) 11:48, 7 February 2014 (UTC)

  Gadgets are added by local administrators, not developers. Bugzilla is not the right place to ask for them. You can requests new gadgets for this wiki at Wikipedia:Gadgets/proposals. – PartTimeGnome (talk | contribs) 00:25, 8 February 2014 (UTC)

While the fiddlers are fiddling, my opinion for what it's worth. Justified paragraphs should be the default, not the option. Newspapers, magazines, books, you name it, have used justified paragraphs since long before the grandparents of anyone alive today were born. It simply looks neater. Aligned left went extinct with the old Remington typewriter. Make aligned left, centered or aligned right the optional preference for those readers who prefer it that way. I'm pretty sure they are not the majority. André Kritzinger (talk) 12:29, 7 February 2014 (UTC)

See also:

• List of user preferences in MediaWiki to be removed
• mw:Requests for comment/Core user preferences#Advanced options (from 2012)
• mw:Wikimedia Foundation Design/Typography#Paragraph justification
• gerrit:27206 (abandoned)
• gerrit:99322 (merged)

Helder 13:19, 7 February 2014 (UTC)

The CSS is

#article, #bodyContent, #mw_content { text-align: justify; }

just put that in Special:MyPage/common.css. --Redrose64 (talk) 14:05, 7 February 2014 (UTC)

Thanks, Redrose64 and all, but that's not good enough. It is a preference option and still belongs in Preferences → Appearance → Advanced options, where it used to be until it was fixed into being broken. Just how many users do you think are aware of Special:MyPage/common.css? I wasn't, and when I click on it I get to "Wikipedia does not have a user page with this exact name". So now I and countless others who are unaware of its existence need to create a new page to replace an option that used to require ticking a box. Plus, setting personal preferences must now be done in multiple locations. That's not progress. I just love the "wham, bam, thank you mam" attitude displayed about this matter at Bugzilla. André Kritzinger (talk) 15:14, 7 February 2014 (UTC)

Thank you for that Redrose, but I think it's ridiculous that this option has been removed from preferences. Justified text looks so much more professional and I can't believe it isn't the default on WP, let alone not even an option any more... --Loeba (talk) 19:49, 7 February 2014 (UTC)

Justified text is actually a poor choice for web readability as it creates "gutter" effects for readers who have dyslexia and certain forms of macral-degeneration. Accordingly, it is not set by default here. I should imagine that the preference was removed because maintaining preference bloat is something we don't really want to deal with.--Jorm (WMF) (talk) 00:32, 8 February 2014 (UTC)

• I agree. It should be the default, and it should certainly be an available preference. But more importantly, this kind of interface change should not be made without visible, public discussion and clear consensus. This change should be reverted. DES ^(talk) 23:51, 7 February 2014 (UTC)

I fear we are heading for another Visual Editor-esque debacle with these typography changes. There needs to be an easily locatable place, widely broadcast (not stuck away in a dark corner of mediawiki), where they can be discussed and user preference actually taken into account. I and many others like justified text, and I and many others like full page width text, so these should be available as preferences if not the default.--ukexpat (talk) 02:48, 8 February 2014 (UTC)

I seem to remember someone saying only 86 users enabled this option, but I lost where. In any case: Oh look here. — Edokter (talk) — 11:21, 8 February 2014 (UTC)

There's something that's being lost sight of here. The no-longer-existing options were available to registered users, therefore mainly contributors/editors. So now the situation exists were some contributors/editors (definitely not all) are aware of a gadget/snippet that will allow them to see the fruits of their labour displayed in a professional-looking justified format. In the meantime, the many millions of users who use the Wikipedia but will never register (the customers) can only see a primitive non-justified version. We're not doing all this work just for our own benefit, are we? André Kritzinger (talk) 12:10, 8 February 2014 (UTC)

Justified text is common in printed texts where it can be controlled by the publication, but not in websites where it's controlled by the reader's browser, usually with poor results. Here is a url for Wikipedia with the "Justify Paragraphs" gadget at Special:Preferences#mw-prefsection-gadgets: https://en.wikipedia.org/wiki/Wikipedia?withCSS=MediaWiki:Gadget-JustifyParagraphs.css. I tried five browsers and it looked bad in all of them with large spaces between words, especially on lines which are shortened due to images, tables or columns. PrimeHunter (talk) 04:18, 9 February 2014 (UTC)

• The spacing between words is part of what I like about justified paragraphs. It makes the text easier to read because it is less of a wall of text. Those spaces make it easier for me to keep my attention on what I'm reading and not lose which line I am on. It's about accessibility to me. — {{U|Technical 13}} ^{(t • e • c)} 04:54, 9 February 2014 (UTC)

• I find unjustified text "jerky" to read. My eyes and two brain cells tend to treat it like a poem and it reads like separate lines of text instead of flowing sentences. André Kritzinger (talk) 11:50, 9 February 2014 (UTC)
• The spaces in https://en.wikipedia.org/wiki/Wikipedia?withCSS=MediaWiki:Gadget-JustifyParagraphs.css vary between around 2 and 7 mm for me. It looks silly. If I wanted to increase spaces then I would do it consistently by adding something like the below to Special:MyPage/common.css. PrimeHunter (talk) 12:58, 9 February 2014 (UTC)

p {word-spacing:3px;}

• Huh, apparently this was very poorly thought out. Gerrit:27206 says "mysql> SELECT COUNT(*) FROM user_properties_anonym WHERE up_property = 'justify' AND up_value = 1 AND LEFT(ts_user_touched_cropped, 6) = 201210;" claims there to be 4,274 users who were using the justify option. — {{U|Technical 13}} ^{(t • e • c)} 15:49, 14 February 2014 (UTC)

Is it me, or did the watchlist display how many pages had changed during the duration you have it set for. For example, mine currently states "Below are the changes in the last 72 hours, as of 8 February 2014, 13:44." I'm sure it used to say x number of pages over the last y number of hours. Lugnuts ^{Dick Laurent is dead} 13:46, 8 February 2014 (UTC)

Yes, that's a change; instead of MediaWiki:Wlnote we're getting MediaWiki:Wlnote2. -- John of Reading (talk) 14:45, 8 February 2014 (UTC)

Thanks John. Is there a way to change it back? Lugnuts ^{Dick Laurent is dead} 14:58, 8 February 2014 (UTC)

@Lugnuts: No, it was a change in the software. Were you using that number for something other than satisfying your curiosity? Maybe there's a better way to do whatever that was :) Matma Rex talk 15:02, 8 February 2014 (UTC)

I just found it useful to see that I had 96 changes, or whatever the number was, over the given time. Lugnuts ^{Dick Laurent is dead} 15:10, 8 February 2014 (UTC)

I miss that number too. What was the point in removing it? Was it consuming too much cpu? HandsomeFella (talk) 20:19, 9 February 2014 (UTC)

• Matma, I also happened to like having that number. What was the purpose of removing it? I'm more curious than anything because I can easily tweak something up in JavaScript to give me the number like:

var changes = 0;
$('.mw-enhanced-rc-nested').each(function(){
    changes++
});
alert(changes);

which tells me how many changes are on the page (yes, I use enhanced-rc, and it could be modified to work for those who don't). — {{U|Technical 13}} ^{(t • e • c)} 21:33, 9 February 2014 (UTC)

as you noted, this works "on the page", i.e., as long as your watchlist change all fit on one page. i do not know how mw behaves when not all changes fit on one page (i never had such a large wathlist) - maybe there is no such thing as "does not fit in one page" for watchlist. presumably, the old count came from the DB and was not dependent on the page. BTW, there is no need to use "each" and increment the counter if all you want is the count - you can simply ask

$('.mw-enhanced-rc-nested').length

peace - קיפודנחש (aka kipod) (talk) 22:14, 9 February 2014 (UTC)

Is this going to be fixed soon?

HandsomeFella (talk) 11:29, 10 February 2014 (UTC)

I suspect that removing it was the "fix". T50615 is still open, but this simplification was suggested there. There have been a number of changes recently aimed at simplifying the UI and slightly improving performance, and this feels like that kind of change. WhatamIdoing (talk) 19:34, 10 February 2014 (UTC)

When refreshing my watchlist just now, I noticed the text <wlnote> in the position that the text in question used to be. So I've undeleted MediaWiki:Wlnote and it the status quo ante has returned. --Redrose64 (talk) 19:55, 11 February 2014 (UTC)

@Redrose64: Is that still using that for you, or was it a temporary glitch? I'm still seeing wlnote2. Jackmcbarn (talk) 20:57, 11 February 2014 (UTC)

Oh dear. It has gone back to MediaWiki:Wlnote2. But just in case it reverts again, let's keep MediaWiki:Wlnote for a while longer. --Redrose64 (talk) 22:33, 11 February 2014 (UTC)

See also MediaWiki talk:Wlnote#Edit request on 13 February 2014. --Redrose64 (talk) 09:48, 13 February 2014 (UTC)

• Do I read that bugzilla correctly? That the number of changes on the watchlist was removed at the suggestion of a single user? Pretty clear that, contrary to the belief of the person suggesting removal, plenty of people were actually using that information. They shouldn't have to use javascript to retain functionality that has been removed for no apparent reason. Risker (talk) 19:30, 14 February 2014 (UTC)

I generally run Wikipedia on "http" because i'm secure about my connection but over the past few days, it seems like wikipedia is now FORCING users to use the "https" format, i even checked my preference thinking "Always use a secure connection when logged in" may have been enabled by mistake but it wasn't..any reason why wikimedia is forcing people to use their https version?, technically http format loads faster, so i always preferred using that..is there any way to get back to using http? This seems be be happening to all wikimedia wikis..--Stemoc (talk) 00:22, 11 February 2014 (UTC)

• For many usernames, they have already been forced to use https/secure protocol because the http-mode does not retain the username in some browsers. Otherwise, IP-address users (21% of edits) for months have been able to run and edit in http-mode. Also, some high-security browsers lose the prior edit-buffers due to security restrictions, and so a mistake in editing could lose all changes, unless copied to an external file beforehand. Also, many people fail to omit the "https:" prefix in diff-links (as just "//en.wikipedia"), and that is another reason users keep getting forced back into https/secure protocol. I opposed the whole https obsession at the outset and noted even the U.S. Library of Congress did not support https mode. I keep suggesting to improve important problems, instead, such as auto-merge wp:edit-conflicts to adjacent lines in diff3.c, or LIFO-stack replies, or increase the wp:expansion depth limit to 60 or 90, or increase the Lua-timeout limit from 10 seconds to 30, but instead we get https-mode confusion, or increased mobile-phone support where almost no one edits from cellphones (and really should not be encouraged to phone-edit WP while driving).... -Wikid77 00:59, 11 February 2014 (UTC)

so they broke it even more instead of fixing it?....so no workaround? https is quite useful for email, online banking and social networking sites as thats where you share private information but seriously; not wikipedia, 90% of users are already incognito..wikipedia should be the last place to have this as its one of those sites which runs on overdrive as it can get millions of views in an hour sometimes, would be even harder for the servers to handle if they run on a secure server...btw, Wikipedia server admins, Wikipedia is created for an INTERNATIONAL market, which means its being used by people from all over the world and not just limited to First world/developed countries where internet speed and internet data is NOT slow and limited respectively..so please think of the poor kids in under developed countries who have no idea why their much beloved wiki is running slow and is constantly getting hit by "wikimedia errors" ..most sites i'm part of have moved on to the the "more secured" https server, but those are "commercial" sites but wikipedia is NOT..so lets keep it that way, free and fast..--Stemoc (talk) 01:30, 11 February 2014 (UTC)

There is one piece of private information sent with every request you make to Wikipedia while logged in: your login cookie. If someone else intercepts this, they can impersonate you on Wikipedia and make edits using your account (which could lead to you being blocked). If you are aware of this and don't mind that risk, then fair enough. I just want to make sure you are aware of the risks of using an unencrypted connection while logged in. – PartTimeGnome (talk | contribs) 01:52, 11 February 2014 (UTC)

(edit conflict)Er, even if you feel secure about your connection (to your ISP), how can you feel secure about all the connections between your ISP and Wikimedia? Even if you have convinced yourself that those links are all free from any risk of eavesdropping, the route from your ISP to Wikimedia can change without notice. You can only have a secure connection to Wikipedia by being sat inside a Wikimedia data centre, or by using some form of end-to-end encryption such as HTTPS or a VPN tunnel. (Personally I don't trust the connection to my ISP. I've seen too many roadside telecom cabinets with their doors wide open...) – PartTimeGnome (talk | contribs) 01:52, 11 February 2014 (UTC)

I have had this discussion before, It hops around 21 IP addresses and i live in a country where no one wants to hack your wikipedia account lol....i'm not on some insecure wifi and there is already an option for those wanting to use the https format in our Special:Preferences, I do not and yet I'm forced to use the https format..I'm aware of the dangers, but its the same as crossing the road, so I should just stop crossing road? not only is https slow, it can also force errors due to its 'slowness' like it did to me when i posted this topic twice...maybe they should just 'enforce' the https format for mobile platform (m.en.wikipedia.org)ONLY as its by far MORE INSECURE than via PC...--Stemoc (talk) 02:16, 11 February 2014 (UTC)

According to meta:HTTPS you are forced to use HTTPS for login only, not for anything else. The disadvantage of this behavior is currently unclear to me. --AKlapper (WMF) (talk) 13:19, 11 February 2014 (UTC)

Meta is just wrong. When logging in via http you dont get logged into other wikis, and if you dare to login to those wikis a forceHTTPS cookie is set for all wikimedia domains overriding your preferences. At that point your preferences are useless, the only way to fix that is to manually go into your cookies and delete all of the forceHTTPS cookies, which then logs you out of the other wikis and you start back where you began. Werieth (talk) 13:32, 11 February 2014 (UTC)

I see. Am I correct that this covered by bugzilla:61048? --AKlapper (WMF) (talk) 13:48, 11 February 2014 (UTC)

Close but not 100% because a forceHTTPS cookie is set. I think it may have to do with the inability to globally disable HTTPS connections, and that centralauth doesnt log you in via unsecured connections anymore. Werieth (talk) 13:52, 11 February 2014 (UTC)

I found that at least one of the CentralNotice banners (I forget which; I think that one of them was to do with wmuk:) contains a link that isn't a straight Wikilink, but goes through some intermediate layer that sets the forceHTTPS cookies. But whether you've been clicking those links or not, if you want to use http: for all projects, you also need to disable "Always use a secure connection when logged in" individually at every site that you are likely to visit, such as meta, Commons, etc. --Redrose64 (talk) 17:37, 11 February 2014 (UTC)

The centralnotices concerned were two of these: POTY2013R11 Stew2014noms Stew2014vote Trademarkpolicydiscussion wm2014_scholar of which the last one seems highly likely, don't recall which the other one was. --Redrose64 (talk) 11:54, 12 February 2014 (UTC)

As a Meta admin, I would appreciate any bug reports regarding CentralNotices to m:WM:RFH. You can check the code of each banner, e.g. m:Special:CentralNoticeBanners/edit/Wikimania2014Submissions. m:Special:CentralNotice has the list of current campaigns running. If you click one like "Stew2014-vote", you can scroll down to see the banner ("stew2014vote"), and look at the code it uses. (see bottom of m:Special:CentralNoticeBanners/edit/stew2014vote) πr² (t • c) 17:14, 12 February 2014 (UTC)

Stemoc, I'm not able to reproduce what you're seeing. I'm assuming you're using your Stemoc account, which is global so CentralAuth is handling the cookie security, and you should not be affected by bug 61048. Can you confirm:

• You don't have a forceHTTPS cookie when you initially visit the site (It's deleted when you logout, but if you log out in another browser and your session is unset, you'll be logged out, but still have your session cookies and the forceHTTPS cookie until you close your browser or relogin).
• When you click login from an http page, the url should contain "&fromhttp=1" (if you click login from an https page, we keep using https for your logged in session, and you will not have this url parameter).
• After you login, you should be redirected to an http url, you should not have any forceHTTPS cookies, and your centralauth_User and centralauth_Session cookies for the .wikipedia.org domain should not have the secure flag set.

Let me know where your login experience is different, and I can help track down what the issue is CSteipp (talk) 16:57, 12 February 2014 (UTC)

Indeed, I have also confirmed how http-mode edit-preview will continue (although very slow) for large pages, when https/secure protocol hits a fatal wp:504_Gateway_Time-out. Thanks again to Stemoc, for the reminder above. By running 25 tests of edit-preview over 2 hours, alternating http versus https, I confirmed how http-mode always worked, while https/secure always cratered with "504 Gateway Time-out" when editing large page "Nash equilibrium" (re: John Forbes Nash, Jr., A Beautiful Mind). In all cases, http-mode worked within 75-95 seconds realtime (2-3 CPU seconds), but the https/secure edit-preview session was always fatal, yet a direct SAVE-changes would work sometimes. Hence, users can edit-preview as http-mode, then redo as https/secure and SAVE to get username in history log. -Wikid77 (talk) 09:04, 11 February 2014 (UTC)

This is a separate issue, but fairly serious. Is there a bug open for this yet? This seems like an issue with the nginx config on the ssl cluster that ops should be looking into. CSteipp (talk) 17:03, 12 February 2014 (UTC)

Template:Edit protected/testcases

@Jackmcbarn and Mr. Stradivarius: since I know you've both worked on this project. For some reason, most transclusions of this template are returning script errors. I tried reverting the most recent edit to the module but it either hasn't gone through the job queue yet or didn't fix it. Could you guys, or any other skilled Lua coder look into this please? Thanks. — {{U|Technical 13}} ^{(t • e • c)} 19:49, 11 February 2014 (UTC)

I don't see any script errors, so I've reverted the revert for now. Where did you see them at? Also, I've un-transcluded /testcases here, as it caused this page to be miscategorized. Jackmcbarn (talk) 20:32, 11 February 2014 (UTC)

• The /testcases I transcluded was all script errors except for two instances, so maybe my undo fixed it once it made it through the job queue. Should know for sure if the errors show back up from your revert. I'll just screenshot it next time. Otherwise I've no idea what caused it, how to replicate it, or how to fix it.  :) — {{U|Technical 13}} ^{(t • e • c)} 20:38, 11 February 2014 (UTC)

  If you do see it somewhere else, make sure you click on "Script error" and include the information that comes up in the screenshot. Jackmcbarn (talk) 20:45, 11 February 2014 (UTC)

  To see the effect of a change to a script or template without waiting for the job queue, purge the test cases page. (I have done so, and it still looks fine to me.) You can also preview the effect of a script/template change without even saving the change, using the "Preview page with this template (what's this?)" options beneath the edit area. – PartTimeGnome (talk | contribs) 21:34, 11 February 2014 (UTC)

@Jackmcbarn: The only one that I saw was at about 20:12 today, on Talk:Cat Creek, Montana#Edit request - it showed Script error where the {{Edit template-protected|ans=n}} template should have been displayed. I didn't click it; but I did notice that it had put the page into Category:Pages with script errors. A WP:NULLEDIT fixed it. --Redrose64 (talk) 22:23, 11 February 2014 (UTC)

• I see a lot of talk pages transcluding Module:Protected edit request in Category:Pages with script errors, but it looks like the script errors have all disappeared now. The edit that Technical 13 reverted was made too early (7 Feb) to have been the cause. The script has definitely been working since then, as I have been answering edit requests without seeing any script errors. It's most likely to have been caused by a server-side change, but I can't see anything likely in the roadmap either. — Mr. Stradivarius ^{♪ talk ♪} 00:06, 12 February 2014 (UTC)

I'm new to Wikipedia. How do i edit protect my personal page so it can't be vandalized? — Preceding unsigned comment added by Justmephotography (talk • contribs) 22:36, 11 February 2014 (UTC)

@Justmephotography: You can't. What you can do is file a request at WP:RFPP, but unless you can demonstrate that there is a genuine need for the page to be protected, I suspect that they will decline the request. --Redrose64 (talk) 23:24, 11 February 2014 (UTC)

Actually, user pages are usually protected on request by the user; you don't need a special reason. User talk pages, on the other hand, are almost never protected. The relevant policy is at WP:UPROT if anyone wants to see it. — Mr. Stradivarius ^{♪ talk ♪} 23:34, 11 February 2014 (UTC)

Now moot, since the only page (other than this one) ever edited by this user has been deleted under WP:CSD#G11. --Redrose64 (talk) 09:39, 12 February 2014 (UTC)

Thanks guys! You've been a big help to a noob like me lol Justmephotography (talk) 19:23, 14 February 2014 (UTC)

Is there any known method to disable page-review notices on talk pages? For instance, see my own – I received eight nearly-identical notices within the course of a few minutes.... Cloudchased (talk) 16:44, 12 February 2014 (UTC)

This isn't a software problem unless there's been a recent change which I'm unaware of; rather, Narvekar ameya has manually been typing "The page is reviewed" into the "optional message" field of the curation toolbar. Narvekar ameya, please refrain from sending redundant messages via the textbox -- rather, only use it for more detailed feedback or a positive note after reviewing an especially good article, for example. Theopolisme (talk) 22:43, 12 February 2014 (UTC)

Resolved

Hello all. At Government by the People Act I reload the page yet the redirect I just created, United States campaign finance reform, still appears red. I've created a lot of redirects, and I've never seen this. I even tried it in another browser and refreshing that one didn't turn it blue either. Thanks. Biosthmors (talk) pls notify me (i.e. {{U}}) while signing a reply, thx 18:11, 12 February 2014 (UTC)

It's blue for me. Try purging the page instead. VanIsaac_{WS Vex}^contribs 18:35, 12 February 2014 (UTC)

Biosthmors I restored this thread, because other people have commented on it, and so WP:TPO applies; I also marked it {{resolved}}. It will be archived automatically in due course. --Redrose64 (talk) 23:47, 12 February 2014 (UTC)

I spotted this thread's removal too, so I archived it instead. I've removed it from the archive again now it's back here. – PartTimeGnome (talk | contribs) 23:29, 13 February 2014 (UTC)

The template Template:uw-editsummary seems to insert duplicate signatures of the user who is posting the message, at least in some circumstances (e.g. when called via Twinkle).

For example, please see User_talk:Trafford09#February_2014.

It may be that this isn't the best place for me to post this fault, in which case I apologise. Trafford09 (talk) 08:34, 13 February 2014 (UTC)

This was a recent change, contrary to Wikipedia:WikiProject user warnings/Design guidelines. I have removed the signature from the template. -- John of Reading (talk) 08:57, 13 February 2014 (UTC)

I just noticed something strange at WP:ANI. Looking at the TOC for the page, some discussion threads that were very current would disappear. If I then purged/refreshed the page (by clicking the digital clock gadget that I have enabled at the upper right corner of my page displays), those sections would sometimes reappear, while other sections would disappear. Purging again makes the reappearing sections disappear and the disappeared ones reappear, and so on. While I check my medications (joke), could someone else please check what is going on with that? Thanks! --Tryptofish (talk) 17:05, 13 February 2014 (UTC)

I was getting a 2-3 day old version of the page a few minutes ago. Northern Antarctica (talk) 17:08, 13 February 2014 (UTC)

I've been noticing the same thing. I saw the live page, then on refresh had a view from a couple days ago (which alerted me to some especially entertaining drama), then back to present. I even had an issue where I clicked on a section edit link from a thread today and ended up on the edit page for a section that was archived yesterday. Resolute 17:10, 13 February 2014 (UTC)

I think the answer is: [69]and [70]. Phew! Hopefully that should be the fix, and hopefully I hadn't lost my marbles! --Tryptofish (talk) 17:14, 13 February 2014 (UTC)

(edit conflict)See this [71] ticket. Leaky Caldron 17:16, 13 February 2014 (UTC)

This has been driving me crazy this morning. :) I hope whatever it is, it is isolated and fixed soon! --Maggie Dennis (WMF) (talk) 17:21, 13 February 2014 (UTC)

The database must not be able to process all the drama and is choking. I recommend we delete ANI! Resolute 17:58, 13 February 2014 (UTC)

Still happening... while trying to fix a recent problem like that, I was also served an ancient page on "edit". The only way I could edit the current page version was by using popups to access the most recent version by its oldid. —Kusma (t·c) 19:37, 13 February 2014 (UTC)

Is this problem isolated to ANI? Northern Antarctica (talk) 19:43, 13 February 2014 (UTC)

I think so. I haven't seen it at any other high use boards (AN, Jimbo's talk page, for example). Resolute 19:54, 13 February 2014 (UTC)

None of these pages compare to ANI in terms of both size and number of revisions. Check Wikipedia:Database reports/Pages with the most revisions for outdated information. —Kusma (t·c) 19:56, 13 February 2014 (UTC)

• I agree with Resolute, so I've deleted the Wikipedia:Administrators' noticeboard/Incidents.--v/r - TP 20:16, 13 February 2014 (UTC)

  i see what you did there Writ Keeper ⚇♔ 20:27, 13 February 2014 (UTC)

It gets better. Try to do a "cur" diff at the history of ANI. It will compare with the page version from 22:01, 10 February: [72] —Kusma (t·c) 20:57, 13 February 2014 (UTC)

Yes, this is also breaking Twinkle, as it gets confused about the revision ids. Writ Keeper ⚇♔ 21:01, 13 February 2014 (UTC)

It is working for me again. Are other people still getting the wrong revision id for the current revision? —Kusma (t·c) 21:24, 13 February 2014 (UTC)

Yes, I just tested it and it reloaded Eric Corbett's discussion from February 10 as being the last one on the page. ♥Soap♥ 21:31, 13 February 2014 (UTC)

• Can we get some browser/OS information? It may help tracking down the issue. Werieth (talk) 21:33, 13 February 2014 (UTC)
  • For me, it's Firefox 27.0 and Windows Vista. I recollect that the Bugzilla says it also happens with Chrome. --Tryptofish (talk) 22:11, 13 February 2014 (UTC)
  • Firefox 26 on a Mac, but this doesn't seem to have anything to do with the browser used unless my user agent affects database behaviour. —Kusma (t·c) 22:18, 13 February 2014 (UTC)
• In the meantime, I've created Special:AbuseFilter/606 as a stopgap measure; it should be able to detect and warn the user of the glitch before they make the edit. Writ Keeper ⚇♔ 21:39, 13 February 2014 (UTC)
• (comment) This may also be occurring at the science ref desk. See this discussion. - Purplewowies (talk) 22:01, 13 February 2014 (UTC)
  • Yup, looks like a related issue. Writ Keeper ⚇♔ 22:16, 13 February 2014 (UTC)
    • And an interesting tidbit—the "cur" test done above when done at that ref desk results in the "cur" diff pulling from one made 10 minutes before the "latest" that ANI shows. diff (21:51 10 February 2014; intermittent, but 8 times out of ten, it's been this behavior) - Purplewowies (talk) 22:38, 13 February 2014 (UTC)

Another observation: I just loaded Wikipedia:Administrators' noticeboard/Incidents. Nothing at the top to indicate I'm looking at an old page, but I see this footer at the bottom:

This version of the page has been revised.
Besides normal editing, the reason for revision may have been that this version contains factual inaccuracies, vandalism, or material not compatible with the Creative Commons Attribution-ShareAlike License.

It looks like MediaWiki was aware at some the level that the page was outdated at the time it served it... – PartTimeGnome (talk | contribs) 23:11, 13 February 2014 (UTC)

This must be something very close to the database: this API call can return two different lastrevid values with different length. Everything else is the same, remarkably including touched. — HHHIPPO 23:52, 13 February 2014 (UTC)

Often I want to leave a message to a single user that doesn't fit into any of the currently implemented communication procedures used around here. For example, I see an editor I am on good terms with, biting a newby. I want to privately message him/her but email is too formal and might not be read for a while (if at all) and halfway through writing a formal user-talk-page message I get discouraged/cold feet and abandon the message.

Proposal: a button next to every edit for autoconfirmed users (and also *emphasis* easily revocable) to jot a quick (certain number of characters, no markup) note to the editor (e.g. Why did you make that edit?; Can you find a source for that statement?; I'm making a big edit to this page so let's avoid edit conflicts etc.). Also could be a very nice alternative to the, overly laden "semi-automated rejection" that comes from Twinkle. Often I want to get the message across to a good-faithed editor without shaming them with an embarrassing letter of rejection that is publicly viewable.This feature could easily be integrated into the WP:Notification drawer. Optional: a way to mark messages as read/flag messages as abusive etc.; an way to reply to the editor who left reply.

We might get an ad-hoc way to do this in Project Flow but this is a really easy stop-gap.

Without picking apart the minutia of this idea just yet, what are your impressions? Mark Schierbecker (talk) 21:30, 13 February 2014 (UTC)

An interesting idea. If the messages sent are private, I'd want on option for users to disable the ability for such messages to be sent to them. I prefer all wiki-related communication with me to be public. Other users might want to block private messages to avoid abusive messages.

I'm rather concerned this private messaging function would damage Wikipedia's transparency. Being able to see the discussions behind edits is a big plus for me, and two of your three examples (explaining an edit and finding sources) are the kind of things I'd want to see on an article talk page. Also, if messages are private, multiple editors could send similar messages without knowing someone else had done so. Receiving multiple such messages could have a worse affect on an editor's morale than one public message. Finally, I think where one has concerns about an editor's edits, they should air them publicly to allow other editors to better establish a pattern of conduct should the editor not improve their behaviour.

(I know there are some good uses of private messaging, which is why we have the e-mail feature. However, the feature you propose makes private messaging easier to use than a talk page, so would discourage public discussion.) – PartTimeGnome (talk | contribs) 22:53, 13 February 2014 (UTC)

You brought up some interesting stuff I never considered. I would be willing to concede the private aspect of the proposed feature if the consensus is for transparency. I just don't know how that would be implemented. Mark Schierbecker (talk) 23:10, 13 February 2014 (UTC)

I think it would be a really neat feature if was a fast way to post to the user talk page or article talk page (perhaps give a choice as to which one). Using the "fast reply" link could even automatically add a link to the diff so its clear to which edit the comment refers, and automatically sign the comment too. – PartTimeGnome (talk | contribs) 23:19, 13 February 2014 (UTC)

Occasionally people send me emails from Wikipedia. I normally ignore them; if they deserve a reply, I copy the email text to either my talk page or theirs, but I was recently pulled up because it's apparently a violation of copyright to do that. I'm in favour of transparency; I don't believe in holding Wikipedia discussions off-Wiki, except when meeting somebody face-to-face. The only times that I send emails from Wikipedia are for WP:OVERSIGHT requests. --Redrose64 (talk) 23:31, 13 February 2014 (UTC)

About an hour ago, I was getting "Wikimedia Foundation Error" when trying to open the history of a talk page. That problem went away after maybe 10 minutes. But now, I'm getting the error every time I try to open the article Peyton Manning.

The exact error is;

Wikimedia Foundation

Error

Our servers are currently experiencing a technical problem. This is probably temporary and should be fixed soon. Please try again in a few minutes. If you report this error to the Wikimedia System Administrators, please include the details below. Request: GET http://en.wikipedia.org/wiki/Peyton_Manning, from 91.198.174.61 via amssq57 amssq57 ([91.198.174.67]:3128), Varnish XID 912289047 Forwarded for: 88.104.19.171, 91.198.174.61 Error: 503, Service Unavailable at Fri, 14 Feb 2014 04:18:45 GMT

I get the same error if I try to access it via the Wikipedia search box.

But I am able to open other articles without problems. 88.104.19.171 (talk) 04:22, 14 February 2014 (UTC)

Update: Still getting the same thing; and I've noticed it on one other article - T.A.T.u._discography. 88.104.19.171 (talk) 05:16, 14 February 2014 (UTC) And All_About_Us_(song). Yet many other articles load fine. 88.104.19.171 (talk) 05:18, 14 February 2014 (UTC)

I am using the API to analyse pages. Lots of pages are giving me this error but I can visit the page via the web browser? Periglio (talk) 10:40, 14 February 2014 (UTC)

I got this a lot from approximately 21:45, 13 February 2014 (UTC). It wasn't specific to one page: when the error was thrown, I would try another page (in order to force my browser to do some cache clearance), and then try the first again, which would sometimes work. All in all, I was getting approximately 25% success, 75% failure. I gave up completely at about 23:45 (UTC), and it seems to have cleared up completely in the following hours. --Redrose64 (talk) 13:05, 14 February 2014 (UTC)

When editing an article you can choose to only edit a section of the article or only edit the lede or again edit the whole article. When you only edit a section you can tell by the edit summary. But there's nothing in the edit summary that allows you to tell if an editor's editing was restricted to the lede or if they edited the whole article. Can that be fixed? Thanks. Contact Basemetal here 04:42, 14 February 2014 (UTC)

I think it'll say something like "Editing Theros (section)". If not, the Preferences tab'll do the trick. Supernerd11 :D Firemind ^_^ Pokedex 04:53, 14 February 2014 (UTC)

Could you be a bit more specific? You think "it'll say something like ..." where? And where in Preferences can you set that option? Thanks. Contact Basemetal here 05:19, 14 February 2014 (UTC)

I think the proposal deals with the default edit summary, not the user interface during the edit. I agree that it sounds like a useful feature. For example, editing this section, which is titled "Editing the lede as opposed to editing the whole article", gives an edit summary box starting with:

/* Editing the lede as opposed to editing the whole article */

with the insertion point afterwards. Assuming I don't muck with it, that means the history says by explicitly entered text but also (in a different font/color) the title of the section. Except for section 0 (the lead) (the presence of a link to edit just this section is indeed a preference). In that case, the summary is blank, which is the same as when editing the entire page. A useful default stub might be

/* WP:LEAD */

? I suspect this would have to be done in the WM code, I don't see any trace of the default edit-summary in the URL or in the Mediawiki namespace. DMacks (talk) 05:31, 14 February 2014 (UTC)

In the meantime people can of course do this manually by starting their edit summary (when they do only edit the lead) with /* lede */ or as you suggested /* [[WP:LEAD]] */ (in case there actually is in the article a section called "lede":) But we'd all have all to be all angels all to all do that. Contact Basemetal here 05:59, 14 February 2014 (UTC)

"Edit link for lead" appears to be a gadget, so maybe it can be fixed there (rather than in WM core). If it were to be in core (a default for section 0, regardless of what activated that edit action), would also need a mw: variable for it so that each local site could determine what it should say in the correct language and pointing to the correct target). DMacks (talk) 06:09, 14 February 2014 (UTC)

The "Edit link for lead" box is what I was referring to at first, but that just lets you edit it, no special thing in the summary. As for the "It'll say something like...", that's what it is on the edit page. Supernerd11 :D Firemind ^_^ Pokedex 06:13, 14 February 2014 (UTC)

MediaWiki:Gadget-edittop.js is the likely place to hack. I don't know the WM API, so I don't know how (if?) one can set a default edit-summary. DMacks (talk) 06:15, 14 February 2014 (UTC)

The API certainly allows setting the edit summary. Here is some javascript which you could use as a bookmarklet to edit the lead for the page you are viewing. In a new tab/window:

javascript:void(window.open((/(^.*\?title=[^&]*).*$/i.test(location.href) ? location.href.replace(/(^.*\?title=[^&]*).*$/i,"$1") : location.pathname.replace(/^.*\/([^\/#]*).*$/,"//" + location.hostname+'/w/index.php?title=$1')) + '&action=edit&section=0&summary=%2F%2A%20top%20%2A%2F%20'))

In the same tab:

javascript:void(location.href=(/(^.*\?title=[^&]*).*$/i.test(location.href) ? location.href.replace(/(^.*\?title=[^&]*).*$/i,"$1") : location.pathname.replace(/^.*\/([^\/#]*).*$/,"//" + location.hostname+'/w/index.php?title=$1')) + '&action=edit&section=0&summary=%2F%2A%20top%20%2A%2F%20')

You can store either as a bookmark which when clicked will edit the lede of the page you are viewing with the default edit summary of "/* WP:LEAD */ ""/* top */ ".

The changes to MediaWiki:Gadget-edittop.js are reasonably easy. I have made the changes and put them in User:Makyen/Gadget-edittop.js. After disabling the option in Special:Preferences#mw-prefsection-gadgets, I edited my common.js page to add:

importScript('User:Makyen/Gadget-edittop.js'); // Adds Edit link to lede section with default edit summary "/* [[WP:LEAD]] */ "; modified from [[MediaWiki:Gadget-edittop.js]] Referenced page blanked/deleted, a better version is now available as the gadget.

I have only minimally tested it, but it appears to be working.

Makyen (talk) 10:37, 14 February 2014 (UTC)

I don't really see the point of this; to me if you really need to specify that you're only editing the leadin an edit summary, you can just write "copyedit lead" or similar. I don't really like the idea of the link either ... but if it must be there, then it should have the link text of "lead"; "WP:LEAD" won't be readily understandable to most newbies. Graham87 11:51, 14 February 2014 (UTC)

Remember that the /* ... */ portion of the edit summary is used to create a link to that section from such pages as: diffs; history; watchlist; etc. If something is placed between the /* ... */ markers, it should therefore correspond to a section on the page that exists following the edit concerned. None of the four suggestions so far (/* Editing the lede as opposed to editing the whole article */ /* WP:LEAD */ /* lede */ /* [[WP:LEAD]] */) will necessarily do that.

However, every Wikipedia page has a pre-set anchor named "top", which is positioned between the tabs and the page title; thus /* top */ will cause the arrow → preceding an edit summary to link to that position. Other anchors exist that are close to the top of most (all?) pages, these are: "globalWrapper" "column-content" "content" "siteNotice" "firstHeading" "bodyContent" "siteSub" "contentSub" "jump-to-nav" "mw-content-text", but with the possible exception of "firstHeading" (which also has the advantage of being on the <h1>...</h1> element itself), I don't consider that their names are as intuitive as "top". See these two edits for working demonstrations: the earlier one used /* top */ and the later one /* firstHeading */. Remember that in most browsers (IE, as ever, excepted) these anchors are case-sensitive. --Redrose64 (talk) 13:09, 14 February 2014 (UTC)

I agree the summary should say /* top */ and link to that anchor. — Edokter (talk) — 13:31, 14 February 2014 (UTC)

I've gone ahead and put it in, and see how it is received. — Edokter (talk) — 14:03, 14 February 2014 (UTC)

I struck-out the no longer available reference to a local copy in my user space and changed the javascript above to the better edit summary of "/* top */ ". Makyen (talk) 19:59, 14 February 2014 (UTC)

The much-maligned content max-width (that squished the page into a fixed column) has been removed from the Typography refresh feature under the Beta preferences. If this was the main reason you didn't use the typography refresh, please try it out again and give us your feedback. Cheers! Kaldari (talk) 01:00, 15 February 2014 (UTC)

At Wikipedia:Village pump (policy)/Archive 111#As WP uses HTTPS.2C should .28some.29 external links.2C_too.3F it was recently decided that Wikipedia should "use HTTPS links for HTTPS only sites, protocol relative links for sites that support both HTTP and HTTPS, and HTTP links for sites that don't support HTTPS at all". The closer of that discussion noted that "the discussion [didn't] concern the implementation of this proposal, and therefore a new one should be initiated regarding this". I am therefore opening such a discussion on how this can best be implemented.

Some editors in the previous discussion and elsewhere have suggested that the consensus can be implemented simply by removing the protocol from the URLs of sites which support both HTTP and HTTPS. For example, [https://www.youtube.com/ YouTube] could be changed to [//www.youtube.com/ YouTube]. However, I contend this may be a bad idea because it breaks such links when reading an offline (or otherwise non-HTTP[S]-hosted) version of Wikipedia. There at least a couple scenarios in which someone might be reading such a version:

• Some Wikipedia Apps for mobile devices and offline readers for computers download a complete dump of Wikipedia to local storage and access it from there. Such scenarios are particularly advantageous for users subject to low bandwidth, government surveillance, or government censorship, which were three groups singled out in the previous discussion.
• Some users who normally read Wikipedia online may use their web browser to manually save an article to local storage for future reference.

When viewing these offline copies the protocol used to view the article is likely file:, which means that the previous example would link to the non-existent file://www.youtube.com/.

In light of this I wonder if there is some technical workaround, be it via clever use of templates or changes to MediaWiki itself. —Psychonaut (talk) 20:49, 23 January 2014 (UTC)

IMO, it would be a bug in the application that has stored the webpage to file:// that any protocol relative links on the page not been changed to the protocol being used at the time the page was stored (unless selected by the user to make an exact copy, or if the linked resource has also been stored). The application is effectively re-authoring the pages and should be responsible for making such changes. My opinion on this does not change the fact that such issues may exist in some situations, may impact users, and are something to be considered in any implementation which we adopt.

Having just checked this, I find that Firefox 26.0 correctly translates PR links to the protocol in use at the time the page is saved when saving files for offline viewing.

I also just checked the Wikipedia App on Android which properly translated a PR link to //www.youtube.com/ stored from a Wikipedia page on to local storage to be https://www.youtube.com/, the protocol in use at that time. I was able to open the link from a saved page with out any problems. It automatically opened in a browser using the HTTP protocol. So, the Wikipedia App is not an issue. Makyen (talk) 01:23, 24 January 2014 (UTC)

Does the WMF Wikipedia App really let you read offline? From the article it wasn't clear, though some of the non-WMF ones listed there certainly do. We should also consider popular offline readers for traditional computers, such as XOWA and Kiwix. —Psychonaut (talk) 10:03, 24 January 2014 (UTC)

If you have saved the page for offline viewing the Wikipedia App does enable viewing the page while completely disconnected from any network.

In addition, I checked IE. Like the others above, IE properly translated //www.youtube.com/ to https://www.youtube.com/ on a Wikipedia page when stored as a file for offline viewing.

For both Firefox and IE, I verified that the original page source served by Wikipedia contained the link as //www.youtube.com/ and that it was translated to https://www.youtube.com/ in the stored file. I did not do this verification for the Wikipedia App. Makyen (talk) 02:02, 24 January 2014 (UTC)

I tested Firefox and SeaMonkey myself. The links are correctly converted only if you use the "Web page, complete" save mode. Using "Web page, HTML only" they don't work. Some web clients, such as Links, don't handle protocol-relative URLs even when reading online—of course, that's a bug, though if it's one that affects several popular browsers, or even a small number used by a particular subset of our readers who have litttle or no choice (such as the blind and visually impaired), then that's something we need to consider. —Psychonaut (talk) 10:03, 24 January 2014 (UTC)

There are many other URLs in the HTML of a Wikipedia page are always protocol-relative, whether we intend them to be or not. Some examples:

• Images - the emitted HTML uses the <img /> tag, with attributes like src="//upload.wikimedia.org/wikipedia/commons/thumb/..." and srcset="//upload.wikimedia.org/wikipedia/commons/thumb/..."
• Interlanguage links (whether in the sidebar or in the page's inline text) - the <a>...</a> element has an attribute like href="//fr.wikipedia.org/wiki/..."
• Interwiki links (commons, meta, wikidata, wiktionary etc.) - similarly, the <a>...</a> element has an attribute like href="//commons.wikimedia.org/wiki/..."

So long as these work without a protocol, I don't think that we should worry about external links which also happen to be formatted using the protocol-relative syntax. --Redrose64 (talk) 13:11, 24 January 2014 (UTC)

Psychonaut: So, at least for Firefox, your issue is that protocol relative links don't work if the user chooses to translate the page first from being online to being offline, and then selects a non-default format which is guaranteed to have all links, other than internally to the page, broken when viewed offline? Sorry, I don't really see that as an issue. As it currently stands, every single link to within Wikipedia is broken under those circumstances. I don't feel we should be considering it to be to be a significant negative that the links are broken when someone chooses to store just the HTML page. Further, this discussion is supposed to be about how we implement the change, not if we are to do so.

So far, the primary thing that I hear you saying is that you have concerns that PR links might be an issue under some unknown/unspecified circumstances (some browsers, etc.), or when the user has made choices which are guaranteed to break most/all links (at least those internal to Wikipedia). Your statements now imply that you do not have any actual cases where using PR links is a known problem (for situations where the content was actually intended to be viewed, which saving just the HTML page is not). I know that it is unreasonable to expect one person to test all cases for all browsers. Thus, I don't expect you to do so.

The reality is that for external sites which support both HTTP and HTTPS we can offer links that are A) HTTP, B)HTTPS, or C) protocol relative. The previous discussion ended with unanimous opposition to both options A and B while showing unanimous support for option C, protocol relative links. The current discussion is how we are to implement changing to using protocol relative links for external sites which support both HTTP and HTTPS. We appear to be getting sidetracked on a subset of concerns as to if we should provide PR links under such circumstances as opposed to how we do so. While considering the potential issues you have brought up about providing PR links, keep in mind that providing HTTP links, or HTTPS links each has its downside where the links are broken for some readers viewing the pages while online. Using PR links was, and is, the best of the three options (when both protocols are available from the external site).

So the question remains how are we going to implement providing such links. I will take a stab at the very rough basics:

For external sites providing both HTTP and HTTPS:

• Change templates which provide links to such sites to providing PR links (e.g. {{YouTube}} ).
• Change configuration files for AWB and other tools such that the change is made along with any other general fixes, typo fixes, etc.
• Consider running a bot/bot task to make such changes more rapidly.

There are certainly enough pages where such links exist to make a bot an appropriate option. One question is: do we want to push such a change through wholesale with a bot, or let it be more of a gradual migration? Is now when we want to make such a change? How fast do we want to make the change? etc.

I am sure that there is more to it than just the above very rough list. Makyen (talk) 15:32, 24 January 2014 (UTC)

Before doing the above, I suggest that we create a page describing protocol relative links, so when someone asks why we removed the "http(s):" from a link, we could point them to protocol relative link or an appropriate page in the Wikipedia or Help namespace. Also, are there any other domains that could use PR links besides youtube.com and web.archive.org? Thanks! GoingBatty (talk) 15:25, 27 January 2014 (UTC)

OK, I'm glad to learn that the situation isn't as problematic as I suspected, and that we've already been using protocol-relative links for some time without any apparent objections. In the absence of any more substantiated suspicions then I'd support changing the necessary templates, and requesting a bot to convert existing and future hard-coded links. —Psychonaut (talk) 17:17, 29 January 2014 (UTC)

As to what links to change: I believe at least the following all can use PRLs:

1. web.archive.org
2. youtube.com
3. myspace.com
4. twitter.com