Jump to content

Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by GJR (talk | contribs) at 07:37, 16 February 2014 (reasons why Watchlist's "green bullet" feature's inaccessibility still needs to be addressed). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts
The technical section of the village pump is used to discuss technical issues about Wikipedia. Bugs and feature requests should be made at Bugzilla (see how to report a bug). Bugs with security implications should be reported to security@wikimedia.org or filed under the "Security" product in Bugzilla.

Newcomers to the technical village pump are encouraged to read these guidelines prior to posting here. Questions about MediaWiki in general should be posted at the MediaWiki support desk.


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

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

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

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)[reply]
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)[reply]
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)[reply]
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)[reply]
Pages now higher.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 22:46, 11 February 2014 (UTC)[reply]

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

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)[reply]
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)[reply]
  • 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}} (t • e • c) 16:41, 9 February 2014 (UTC)[reply]
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)[reply]

@Dispenser: (t) Josve05a (c) 20:08, 9 February 2014 (UTC)[reply]

24 Terabytes. That's 24 Flickrs accounts or $1,000 in Hard Drive ($10,000 with infrastructure [1]). 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)[reply]
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)[reply]
Does anyone here know why it's broken and when it might be fixed? Roger (Dodger67) (talk) 07:01, 14 February 2014 (UTC)[reply]

Math aligned environments failing to parse

Tracked in Phabricator
Task T62997

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

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

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)[reply]
See also a similar question above. Graham87 04:20, 7 February 2014 (UTC)[reply]

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

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

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

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

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

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

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

  • 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)[reply]

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

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


@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)[reply]

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

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


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

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

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


Wikid77 has raised this issue at Wikipedia:Administrators' noticeboard/Archive259#Reverting fixes of equations. – PartTimeGnome (talk | contribs) 18:01, 8 February 2014 (UTC)[reply]


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



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


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

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

See Wikipedia:WikiProject_Mathematics/Popular_pages for the "Top 100 math articles" to watch/rescue.--Salix alba (talk): 12:57, 10 February 2014 (UTC)[reply]


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; [2], [3], [4], [5].

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



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

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

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


@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 (Template:Bug), 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)[reply]

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


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



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

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

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

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 Template:Bug.--Salix alba (talk): 00:42, 9 February 2014 (UTC)[reply]


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



That was probably related to the issues reported above. A purge fixed it. Matma Rex talk 01:18, 9 February 2014 (UTC)[reply]


So are 0.999... and every single article that contains \begin{align}...  [ Derek Leung | LM ] 01:28, 9 February 2014 (UTC)[reply]

 Done Thanks, looks good now. --BrownHairedGirl (talk) • (contribs) 04:43, 9 February 2014 (UTC)[reply]


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



There's still at least one page that still isn't working. Jestingrabbit (talk) 07:25, 9 February 2014 (UTC)[reply]

It loaded for me (though it took 33 seconds) and looks fine.--JohnBlackburnewordsdeeds 08:02, 9 February 2014 (UTC)[reply]

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

@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)[reply]



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


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



Please see previous threads. --Redrose64 (talk) 14:06, 9 February 2014 (UTC)[reply]


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


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



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

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

Example? — {{U|Technical 13}} (t • e • c) 20:27, 10 February 2014 (UTC)[reply]

I don't know of any, that's the point. Are there any left out there? --Redrose64 (talk) 22:12, 10 February 2014 (UTC)[reply]

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

These both look OK to me; try a WP:BYPASS. --Redrose64 (talk) 13:18, 12 February 2014 (UTC)[reply]


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


Side question


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



Ping AKlapper (WMF) Steven (WMF) Werieth (talk) 13:35, 12 February 2014 (UTC)[reply]

Not that I'm aware of. Steven Walling (WMF) • talk  17:27, 12 February 2014 (UTC)[reply]

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


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



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

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


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



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


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


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


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


Justify paragraphs






Tracked in Phabricator
 Task T54810


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



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



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


See also:



Helder 13:19, 7 February 2014 (UTC)[reply]

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

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


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

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


  • 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)[reply]


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

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


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



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

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




p {word-spacing:3px;}



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


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



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

Thanks. I reviewed my changes and did what I needed to do. —Anomalocaris (talk) 21:17, 7 February 2014 (UTC)[reply]


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

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



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

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

Have you seen this at a page when the most recent editor is not ClueBot?  Whatamidoing (WMF) (talk) 00:34, 13 February 2014 (UTC)[reply]


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


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

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

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


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

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


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



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


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

@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)[reply]


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


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


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


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



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

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


Is this going to be fixed soon?


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

I suspect that removing it was the "fix".  Template:Bug 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)[reply]

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

@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)[reply]

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

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


  • 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)[reply]


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



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


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

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

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

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


RFC: UploadWizard: scale to sister projects


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



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



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

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

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


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



  • 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)[reply]


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

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


(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)[reply]

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

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

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

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

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

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

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

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 (t • c) 17:14, 12 February 2014 (UTC)[reply]


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


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



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


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



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

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

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


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




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


{{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)[reply]

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


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


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



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



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



@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)[reply]

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


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}} (t • e • c) 19:49, 11 February 2014 (UTC)[reply]



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

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

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

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


@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)[reply]



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 (talk • contribs) 22:36, 11 February 2014 (UTC)[reply] 



@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)[reply]

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

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


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





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 (talk • contribs) 07:20, 12 February 2014 (UTC)[reply]



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


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 (talk • contribs) 09:03, 12 February 2014 (UTC)[reply]

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 (talk • contribs) 09:27, 12 February 2014 (UTC)[reply]

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.3F —TheDJ (talk • contribs) 09:30, 12 February 2014 (UTC)[reply]


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



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 (talk • contribs) 06:45, 14 February 2014 (UTC)[reply]


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



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




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



It's blue for me. Try purging the page instead. VanIsaacWS Vexcontribs 18:35, 12 February 2014 (UTC)[reply]

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

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


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

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



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

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


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



Page protection check-box


Tracked in Phabricator
 Task T41038


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



  • Support for such a mechanism and I'll comment on the Bz ticket as well. — {{U|Technical 13}} (t • e • c) 03:45, 13 February 2014 (UTC)[reply]
    • 

  • Support Jimfbleak -  talk to me? 07:17, 13 February 2014 (UTC)[reply]
    • 

  • 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)[reply]
    • 

  • 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)[reply]

    • 

  • Support This is an infinitely logical idea. - The Bushranger One ping only 00:48, 14 February 2014 (UTC)[reply]
    • 

  • 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)[reply]
    • 

  • 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}} (t • e • c) 17:29, 14 February 2014 (UTC)[reply]


  • 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)[reply]




  • 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)[reply]


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}} (t • e • c) 02:29, 15 February 2014 (UTC)[reply]

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

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}} (t • e • c) 15:23, 15 February 2014 (UTC)[reply]

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


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


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



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


Discussions disappearing and reappearing


Tracked in Phabricator
 Task T63319


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



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


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

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


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



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

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


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

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



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

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



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: [9] —Kusma (t·c) 20:57, 13 February 2014 (UTC)[reply]



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

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

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



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

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


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



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

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

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

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


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://en.wikipedia.org/wiki/Peyton_Manning, from 91.198.174.61 via amssq57 amssq57 ([91.198.174.67]:3128), Varnish XID 912289047
Forwarded for: 88.104.19.171, 91.198.174.61
Error: 503, Service Unavailable at Fri, 14 Feb 2014 04:18:45 GMT


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

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

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



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

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


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



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

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


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

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


"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)[reply]

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

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

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

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

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

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


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

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


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



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

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


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

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

bugzilla:23824? :) --AKlapper (WMF) (talk) 13:44, 14 February 2014 (UTC)[reply]


...but be aware it is very slow! Helder.wiki 14:27, 14 February 2014 (UTC)




A bug in template:music


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



Yes it is. The SVG is an image that always gets shown in black. —TheDJ (talk • contribs) 07:39, 14 February 2014 (UTC)[reply]


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

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

Have you tried <score>? --  Gadget850 talk 13:10, 14 February 2014 (UTC)[reply]

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

Why do you need to change the color? --  Gadget850 talk 04:41, 15 February 2014 (UTC)[reply]

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

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

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

@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)[reply]


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


Searchbox is broken & Search is overloaded


When I enter anything into the Searchbox, the searchpage comes up instead of bringing me to the page in question, this happens whether I enter a page name, a redirect name, or a shortcut name (yes, I have spelled it properly. It's also become case sensitive, saying the page I entered doesn't exist if I use a different case (say all lower case when the shortcut is all upcaps) - 76.65.129.222 (talk) 07:29, 14 February 2014 (UTC)[reply]



Also, I suspect as a result of this bug ("feature") it appears that the search engine is now extremely bogged down. In the wee hours of the day, searchbox keeps failing by saying it is overloaded. -- 76.65.129.222 (talk) 07:37, 14 February 2014 (UTC)[reply]

Exact error message welcome, plus browser information (for the first part). --AKlapper (WMF) (talk) 13:46, 14 February 2014 (UTC)[reply]


(My IP has rolled over). Today, it doesn't seem overloaded, but there's a persistent error. If I enter WP:USA into the searchbox, it will return:


 An error has occurred while searching: The search backend returned an error:  

And anything I type into the searchbox whatsoever always goes to the searchpage. If I enter WP:VPT into the searchbox I get


 There is a page named "Wikipedia:VPT" on Wikipedia 

with a list of results


I am using Firefox 27 (versions newer than this version appear to be incompatible with other software I have, but this behaviour of Wikipedia did not occur before I posted this message, it worked fine in FF27 previoiusly) -- 70.50.151.11 (talk) 23:34, 14 February 2014 (UTC)[reply]


This is also happening with WaterFox 18 and PaleMoon 24 -- 70.50.151.11 (talk) 08:51, 15 February 2014 (UTC)[reply]


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

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



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



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

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

OK, I needed to make one more cleanup edit. --Redrose64 (talk) 14:35, 15 February 2014 (UTC)[reply]


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



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



Italics in citation title broken


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



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




Live

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




Sandbox

"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)[reply]

Alrighty then, moved discussion to Module talk:Citation/CS1#Italics in citation title broken. Whisternefet (talk) 15:54, 15 February 2014 (UTC)[reply]


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



@Dudemanfellabra: What is the exact version of Firefox you're running? Matma Rex talk 18:53, 15 February 2014 (UTC)[reply]

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

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


@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)[reply]

@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)[reply]


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

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


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:



Template:Z12
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. 

  2. At an administrator's discretion, you may be unblocked for 24 hours to file a request.
    3. 

  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.
Village pump (technical)

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



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

Thank you PrimeHunter! --Anthonyhcole (talk · contribs · email)  05:39, 16 February 2014 (UTC)[reply]


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;
    2. 

      

    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. 

    

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

    3. 

  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. 

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

    4. 



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



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


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. 

  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. 

  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. 

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









Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=595701168"