Jump to content

Wikipedia:Village pump (technical)/Archive 123

From Wikipedia, the free encyclopedia

#time: bug?

...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)
@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 ChatAbsent 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 ChatAbsent 04:27, 28 January 2014 (UTC)

 Resolved DDoS has now been taken care of. Tools have been re-activated.—cyberpower ChatAbsent 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)

Labs server down?

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://wiki.riteme.site/w/index.php?title=Prime_number&action=submit#Primality_of_one rather than to https://wiki.riteme.site/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://wiki.riteme.site/w/index.php?title=Prime_number&action=submit when you click that link, then it will take you to that section on https://wiki.riteme.site/w/index.php?title=Prime_number&action=submit, not that section on https://wiki.riteme.site/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)

Help with template code

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)

Cite template

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 (talkcontribs) 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 (talkcontribs) 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)

Pages very slow to load today

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)

Scores app?

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)

Citing web sources - ArchiveURL question Suggestion

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)

Changes to Education Program interface causing errors

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) (talkcontribs) 12:35, 31 January 2014 (UTC)

User contributions: "articles created" feature not working

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)
  • 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 ChatAbsent 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)
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)
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)

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

Templates etc do not get updated automatically

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)

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)

Transclusion count missing at action=info pages

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://wiki.riteme.site/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)

Indefinitely blocked IP addresses

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

08:30, 3 February 2014 (UTC)

Fraction formats

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: 2732, 34 as <sup>3</sup>&frasl;<sub>4</sub>
  2. superscript+small format:      27/32, 3/4 as <sup>3</sup>/<small>4</small>

By avoiding subscripts, <sub>4</sub>, 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: 3/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 (2732 v.s 27/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)

"Search"

I entered "Brolin" in Wikipedia search and instead of a list of search results I was taken straight to this page: http://wiki.riteme.site/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)

Cirrus now a Beta Feature

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)

I want to use a commons photo twice in one article, the second time being a close-up

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)

Change of username, contributions and SUL

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)

Two cool statistical tables; 2013 on en.wp

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.

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
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 (talkcontribs) 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)

Live feed for submissions at Articles for Creation

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)

Template:Sisterheader on Commons

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)

Where do you type in IRC channel?

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 (talkcontribs) 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}} (tec) 02:25, 4 February 2014 (UTC)
  • Thanks. Yeah, I found that white input box. Meta Self (talk) 11:39, 5 February 2014 (UTC)

Template to swap two words

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

IP's signing their name in articles

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 (talkcontribs) 02:37, 5 February 2014 (UTC)

Preprocessor counts of table and div

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)

Portal needed deletion but can't locate text

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. BencherliteTalk 10:55, 5 February 2014 (UTC)
Many thanks! Market St.⧏ ⧐ Diamond Way 13:13, 5 February 2014 (UTC)

Soft redirects

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)

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

Wasted space on right-hand side constraining width

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

New extension: Flow

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

mobile watchlist grayed out...or greyed out if you're european..

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)

Bad Gateway error

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)

Notifications broken

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


The notifications system appears to have broken. I see a red box indicating that I have 2 notifications, but when I click on it Special:Notifications just displays: "Error: Could not find the requested workflow". --BrownHairedGirl (talk) • (contribs) 13:05, 5 February 2014 (UTC)

When I click the red letter 1 on my messages it won't clear and keeps coming up with

"Error From Wikipedia, the free encyclopedia

Could not find the requested workflow.

Return to Main Page."

I'm out of here at the moment, hope it's fixed by the time I return!♦ Dr. Blofeld 14:00, 5 February 2014 (UTC)

@BrownHairedGirl and Dr. Blofeld: I've combined the "Notifications broken" and "Message" sections as they are about the same problem. (For me the notifications display fine, though I don't have any new ones.) SiBr4 (talk) 14:10, 5 February 2014 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

When I edit a section and then "Cancel" I'm taken to the top of the page instead of staying at that section

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)

Hiding admin tools

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

User contributions for new accounts + view 500 per page = database error. Known bug?

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)

API query to list available protection levels for a wiki?

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)

Yikes! Science Refdesk is dropping PHP errors?

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

Changes to button colors/styles on some forms

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)

Rotten Tomatoes glitch

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}} (tec) 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)

Merge the Page Curation and Patrol logs?

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)

Portal:Current events displaying "Invalid time"

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)

Customizing user experience based on logged-in status

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)

Highlighting within an article from a list of regex expressions

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}} (tec) 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}} (tec) 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}} (tec) 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. SiBr4 (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)
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}} (tec) 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}} (tec) 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:
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}} (tec) 04:51, 9 February 2014 (UTC)

Chronology of category-insertion and category-removal events

There are, in fact, people tougher than Chuck Norris...

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)

implementation tech

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)

half answer

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)

three-quarters answer

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)

Template mess

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)

Help requested with using Module:String

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)


Odd post-deletion behaviour

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)

CSS bug in IE 8 and 9

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)

requesting support for collapsible template at mr-wikisource

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

TOR, proxies and whatever

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)

Which TCP ports does Wikipedia use?

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, wiki.riteme.site 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)

Reviewing broken by early edit?

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)

Bizarre array of errors

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? WikiDan61ChatMe!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)

Files not recognized as such

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)

Switching template colours

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)

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}} (tec) 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)

RFC: Should display equations be centered?

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)

Images

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)

Differences between Wiki ViewStats and Stats.grok.se

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

Removed preferences

Show table of contents (for pages with more than 3 headings)

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)

Contents switch disable?

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)

Justify paragraphs

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}} (tec) 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:
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://wiki.riteme.site/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}} (tec) 04:54, 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}} (tec) 15:49, 14 February 2014 (UTC)

Watchlist question

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}} (tec) 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)

Forced "https" on wikis

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.wiki.riteme.site)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) πr2 (tc) 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)

Confirmed http works when https gets 504 Gateway Time-out

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 script errors..

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}} (tec) 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}} (tec) 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)

Edit Protecting

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 (talkcontribs) 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)

Opt out of page-review notices

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

Fault in Template:uw-editsummary (duplicates signature)

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)

Discussions disappearing and reappearing

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)

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

Proposal: "reply to edit" option

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)

Wikimedia Foundation Error

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://wiki.riteme.site/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)

Editing the lede as opposed to editing the whole article

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)

Max-width removed from Typography refresh in Beta features

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
There are certainly others. I know that user:Bender235 has a list that has been used to implement a large number of PRL changes via AWB.
Any volunteers to take on creating Protocol relative link? Makyen (talk) 00:11, 4 February 2014 (UTC)
MySpace and Twitter use HTTPS by default. No need for protocol-relative links there. Wayback only keeps the existing HTTP links alive so that no link is broken. Anyone who enters their site now is redirected to HTTPS per default. Only YouTube has a true either/or strategy from those on your list. --bender235 (talk) 00:35, 4 February 2014 (UTC)
When I enter "web.archive.org" into my browser, I'm not redirected to a HTTPS page. When I click on a link in Wikipedia that starts with "http://web.archive.org" (e.g. reference 5 in Linda McCartney), I'm not redirected to a HTTPS page. GoingBatty (talk) 02:18, 5 February 2014 (UTC)
OK, so our list is really only 2 sites? It would be nice to have a moderately comprehensive list prior to starting so we are not making a run for each site. Makyen (talk) 18:31, 9 February 2014 (UTC)
Hmm, you're right, Wayback doesn't redirect every site. Entering http://web.archive.org gives you the HTTP version. Only the "main entrace" http://archive.org is redirected. That's what they announced in October 2013. But the way I read their announcement, they encourage people to use HTTPS and HTTPS only.
@Makyen: it's not just two sites. Basically you can add all pages from the EFF's HTTPS Everywhere Atlas. But the main ones, from Wikipedia's perspective, are Wayback and YouTube, because those are (as far as I can tell) by far the most linked domains from Wikipedia (maybe apart from http://dx.doi.org). --bender235 (talk) 19:55, 11 February 2014 (UTC)

The list of sites at EFF's HTTPS Everywhere Atlas appears to be quite substantial; perhaps a bit too substantial for our use? I have not looked at the HTTPS Everywhere ruleset. However, my expectation is that there are sites on that list which we may not desire to include. At a minimum, we should visit each site we choose to include using both HTTP and HTTPS to verify that any links we are changing result in a user experience where the link is not broken. Perhaps if a bot is being used to make the changes, it should verify that the link is accessible using both protocols prior to making the change.

The existence of the relative hyperlinks section below clearly indicates that we need some page, or section of a page, which can be linked in the edit summary. If this does not exist prior to making wholesale edits to individual pages there will be a significant number of editors with questions looking around trying to figure out why any such changes are being made. As an example of this, @Bender235: has been making such changes for a limited subset of domains. Doing so has generated comment on bender235's talk page with at least one other user attempting to find out why such changes were being made. If there is a larger volume of changes, then there is likely to be a larger number of editors which have questions. It is, of course, unclear how many editors had question which were resolved by seeing the already existent discussions.

After writing the above paragraph, I realized that I should just do it, rather than talk about it being done. A large part of my resistance to personally creating Protocol-relative links was that I have not seen enough reliable sources, and did not find them when briefly looking on Google, for what I considered needed to have a complete page. Thanks to @TeleComNasSprVen:'s comment about it being more appropriate for a section in URL, I have created a very rough beginning to Uniform resource locator#Protocol-relative URLs and redirects from multiple names which people could use when attempting to find the information.

There appears to be a relative lack of interest/activity on this topic. Without action, the default is that links are left the way they currently are with some changes being made by individual editors (e.g. bender235). The current state is that each link will use the protocol which happened to be entered by the individual adding it to a page. The problem with this is that each of HTTP and HTTPS has disadvantages associated with it, including that the link is broken for some users. While this does not affect me personally, it does seem like something for which we should move forward beyond the "it is a good idea"/"we should do it" stage. Makyen (talk) 02:42, 17 February 2014 (UTC)

Just wondering, who was it that made the decision to convert nearly everything into protocol-relative URLs? I only have a passing knowledge of them, so perhaps someone with more intricate knowledge of the technical details may care to enlighten me. Maybe protocol-relative urls should become a bluelink? Anyway, was it because someone from the Wikimedia Foundation suggested it, was it based on the change from secure.wikimedia.org to https, or was it what everyone wanted from the start but the earlier versions of MediaWiki simply didn't support it? TeleComNasSprVen (talkcontribs) 07:20, 12 February 2014 (UTC)

Some links for you:
VPP: Original external PRL discussion (discussion/decision to implement external links as protocol relative when applicable).
Wikipedia:Wikipedia Signpost/2011-07-25/Technology report#Protocol-relative URLs coming
Wikipedia will switch to HTTPS by default (announcement from Wikipedia)
Enabling PRLs on test wiki
Wayback uses HTTPS by default
and the ongoing discussion on "How should external protocol-relative links be implemented?" at the top of this page. Makyen (talk) 08:21, 12 February 2014 (UTC)
Thanks. I'm wondering if perhaps the creation of login.wikimedia.org was related to this issue. It seems to be an empty wiki for storing SUL cookies and tokens. TeleComNasSprVen (talkcontribs) 09:03, 12 February 2014 (UTC)
No, that has nothing to do with it and is just the server for global authentication across the projects (aka centralauth SUL2). Protocol relative links weren't used before because our https access was on a different domain, but now they are and we don't need separate caches of http and https versions of the website anymore because we can use protocol relative links. —TheDJ (talkcontribs) 09:27, 12 February 2014 (UTC)
As for the reasons to use it in content: Wikipedia:Village_pump_(policy)/Archive_111#As_WP_uses_HTTPS.2C_should_.28some.29_external_links.2C_too.3FTheDJ (talkcontribs) 09:30, 12 February 2014 (UTC)

Sources for URI

We need some wp:RS sources for writing page "Protocol-relative URL" where page "URI scheme" links to webpage "http://tools.ietf.org/html/std66" (2005), but that is not considered the current standard document, and it mentions the relative referencing within the hierarchical part of a URI, which is not the protocol-relative URL (for URI scheme name omitted). Let's briefly discuss wp:RS sources about protocol-relative URLs, and then more can be discussed at Talk:URI_scheme or such. -Wikid77 13:28, 13 February 2014 (UTC)

That's a good start, @Wikid77: however, based on a cursory Google search there appears to be very scant material or any information at all discussing this subject, especially in light of the fallout of https-switching websites after the Snowden controversy. At most, it'll probably warrant a section underneath URL rather than a separate page, with the amount of sources I'm seeing. TeleComNasSprVen (talkcontribs) 06:45, 14 February 2014 (UTC)

Page protection check-box

Right now, when we protect a page for a definite period of time, all protection ends when the expiration date/time passes, even if the page had a previous protection that wouldn't yet have expired. What would everyone think about requesting the addition of a checkbox to put the previous protection back? Example: earlier today, an edit war prompted me to give a 24-hour full protection to Chiropractic (see section "Chiropractic" at WP:AN), a page that previously had been indefinitely semiprotected due to vandalism. With our current software, the page won't be protected at all after the full protection expires; someone will have to go back and restore the semiprotection. What if there were a box that, if checked, would cause protection to go back to indefinite semiprotection at the end of the 24 hours, rather than going to nothing? I'm proposing this here in hopes that it will demonstrate community support for the idea; if people agree that it's a good thing, I'd hope that developers at Bugzilla would look at it and realise that the community wants it. Nyttend (talk) 01:30, 13 February 2014 (UTC)

  • Support for such a mechanism and I'll comment on the Bz ticket as well. — {{U|Technical 13}} (tec) 03:45, 13 February 2014 (UTC)
  • Support Jimfbleak - talk to me? 07:17, 13 February 2014 (UTC)
  • Support I suggest that the default should be that the box is checked (i.e. the default should be that if the prior protection time-frame has not expired by the end of the new protection level, then revert to the prior protection level at the end of the new definite time-frame). Removing a lessor level of protection which was enabled for a longer time, of either definite or indefinite length, should not be the default action. Removing an indefinite, or even a longer-term definite, page protect should be something that requires active, intentional action. Makyen (talk) 08:05, 13 February 2014 (UTC)
  • Support Automatic restoration of the previous prot level and duration is the intuitive thing to happen. I've come across instances like this before, in talk-page questions from others along the lines of "this was supposed to be indef semi-prot, but I've just had to revert an IP for BLP violation" - what had happened was a one-week full-prot had been imposed and had since expired. I've made tests to be certain (observed result: when the full-prot expired, it didn't restore the pre-existing semi-prot). --Redrose64 (talk) 13:33, 13 February 2014 (UTC)
  • Support This is an infinitely logical idea. - The Bushranger One ping only 00:48, 14 February 2014 (UTC)
  • Support A very sensible idea that ought to have been thought of long ago. Per Makyen, make it the default. Peridon (talk) 15:58, 14 February 2014 (UTC)
  • Note It wouldn't really be "restoration" of the previous level, it would be more of multiple levels running concurrently and you would need permissions to get through all of the applied levels to edit. According to the Bz ticket, it looks like "some" of this has been in place all along, but was never finished up and enabled. — {{U|Technical 13}} (tec) 17:29, 14 February 2014 (UTC)
  • Actually, I had imagined a feature that would restore the previous level. Think of it this way: admin 1 imposes protection 1 for an indefinite or long-definite time; admin 2 imposes protection 2 for a short time, making sure that the "restore previous protection" box is checked; at the end of protection 2, software imposes protection 3, which is identical in every way to protection 1. No new log entry is created for protection 3, and in places where the most recent protection appears (e.g. when you try to edit and you don't have the relevant rights), we see the log entry from when admin 1 imposed protection 1. Requiring permission to edit through all of these wouldn't be as helpful. Imagine if we had a page at full protection due to incessant vandalism by autoconfirmed users, but it got reduced to semi for a day as an experiment, with the intention of restoring full protection at the end of a day. If you needed permission to edit through everything, this scenario wouldn't be possible, since the full protection would still be running in the background. Nyttend (talk) 20:41, 14 February 2014 (UTC)
  • I'm fully aware that I may be asking for something that's less than easy to implement: I'm no technical person. For that reason, I'm not rejecting the multiple-levels thing; I'm asking for the restoration idea if possible. See the protection logs for the Elephant article: I removed protection because it had been years since the elephant population grew by 300%, so I was guessing that unprotection could be attempted, but after a couple of weeks, Mark Arsten reprotected it after we found that vandalism resumed. If we had the restoration idea, we could reduce protection for a set amount of time as a test, with the previous protection to come back when the test was over. Nyttend (talk) 01:16, 15 February 2014 (UTC)
But the vandalism wouldn't have had time to come back if it was automatically restored to full protection after a few days. I think in a case like this it is better to leave it at the lower protection until the vandalism starts back up again, and then it is easy for anyone to request it increased on RFPP. — {{U|Technical 13}} (tec) 02:29, 15 February 2014 (UTC)
That's a single example, and not all situations will be identical to it; please don't reject the idea just because you disagree with just one implementation of the idea. Please explain how it would be harmful for admins to be able to have this ability? Nyttend (talk) 03:15, 15 February 2014 (UTC)
I haven't and am not rejecting the idea Nyttend. I'm just waiting for a valid use case for why it should be only one protection level at a time instead of all of them running concurrently. Thanks. — {{U|Technical 13}} (tec) 15:23, 15 February 2014 (UTC)
Would you object to an admin doing this manually? It's not uncommon to run this kind of a test, and the elephant history showed very quickly that the higher level of protection was needed. It would be appreciated if you didn't require us to wait because a common protection procedure is invalid. Nyttend (talk) 15:30, 15 February 2014 (UTC)
I'd have no objection to an admin increasing the protection manually, because an admin can make a judgement call as to whether the protection is necessary. Pages should only be protected where there is reason to do so; automatic re-protection could protect pages without good cause. Also, "tests" shouldn't have a set end date: the page should remain unprotected until such a time as there is reason to protect it. – PartTimeGnome (talk | contribs) 17:54, 15 February 2014 (UTC)

When you use the bbb, bb, ## and ### parameters in template:music the behavior when you change color and when you change size is not right.

Here's an example and compare how it behaves with those parameters and how it behaves with parameters b and # (which is how it should behave).

Atriple flat, Adouble flat, A, A, A, Adouble sharp, Atriple sharp

See? The triple-flat, double-flat and double-sharp signs don't change to white and don't become large as they should, but stay black and small. In the triple-sharp sign the sharp becomes white and large but the double-sharp stays black and small.

The documentation says that the template makes use of Scalable Vector Graphics to display double flat and double sharp signs "since the corresponding Unicode characters are not widely supported".

But is this bug an inevitable consequence of using SVG?

Contact Basemetal here 06:29, 14 February 2014 (UTC)

Yes it is. The SVG is an image that always gets shown in black. —TheDJ (talkcontribs) 07:39, 14 February 2014 (UTC)
It's because they are images that are transcluded inline (not necessarily because they are in SVG format). The only way to make the bb, ## etc. characters change color is to upload separate images in different colors and use those instead. I don't think it's possible to let the size of an image depend on the font size, though a {{{size}}} parameter could be added to {{Music}} to be able to manually change the image size. SiBr4 (talk) 07:52, 14 February 2014 (UTC)
Markup (whether wikicode, HTML or CSS) that affects the appearance (size, colour, anything else) of text has no effect upon images, and vice versa. There is in fact very little that you can do to change an image's appearance using markup, other than altering its dimensions: the colour, etc. are inherent to the image and cannot be overridden. It is because the colour cannot be chosen on the fly that it is necessary for there to be so many images for the WP:RDT project - see the first four images at WP:RDT/C. Each of these is a square, containing a centred vertical stripe which is 20% of the width of the square; and the only difference between the four is the colour of the stripe (red, dark blue, pink, and light blue) - but to get that stripe in each of the four colours requires four separate images. --Redrose64 (talk) 12:55, 14 February 2014 (UTC)
Have you tried <score>? --  Gadget850 talk 13:10, 14 February 2014 (UTC)
Well yeah
 {c' c'' e' g' c'}
but how do you change the size or the color of a score? Plus what I want is to embed those symbols in text, e.g. "In the key of F major the fourth degree (IV) is Bdouble flat".
How would <score> help me there? Contact Basemetal here 04:20, 15 February 2014 (UTC)
Why do you need to change the color? --  Gadget850 talk 04:41, 15 February 2014 (UTC)
How about the size? Can I change the size? Why do you need to change the size? Ok. Because (like I said) I'd like to be able to insert those signs of notes with (or without) accidentals in text of various sizes, colors and backgrounds. It's just that charts and tables (for example) are clearer when you can change size, color and background. For an example here's the type of chart I'd like to use size, color and background for: example. Clearly they would be more readable if I could change size, font, color, background and so on. Does this make sense? Is <score> gonna help me? Contact Basemetal here 05:20, 15 February 2014 (UTC)
I've just added a {{{size}}} parameter to {{music}} which makes it possible to specify a size for smaller or bigger images: <big>G{{music|bb|size=x15px}}</big>Gdouble flat. It requires a bit of trial and error to find the right size. Since the backgrounds of the images used by the template are transparent, you should be able to change the background color behind the symbols. To change their color, as I said, separate images need to be made.
<score> is mainly intended for complete music sheets; I don't think that it can produce individual symbols like "double flat" or "double sharp" without staff, nor that its color or size can be changed manually. SiBr4 (talk) 10:35, 15 February 2014 (UTC)
Great. Thanks. It's already something. I'll play a little bit with the {{{size}}} parameter. But did you document the new {{{size}}} parameter? I don't see anything here. Make sure you document this for the benefit of other users. Regarding <score>: that's what I thought. Contact Basemetal here 21:54, 15 February 2014 (UTC)
@Basemetal: Did that with this edit. I don't think resizing is actually necessary in most articles {{music}} is transcluded in, since it is usually only used for single flat and/or sharp signs, which are rendered as HTML characters and do change color/size along with the surrounding text. SiBr4 (talk) 22:53, 15 February 2014 (UTC)
Here's what I got so far (compare with what's at the top of the section):
Atriple flat, Adouble flat, A, A, A, Adouble sharp, Atriple sharp
You can see I had to use different sizes for double-flat and for double-sharp. But there's nothing you can do about that I guess.
BTW, if yall answer this question could yall please ping me? I don't like having this page in my watchlist because it is just too active. Thanks. Contact Basemetal here 21:54, 15 February 2014 (UTC)

Test

Hi everyone, I just want to test a script, can anyone who has time post messages on my talk page so I can see if it works? (Look for a section named Testing and put hi or something.)Yutah Andrei Marzan Ogawa (talk) 12:46, 14 February 2014 (UTC)

Hi, everyone it's working, thanks Yutah Andrei Marzan Ogawa (talk) 05:42, 15 February 2014 (UTC)

Detecting articles about people which do not contain the DEFAULTSORT key

Is it possible to detect all the articles about people that don't contain {{DEFAULTSORT}} ? I that know many articles about people don't need the DEFAULTSORT key, but I want to know if it's possible to do that. On a smaller Wikipedia, most articles about people need DEFAULTSORT. —  Ark25  (talk) 13:31, 15 February 2014 (UTC)

Italics in citation title broken

Discussion has moved to Module talk:Citation/CS1/Archive 9#Italics in citation title broken. – PartTimeGnome (talk | contribs) 18:30, 16 February 2014 (UTC)
The following discussion has been closed. Please do not modify it.

Italics within the title parameter for CS1 templates are borked for some reason. For example:

{{cite web | title=''Lorem ipsum'' NOTITALIC | publisher=Foo | work=Bar | date=December 0, 0000}}

Which used to output:

"Lorem ipsum NOTITALIC". Bar. Foo. December 0, 0000.

Instead generates:

"Lorem ipsum NOTITALIC". Bar. Foo. December 0, 0000. {{cite web}}: Check date values in: |date= (help); Missing or empty |url= (help)

Without template:

" ''Lorem ipsum NOTITALIC". Bar. Foo. December 0, 0000.

Whisternefet (talk) 15:35, 15 February 2014 (UTC)

Let's see how it behaves without the Lua module:
Cite web comparison
Wikitext {{cite web|date=December 0, 0000|publisher=Foo|title=''Lorem ipsum'' NOTITALIC|work=Bar}}
Old "Lorem ipsum NOTITALIC". Bar. Foo. December 0, 0000. 
Live "Lorem ipsum NOTITALIC". Bar. Foo. December 0, 0000. {{cite web}}: Check date values in: |date= (help); Missing or empty |url= (help)
But the main forums for CS1 problems are Help talk:Citation Style 1 and Module talk:Citation/CS1. --Redrose64 (talk) 15:44, 15 February 2014 (UTC)
Alrighty then, moved discussion to Module talk:Citation/CS1/Archive 9#Italics in citation title broken. Whisternefet (talk) 15:54, 15 February 2014 (UTC)

Annoying scrollbar

I've recently (it started yesterday or the day before I'm pretty sure.. definitely within the last week) had my pages start randomly requiring a horizontal scroll bar. This happens on every page, and there are no <pre></pre> tags anywhere causing the content to run over the side of the page. I've checked on both my accounts (I also operate User:NationalRegisterBot), and the problem is there for both. Resizing the window or even the size of the text on a page has no effect; it seems the page always extends beyond the edge of the window some set number of pixels. This only happens on Wikipedia. I'm running OS X Leopard, so my Firefox is out of date, but like I said this was not happening as recently as a few days ago. I don't get the scrollbars in Safari or Chrome. Here's a screenshot. Anyone have any ideas?--Dudemanfellabra (talk) 18:04, 15 February 2014 (UTC)

@Dudemanfellabra: What is the exact version of Firefox you're running? Matma Rex talk 18:53, 15 February 2014 (UTC)
16.0.2. I believe that is the latest version compatible with Leopard. Or at least that's the latest version they sent me updates for. I realize I need to update OS X haha, but like I said everything was fine until a few days ago, and I've had Leopard for years, so it has to be something on Wikipedia that has changed recently.--Dudemanfellabra (talk) 19:21, 15 February 2014 (UTC)
Could be anything. I see you have some scripts and gadgets running (like LinkClassifier). Try turing them off one by one to see if they are causing the problem. Edokter (talk) — 19:30, 15 February 2014 (UTC)
@Dudemanfellabra: It's not entirely unlikely that this was caused by the internal cleanup of the search box mentioned in latest tech news (already archived from this page), which used some CSS features which seemed mundane at the time and which Firefox seems to have incredible troubles with. This is kind of a long shot (especially since I didn't actually test this on that Firefox version), but can you try adding div#simpleSearch { overflow: hidden; } to your vector.css page? If it helps and doesn't break anything, we'll probably get that added to MediaWiki itself. Matma Rex talk 19:42, 15 February 2014 (UTC)
@Edokter: This happens on multiple accounts, so the scripts/gadgets can't be causing it. User:Matma Rex's idea solved the problem. Thanks for that! I agree that it should be added to the main css file so other users don't experience the same thing.--Dudemanfellabra (talk) 20:16, 15 February 2014 (UTC)
Hmm, that snippet I posted seems to break the search box styling when applied on Wikidata; it always felt rather icky to me. Given that OS X ≤ 10.5 and Firefox ≤ 16 both have less than half a percent of market share currently (and the combination of both is probably ), and given the troublesomeness of the patch, it's probably a better idea not to include it. (You can of course continue using it for as long as it works, just remember about it if something related to searching ever breaks for you :) ). Matma Rex talk 21:50, 15 February 2014 (UTC)
Fine with me. I'll just add it to my other account now and not have to worry about it anymore. Thanks again for the help!--Dudemanfellabra (talk) 23:54, 15 February 2014 (UTC)

Where do I find the talk page for this template?

I found this on a user talk page today and its instructions seem to contradict WP:USERNAME. I'd like to discuss it with the users that are deploying it but don't know where to find the template or its talk page:

This account has been blocked indefinitely from editing Wikipedia because your username does not meet our username policy.

Your username is the only reason for this block. You are welcome to choose a new username (see below) and continue editing.

A username should not be promotional, related to a "real-world" group or organization, misleading, offensive or disruptive. Also, usernames may not end in the word "bot" unless the account is an approved bot account

You are encouraged to choose a new account name that meets our policy guidelines and create the account yourself. Alternatively, if you have already made edits and you wish to keep your existing contributions under a new name, then you may request a change in username by:

  1. Adding {{unblock-un|Your proposed new username}} on Medanta. You should be able to do this even though you are blocked, as you can usually still edit your own talk page. If not, you may wish to contact the blocking administrator by clicking on "E-mail this user" on their talk page.
  2. At an administrator's discretion, you may be unblocked for 24 hours to file a request.
  3. Please note that you may only request a name that is not already in use, so please check here for a listing of already taken names. The account is created upon acceptance, thus do not try to create the new account before making the request for a name change. For more information, please see Wikipedia:Changing username.
If you feel that you were blocked in error, you may appeal this block by adding below this notice the text {{unblock|Your reason here}}, but you should read our guide to appealing blocks first.

Category:Wikipedians who are indefinitely blocked for a violation of the username policy

Anthonyhcole (talk · contribs · email) 04:54, 16 February 2014 (UTC)

Such substituted templates usually leave their name as a comment. This one says <!-- Template:Uw-ublock --> so it's at Template:Uw-ublock. The talk page redirects to Wikipedia talk:Template messages/User talk namespace. PrimeHunter (talk) 05:19, 16 February 2014 (UTC)
Thank you PrimeHunter! --Anthonyhcole (talk · contribs · email) 05:39, 16 February 2014 (UTC)

Is there any interest in this template? See discussion at MediaWiki_talk:Common.js#Template:InterProject. Reagrds, --Brackenheim (talk) 10:44, 16 February 2014 (UTC)

Clicking on any geocordinate link (ie the coordinate links at the top-right of pages like Thang Long Bridge) is giving a 400 Bad Request error: "Your browser sent a request that this server could not understand." This seems consistent over multiple articles and browsers, I even restarted my PC. --Derek Andrews (talk) 13:00, 16 February 2014 (UTC)

The servers hosting this (Labs Tools) is currently down, affecting all tools and bots hosted there. [73] --Sitic (talk) 15:01, 16 February 2014 (UTC)
The servers are back online. --Sitic (talk) 15:56, 16 February 2014 (UTC)
Thank you. --Derek Andrews (talk) 16:14, 16 February 2014 (UTC)

Wikiproject cleanup listings

Hello all! Thank you for your previous help. This time I beseech the help of the mighty technical editors again, on behalf of the WP:ANATOMY editors. There is a very useful cleanup listing of issues under a project's scope produced by Svick (example here: [74]), and I would dearly like to procure a copy for our Wikiproject if possible.

I've followed the instructions at User:Svick/WikiProject cleanup listing, and user Svick hasn't responded for over a month, and I was wondering if any technical editors could help with this problem? (for example, if any other editors had permission to add the wikiproject as documented here: User:Svick/WikiProject cleanup listing/Add?) Would be very grateful for any assistance provided. Kind regards, --LT910001 (talk) 02:37, 17 February 2014 (UTC)

It's the tool I use more often than I use all other automated tools combined. The fact that it is still hosted on the old toolserver is very frustrating. It is in fact the only tool stranded on that old server that I use regularly. What is required to make moving it to wmflabs a high priority task for the server staff? Roger (Dodger67) (talk) 13:36, 5 February 2014 (UTC)

It is already listed here: http://tools.wmflabs.org/ so you might want to ask its maintainer. --AKlapper (WMF) (talk) 15:59, 5 February 2014 (UTC)
The link in my "Tools" menu still goes to the old server - how do I fix that? Who is the "maintainer"? Roger (Dodger67) (talk) 15:53, 9 February 2014 (UTC)
  • Roger, you are the maintainer of that link actually. Go to your common.js and replace:
// Add [[WP:Reflinks]] launcher in the toolbox on left
addOnloadHook(function () {
 addPortletLink(
  "p-tb",     // toolbox portlet
  "http://toolserver.org/~dispenser/cgi-bin/webreflinks.py/" + wgPageName
   + "?client=script&citeweb=on&overwrite=&limit=20&lang=" + wgContentLanguage,
  "Reflinks"  // link label
)});
with:
// Add [[WP:Reflinks]] launcher in the toolbox on left
addOnloadHook(function () {
 addPortletLink(
  "p-tb",     // toolbox portlet
  "https://tools.wmflabs.org/dispenser/cgi-bin/webreflinks.py/" + wgPageName
   + "?client=script&citeweb=on&overwrite=&limit=20&lang=" + wgContentLanguage,
  "Reflinks"  // link label
)});
Would be my guess (I can't seem to get anything to load from tools.wmflabs.org today, not sure why so I can't confirm AKlapper any ideas on what's up with that?). — {{U|Technical 13}} (tec) 16:41, 9 February 2014 (UTC)
Thanks, I've updated the script. (Note to self: Create a list on my User page of all of my "custom" scripts. I can't keep track of such stuff I did years ago.) Roger (Dodger67) (talk) 17:19, 9 February 2014 (UTC)

@Dispenser: (tJosve05a (c) 20:08, 9 February 2014 (UTC)

24 Terabytes. That's 24 Flickrs accounts or $1,000 in Hard Drive ($10,000 with infrastructure [75]). That's equivalent to 2-4 weeks opportunity cost of an American worker. There are other demands, but considering waving of FLOSS requirements and that security is borked, it shouldn't be an issue. Even if I do not fully use it, other tools are also disk space strapped. (e.g. offline copies of enwiki to annotate)
I am willing to entertain offers from other players (Other Toolservers, Amazon's AWS, Google's Compute Engine, etc.) with acceptable terms. If that doesn't work out, I may need to solicit donations. — Dispenser 00:54, 10 February 2014 (UTC)
Since I changed to use the wmflabs version it doesn't work at all! The toolserver version at least worked some of the time. Roger (Dodger67) (talk) 13:54, 11 February 2014 (UTC)
Does anyone here know why it's broken and when it might be fixed? Roger (Dodger67) (talk) 07:01, 14 February 2014 (UTC)
Anyone, please? Roger (Dodger67) (talk) 09:05, 17 February 2014 (UTC)
  • Roger, based on Dispenser's above comment, it won't be fixed or running on labs correctly any time soon. So, for now I would change your common.js to:
// Add [[WP:Reflinks]] launcher in the toolbox on left
addOnloadHook(function () {
 mw.util.addPortletLink(
  "p-tb",// Toolbox portlet
  "http://toolserver.org/~dispenser/cgi-bin/webreflinks.py/" + encodeURIComponent(wgPageName)
   + "?client=script&citeweb=on&overwrite=&limit=20&lang=" + wgContentLanguage,
  "Reflinks",// Link label
  "p-reflinks",// Link ID
  "Add titles to bare references"// Link description
)});
until it is fixed on labs. When Toolserver is completely shut-down, it would be a good idea to come back and ask again. I know it sucks, but that is just the way it is. — {{U|Technical 13}} (tec) 14:18, 17 February 2014 (UTC)
Thanks - so it's back to the old semi-functional server then. Sorry I couldn't make head or tail of Dispenser's techno-babble post. Roger (Dodger67) (talk) 14:26, 17 February 2014 (UTC)
  • To be honest, I'm not sure there is anyone that knew what he was talking about. I myself had to ask him to clarify what he meant on IRC and still only semi-understand. So, no worries. :) — {{U|Technical 13}} (tec) 14:36, 17 February 2014 (UTC)
    I want to cache all 20 million external link so references can be done in a post processing stage where details (title, author, date) can be cross verified and lots of other goodies. The foundation employee have calling 24 TB excessive (it's not) and are not working with me. — Dispenser 20:40, 17 February 2014 (UTC)
    Is that what the system was doing on the Toolserver? Or is that less of a "maintain existing functionality" and more of a "expand functionality" request? --Izno (talk) 20:47, 17 February 2014 (UTC)
  • The "net" is so dynamic, is caching all of that really possible, and is it productive? Is there any way to get a chunk of the old Toolserver hardware once it is decommissioned so that you could run your own local server to do this? — {{U|Technical 13}} (tec) 21:58, 17 February 2014 (UTC)

User Contributions: Accept Revision

Does Wikipedia already have a way to display a list of "Accept Revision" approvals given by Reviewer? If not, this feature is needed. I need it because I believe I have approved revisions in violation of WP:DOY and I wish to remove some additions to some pages that I should not have approved. By the way, am I posting this question and request to the right place? If not, where should I have posted it? —Anomalocaris (talk) 18:10, 7 February 2014 (UTC)

You can use the review log. You can "unnaccept" a revision, but unless there are no newer reviewed revisions, it's kind of pointless. You don't have to unnaccept an edit to revert it. Mr.Z-man 18:31, 7 February 2014 (UTC)
Thanks. I reviewed my changes and did what I needed to do. —Anomalocaris (talk) 21:17, 7 February 2014 (UTC)

New problem: I go to Special:PendingChanges and open review links in a new window or the same window. Usually everything is fine, but sometimes, the Accept Revision button is grayed out and can't be clicked. One might think that this is because by the time I get to the page, someone has already approved the revision. Not so. The revision remains awaiting approval. Right now, I am on Ricky Rubio: Difference between revisions and the Approve Changes button is grayed out, but Ricky Rubio Revision history reveals that there are two revisions pending review. What is going on? —Anomalocaris (talk) 23:41, 11 February 2014 (UTC)

It seems to happen mostly when a user such as ClueBot NG reverts a change and leaves it in "pending review" state. In such cases, if I attempt to edit the page, there is no checkbox for "Accept this version (includes 2 pending changes)" as would be normal. It is not because someone already approved the change, because (1) the page continues to appear in Special:PendingChanges; (2) the "Unaccept Revision" button works; (3) History shows the latest change is pending review. I will note here if I find any occasions where I can't approve changes and the article is not already in a reverted-and-pending-review state. —Anomalocaris (talk) 23:24, 12 February 2014 (UTC)

It's not actually leaving it in a pending state. What you're seeing is that it's in the pending state on Special:PendingChanges, but by the time you click the link, ClueBot NG has reverted it and accepted its own revert. Jackmcbarn (talk) 23:39, 12 February 2014 (UTC)
No, that is not it, as I explained before. The situation can persist for many minutes or even over an hour, where, as I said before, (1) the page continues to appear in Special:PendingChanges; (2) the "Unaccept Revision" button works; (3) History shows the latest change is pending review, but, (4) the "Accept Revision" button is grayed out and (5) if I attempt to edit the page, there is no checkbox for "Accept this version (includes 2 pending changes)" as would be normal. If ClueBot NG has accepted its own revert, why 1, 2, and 3 above? It's happening right now at Byron Mullens, where ClueBot NG has not accepted its own revert. —Anomalocaris (talk) 00:29, 13 February 2014 (UTC)
Have you seen this at a page when the most recent editor is not ClueBot? Whatamidoing (WMF) (talk) 00:34, 13 February 2014 (UTC)
2 is normal in that situation. I've seen this happen with 2, 4, and 5, and a refresh made 1 and 3 disappear when I looked again. Jackmcbarn (talk) 00:39, 13 February 2014 (UTC)
Oh. I see what you mean on Byron Mullens right now. Please nobody review or unreview that page. Jackmcbarn (talk) 00:43, 13 February 2014 (UTC)
Responding to Whatamidoing: In the above-noted edit of Ricky Rubio: Difference between revisions, History page shows that, since the last then-accepted revision of 13:12, 9 February 2014‎ by Anupmehra, there were three revisions:
00:07, 12 February 2014‎ WhatamIdoing ... [automatically accepted]
23:11, 11 February 2014‎ ClueBot NG ... (Reverting ...) ... [automatically accepted]
23:10, 11 February 2014‎ 108.253.212.76
So now WhatamIdoing's edit and ClueBot NG's edit were both automatically accepted, but then, for an extended period of many minutes, I believe these two edits were not automatically accepted. I know I had 1, 2, and 4 at that time but I don't know about 3 and 5.—Anomalocaris (talk) 01:12, 13 February 2014 (UTC)
It's happening right now at Disaster, where ClueBot NG has not accepted its own revert. 1 2 3 4 5. —Anomalocaris (talk) 19:10, 14 February 2014 (UTC)
It's still happening at Disaster, and it's happening right now at Huntington's disease, where ClueBot NG has not accepted its own revert. 1 2 3 4 5. —Anomalocaris (talk) 19:30, 14 February 2014 (UTC)
Hello! Anomalocaris was kind enough to message me about Disaster and Huntington's disease. I "accepted" those changes. I got to the pages from Pending Changes and the "accept" was grayed out. I've seen it a few times before. I've found that if I "unaccept" the change, I can immediately "accept" it again and it is removed from the Pending Changes list. It doesn't solve the bug, but it's a quick way to get the pages off the pending changes list. EvergreenFir (talk) 20:51, 14 February 2014 (UTC)
I just did the same trick on Sharon Osbourne. Another ClueBot reversion, Accept Revision grayed out; clicking Unaccept Revision ungrayed Accept Revision, so I immediately accepted it. —Anomalocaris (talk) 06:11, 18 February 2014 (UTC)

Article Feedback: Next Steps

Hello everyone: As many of you know, we have been testing an improved version of Article Feedback v5 in two pilots on the English and French Wikipedias throughout 2013. The main purpose of this experiment was to increase participation on Wikipedia by inviting readers to leave comments on article pages.

Article Feedback seemed effective for engaging readers: 70% of survey respondents liked the tool; 2.7% of invited readers registered after leaving feedback -- and 3.0% of invited readers completed an edit. Over a million comments were posted during this experiment: on average, 12% of posts were marked as useful, 46% required no action, and 17% were found inappropriate by Wikipedia editors.

However, a majority of editors did not find reader comments useful enough to warrant the extra work of moderating this feedback. The French pilot just ended last month, providing further confirmation of this issue. In the final RfC we ran on the French site, about 45% of respondents wanted AFT5 removed everywhere, while 38% wanted to keep it on an opt-in basis, and 10% on help pages only; nearly everyone agreed it should not be on by default on all 40,000 pilot pages, let alone on the entire French Wikipedia. Their concerns are consistent with what we heard from editors on the English and German pilots.

Here on the English Wikipedia, Article Feedback is now available on an opt-in basis, and has been enabled on about 3,677 articles by editors who want reader feedback on articles they watch. On average, editors enable this tool on about 100 new articles per week -- but some editors who oppose the tool have disabled it on thousands of articles in recent months, which creates an awkward tension in our community. (Previously, the tool was enabled on over 400,000 articles, and 672k comments were collected during this pilot; but about 63% of editors in a February 2013 RfC voted against wide deployment, leading to the removal of the tool on these articles.)

Based on these pilot results, we recommend that Article Feedback be removed from our two pilot sites at the end of the month, as outlined in this report — since the tool is not welcome by a majority of editors, despite its benefits to readers.

We propose to give editors two weeks to transfer any feedback they find useful to their article talk pages, using the ‘Discuss on talk page’ tool. We also recommend that we archive the data from our pilot sites, and that we keep one instance running on Labs, for reference purposes.

Lastly, we recommend further discussions between the community and the foundation on how to give readers a voice on our sites. Suggested topics include how to make it easier for readers to comment on articles they read — as well as how to enable readers to participate in decisions that impact them, so that we can better serve the needs of all our users in the free culture movement.

We would be grateful for your comments about this recommendation — and on how to better integrate readers in our communities. Could you share your thoughts on this Article Feedback talk page in coming days? You are also invited to share any lessons learned from this experiment in our report's discussion page.

I would like to take this opportunity to thank all the community and team members who contributed to this experiment. We’re particularly grateful to Matthias Mullie, Pau Giner, Oliver Keyes, Maggie Dennis, Philippe Beaudette, Howie Fung and Erik Moeller at the Wikimedia Foundation -- as well as to community members Denis Barthel, Benoît Evellin, Tom Morris, Sebastian Peisker, TMg and Utar, to name but a few.

We appreciate your willingness to experiment with new ways to involve our readers in our communities — and we hope that the lessons we learned together can inform future initiatives. Regards as ever. Fabrice Florin (WMF) (talk) 01:15, 13 February 2014 (UTC)

Fabrice, if the tool falls into disuse, will it be easy to resurrect it to run reader surveys? --Anthonyhcole (talk · contribs · email) 10:12, 14 February 2014 (UTC)

As one who fought hard to get the thing to stop displaying for me (as I had neither faith nor interest in it), I would be interested to see if anyone has done an analysis of the feedback. What proportion of it was useful comment, and how much was unmitigated crap ('Shaun is awesome!!!!')? I'm not one of the disablers - I haven't seen it for a long time - by the way. Peridon (talk) 16:08, 14 February 2014 (UTC)
It all depends on what you call "useful" comment. For the purpose of studies, anything that suggested a change to article content was counted as "useful". Remember, the vast majority of comments that were moderated were moderated by people not familiar with the article, so their sense of what was and was not useful isn't necessarily, um, useful.

More importantly, I noticed that AFT5 seemed to apply itself to a very significant number of pages on my watchlist when the page was semi- or full-protected. (We had a real problem with AFT5 unintentionally being activated on a lot of arbcom pages last year - it's about the last place you want that kind of feedback.) I'd suggest reviewing the list of pages with it activated and ensuring that there really was a consensus amongst active article editors that it should have been there, because I suspect that is not the case. Risker (talk) 23:16, 14 February 2014 (UTC)

It also depended on the subject matter. People watching pop culture pages complained a lot about feedback that amounted to "I like (or hate) this celebrity". Feedback on company pages tended to be "What's their phone number?!" People watching medical articles tended to be pretty happy with it. I think it fared best on general-interest pages, rather than pages that attracted fans and/or people trying to accomplish something specific (like phoning a company). I found it very useful on High school diploma, for example. WhatamIdoing (talk) 20:18, 17 February 2014 (UTC)

Lessons from other wikis: "Report an error"

The subject is an initiative that was developed in the Polish wikipedia, and was since imported to some ~10 other wikis, including Spanish, Portuguese, Russian and Hebrew.

The idea is to specifically ask readers to report an error in the article they are reading. this is not your normal "feedback" - in fact, some wikis have this tool in addition to (or in parallel with) the feedback tool. You can see the Polish "Error reprort page" here: pl:Wikipedia:Zgłoś błąd w artykule. If you are more comfortable with another language that implemented it, notice the interwiki links.

This tool adds a "Report an error" link on the left-hand-side menu. In hewiki, we also added a second "report an error" link at the top menu, for anons only.

What this tool does is to open a "report an error" form, for the current page - the reported should merely fill in the actual error and press "send" (or "save" or "confirm" or whatever). the report is then saved in a special page in the WP namespace, with link to the article for which the report was written. in hewiki, we found that over 50% of the reports are good ones - either pointing a real error, or at least a deficiency in the article that requires fixing. This is way better ratio than we get with the "feedback" tool, where we are lucky if 10% of the feedback reports are useful.

We found this tool very helpful in engaging the non-wikipedian-population - significantly more useful than several incarnations of "feedback" tools like the one discussed in the previous section. it yields excellent "errata" raw material, and several wikignomes regularly correct articles based on the "Report an error" input.

Behind this tool is a default gadget. The plwiki original is here: pl:Mediawiki:Gadget-wikibugs.js. Other wikis may have modified it to their own needs and preferred workflows.

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

This was also proposed for English Wikipedia: Wikipedia:Kvetch (talk). And it was also mentioned in previous topics about AFT: WP:Village pump (proposals)/Archive 76#Ratings poll a distraction?. Helder.wiki 12:03, 17 February 2014 (UTC)
thanks. i was not aware of those. there is a significant difference: these are old discussions - i did not go over them in full, but i do not think these discussions enjoyed the lessons learned by other wikipedias. now that this is active in other wikis for a while (i think a little less than a year), it may be worth discussing it again and looking at the value (or lack thereof) it provided those other wikis. peace - קיפודנחש (aka kipod) (talk) 00:30, 18 February 2014 (UTC)

Will we ever have find and search and replace?

Is there any chance that the editor we use to edit WP articles (I'm talking about the usual one, not VisualEditor) will one day have such hightech features as find and search and replace? Jussayin. Contact Basemetal here 04:50, 14 February 2014 (UTC)

Ctrl+F can come in handy, but I'm not sure if anything like that exists. Supernerd11 :D Firemind ^_^ Pokedex 04:53, 14 February 2014 (UTC)
There is one already, at the right-hand side of the "Advanced" tab of the editing toolbar. It does not appear for some users (Internet Explorer?) so if you do not see it, consider using a different browser. — This, that and the other (talk) 04:56, 14 February 2014 (UTC)
I hope not. Lots of potential to cause chaos, few cases when it's really needed.
If I need to do this, especially if it's something complicated like re-ordering columns in a table, then I edit the page, copy the wikicode and paste it into my programming text editor. Edit as I wish, with regexes and everything, then copy and paste it back. Andy Dingley (talk) 12:20, 14 February 2014 (UTC)
See the bottom of Help:Edit toolbar. You need the enhanced toolbar enabled and you need to click on the Advanced tab to bring up the S&R icon. We also have Preferences → Gadgets → Add a sidebar menu of user-defined regex tools. --  Gadget850 talk 13:15, 14 February 2014 (UTC)
(NB that the search and replace icon is all the way over on the right hand end of the edit bar, which is easy to overlook if you have a wide screen.) WhatamIdoing (talk) 20:26, 17 February 2014 (UTC)
bugzilla:23824? :) --AKlapper (WMF) (talk) 13:44, 14 February 2014 (UTC)
...but be aware it is very slow! Helder.wiki 14:27, 14 February 2014 (UTC)

Watchlist's "green bullet" (page updated since last visit) feature inaccessible

Note: this report refers to items contained in div class=mw-changeslist in the rendered document source for the Wikipedia Watchlist page.

in the second paragraph of the introductory text for the Wikipedia Watchlist -- immediately preceding the "Mark all pages as visited" button in the document's reading-order -- the following prose appears:

Pages that have been changed since you last visited them are shown with a green bullet.

this is a clear, obvious and inexcusable violation of the W3C's Web Content Accessibility Guidelines -- as well the Wikipedia Manual of Style as regards accessiblity, which is based upon WCAG -- by those who construct and vet the templates for Wikipedia... for details, please consult both the enumeration and explanation of specific problems contained in the next section, as well as:

problems posed by the use of the green button "feature"

  1. this information is conveyed using a purely visual indicator;
    1. due to the use of CSS to insert the green bullet into the page's visual rendering, there is no "alt" text (of any kind) available for those who cannot process images... this means that there is no programatic binding between the iconic "green bullet" and a textual equivalent for the icon which would enable a blind user's screen reader to say (for example) "changed", whenever the screen reader encounters the code that causes the bullet icon to be visually rendered, thereby making the visual indicator accessible to those who cannot perceive it;
  2. the choice of a color as the sole means of communicating essental information to the user; reliance on a color change to a universally recognized page element (a bullet), rather than the provision of a distinctive icon or a unique symbolic convention -- for which a programmatically determinable textual alternative can be defined -- to indicate to the watchlist's user that the page's content has been updated since the user's last visit...
    1. consider the obvious problem posed to color blind users; a.k.a. users with a "color vision deficiency" to use the current medical/scientific term for the range of conditions traditionally labelled "color-blindness"... the "greenness" of the bullet will not be perceptible to users with monochromacy (also known as "total color blindness"), achromatopsia and red-green color-blindness... additionally, users with tritanopia and tritanomaly experience great difficulty discriminating between blue and green hues and may not, therefore, perceive the "green bullet" as "green" -- a situation exacerbated by the fact that the default list-item-style for unordered lists in Wikipedia causes the rendering/generation of blue bullets
  3. there is no non-visually-dependent alternative mechanism to indicate changes to listed pages
    1. a universally accessible and useable indicator should be used to implement this feature; it should not rely on color alone to indicate the status of a watchlisted page...
    2. an image should not be used to convey information to users unless it can be programmatically bound to a textual equivalent for that image/icon/page element such as alt text or the ARIA property aria-label (or aria-labelledby, if an appropriate and unambiguous textual label which can be re-used to provide a textual equivalent for the image appears as text elsewhere in the document)... none of these solutions can be applied to graphics inserted into a document to provide a textual equivalent for images generated via list-style-image)

this "feature" needs to be re-engineered and replaced, either through the scripted -- rather than a CSS-generated -- insertion of an image into the document source to indicate that the listed item has changed since the user's last visit using the IMG/alt tandem, in order to provide a programmatic binding between the image and its textual equivalent, or by another non-modality-specific mechanism, such as the scripted insertion of a terse phrase, such as "changed"... note that the CSS content property, in conjunction with the CSS :before pseudo-element, cannot be used to insert a textual status update, as support for CSS-generated text varies greatly from browser to browser and browser version to browser version, and support for CSS-generated/inserted text by assistive technology (such as a screen-reader or refreshable braille display) is extremely poor, and therefore cannot be implemented as an accessible solution

WCAG 2.0 Reference on list-style-image

WCAG 2.0 CSS Technique C9: Using CSS to include decorative images, with special emphasis on the following quote's use of the terms "purely decorative images" and its final cautionary sentence:

The objective of this technique is to provide a mechanism to add purely decorative images and images used for visual formatting to Web content without requiring additional markup within the content. This makes it possible for assistive technologies to ignore the non-text content. Some user agents can ignore or turn off CSS at the user's request, so that background images included with CSS simply "disappear" and do not interfere with display settings such as enlarged fonts or high contrast settings.

Background images can be included with the following CSS properties:

  • background,
  • background-image,
  • content, combined with the :before and :after pseudo-elements,
  • list-style-image

Note: This technique is not appropriate for any image that conveys information or provides functionality, or for any image primarily intended to create a specific sensory experience.

oedipus (talk) 04:59, 16 February 2014 (UTC)

Special:Preferences#mw-prefsection-gadgets has this: "Display pages on your watchlist that have changed since your last visit in bold (see customizing watchlists for more options)" PrimeHunter (talk) 05:50, 16 February 2014 (UTC)
thanks for the pointer -- i was able to change my personal settings... however, the complaint stands, for the following reasons:
  1. the change from a clearly indicated font-style change to communicate the change in status to an exclusively visual indicator was applied to my account without my consent... moreover, the change from bold as an indicator to a green bullet without a textual equivalant occured without my knowledge... i don't even know when the change was put into effect because, as a screen reader user, when i use a resource such as wikipedia, on which so many pages have repetitive boilerplate information which one does not need to re-read every time one uses a frequently utilized resource such as the Watchlist, i did not hear -- and probably, if not for a series of coincidences, would not have heard -- the prose which i quoted: this is the impetus behind "skip navigation" and "skip to content" links... forcing a user re-read such boilerplate every time one uses such a frequently used resource, not only constitutes an "undue burden", but quickly drives one mad... i happened to hear it today because when a page loads, my screen reader is set to automatically start reading that page from the "beginning" in "document order" (it uses the DOM to navigate the page by structure and structure type) and today, when i loaded my Watchlist, the phone happened to ring... i was expecting an important call, and so i got up to get my phone, but the "squelch speech" command i quickly issued wasn't correctly processed by my screen reader, and so it began to read the page in its entirety and, consequently, i learned that changes were now indicated via the presence of an image which does not have a programmatic binding to a textual alternative, and, hence, creates a perceptual black hole...
  2. the green bullet "convention" now appears to be the default setting for the Watchlist -- an inaccessible option/feature should never be a default option/feature -- this needs to be changed;
  3. the average user -- especially the average user of assistive technology -- is not going to find the page to which you pointed me without the inclusion of a link to the Watchlist section of that preferences form in the explanatory prose quoted in the initial report -- that is a very large form to process aurally or tactilely... something along the following lines needs to be added to the deafault text quoted above:

    Pages that have been changed since you last visited them are shown with a green bullet. You can change the way that updated pages are displayed.

  4. even though this is an option that can be changed, why offer such an inaccessible option with serious usability problems for a number of user groups? and why is it necessary to use a CSS-capable user agent in order to obtain such critical information? neither indication method works if one does not have CSS support available or if one has CSS-support disabled or severely curtailed -- something which is not uncommon for those using screen readers and screen magnification... many assistive technologies offer simple methods to turn off or strictly curtail styling, especially author-defined/site-default styles, so as to provide a consistent and reliable HCI interaction experience... i personally quite often use text-based browsers (mainly, but not exclusively lynx and lynx32) to access wikipedia and related project pages -- it is far quicker, uses far fewer system resources than a new browser tab or instance... one cannot perceive either the font-weight change nor the CSS-defined colored bullet images when using a text-based or non-visual browser, whether one can perceive the image (and/or its color value) or not...

oedipus (talk) 07:37, 16 February 2014 (UTC)

The green bullet feature has been around for some nine months now. The earliest mentions on this page may now be found in Wikipedia:Village pump (technical)/Archive 112, but the earliest mention chronologically is not necessarily the first mention physically on that page. The archive contains several threads on the subject: but I can't find any comments by e.g. Graham87 (talk · contribs) or RexxS on the matter of the green bullets. The only mention of the green bullets at WT:WCAG is the note that you left earlier today (for which, thankyou). --Redrose64 (talk) 09:58, 16 February 2014 (UTC)
When bolding was enabled by default there were a lot of complaints at Wikipedia:Village pump (technical)/Archive 99#Watchlist - bold letter article titles! People wanted something less distracting. I think "You can change the way that updated pages are displayed" is too long to display every time the watchlist is viewed, and it only links to a long list of gadgets where one change can be made. I suggest just adding "(customize)" to MediaWiki:Wlheader-showupdated (that message either says in bold or with a green bullet depending on your gadget setting). PrimeHunter (talk) 12:51, 16 February 2014 (UTC)
The problem here is just TOO much information. The amount of information itself is an accessibility problem. The fact that users complain because this feature and have since 'hidden' it in yet another purely decorative indicator, tells us the same. I agree with the basic premise (accessibility has been one of my many areas of focus), but I don't see how we can satisfy everyone, with the current design and features of a watch list. As such I think that non essential features such as this one (it's not like we had in the first 12 years of wikipedia), are better off not being accessible to a small user group, rather then bothering lots of people. Should we strive to a better design ? I'd love to. Anyone have some ideas ? Anyone willing to fight the hoards of other users who will complain when we take the old design away ? It won't be me :D —TheDJ (talkcontribs) 12:51, 17 February 2014 (UTC)
I'm up to it. The problem is real estate. The watchlist (and history) can be partitioned much more efficient, at the cost of more required space. Problem is, it needs to be done in core, and I don't have a local copy running. Edokter (talk) — 13:09, 17 February 2014 (UTC)
The green bullet was the compromise solution arrived at after "the watchlist war" - one of the most vicious wiki-wars I had the misfortune to witness. It was really nasty, it makes the ructions around the VE rollout look like the proverbial Sunday-school picnic. Messing with it again is likely to cause much unhappiness. Roger (Dodger67) (talk) 14:40, 17 February 2014 (UTC)
I'm not entirely sure that this is actually a violation of the norms. The green bullet provides exactly the same information as the text that says "updated since my last visit", which you will find immediately after the edit summary and immediately before the (undo | thank) buttons on a page history. It is therefore not "the sole means of communicating essential information", although in some implementations, it's the sole means on the watchlist itself.
Having said that, and having been involved in the watchlist war (Roger's not exaggerating much about the nastiness), I still think that the English Wikipedia ought to offer the default MediaWiki formatting as the default, and let people who want other approaches take the responsibility for changing. But I doubt that anyone who was there is interested in doing that all over again. WhatamIdoing (talk) 21:06, 17 February 2014 (UTC)

Batch delete broken?

Resolved

I've never tried to batch delete before, but now I want to delete these pages per user request. I see a button for "d-batch" = "Delete pages found in this category/on this page" top left, but clicking it doesn't do anything". :-( Is the functionality broken? (The other button, "p-batch" for batch protection, seems to work all right.) How can I delete all those pages? Of course I could do them individually, but… heck, I'm supposed to be able to batch delete, right? Bishonen | talk 12:21, 16 February 2014 (UTC).

I tried to d-batch from the Special:PrefixIndex page, and it didn't work for me either. I don't know whether it's a bug or a feature. However, I copied the text from that page into Word, used search/replace to format them as [[User talk:XXX/XXX]] format, saved them back to my sandbox, and then d-batch worked fine on that. So d-batch either intentionally or unintentionally doesn't work on Special:PrefixIndex, but seems to work fine on normal pages. --Floquenbeam (talk) 18:51, 16 February 2014 (UTC)
Twinkle problem, the URL parameters aren't recognized correctly, would have worked with Special:PrefixIndex/User:Sam Korn. I'm looking into it ... Amalthea 19:25, 16 February 2014 (UTC)
Should be fixed, may need a browser cache refresh. Amalthea 19:30, 16 February 2014 (UTC)
Thanks for the workaround, Floq, with a special floral tribute because I could understand it, and thanks for the fix, Amalthea — I don't have to understand it, do I? Bishonen | talk 13:54, 17 February 2014 (UTC).

Last December, I suggested:

Articles with a Wikidata equivalent have a "Data item" link in the "Tools" menu. For other articles, it would be useful if a "Make data item" (or similar) link could be provided.

There was a brief discussion (thanks to User:Redrose64), but no solution was provided. Can we find one? Do I need to raise a Bugzilla ticket? Could someone provide a script, or gadget? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:20, 16 February 2014 (UTC)

I have d:User:Yair rand/WikidataInfo.js in my common.js file, but it's not in the tools menu, but under the page title. If the page is not in Wikidata it shows "Wikidata item not found" and has a link to create an item on Wikidata. --Stryn (talk) 21:32, 16 February 2014 (UTC)
Well did you file it in bugzilla or provided it as feedback to the WikiData team ? Otherwise things don't just start happening usually :D —TheDJ (talkcontribs) 12:44, 17 February 2014 (UTC)

Current

In my "contributions" there is an entry that is current (I checked the site's history as well), yet the word "current" is not present following my entry. Does any-one have an idea why? Here is the item: 2014-02-16T06:25:10 (diff | hist) . . (0)‎ . . List of Korean-language poets ‎ (→‎1910s: Changed dates for one poet, based on Wik article) (Tag: VisualEditor)Kdammers (talk) 02:46, 17 February 2014 (UTC)

Hmm. Suddenly it's there. Did my action here change it? Kdammers (talk) 02:49, 17 February 2014 (UTC)
Special:Contributions/Kdammers and the page history [76] both show me another edit [77] to the same page 6 minutes later. PrimeHunter (talk) 04:11, 17 February 2014 (UTC)

08:38, 17 February 2014 (UTC)

Tech news userboxes

As a sidenote to the weekly newsletter posted above, related userboxes are now available: See {{User wikipedia/Tech ambassador}} and {{User wikipedia/Tech news}}. guillom 09:49, 17 February 2014 (UTC)

fixing archive oddity

Currently there exist 2 archive pages of the "Talk:Transistor" page -- Talk:Transistor/archive and Talk:Transistor/Archive 1. Alas, the page Talk:Transistor only links to 1 of them.

What can I do to fix this? --DavidCary (talk) 19:19, 14 February 2014 (UTC)

 Done It looks like only the second of these was bot-created, the first being from manual archiving, so I moved Talk:Transistor/Archive 1 to Talk:Transistor/Archive 2 and Talk:Transistor/archive to Talk:Transistor/Archive 1 - this has got them into a consistent sequence; and then I made two cleanup edits. --Redrose64 (talk) 19:53, 14 February 2014 (UTC)
I went and checked the contributions of the person who created that archive to find out if they had made any other similarly misnamed archives. Due to the discrepancy between the number of bytes removed from the transistor talk page and the size of the archive (which can be accounted for by the move of some text from the main talk page to Talk:History of the transistor), I examined their archival edit to the main transistor talk page, and discovered that there was yet another missing archive at Talk:Transistor 1. It was later deleted as an orphaned talk page, so I've restored it and moved it to Talk:Transistor/Archive 1, necessitating yet another renumbering of the transistor talk page archives. Just letting you all know because this operation has broken most of the links in the above posts. Graham87 12:10/12:30, 15 February 2014 (UTC)
OK, I needed to make one more cleanup edit. --Redrose64 (talk) 14:35, 15 February 2014 (UTC)
Thank you, Redrose64 and thank you, Graham87, for going beyond what I pointed out and making it even better. That looks perfect. --DavidCary (talk) 03:23, 20 February 2014 (UTC)

Problem with subst-ing template multi-move

Hello.

I was trying to propose a multi-move at Talk:Alpine skiing at the 2014 Winter Olympics – Men's Super-G. When I subst-ed the multi-move template, I got an error message telling me that parameter current1 should be Alpine skiing at the 2014 Winter Olympics – Men's Super-G, and nothing else. It was; I copy-pasted it several times just to be sure. Finally, I had to empty the parameter – not remove it, as the error message suggested – and then it worked. Is there a bug somewhere? Does this have anything to do with the endashes in the article title? I tried to replace the endashes with &endash;, but it didn't help.

HandsomeFella (talk) 22:26, 16 February 2014 (UTC)

The documentation at {{Move-multi}} says:
See also Template talk:Move-multi#Current page? PrimeHunter (talk) 00:24, 17 February 2014 (UTC)
Ok, thanks. But this bug must have been "introduced" in some new release. I have proposed similar multi-moves before, for instance this one a year ago. There were no such problems then. Also, the error message should say that the parameter should be empty, not omitted. If I remember correctly, omitting the parameter didn't work properly.
HandsomeFella (talk) 07:06, 17 February 2014 (UTC)
I've just written Module:Move-multi, which fixes this bug and removes the 30-page limit. You can test it out using {{subst:move-multi/sandbox}}. Unless anyone spots any problems with it in the next day or so, I plan on replacing the existing template with it. — Mr. Stradivarius ♪ talk ♪ 13:44, 17 February 2014 (UTC)
Also, Wbm1058 will probably want to look at this, seeing as RMCD bot uses this template. I've kept the formatting very close to the current template, save from tweaking a couple of the error messages, so hopefully there won't be any issues. It can't hurt to have more people take a look at it, though. — Mr. Stradivarius ♪ talk ♪ 13:59, 17 February 2014 (UTC)
Omitted and empty current1 both work in my tests of the existing template version. The check of current1 was added in August 2012.[91]. Your example is from February 2013 but didn't trigger the bug because it had no apostrophe or other problematic character in current1. It used the pagename at the time and said current1=2008–09 Speed Skating World Cup/100 m Men. PrimeHunter (talk) 13:56, 17 February 2014 (UTC)
Geesh. The documentation says: Specification of parameter current1 is unnecessary and optional. I would really like to deprecate this parameter. My longer-term goal was to merge {{Move-multi}} into {{requested move}}, but the clunky coding to support 30 pages was impeding my plans. Lua-coding to support 30+ pages seems like a good idea. What I really want to do is make parameter {{{new1}}} an alternative way for specifying the unnamed parameter {{{1}}} of {{move}}. It will probably be some time before I take the time to learn Lua. I would rather see one module Module:Move that supports both {{move}} and {{move-multi}} rather than have redundant error-checking being done in two different languages which will be prone to logic-forking. I won't be supporting that. Someone should test by submitting some actual move requests using the sandbox template before turning it live. Wbm1058 (talk) 14:57, 17 February 2014 (UTC)
Interesting thoughts. None of that will be too hard to put in the current module - the hard work is done already. I'll have a go at adding it in now. — Mr. Stradivarius ♪ talk ♪ 15:16, 17 February 2014 (UTC)
I've now updated the module to handle {{requested move}}, and consequently I've renamed it to Module:Requested move. You can test out the new code with {{subst:requested move/sandbox}}. I've also had a new idea for the module, but VPT isn't really the place for it, so I've started a new thread at Template talk:Requested move#Lua conversion. — Mr. Stradivarius ♪ talk ♪ 16:01, 18 February 2014 (UTC)

Substituting inside includeonly tags

Is there a way to substitute templates and magic words inside <includeonly> tags, such as here (where the templates should have expanded to generate a sort key but didn't)? This archived discussion is about the same issue but doesn't give a solution. SiBr4 (talk) 21:54, 17 February 2014 (UTC)

If that's not possible, I think I'll have to avoid using includeonly and use tricks like this instead. SiBr4 (talk) 12:13, 18 February 2014 (UTC)

Here's one way to get it working: replace the initial <includeonly> tag with "{{subst:includeonly|". Replace the closing </includeonly> tag with "}}". Substitution will work normally between these. The {{subst:includeonly}} template itself expands back into regular <includeonly>...</includeonly> when you save. – PartTimeGnome (talk | contribs) 23:12, 18 February 2014 (UTC)
I tried that and it worked, so thank you. SiBr4 (talk) 12:25, 19 February 2014 (UTC)

iPhone search options not working

A few months ago I noticed that while typing items into the search box on the "web version" of Wikipedia that it no longer gives me a list of options from what I am typing. For example, before the problem, I would start typing the word "New" and I would get options like "New York" and "New Orleans" that I could click on instead of needing to type in the entire phrase.

I have experienced this on multiple iPhones, logged in and not, so I know it's not just me. This does not appear to be a problem with the iPad or with other mobile devices, only on the iPhone. Nor does it happen while using the "mobile version" of Wikipedia. It also does this on wifi and on the cell network.

With nearly half of all US smart phone users owning iPhones, this may be a problem that affects quite a few people. Any thought?JOJ Hutton 22:03, 17 February 2014 (UTC)

Confirming this. Search suggestions don't appear when using the Wikipedia desktop site in Safari on my iphone 4, although they do appear for the mobile site. — Mr. Stradivarius ♪ talk ♪ 12:37, 18 February 2014 (UTC)
This is intentional. iPhone and iPad are on the blacklist. I do remember that a while ago the blacklist wasn't working for a few months. If it's on the blacklist, then that is probably because it is broken in some versions of iOS. So to enable this feature, we would need to investigate from which Safari iOS version this feature works. —TheDJ (talkcontribs) 15:28, 18 February 2014 (UTC)

How do I retrieve a specific short sequence from Special:Contributions?

I can do it from a page history [92], but I want to list a user's contributions to this project over a specific period. Can I do that using Special:Contributions? --Anthonyhcole (talk · contribs · email) 06:53, 18 February 2014 (UTC)

You can indeed, and it has the exact same syntax as doing it from the page history. Just alter the "offset" and "limit" fields in the URL, like this. — Mr. Stradivarius ♪ talk ♪ 07:05, 18 February 2014 (UTC)
Thank you Mr Strad. --Anthonyhcole (talk · contribs · email) 15:00, 18 February 2014 (UTC)

An expert in mobile.css would be appreciated at Template talk:Redirect#Template not working on iphone. --Redrose64 (talk) 13:35, 18 February 2014 (UTC)

Fixed. —TheDJ (talkcontribs) 15:25, 18 February 2014 (UTC)

"Typography refresh" beta feature changes the appearance of TOC?

Somewhere higher on this page we learned that the "Typography refresh" beta feature no long changes the "max-width" of the content. However, it seems that now it does something else instead: it changes the appearance of "Table of content". To view it, go to any page with TOC, enable and disable this beta feature (Special:Preferences#mw-prefsection-betafeatures), and notice the change in TOC appearance.

It does not seem obvious why "Typography refresh" should change aspects of the UI and appearance which are not related to fonts. Maybe the name of this beta preference should change to "Page design improvements" or something, or, alternatively, maybe the "Typography refresh" project and team should just leave the page design alone, and concentrate on "Typography refresh". peace - קיפודנחש (aka kipod) (talk) 18:29, 18 February 2014 (UTC)

You can review the VectorBeta CSS here. And we get fat quotes on blockquotes. --  Gadget850 talk 00:52, 19 February 2014 (UTC)
"vectorbeta" makes sense. "Typography refresh" does not. inasmuch as there is a "vectorbeta" project, it should be marked as "vector beta", and this way it won't surprise those who enable it in their "beta" preferences. it's always a bad idea to call something one name while it means something completely different. it's deceiving, and it does not promote trust. if there is a project to revamp the UI, it should say so. my guess is that if this was marked "vector beta" in the first place, people would not make so much noise about the asinine decision to limit the width to 750px (or whatever it was). when you call something "Typography refresh", i think you should better limit what this something does to the vicinity of fonts. peace - קיפודנחש (aka kipod) (talk) 01:32, 19 February 2014 (UTC)
The discussion page for this (linked from the preference) is at mw:Talk:Typography Refresh. There is more discussion there about the TOC and more. TL;DR: I think you're probably right. Eventually just migrating the TOC and other changes to a "Vector beta" feature instead of "Typography Refresh" should be done. Repeating this feedback on the Talk page on mediawiki.org will help the UX designers hear that. ;) Steven Walling (WMF) • talk 01:34, 19 February 2014 (UTC)

Commons.js

Is this something new that I've missed? It seems I can put code into Special:MyPage/common.js now and the JavaScript will apply regardless of the skin I'm using or the browser modifications that I have, so long as JS is enabled. I thought it was the case that I originally had to specify the skin I'm using when putting JS code in, like Special:MyPage/vector.js or Special:MyPage/monobook.js. When did common.js make such practices obsolete? TeleComNasSprVen (talkcontribs) 09:54, 19 February 2014 (UTC)

It's not obsolete. Common.js applies to all skins, but you can still use skin-specific code in vector/monobook.js/css, which is especially usefull for CSS. But if you only use one skin, then just use common.js/css. Edokter (talk) — 12:11, 19 February 2014 (UTC)
It has been there for years. It's called "Shared CSS/JavaScript for all skins" at Special:Preferences#mw-prefsection-rendering. PrimeHunter (talk) 13:46, 19 February 2014 (UTC)
It was introduced three years ago with mw:MediaWiki 1.17 in February 2011 (the earliest mentions on this page are in Archive 87 of March 2011 but serious discussion doesn't occur until Archive 88); since then the links have been shown at Preferences → Appearance as "⧼prefs-common-css-js⧽ Custom CSS Custom JavaScript". More at bugzilla:10183. Please note that the file names begin "common", not "commons"; that is, the links are to Special:MyPage/common.css and Special:MyPage/common.js --Redrose64 (talk) 15:08, 19 February 2014 (UTC)
Since I can never remember the links, I created {{yourcss}} and {{yourjs}}. --  Gadget850 talk 01:14, 20 February 2014 (UTC)

Confusing error message

I was just asked why an article was giving the error message "Cite error: There are <ref> tags on this page, but the references will not show without a {{reflist}} template (see the help page)." I was told that the help page wasn't helpful. No wonder, since the error was simply a missing </ref>. Can this be fixed? It's pointing people in the wrong direction. Thanks. Dougweller (talk) 10:15, 19 February 2014 (UTC)

The example was [93]. The error message links to Help:Cite errors/Cite error refs without references which lists several possibilities including the one in the example:
  • Sometimes the reference list markup exists, but the message is shown because the <ref> tag immediately before the reference list markup does not have a closing </ref> or it is malformed, thus hiding the rest of the text in the article, including the reference list. If this is the case, find the last <ref> tag and ensure it is properly closed with </ref>.
I don't think it's possible for the software to distinguish between this and other possibilities, but maybe the help page could be improved. PrimeHunter (talk) 13:43, 19 February 2014 (UTC)
A bug (listed on the help page) has been open on this since 2009. And I am always open to improving this series of help pages. --  Gadget850 talk 00:52, 20 February 2014 (UTC)

Universal Language Selector will be enabled by default again on this wiki by 21 February 2014

On January 21 2014 the MediaWiki extension Universal Language Selector (ULS) was disabled on this wiki. A new preference was added for logged-in users to turn on ULS. This was done to prevent slow loading of pages due to ULS webfonts, a behaviour that had been observed by the Wikimedia Technical Operations team on some wikis.

We are now ready to enable ULS again. The temporary preference to enable ULS will be removed. A new checkbox has been added to the Language Panel to enable/disable font delivery. This will be unchecked by default for this wiki, but can be selected at any time by the users to enable webfonts. This is an interim solution while we improve the feature of webfonts delivery.

You can read the announcement and the development plan for more information. Apologies for writing this message only in English. Thank you. Runa —Preceding undated comment added 12:30, 19 February 2014 (UTC)

This means that most of ULS will come back soon, but webfonts (is anyone here looking for OpenDyslexic?) will need to specifically be enabled by each user. Whatamidoing (WMF) (talk) 18:21, 19 February 2014 (UTC)

Babel categories

Please can editors familiar with the Wikipedia:Babel comment at Template talk:Babel#Capitalisation_of_categories?

I have been trying to sort of the capitalisation of some categories, but have realised that the issues are a little more complex than first appeared. --BrownHairedGirl (talk) • (contribs) 08:14, 20 February 2014 (UTC)

Disable sortability in selected wikitable columns

Is there a way to disable the sortability on selected columns in wikitables? If so, how? Thanks, Rehman 12:38, 20 February 2014 (UTC)

A considerable amount of information about setting up sorting in tables is available at Help:Sorting. Your specific question is covered at Help:Sorting#Making a column unsortable, which has an example. You define the column as class="unsortable". Makyen (talk) 13:18, 20 February 2014 (UTC)
Thanks a lot! I looked all over the "Wikipedia:" prefix and forgot about the "Help:" pages. Best regards, Rehman 13:50, 20 February 2014 (UTC)

Math aligned environments failing to parse

There's a bug being discussed at Wikipedia talk:WikiProject Mathematics#Problem with multiline equations. The "aligned" and "alignedat" environments are failing to parse. Affected articles include Spherical trigonometry#Polar triangles and 1 + 2 + 3 + 4 + ⋯#Heuristics. Here's an example:

I see the output Failed to parse(unknown function '\begin'): {\begin{alignedat}{3}A'&=\pi -a,&\qquad B'&=\pi -b,&\qquad C'&=\pi -c,\\a'&=\pi -A,&b'&=\pi -B,&c'&=\pi -C.\end{alignedat}}

Can anyone here help? Thanks, Melchoir (talk) 02:05, 7 February 2014 (UTC)

Oh, and I should mention that this was working yesterday! Melchoir (talk) 02:14, 7 February 2014 (UTC)

I am seeing this at Triple product#Using geometric algebra, which was working when I edited it on 21 January. Similarly it's complaining about the align directive:
Failed to parse(unknown function '\begin'): {\begin{aligned}{\mathbf ...
--JohnBlackburnewordsdeeds 02:30, 7 February 2014 (UTC)
See also a similar question above. Graham87 04:20, 7 February 2014 (UTC)

There are some more examples, which helpfully list the TeX source, at Help:Displaying a formula. Also experienced a few timeout/too many people accessing the page errors accessing that and Noether's theorem, another problem page.--JohnBlackburnewordsdeeds 14:17, 7 February 2014 (UTC)

This has also been reported to OTRS, see Steradian for example.--ukexpat (talk) 15:19, 7 February 2014 (UTC)
Sorry, I'm not really sure what that means... Is anyone working on this issue? Melchoir (talk) 19:00, 7 February 2014 (UTC)

This seriously undermines the functionality of Wikipedia's mathematics articles. It needs to be fixed right away, even if that means undoing the recent upgrade. Sławomir Biały (talk) 20:08, 7 February 2014 (UTC)

I see red everywhere I go on WP today - and also botched attempts to fix the affected formulae. Where can I go to usefully complain about this? --catslash (talk) 23:23, 7 February 2014 (UTC)

This week's update of the Math extension had some weirdness, but it was reverted - which means the Math extension here should be running the same version as last week. bugzilla:60997 is the tracking bug for the issues. Legoktm (talk) 23:51, 7 February 2014 (UTC)

I'm unclear what you mean. You mean it was broken but was reverted so should be back to normal/how it was a week ago? It's still broken on the many pages linked here and in the example above. Or do we have to wait for this to be rolled out/propagated?--JohnBlackburnewordsdeeds 00:12, 8 February 2014 (UTC)

This has to be fixed quickly. Almost all of the articles that display mathematical equations have been showing this error. Formulas and equations are definitely the most important things that people are looking for in articles about Math and science.  [ Derek Leung | LM ] 00:17, 8 February 2014 (UTC)

  • Use {array} columns or colon-indent to align: Hopefully, the source of the problems with "{alignedat}" can be pinpointed and corrected, but meanwhile, the "{array}" alignment works (such as with 6-el "{llllll}" for 6 columns separated by "&"), as follows:
      :: <math> 
      \begin{array}{llllll}
      A' &= \pi - a ,  \qquad & B' &= \pi - b ,\qquad& C' &= \pi - c ,\\
      a' &= \pi - A ,         & b' &= \pi - B ,      & c' &= \pi - C .
      \end{array}
      </math>
That math-tag will show alignment into 6 columns:
Each qquad spacer "\qquad &" should end with an "&" separator, and with that then the various math articles can be fixed, as well as other issues copy-edited, to format correctly. -Wikid77 (talk) 03:42, 8 February 2014 (UTC)
That's a very bad idea. Align works as it's an easy and natural addition to a block of formulae: the directives at beginning and end and then '&=' and '//' where you want things aligned and lines broken within. Using arrays like that is overkill. But more importantly the articles aren't broken: the Mediawiki software is. The solution is to get that fixed as soon as possible, not edit articles just to revert then hours or days later. Anyone who needs to work with such formulae in the (hopefully very short) interim can enable MathJax which doesn't have this problem.--JohnBlackburnewordsdeeds 03:54, 8 February 2014 (UTC)
Using the "{array}" alignment is already done for other equations in those math articles, and is not "overkill" by any means. Telling users here to "enable MathJax" does not fix the red-error parser messages which hundreds of users see in major math articles such as "Integral". Also, there is no need to revert use of "{array}" alignment as it is already used in many articles. -Wikid77 07:17, 8 February 2014 (UTC)
@Wikid77: As long as you continue to damage the formatting on mathematics articles in this way I will continue to revert you. Ozob (talk) 06:08, 8 February 2014 (UTC)
Calling the copy-editing of math articles as "damage" still does not permit a violation of wp:3RR by reverting the re-aligned formulas to, once again, display parser errors such as the glaring "Failed to parse(unknown function '\begin'): {\begin{alignedat}{3}". The copy-editing of those articles should not be reverted to emphasize a wp:POINT about problems with math-tag formatting. Let other users edit those math pages to improve the formats. -Wikid77 07:17, 8 February 2014 (UTC)
As of yet none of the editors in this discussion have violated WP:3RR. Ozob made two reverts each to Integral and Spherical trigonometry. The 3RR rule only counts reverts within the same article. – PartTimeGnome (talk | contribs) 18:01, 8 February 2014 (UTC)
I didn't realise that Wikid77 was going ahead with this. Seconded. I've reverted other editors already who've tried 'fixing' articles not realising the problem was with Mediawiki. But anyone who's read the thread here or at the maths project should be perfectly clear where the problem lies and so should not be 'fixing' the articles which aren't broken.--JohnBlackburnewordsdeeds 06:27, 8 February 2014 (UTC)
The main goal is to fix the equation-formatting problems wherever they are displayed, rather than blame the math-tag software as an excuse to leave broken equations in major articles, for 3 days. -Wikid77 07:17, 8 February, 12:17, 10 February 2014 (UTC)
They will fix themselves once the fix in MediaWiki has been backported. It is futile to fix all errors by hand. Edokter (talk) — 10:57, 8 February 2014 (UTC)
Wikid77 has raised this issue at Wikipedia:Administrators' noticeboard/Archive259#Reverting fixes of equations. – PartTimeGnome (talk | contribs) 18:01, 8 February 2014 (UTC)

While some choose to bicker over the short-term management of this problem, I would prefer to look at the underlying issue. How is that a change to the software that supports mathematics articles can be made which breaks a significant number of them without that fact being noticed, or fixed before it is deployed? Why is it that mathematics editors at such places at Wikipedia:WikiProject Mathematics, who may be assumed to have between them a considerable degree of expertise and experience in these matters, are not consulted, or even informed about these changes? There appear to have been failures at a number of levels over this matter. Deltahedron (talk) 12:06, 8 February 2014 (UTC)

Many math experts used MathJax format and did not see the error messages viewed by thousands of people. -Wikid77 12:17, 10 February 2014 (UTC)
You raise a good point. I don't know the details, but expect that there is some set of automated tests the programmers use to test changes to the Mediawiki software. It is apparent that the automated latex test suite is not comprehensive. Part of the problem is that this is only broken for folks not using MathJax--perhaps not all branches are tested automatically? This particular change was meant to be transparent to the user, which is likely why it was not mentioned at WP Math. It is not the first time in the past year that we have had latex rendering issues, so it seems a problem area for Mediawiki. --Mark viking (talk) 17:32, 8 February 2014 (UTC)
All MediaWiki seems to be "problem areas" and rebroken many times; the only reason why #switch or #ifeq still work is they remain "non-improved" but there is talk to "rewrite the parser" as NewPP is likely a hodge-podge of software subsystems. Rather than blame the developers, we need to know "Top 100 math articles" to watch/rescue, and then notice how Polynomial, Calculus, Derivative, Integral, Sine, Complex number (etc.) were all broken, to be quick-fixed (same-day) not bicker for 3 days whether altered alignment is worse than a glaring red-error message. Meanwhile "wp:Equation hoarding" has overcomplified the major math pages, where most of the botched equations should have been in minor subpages, not excessive wp:UNDUE detail in major pages viewed 2x per minute. The page "Sine" should be kept minimal with links to subpages such as "Polynomial equivalents of sine" and then put Taylor series formulas (+Lagrange polynomials +others) on the subpages. -Wikid77 12:17, 10 February 2014 (UTC)
See Wikipedia:WikiProject_Mathematics/Popular_pages for the "Top 100 math articles" to watch/rescue.--Salix alba (talk): 12:57, 10 February 2014 (UTC)

Problems with math rendering

As of 7-Feb-2014 there seems to be a problem with math rendering.

Referring to Preferences, Appearance, Math, options "Always render PNG", and "MathJax (experimental; best for most browsers)", the following used to work in PNG and in MathJax. Now it doesn't work in PNG anymore, producing an error "Failed to parse(unknown function '\begin'): {\begin{aligned}...", but it still works in MathJax, although the formular are now centered on the page:

In article Complex number:

In article Polynomial:

Attempts were made to "correct" the faulting aligns; [94], [95], [96], [97].

Other changes were made, for instance this one to Maxwell's equations.

The following render correctly (no problems in PNG) but in MathJax some equations get centered on the page, whereas other remain left aligned and are properly indented:

When text is added after the math tags, there is no centering:

(text)

(text)

(text)
(text)
(text)
(text)

What's up? - DVdm (talk) 10:49, 8 February 2014 (UTC)

The first problem is being discussed above, at #Math aligned environments failing to parse. I am not sure if the other alignment inconsistencies are related or not. —PC-XT+ 11:18, 8 February 2014 (UTC)
They are; all math related problems started to happen when they took out a large chuck of math code from core in the assumption that the Math extension could handle it. Turns out it can't because the core code did a lot of converting before feeding it to the extension. Without this converting, the extension is now being fed invalid code, hence the errors. Edokter (talk) — 11:26, 8 February 2014 (UTC)
Thanks for the replies. Let's hope this gets fixed before too many math articles get—sort of —damaged by well-meaning authors. Shouldn't some kind of watchlist announcement be put in place? - DVdm (talk) 12:10, 8 February 2014 (UTC)
@Edokter: That's not a correct assessment of the situation. The Math extension has been handling the rendering since about 2011. There were several issues with the most recent update; the code removed from core did not cause the issue with rendering various formulas (it did cause some site performance issues). The problem behind the rendering is that when the "transformation and validation" code was separated from the "render PNG" code so that validation could be used for MathJax as well (T51169), it was overlooked that the output of the validator isn't accepted as input to the renderer (which still contains all the same transformation and validation code). Anomie 14:35, 8 February 2014 (UTC)
Oh well, that was my quick assesment of the situation browsing through the bugs. BTW, why is bug 49169 hidden? Edokter (talk) — 14:46, 8 February 2014 (UTC)

Math parsing Error

At Real_projective_line#Motivation_for_arithmetic_operations I get this error:

Failed to parse(unknown function '\begin'): {\begin{aligned}\\a+\infty =\infty +a&=\infty ,&a\in {\mathbb {R}}\\a-\infty =\infty -a&=\infty ,&a\in {\mathbb {R}}\\a\cdot \infty =\infty \cdot a&=\infty ,&a\in {\mathbb {R}},a\neq 0\\\infty \cdot \infty &=\infty \\{\frac {a}{\infty }}&=0,&a\in {\mathbb {R}}\\{\frac {\infty }{a}}&=\infty ,&a\in {\mathbb {R}},a\neq 0\\{\frac {a}{0}}&=\infty ,&a\in {\mathbb {R}},a\neq 0\end{aligned}}

Can someone fix it please. I am not sure what else I should tell you, so feel free to ask. TheKing44 (talk) 19:27, 8 February 2014 (UTC)

Yes, see all over the place. I made the same mistake, creating a section about something already well under discussion - DVdm (talk) 19:16, 8 February 2014 (UTC)
I've backported and deployed a Math syntax check fix. It should be less broken now (which seems to be the case). Aaron Schulz 21:08, 8 February 2014 (UTC)
Yes, it seems to be fixed. Thanks!

The strange indending/centering behaviour in MathJax remains though—see two threads higher at #Problems with math rendering. Any idea about that? DVdm (talk) 21:31, 8 February 2014 (UTC)

This is discussed at Wikipedia talk:WikiProject Mathematics#Displayed equations are centered?. It might be due to a change in the MathJax from version 2.2 to version 2.3. There is a bug at T63051.--Salix alba (talk): 00:42, 9 February 2014 (UTC)

Broken math markup at Great-circle navigation

The article Great-circle navigation includes some mathematical formulae, which are displayed using <math>...</math> tags.

However, something is broken, and the display just consists of red error messages. Can anyone fix it? --BrownHairedGirl (talk) • (contribs) 01:14, 9 February 2014 (UTC)

That was probably related to the issues reported above. A purge fixed it. Matma Rex talk 01:18, 9 February 2014 (UTC)
So are 0.999... and every single article that contains \begin{align}...  [ Derek Leung | LM ] 01:28, 9 February 2014 (UTC)
 Done Thanks, looks good now. --BrownHairedGirl (talk) • (contribs) 04:43, 9 February 2014 (UTC)

Fixed but slow

Although it's now rendering properly it's so slow it's causing serious problems. See Wikipedia talk:WikiProject Mathematics#Performance problems.--JohnBlackburnewordsdeeds 07:06, 9 February 2014 (UTC)

There's still at least one page that still isn't working. Jestingrabbit (talk) 07:25, 9 February 2014 (UTC)
It loaded for me (though it took 33 seconds) and looks fine.--JohnBlackburnewordsdeeds 08:02, 9 February 2014 (UTC)
Editing is extremely slow. Just made this edit. It took a few minutes between Save page and a "504 Gateway Time-out". The same thing happened with the preceding edit earlier. I estimate that it took as much as 5 minutes. Math editing has become virtually impossible. - DVdm (talk) 11:24, 9 February 2014 (UTC)
@DVdm: I think it's a known issue, Aaron and Physikerwelt were investigating it on IRC yesterday. Stay tuned :) Matma Rex talk 11:38, 9 February 2014 (UTC)
Confirmed math-tag cache speed double 2x, similar now to Simple WP, where new equations edit-preview 2x faster than before (124 math-tags in 42 seconds, formerly 92 sec.) and then will re-display from cache within a few seconds. -Wikid77 08:01, 15 February 2014 (UTC)

Failure to Parse Mathematical Formulas

The \begin{aligned} command seems to fail in many pages, such as these:

Maximum entropy classifier

Positive-definite matrix

The matter is of some urgency as there are many pages with matrix algebra and these seem affected. Limit-theorem (talk) 14:04, 9 February 2014 (UTC)

Please see previous threads. --Redrose64 (talk) 14:06, 9 February 2014 (UTC)
Both pages are now fine. I guess someone purged them. The underlying software bug is fixed, so any pages still showing this error are from cache and can be fixed with a purge. Per the first point in the Village pump (technical) FAQ, if something looks wrong, a purge is the first thing to try. – PartTimeGnome (talk | contribs) 22:31, 9 February 2014 (UTC)

Purge-refresh major math pages

People should continue to wp:purge-refresh the major math pages (with "?action=purge"), which have lagged in reformatting the 3-day mathtag glitch, even though the math-tag '{align}' problem was fixed over 24 hours earlier, on Saturday c.21:00, 8 February 2014. I had to purge the following: Calculus, Derivative, Integral, Sine, Fast Fourier transform, Completing the square, System of linear equations, Quadratic integral, etc. Others have purged: Complex number, Polynomial, Quadratic formula, Great-circle navigation, Maximum entropy classifier, etc. Many had pageviews 1,000-3,000 per day. The typical page uses 'begin{aligned}' to force equations at '=' into alignment. I posted a similar note at User_talk:Jimbo_Wales, viewed 1,000 per day. -Wikid77 00:58/12:17, 10 February 2014 (UTC)

I just purged Level set method which was showing "Failed to parse(unknown error)" for the <math>\varphi</math> in "The boundary of the shape is then the zero level set of " and for the same markup later in the section at " is represented as the zero level set of " - in both cases without the align environment (if I've understood things correctly). I don't know if this is significant, but this seems a vaguely appropriate place to report it. --Mrow84 (talk) 18:13, 10 February 2014 (UTC)
That's fine... what we'd really like to know about is pages where a WP:PURGE didn't fix the problem. --Redrose64 (talk) 19:40, 10 February 2014 (UTC)
Example? — {{U|Technical 13}} (tec) 20:27, 10 February 2014 (UTC)
I don't know of any, that's the point. Are there any left out there? --Redrose64 (talk) 22:12, 10 February 2014 (UTC)
I first saw a "parse" problem on Cosine similarity a few minutes ago; there's no error message; just the display
 complement in positive space, that is: $ D_{C}(A,B)=1-S_{C}(A,B) $. It is important
Purging doesn't seem to work. Also on Level set method which fails on en but works on de.
SBaker43 (talk) 12:18, 12 February 2014 (UTC)
These both look OK to me; try a WP:BYPASS. --Redrose64 (talk) 13:18, 12 February 2014 (UTC)
This is what you see if you have MathJax enabled in preferences, but your browser does not support MathJax (e.g. JavaScript is disabled). It probably works on the German Wikipedia because you don't have MathJax enabled there. Other possibilities are problems with a user script or gadget preventing MathJax from working correctly, or a server problem preventing the MathJax scripts loading from bits.wikimedia.org. (The latter is unlikely; we normally have a lot more people complaining when bits goes down.) – PartTimeGnome (talk | contribs) 23:03, 12 February 2014 (UTC)

Side question

Does mediawiki throw pages with these types of errors into a tracking category? Werieth (talk) 21:06, 10 February 2014 (UTC)

Ping AKlapper (WMF) Steven (WMF) Werieth (talk) 13:35, 12 February 2014 (UTC)
Not that I'm aware of. Steven Walling (WMF) • talk 17:27, 12 February 2014 (UTC)
If mediawiki doesnt we should have it do so. It would enable us to not only find pages that need purged, but in general identify pages with broken math syntax. Werieth (talk) 21:50, 12 February 2014 (UTC)

Status?

Looking at article Summation in MathJax, it is clear that there still is a serious problem. All equations are centered except those that have text added. Using \text{} to move the text inside the math tags is no solution as wikimarkup doesn't work that way.

with text added and centering fails and wp:wikilinks work

What is the status now? - DVdm (talk) 09:52, 21 February 2014 (UTC)

Note - Look what people are doing now, due to this problem. - DVdm (talk) 12:54, 21 February 2014 (UTC)

Another editor has fixed it, it appears. – Jonesey95 (talk) 12:59, 21 February 2014 (UTC)
I don't see how it is fixed. Please look with option MathJax at the above three equations. Two are centered, one is not. - DVdm (talk) 13:47, 21 February 2014 (UTC)

Why is rendering math so slow?

I don't know if this is a result of the MathJax update itself or already was an issue before, but I realized that rendering math on this very page is extremely slow. On my Notebook it's so bad that on a first page load it completely locks up Firefox for about 5-10 seconds and throws an "unresponding script" warning. Strange part is that I copied this whole section regarding math into a test page in my userspace where it renders much faster without locking Firefox.

Does anybody else experience something similar? Is there an explanation why it's rendering faster in my user page? Might this even indicate a potential performance issue regarding MathJax? In my opinion math shouln't render slower if there is other content on the page, but maybe the implementation details of the Math extension are responsible for the observed behavior. --Patrick87 (talk) 13:13, 22 February 2014 (UTC)

Wikipedia:Help desk/Archives/2014 February 10 and Wikipedia:Help desk/Archives/2014 February 11 are both linking to the Current Help Desk, even though there is at least one page already archived between each of those and the first page that, while archived, is still transcluded.— Vchimpanzee · talk · contributions · 20:58, 17 February 2014 (UTC)

No response, but the problem appears to be fixed.— Vchimpanzee · talk · contributions · 21:56, 17 February 2014 (UTC)
Next time you see this problem, try purging the page and it should come right. -- John of Reading (talk) 07:18, 18 February 2014 (UTC)
I've been given this advice before. I actually tried it today with a red link and it turned purple. Thanks.— Vchimpanzee · talk · contributions · 22:01, 21 February 2014 (UTC)

Raw LilyPond score problem

Hello everyone!

I have a big problem with translating File:Bach-raison-passacaglias.gif to LilyPond markup in <score> tag, provided in mw:Extension:Score. I try to use all features of LilyPond by enabling {{{raw}}} param, however I get:


\score {
  \new Staff \relative g, {
    \clef bass
    \key g \major
    \repeat unfold 2 { g16( d' b') a b d, b' d, } |
    \repeat unfold 2 { g,16( e' c') b c e, c' e, } |
  }
}

\score {
  \new Staff \relative b {
    \clef bass
    \key g \major
    \partial 16 b16 |
    <g, d' b'~>4 b'16 a( g fis) g( d e fis) g( a b c) |
    d16( b g fis) g( e d c) b(c d e) fis( g a b) |
  }
}

I don't understand, I even disabled MIDI file generation (which is disabled by default).

Here's my code:

<score lang="lilypond" raw="1" midi="0">
\score {
  \new Staff \relative g, {
    \clef bass
    \key g \major
    \repeat unfold 2 { g16( d' b') a b d, b' d, } |
    \repeat unfold 2 { g,16( e' c') b c e, c' e, } |
  }
}
\score {
  \new Staff \relative b {
    \clef bass
    \key g \major
    \partial 16 b16 |
    <g, d' b'~>4 b'16 a( g fis) g( d e fis) g( a b c) |
    d16( b g fis) g( e d c) b(c d e) fis( g a b) |
  }
}
</score>

Thanks in advance for help. --Rezonansowy (talkcontribs) 18:27, 19 February 2014 (UTC)

I can get it to work with the following changes: (i) omit the raw="1" (ii) remove the second \score { and the } immediately preceding (iii) alter the first \score { to << (iv) alter the last } to >> --Redrose64 (talk) 19:52, 19 February 2014 (UTC)
Could you post your code here please? --Rezonansowy (talkcontribs) 20:29, 19 February 2014 (UTC)
<score lang="lilypond" midi="0">
<<
  \new Staff \relative g, {
    \clef bass
    \key g \major
    \repeat unfold 2 { g16( d' b') a b d, b' d, } |
    \repeat unfold 2 { g,16( e' c') b c e, c' e, } |
  }
  \new Staff \relative b {
    \clef bass
    \key g \major
    \partial 16 b16 |
    <g, d' b'~>4 b'16 a( g fis) g( d e fis) g( a b c) |
    d16( b g fis) g( e d c) b(c d e) fis( g a b) |
  }
>>
</score>
which gives

<<
  \new Staff \relative g, {
    \clef bass
    \key g \major
    \repeat unfold 2 { g16( d' b') a b d, b' d, } |
    \repeat unfold 2 { g,16( e' c') b c e, c' e, } |
  }
  \new Staff \relative b {
    \clef bass
    \key g \major
    \partial 16 b16 |
    <g, d' b'~>4 b'16 a( g fis) g( d e fis) g( a b c) |
    d16( b g fis) g( e d c) b(c d e) fis( g a b) |
  }
>>
--Redrose64 (talk) 21:28, 19 February 2014 (UTC)
Thank you, but your output is a little different than expected above. See the first example which uses \score param, so full LilyPond markup is needed. --Rezonansowy (talkcontribs) 22:11, 19 February 2014 (UTC)
I don't know. The extension was written by GrafZahl (talk · contribs) who is probably a much better person to ask. --Redrose64 (talk) 23:21, 19 February 2014 (UTC)
The thing I'm most confused about here is that Rezonansowy's code is producing output completely different from File:Bach-raison-passacaglias.gif: different time signature, different key signature, different number of parts... Rezonansowy, did you link to the wrong file? — Mr. Stradivarius ♪ talk ♪ 03:38, 20 February 2014 (UTC)
@Mr. Stradivarius: No, this code is taken from LilyPond free documentation, I only have to change notes. But the problem occurs when I use {{{\score}}} form full LilyPond functionality, it supported (see its doc) by setting {{{raw}}} to 1, but I get error about MIDI, even if I disable MIDI generation. --Rezonansowy (talkcontribs) 12:45, 20 February 2014 (UTC)
It appears that the MIDI file is generated and expected even if 'midi="0"' is passed in the tag (and actually, it appears that's the default). If you're doing raw lilypond, you need to include \layout and \midi so a PNG and a MIDI file get output for MediaWiki to find, and you'll probably also want a \header too to keep it from making a full-page image. Something like this:

 \header {
     tagline = ##f
 }
 
 \score {
   \new Staff \relative g, {
     \clef bass
     \key g \major
     \repeat unfold 2 { g16( d' b') a b d, b' d, } |
     \repeat unfold 2 { g,16( e' c') b c e, c' e, } |
   }
   \layout {}
   \midi {}
 }

 \score {
   \new Staff \relative b {
     \clef bass
     \key g \major
     \partial 16 b16 |
     <g, d' b'~>4 b'16 a( g fis) g( d e fis) g( a b c) |
     d16( b g fis) g( e d c) b(c d e) fis( g a b) |
   }
   \layout {}
   \midi {}
 }
HTH. Anomie 22:41, 20 February 2014 (UTC)
Thank you --Rezonansowy (talkcontribs) 17:46, 21 February 2014 (UTC)
Resolved

On Meta, an RfC has been opened to discuss whether c: should be added as an interwiki link prefix for Commons. The RfC was originally run in 2011 and met a positive response, but was not well-attended. Following concerns of some editors here that it was insufficient to demonstrate broad consensus across projects for the feature, it has now been reopened to attract more discussion.

A related discussion is underway at RfD regarding several existing redirects beginning with "C:" that could clash with this development if cross-project consensus is found for its implementation. — Scott talk 22:44, 19 February 2014 (UTC)

all the shortcuts using "C:" to refer to "Category:" will need to be deleted first... -- 70.50.151.11 (talk) 05:02, 20 February 2014 (UTC)
  • Will all of the articles that start with that be deleted too? Special:PrefixIndex/C: suggests there are nine non-category uses of "C:" and two of them are actual articles of which there is no appropriate alternate location. Also, hi: (hindi) Wikipedia uses C: as a category alias, and many other wiki's have articles that legitimately start with "C:". I've noted this on the discussion on meta, on the Bugzilla ticket, on the Gerrit patch (which is a hack to make it happen because the software apparently doesn't like the change either) and as such. 70.50.151.11 (talk · contribs · WHOIS), I suggest you make your comments at one of those places. — {{U|Technical 13}} (tec) 05:44, 20 February 2014 (UTC)
    m:IWM is fine alternative to patch if you want. Hiwiki agreed to remove it, see gerrit:113656 and bug. I even generated list of pages on all wikis. I think I know what I'm doing, so please AGF. πr2 (tc) 16:35, 20 February 2014 (UTC)
    • Yes, Technical 13, discussion is already happening at those venues. Please do not start another discussion here. English Wikipedia-specific concerns need to be raised in the wider context of the RfC, as this is a cross-project proposal. — Scott talk 16:48, 20 February 2014 (UTC)
  • Scott, I'm telling the IP that this isn't the place for discussion and pointing them to the other, existing venues and your scolding me telling me not to start another discussion here? I'm sorry, but I just don't get that... wow... — {{U|Technical 13}} (tec) 17:07, 20 February 2014 (UTC)
Everything you said before I suggest you make your comments at one of those places, starting with a question, was discussion. Repeating your opinion (and asking additional questions) in a variety of different places outside the primary venues is not helpful to keeping this process on track. — Scott talk 17:23, 20 February 2014 (UTC)
  • I disagree that it was "discussion". It was, in my mind, more of a prelude. "Things to think about when you make your comments on one of the existing discussions" It's why I specifically ended my post with, I suggest you make your comments at one of those places, so that there would be no response here. If you want people to comment on other forums, you need to tell them what they are commenting on, and why they should repeat themselves there. It's also useful to point out some of the things already being discussed. Any-who, I'm done here and I really don't care if you have the LASTWORD, or if you are SPIDERMAN... — {{U|Technical 13}} (tec) 17:38, 20 February 2014 (UTC)
    Suggesting things for someone to think about when directing them to a discussion sounds a bit like canvassing to me... The opening comment to this discussion was all the prelude necessary. All you needed to add was "Also being discussed at X, Y and Z.". – PartTimeGnome (talk | contribs) 22:19, 20 February 2014 (UTC)

Importing some images

I'm pretty sure the images on this page are in the public domain by this time, and I'd like to use them to illustrate the article on billet reading. I'm at a loss how to extract them though. Normally I simply Copy and Paste into "Preview", but that doesn't work in this case. Can someone extract these for me? Maury Markowitz (talk) 15:14, 20 February 2014 (UTC)

I don't know how to extract them directly but you could make a screenshot. If you have Windows then you probably have Snipping Tool in a menu somewhere. PrimeHunter (talk) 21:11, 20 February 2014 (UTC)
At least on Windows, images from sections of the page can be easily copied by downloading the PDF file and opening it using Adobe Reader (I only tested on version XI, but other versions have worked previously). You can left click to select the sub-image you desire, then right click, or Ctrl-C, to copy the image to the clipboard. It can then be pasted into a image viewer/editor (e.g. irfanview). Makyen (talk) 00:08, 21 February 2014 (UTC)

Quick request

Would anyone be able to fix what I clearly messed up in this sandbox? As part of changing the links to a more reliable page (labs), the whole template needs reformatting, so if anyone could fix my mistake(s), that would be great, as it really shouldn't amount to much. Kevin Rutherford (talk) 21:13, 20 February 2014 (UTC)

Each of the {{#if}} parser functions used for the "quick check" links was missing two closing brackets, which caused the entire message box to break. I think I've fixed that with this edit. Could you check whether the template now behaves like it should? SiBr4 (talk) 21:50, 20 February 2014 (UTC)
It looks awesome, so thanks for the help! Kevin Rutherford (talk) 05:42, 21 February 2014 (UTC)

Why doesn't it leave redirects from .js pages on rename?

I just renamed @Gary King: and it didn't leave redirects from his .js pages and the like. Is that intended behaviour, and isn't that going to break a lot of user scripts? (e.g. User:Gary King/comments in local time.js) –xenotalk 22:35, 20 February 2014 (UTC)

I don't think redirects work on .js pages. And yeah, that's gonna break some userscripts. Writ Keeper  22:40, 20 February 2014 (UTC)
Redirects don't work on .js pages, so MediaWiki doesn't try to create them (anymore?). The scripts would be broken either way. Anomie 22:44, 20 February 2014 (UTC)
Okay, thank you. –xenotalk 22:53, 20 February 2014 (UTC)
  • Xeno, that is not Gary's userspace anymore and he will not have access to that userjs as he is not an administrator (according to his user page). An admin will need to put that there, perhaps Redrose64 would be so kind? — {{U|Technical 13}} (tec) 02:38, 21 February 2014 (UTC)
  • Well, global account Gary King persists and I'm sure en Gary King will be back shortly as an autocreate while Gary migrates himself globally, so he should be able to create them from that alternate account (there's a lot more than just the example). –xenotalk 03:16, 21 February 2014 (UTC)
(edit conflict) A #REDIRECT [[...]] on a .js page has not worked to redirect a link for at least as long as I've been aware that the possibility existed - over four years. Quite simply, the #REDIRECT is not a valid javascript statement. This is why an admin who moves a .js page should deselect "Leave a redirect behind". If you want to simulate a redirect, use importscript as noted above. --Redrose64 (talk) 23:35, 20 February 2014 (UTC)
MediaWiki:Movepagetext-noredirectfixer displays the same redirect claim for .js moves as other moves. Maybe we should add a pagename check and display a correct message for .js and .css. We could even display code you can add to the old title to import the new title. PrimeHunter (talk) 03:12, 21 February 2014 (UTC)
Consider also adding a mw.log.warn( 'Please update your scripts to load X instead of Y' ) call to the old page name so users are notified of the change and can update their scripts to avoid making an extra HTTP request. Helder.wiki 12:57, 21 February 2014 (UTC)
The default MediaWiki message (currently seen at MediaWiki:Movepagetext-noredirectfixer/en-gb) also makes the false redirect claim for .js and .css, so maybe it should be reported somewhere (not by me). PrimeHunter (talk) 03:29, 21 February 2014 (UTC)
(edit conflict) MediaWiki:Movepagetext-noredirectfixer/en-gb is not customised for this Wikipedia; whereas MediaWiki:Movepagetext-noredirectfixer/en has been customised. --Redrose64 (talk) 14:00, 21 February 2014 (UTC)

Strange problem with "GA nominee" template?

If you'll take a look at http://wiki.riteme.site/w/index.php?title=Talk:SpaceX_reusable_launch_system_development_program&oldid=596357499, another user had inserted the {{GA nominee}} template onto the talk page, which caused the TOC to disappear. A cursory glance at the code on the talk page and at the template didn't reveal any problems, but perhaps I missed something. Things are fine right now, as I just forced the TOC with the magic word. Still, the underlying problem should probably be found, if possible. Thanks! Huntster (t @ c) 05:41, 21 February 2014 (UTC)

It isn't caused by {{GA nominee}} but by {{Box-header}} which inserts __NOTOC__ unless the parameter TOC is set to non-empty. This is only documented on Template talk:Box-header. It should probably also be on the template page. PrimeHunter (talk) 06:54, 21 February 2014 (UTC)

Malware on Template talk:Did you know placed by an IP address

Please see Template talk:Did you know. Under Feb 20 there is a nomination template called The Psycoexwife placed there by an IP address. If you open the template, it's a redirect page to an external website. Can this please be removed? — Maile (talk) 13:00, 21 February 2014 (UTC)

As of this time of writing, I see it, but it appears legit. It's an article, but an orphan, see: https://wiki.riteme.site/wiki/ThePsychoExWife.com
Are you sure it's malware, or are just suspicious? meteor_sandwich_yum (talk) 13:12, 21 February 2014 (UTC)
What you're seeing is not the redirect page. The redirect page is not a Wikipedia page, but an external website spam or some kind of hoax, with lots of Asian-type graphics on it. And the url for it is The PsychoExWife.com. In fact, just the way the Wikipedia page has the ".com" in the title should indicate that. It's not the link to the Wikipedia page that is the redirect. It's the template itself, and it doesn't happen instantly. I clicked on the "Review or comment" link on its place in the Nominations page. That action is supposed to open the edit window on an individual nomination template, which it did except the template was blank. It was supposed to show the actual template nomination text for editing. Without closing that, and thinking it was a harmless fluke, I opened a different browser window and went to Wikipedia talk: Did You Know. Then I came back to the window with the nomination template, and it was on the external website.— Maile (talk) 13:31, 21 February 2014 (UTC)
The blank page was probably because the DYK nomination was originally at Template talk:Did you know nominations/ThePsychoExWife.com rather than Template:Did you know nominations/ThePsychoExWife.com. I have no idea why you might have wound up elsewhere or where exactly you might have ended up. Anomie 13:47, 21 February 2014 (UTC)
If you can pull up "Contributions" for IP 72.74.206.122, which is who created this. Not much there, but scroll down to the two entries for Articles for creation/Redirects. I'm not sure what those entries mean, but they are a piece of this.— Maile (talk) 13:54, 21 February 2014 (UTC)
They mean that the IP was asking for redirects to be created to the article about the website. I see nothing wrong with the requests from a technical standpoint. Anomie 13:59, 21 February 2014 (UTC)

Wanted: Gadget

I would like a way to change the "Edit this page" tab to a more concise "Edit". Werieth (talk) 15:08, 21 February 2014 (UTC)

The default Vector skin says Edit so I guess you have MonoBook. Try this in Special:MyPage/monobook.js:
var tablink = document.getElementById('ca-edit').getElementsByTagName('a')[0];
tablink.firstChild.nodeValue = 'edit';
PrimeHunter (talk) 15:29, 21 February 2014 (UTC)
Do you have Visual Editor enabled in your preferences? That may change the name of tags I've used jquery in my Special:MyPage/skin.js to set things to just how I want them
jQuery( document ).ready( function( $ ) {
        // Paste jQuery snippet heres
 
        $('li#ca-edit a').html('Edit');        // change label for wikitext edit tab
        $('li#ca-ve-edit a').html('VE edit');  // change label for visualEditor edit tab
 
        $('.mw-editsection a:nth-child(2)' ).html('Edit');  // change label for wikitext section edits links
        $('.mw-editsection-visualeditor').html('VE edit');  // change label for visualEditor section edit links
        $('.mw-editsection-bracket').css('display','none'); // Don't display [ ] square brackets for section edits 
 
        // $('.mw-editsection-divider').css('display','none');      // Don't display the | divider for section edits (commented out)
 
        $('#firstHeading .mw-editsection-visualeditor').css('display','none'); // Don't display the section 0 VE edit link which is broken
        $('#firstHeading .mw-editsection-divider').css('display','none');      // Don't display the divider for section zero
 
} );
You can do things either using PrimeHunters methods or jquery.--Salix alba (talk): 15:42, 21 February 2014 (UTC)
$('#ca-edit a').text('Edit');
Happy editing! — {{U|Technical 13}} (tec) 15:56, 21 February 2014 (UTC)

I would like to add a link, similar to the user, talk, and contributions links, at the top of each page I display when logged in, to go to a user subpage which would have a variety of convenience links. What would be the best way to add such a link? Assume the page is User:DESiegel/Tools. DES (talk) 16:17, 21 February 2014 (UTC)

  • So, what you went is your own TW style dropdown of custom links? It will require a custom userscript if that is the case. If you just wanted a link to take you directly to User:DESiegel/Tools from any page, it would be a one-line command like:
mw.util.addPortletLink('p-views', '/wiki/User:DESiegel/Tools', 'p-DEStools', 'Go to [[User:DESiegel/Tools]]');
As far as the personal dropdown goes, I'm not sure if that is part of MediaWiki:Gadget-morebits.js or not, but I'm guessing @This, that and the other, Azatoth, and Amalthea: would probably know and be able to help you. — {{U|Technical 13}} (tec) 16:33, 21 February 2014 (UTC)
You are missing ')' and the link isn't made in the requested place. Try this:
mw.util.addPortletLink('p-personal', mw.util.wikiGetlink('User:DESiegel/Tools'), 'Tools', 'pt-DEStools', 'Go to User:DESiegel/Tools', null, '#pt-preferences');
PrimeHunter (talk) 16:50, 21 February 2014 (UTC)
Thank you I just want one link, not a drop-down, at least not yet. Which special page should the above code go into please? DES (talk) 17:02, 21 February 2014 (UTC)
@@PrimeHunter and Technical 13: DES (talk) 17:04, 21 February 2014 (UTC)
Special:MyPage/common.js. PrimeHunter (talk) 17:07, 21 February 2014 (UTC)
  • Thank you very much, PrimeHunter, and Technical 13 that worked just as I had in mind. Now there is no need for me to clutter up my talk page with my list of tools, and I can feel easier making the list longer. I should have thought of this and asked about it long ago. DES (talk) 17:14, 21 February 2014 (UTC)
Please note the "wikiGetlink()" is deprecated, and you should use "getUrl()" instead. peace - קיפודנחש (aka kipod) (talk) 17:41, 21 February 2014 (UTC)

WikiLove seems broken

Was there a change to the WikiLove extension that just got deployed this week? Please see Wikipedia talk:WikiLove#WikiLove seems broken for details and comment there. Thank you. — {{U|Technical 13}} (tec) 20:40, 21 February 2014 (UTC)

Amendment to the Terms of Use

Setting a max-width for the vector skin + centered layout

Hi,

Is there a CSS expert that could help me with this? I need to set a maximum width for the vector skin and center its layout (see the following image).

Vector skin with a centered layout and a maximum width

With Monobook, the code was the following:

#globalWrapper {
	max-width: 1140px;
	margin-left: auto;
	margin-right: auto;
}

#column-one {
	position: relative !important;
}

Any help would be greatly appreciated.

--Lorangeo (talk) 23:42, 21 February 2014 (UTC)

The following works for me:
body {
	max-width: 1140px;
	margin-left: auto;
	margin-right: auto;
	position: relative;
}
You can use the same trick on almost all well-designed websites, I believe. Vector is not very well-designed ;), so you need one more little hack (otherwise the search suggestions are misaligned – you might need to tweak the value of "16px" depending on various factors, sadly):
.suggestions {
	right: 16px !important;
}
Matma Rex talk 00:15, 22 February 2014 (UTC)

(edit conflict) Try this:

#bodyContent {
max-width: 800px !important;
margin-left: auto !important;
margin-right: auto !important;
}

--  Gadget850 talk 00:24, 22 February 2014 (UTC)

That's not valid CSS, Gadget850. It would be fine without that first line. – PartTimeGnome (talk | contribs) 17:52, 22 February 2014 (UTC)
Whoops- copied a bit too much. Fixed. --  Gadget850 talk 18:12, 22 February 2014 (UTC)
Thank you. Matma Rex gave the good solution (whole layout centered). I came to the same solution as you, but I didn't know where to put the relative positioning property. I hope this will be supported on most modern browsers. --Lorangeo (talk) 00:38, 22 February 2014 (UTC)

Undoing edits on multiple pages at once?

A registered user has added a category to about 40 pages and I believe the addition has been made in error (though in good-faith). Is it possible to remove the category from all 40 pages without performing an "undo" on each page separately?Sxg169 (talk) 02:19, 22 February 2014 (UTC)

see cat-a-lot on WP:US. peace - קיפודנחש (aka kipod) (talk) 04:16, 22 February 2014 (UTC)

Linux issues

Troll. Nothing to see here. Jackmcbarn (talk) 01:10, 23 February 2014 (UTC)
The following discussion has been closed. Please do not modify it.

Just to let you guys know that the new version of Linux has a bit of trouble viewing the screen resolution in Wikipedia. Wrong ratios, wrong everything. --Civivlaospei (talk) 21:17, 22 February 2014 (UTC)

Which web browser? Which Linux distribution? What exactly looks wrong? Could you upload a screenshot? – PartTimeGnome (talk | contribs) 22:28, 22 February 2014 (UTC)
OP has been indeffed for trolling. Johnuniq (talk) 00:57, 23 February 2014 (UTC)

Replace old stats.grok.se with wikiviewstats

WP:Stats.grok has its successor - Wiki ViewStats on wmflabs. What can I say, it's better, much better! Please comment if you agree with me. --Rezonansowy (talkcontribs) 10:02, 22 February 2014 (UTC)

  • Oppose until such time as Wikiviewstats has the seven years + of stored hits that stats.grok does. That is important for researchers as well, and we should not get rid of it. Last I checked, wikiviewstats purges the data every 3 months or so. — Crisco 1492 (talk) 10:07, 22 February 2014 (UTC)
  • Oppose as well for now. Last time I checked, Wikiviewstats wasn't even working and still has no API. It would need to be working before it can replace anything, it needs to have an API like stats does so that information there can be retrieved with userscripts onwiki, and yeah, it should have a decent chunk of historical data. — {{U|Technical 13}} (tec) 13:48, 22 February 2014 (UTC)
  • Oppose "tools.wmflabs.org" fails all the time and is unreliable..and also, stats.grok's simplicity and longevity is its best feature...would support the option to add a link to wikiviewstats on history pages for 'advanced' users--Stemoc (talk) 14:01, 22 February 2014 (UTC)
  • Oppose as well, at least when it comes to replacing stats.grok; would support adding a link in addition to stats.grok.se. For now, there are in my opinion far too many issues with tools.wmflabs.org and thus Wiki ViewStats and the information is not kept quite long enough for various purposes. AddWittyNameHere (talk) 14:31, 22 February 2014 (UTC)
Comment Wiki ViewStats is working and is a far superior tool than stats.grok will ever be. stats.grok is constantly missing data and has lower than actual page stats when compared with the actual dump and as Henrik is absent the majority of the time, issues and errors with it are rarely fixed properly if at all. Wiki ViewStats however has been designed as a 90 day rolling stat service not a permanent record which means its not suitable as a permanent replacement. Someone however will have to come up with a replacement at some point as this is likely to pack in at some point as Henrik goes absent. I would however say the people opposing because of unreliability of Labs isn't really a valid reason to oppose, Labs is the replacement for tool server provided by the WMF and we don't have much choice in the matter, although it is more reliable than tool server is at present. I see no reason why both cant be on offer especially to experienced users.Blethering Scot 17:08, 22 February 2014 (UTC)
  • I have nothing against Labs as a tool, or at least nothing that cannot be fixed. I just find it ridiculous that we want to lose 7 years + of archives willy-nilly. Historical page views are necessary for research, to follow on-Wiki trends, and if Labs is purging their archive every month or so then that is going to cause severe damage to research into Wikipedia. Migrate the archives, and I'll be liable to support. Otherwise Labs is just a shiny tool which does not recognize the importance of history. — Crisco 1492 (talk) 11:59, 23 February 2014 (UTC)
  • You don't seem to be able to separate Labs from Wiki ViewStats. WikiViewStats runs on Labs, it isn't Labs. No one has suggested losing any history not even me. The issue is that Stats.grok is becoming more and more unreliable, and as he becomes less active it's only going to get worse providing users links to both provides no issues whatsoever. Nobody loses history already in Stats.grok it will always be there, well until it dies from no maintenance which is a distinct possibility. Anyone is welcome to preempt that happening and create a new tool and migrate data.Blethering Scot 12:12, 23 February 2014 (UTC)
  • WT:DYK has come up with a proposal to use both systems together. I think that this would be the best of both worlds as it retains the system that works while also giving the option to use the new one. I personally prefer stats.grok but I think that using both would please the majority. The C of E God Save the Queen! (talk) 18:28, 23 February 2014 (UTC)

Experimenting with a new template?

I'm making some significant modifications to Template:Infobox river. So naturally I created a working copy in my sandbox: User:scs/Sandbox/Template Infobox river. To test it, I'm temporarily transcluding it from a few actual river articles, e.g. Little Bighorn River. Is this wrong? Is there a better way? (I'm half-remembering a rule against transcluding userspace templates from article space, which if so I'm breaking. I know I could create scratch copies of the river articles themselves, and in fact I did start with User:scs/Sandbox/Hoosic River, but it's a nuisance to do for the multiple articles one wants to test on to ensure functionality in all use cases.) —Steve Summit (talk) 14:55, 22 February 2014 (UTC)

(edit conflict) The usual way to do this is with /testcases pages. You could put your proposed template code in Template:Infobox river/sandbox, and create some tests at Template:Infobox river/testcases. See WP:TESTCASES for instructions, and see Template:Infobox person/testcases for an example. Also, you might find {{testcase table}} useful, as it avoids you having to type in the template code twice. I don't recall there being an actual rule against transcluding userspace sandboxes in mainspace, but I wouldn't do it myself. I think it's better to test pages elsewhere, and use the code in articles only when it's ready. — Mr. Stradivarius ♪ talk ♪ 15:08, 22 February 2014 (UTC)
See if Special:TemplateSandbox does what you want. Jackmcbarn (talk) 16:04, 22 February 2014 (UTC)
WP:UP#Userspace and mainspace expressly forbids the linking of user pages from articles. By extension, the transclusion into articles of pages in user space is also prohibited. --Redrose64 (talk) 16:40, 22 February 2014 (UTC)

Thanks, everybody.

  • Thanks for the information about testing templates -- I didn't know any of this. (In particular, Special:TemplateSandbox and {{Test-mode}} look especially useful. Kudos to whichever mediawiki devs conceived, implemented, and deployed those powerful features.)
  • All five river articles that were temporarily transcluding the userspace sandbox copy of the template are now pointing back at the official template, which now has the new, tested changes.

Steve Summit (talk) 13:19, 23 February 2014 (UTC)

Resolved
Note the idea for TemplateSandbox wasn't mine, I just implemented it. And {{test-mode}} is entirely someone else's doing. Anomie 17:46, 23 February 2014 (UTC)
Your modesty is appreciated, but as a software engineer myself, let me just say that I know both how fabulously useful design for testability techniques can be, and also how tantalizingly difficult it can be to find the wherewithal to actually get them implemented. So thanks again. —Steve Summit (talk) 18:45, 23 February 2014 (UTC)

What is Delivery of "Popular pages tool update" to...

I see "Mass Media Log Delivery of "Popular pages tool update" to (all project names) was skipped because target was in a namespace that cannot be posted in" Fine, but other than skipping the projects, what is the popular pages tool update? — Maile (talk) 23:36, 22 February 2014 (UTC)

Mark single pages as visited

Hi all, there is the Mark all pages visited button on the watchlist but does anybody know how I can mark single pages that I have on my watchlist as visited (without actually visiting them)?

I checked the source a little and all what the mentioned button seems to do is calling User::clearAllNotifications(). There is also User::clearNotification() which seems to do exactly what I want, but I didn't find a way yet to access this from e.g. user JS.

Any idea how I could get the wanted functionality to e.g. add a "mark visited" button to all history pages? --Patrick87 (talk) 16:06, 23 February 2014 (UTC)

The API has action=setnotificationtimestamp that could be used in a user script for this purpose. Anomie 17:53, 23 February 2014 (UTC)

Where is Mediawiki loading this script?

I'm on Commons, and I have the AjaxQuickDelete script installed. It is here: commons:MediaWiki:Gadget-AjaxQuickDelete.js.

I'd like to make some changes to the script, but I'm in my JavaScript debugger in Chrome, and I cannot find it in the debugger. Here is a list of the scripts which it is loading: http://postimg.org/image/sf6i73lax/.

Please note it is not any of the scripts in green, as those are actually stylesheets. Magog the Ogre (tc) 18:01, 23 February 2014 (UTC)

It depends on how you load the script. If you have the gadget enabled, it should be delivered through ResourceLoader as one big, combined package (unless you use ?debug=true) coming from bits.wikimedia.org, But if you use importScript from your user space, it is loaded separately (as seen in your screenshot for AjaxSubmit.js at the top). Edokter (talk) — 18:28, 23 February 2014 (UTC)
?debug=true is what I needed. Thanks. Magog the Ogre (tc) 19:14, 23 February 2014 (UTC)

Lots of Wikimedia Foundation errors

I have been getting lots of Wikimedia Foundation errors in the last hour or so, nearly every time I load any page. Normally 1 or 2 refreshes makes it go away. Here is one of these:

Request: GET http://wiki.riteme.site/wiki/Wikipedia:VPT, from 10.128.0.117 via cp1065 cp1065 ([10.64.0.102]:3128), Varnish XID 141763187
Forwarded for: [my IP address], 10.128.0.116, 10.128.0.116, 10.128.0.117
Error: 503, Service Unavailable at Sun, 23 Feb 2014 19:43:27 GMT
This is from western Washington (state):Jay8g [VTE] 19:46, 23 February 2014 (UTC)

Yeah, I'm getting them too. -- Veggies (talk) 19:52, 23 February 2014 (UTC)
I was getting them in the United Kingdom from about 19:00 UTC, for a while no link worked on first click, sometimes it took five or six clicks for a link to succeed. Affected both https: and http: so it wasn't a protocol problem. Seems to be working OK now. --Redrose64 (talk) 23:21, 23 February 2014 (UTC)

Apparent ref name and/or ref group name confusion

I was looking at the List of ongoing armed conflicts article with an eye to replacing the {{ref}}/{{note}} bits with {{efn}}s and a {{notelist}} with the notes as list-defined references (besides being arguably neater, the notelist approach would allow named notes to be reused). I ran into some problems. It seems as if either I'm missing something here or there is a reportable bug in here somewhere. Following are some examples simplified from what I was doing in the article to illustrate the problems I think I see (edit this to see the wikitext).

Let's try a simple case:

  1. ^ note a body[1]
  1. ^ ref a body

That looks OK and the forward and back links work as expected.

Let's add a second note with a second ref.

{{quotation| *{{efn|name=a}} *{{efn|name=b}} {{notelist|refs= {{#tag:ref|note a body<ref name="ref a">ref a body</ref>|name=a}} {{#tag:ref|note b body<ref name="ref b">ref b body</ref>|name=b}} |close}} {{reflist|close}} }}

That looks screwed up. It looks like there is some confusion about reference groups. Let's try adding explicit group names to the #tag:refs.

{{quotation| {{notelist|refs= {{#tag:ref|note a body<ref name="ref a">ref a body</ref>|name=a|group=lower-alpha}} {{#tag:ref|note b body<ref name="ref b">ref b body</ref>|name=b|group=lower-alpha}} |close}} {{reflist|close}} }}

That also looks screwed up.

If I'm doing something dumb here, I'd appreciate a clue. If not and it looks buggish, perhaps this can be reported.Wtmitchell (talk) (earlier Boracay Bill) 02:01, 24 February 2014 (UTC)

Attempting to include a nested reference more than once within list-defined references results in a Cite error; see T22707. Depending on how the reference is defined, you can get most any error. --  Gadget850 talk 02:41, 24 February 2014 (UTC)
And you can use {{refn}} instead of the more cryptic #tag:ref. --  Gadget850 talk 02:43, 24 February 2014 (UTC)
(edit conflict) @Wtmitchell: Nesting <ref>s is basically not supported, there are a few bugs like T18330 or T22707 reported, but basically this was never intended to work (as you can clearly tell by the fact that just doing <ref><ref></ref></ref> doesn't work, you need to use #tag). Making it work consistently would probably require considerable effort, but I have no detailed knowledge of Cite internals. Filing a bug is never a bad idea anyway :) Matma Rex talk 03:00, 24 February 2014 (UTC)
Thanks.
  • I'll take a look at T22707 and perhaps add something there regarding this. I tend to stay away from WP:Bugzilla because I haven't seen much result from the time I've spent there in the past on other things.
  • #tag:ref was among the things I keep at the back of my mind before {{refn}} appeared. I agree that {{refn}} looks less cryptic, though. I'll try to remember to use {{refn}} the next time a need to nest refs comes up.
  • Unless I really garbled something, I wasn't attempting to nest <ref>s within <ref>s. I was nesting <ref>s within #tag:refs, as in Help:Footnote#Footnotes: embedding references (which I see now describes {{refn}} -- another reason to use that template).
Wtmitchell (talk) (earlier Boracay Bill) 07:08, 24 February 2014 (UTC)
I tried to make this work with {{refn}}, but couldn't get that to work either. Anyone interested can edit the wikitext here and see my attempts, which I've commented out to avoid rendering them here. If interested, uncomment to see the renderings and my remarks. Wtmitchell (talk) (earlier Boracay Bill) 08:12, 24 February 2014 (UTC)
I think Matma Rex meant that nesting references of any sort was not intended to work, regardless of whether you use {{#tag:ref|...}} or <ref>...</ref>. – PartTimeGnome (talk | contribs) 23:10, 24 February 2014 (UTC)

10:18, 24 February 2014 (UTC)

Getting redirect targets

Is there a way of getting the target of a redirect known to be at a specific title? I.e. {{blahblahmagic:WP:EXAMPLE}} would produce Wikipedia:Example. — Scott talk 17:45, 24 February 2014 (UTC)

See Module:Redirect. Ruslik_Zero 19:34, 24 February 2014 (UTC)
Beautiful. Thanks. — Scott talk 19:38, 24 February 2014 (UTC)

Passing a ?search-string parameter to a url in a template (either raw of wrapped in a citation template) to produce a reference in a reflist.

Here is the scenario. We have a long list of buildings in table format with a heritage-number in one field. This number is also used by website ''http://yorkshire.u08.eu'' as a page reference- to a encyclopedic page on that particular building. The aim is to wrap the heritage-number in a template {{Ynbr}} so it is rendered as reference (group) at the bottom of the page. This will appear as YNBR No: XXXX English Heritage, where XXXX is hyperlinked to ''http://yorkshire.u08.eu/?b=XXXX''.


Here is the sample page User:ClemRutter/sandbox4, and here is the template {{Ynbr}}. Here is the desired result when the links all follow http://yorkshire.u08.eu/?b=62684

The coding should have been fairly simple:

National Building Register: {{{1}}} <ref name="NBR">[http://yorkshire.u08.eu/?b={{{1}}} Yorkshire Heritage {{{1}}}] English Heritage}}|</ref> <noinclude>{{documentation}}</noinclude>

so I changed it to :

National Building Register: {{{1}}} <ref name="NBR">[http://yorkshire.u08.eu/?b={{#tag:ref| {{{1}}} }} Yorkshire Heritage {{#tag:ref| {{{1}}} }}] English Heritage}}|</ref> <noinclude>{{documentation}}</noinclude>

Still that didn't work either.

  • Perhaps there is someone who could explain what is going wrong-- or submit the necessary bug report.

And as my supplementary questions

  • How do you write an url= attribute in a {{cite web}} template now the undefined positional parameter is ignored
  • When these both work- will they continue to work when placed in a tfield in a trow in table?

Thanks in advance, the result will be worth the effort.-- Clem Rutter (talk) 18:09, 24 February 2014 (UTC)

You are trying to nest two levels of <ref> tags, which simply cannot be done with the Cite extension. See WP:REFNEST. --  Gadget850 talk 18:20, 24 February 2014 (UTC)
Good Thanks for WP:REFNEST.In the second example, the nesting is clear. But I can't see the nest in the first example. The principal problem though is getting the url to accept the the parameter from the template, Any further clues?-- Clem Rutter (talk) 22:19, 24 February 2014 (UTC)
I tried to make it work. Ruslik_Zero 19:29, 24 February 2014 (UTC)
You appear to have succeeded .
Clem, as has already been mentioned, the problem in the second example was nested references. What caused a problem in the first case was that the content of <ref>...</ref> is used before parameters are expanded. Ruslik's solution was to use {{#tag:ref}} instead, where the tag content is used after parameters have been expanded. – PartTimeGnome (talk | contribs) 23:26, 24 February 2014 (UTC)
(edit conflict) I rather suspect that the problem here is that your specified URL includes an equals sign and that {{=}} must be used. There may be other issues as well, this is from inspection, not testing. DES (talk) 23:27, 24 February 2014 (UTC)
I'm not sure that's essential when using {{cite web}} as used in the template. {{=}} is usually only necessary for unnamed parameters, but the url= parameter for {{cite web}} is named. If we had stuck with the [bare links] from the examples above, {{=}} would have been necessary, else the left side of the URL would be treated as a parameter name for {{#tag:ref}}. In any case, Ruslik used {{=}} and it's working, so I'm not minded to change it. – PartTimeGnome (talk | contribs) 23:43, 24 February 2014 (UTC)
In the first example, you are using variables inside a parser tag and that just does not work- that is what #tag does. --  Gadget850 talk 23:36, 24 February 2014 (UTC)

The table of contents problem in mobile version

The chapters after "The Games" on page [113] are wrongly folded into the chapter "The Games". --fireattack (talk) 21:49, 25 February 2014 (UTC)

Investigating... Jackmcbarn (talk) 22:04, 25 February 2014 (UTC)
Fixed. Jackmcbarn (talk) 22:26, 25 February 2014 (UTC)
This very table was recently being discussed at WP:VPR#Issue with the use of Columns where I did explain that {{multicol}} should not be mixed with {{Col-break}} - the latter belongs with {{Col-begin}} - and that neither should be closed with a plain |} - there are appropriate templates to close these lists which add the appropriate number of </div>s. --Redrose64 (talk) 10:26, 26 February 2014 (UTC)

MathJax parsing error

Has anybody recently noticed that with MathJax on in Prefrences equations with roots → \sqrt ← are displayed wrong (shifted)? See below:

Blackfish (talk) 12:33, 26 February 2014 (UTC)

See also above in section #Status? and elsewhere all over the place. - DVdm (talk) 12:59, 26 February 2014 (UTC)
It's not about centering of equations (that's differnt issue), but about a radical symbol (radix). "V" part is not connected with top line etc. Blackfish (talk) 13:08, 26 February 2014 (UTC)
Ah, yes, sorry.
OTOH, when I do an edit preview, everything is OK. After the save, the V of the second equation is disconnected. The first equation is OK. I use Firefox 27.0.1.
By the way, with IE8, the new MathJax doesn't work at all anymore in IE8. Not a single equation appears—stone dead.
Everything (i.e. your square roots, and the entire IE8) works just fine with <script type="text/javascript" src="http://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML">, which I assume can be called the "old" MathJax. - DVdm (talk) 15:29, 26 February 2014 (UTC)
Duh. After this save the V of the second equation also connects with its top line. Someone's experimenting around as we speak? - DVdm (talk) 15:31, 26 February 2014 (UTC)
DuhDuh. And now it's broken again. - DVdm (talk) 15:33, 26 February 2014 (UTC)
DuhDuhDuh. And now it's connected again. Whatever happens next, I won't bother updating again. - DVdm (talk) 15:34, 26 February 2014 (UTC)

How can I search for words WITHIN an article?

Is there a way to search for words that appear WITHIN an article? (In the articles text, not its title) I want to search articles that include the words "vasculitis". The main Vasculitis page is no help in that regard. Thanks for any help!Juneau Mike (talk) 16:42, 26 February 2014 (UTC)

Like this [114]? Advanced search did it for me. Leaky Caldron 16:45, 26 February 2014 (UTC)
See the lead of Help:Searching. PrimeHunter (talk) 19:53, 26 February 2014 (UTC)

Template fonts

Perhaps I missed the party, so how to restore the previvous fonts in templates instead of current bolded ones (like dates in Today's featured article templates or "Competitor for ..." in Template:Infobox sportsperson?) Is it in preferences or something else? I recall seeing different fonts some time ago (unless I'm not hallucinating). Brandmeistertalk 20:04, 26 February 2014 (UTC)