Wikipedia:Village pump (technical): Difference between revisions

Browse history interactively

← Previous edit Next edit →

Content deleted Content added

VisualWikitext

Inline

Revision as of 19:42, 3 February 2014

Table of contents
First discussion
End of page
New post

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.

view · edit

Frequently asked questions (see also: Wikipedia:Technical FAQ)

Click "[show]" next to each point to see more details.

If something looks wrong, purge the server's cache, then bypass your browser's cache.
This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown.

No, we will not use JavaScript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an `accesskey` property on it (default to `accesskey="f"` in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences.

No, we will not add a spell-checker, or spell-checking bot.
You can use a web browser such as Firefox, which has a spell checker.

If you have problems making your fancy signature work, check Help:How to fix your signature.

If you changed to another skin and cannot change back, use this link.
Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem.

If an image thumbnail is not showing, try purging its image description page.
If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear.

For server or network status, please see Wikimedia Status. If you cannot reach Wikipedia services, see Reporting a connectivity issue.

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

Can we please get rid of those shouty comments in template documentation?

You know the ones I mean... "PLEASE ADD CATEGORIES AND INTERWIKIS AT THE BOTTOM OF THIS PAGE" and "CATEGORIES AND INTERWIKIS HERE, THANKS". I don't know where or when they originated, presumably in the first ever template documentation template. But we've now been successfully using the system for years, and everybody knows how it works. For the times that someone doesn't, another person will fix the transclusion of a category momentarily; and it causes no actual harm until they do. Perpetuating this copy-and-paste mess also creates its own maintenance overhead, as I've now seen someone who's decided that they need to grind through them adding a mention of Wikidata. That's a colossal waste of time.

So can we please, please agree that it's time to get rid of these patronizing and shouty comments? And when we have, get a bot to remove them? I, for one, am sick to death of seeing them, and will continue my practice of nuking them on sight if they occur in a documentation template that I'm working on. — Scott • talk 12:26, 17 January 2014 (UTC)[reply]

Technical: The comments are added by Template:Documentation/preload. -- Gadget850^talk 14:37, 17 January 2014 (UTC)[reply]

Thank you. I was almost right, then; they originated in the first version of Wikipedia:Template documentation in 2006. See also my reply below. — Scott • talk 16:02, 17 January 2014 (UTC)[reply]

I'm assuming they are still there for all of the editors that are new to templates and documentation that might not know. The reason for them to be all caps like that is that they are HTML comments, and as such, need to stand out to be noticed in a seas of text or walls of code. I suppose there could be a note added to the editnotice for all template pages, but that might be more work than it is worth and easier to just have the SHOUTY comments in the source (where they are more likely to be seen than editnotices anyways). Technical 13 (talk) 14:55, 17 January 2014 (UTC)[reply]

Following the link provided above by Gadget850, it seems that the shouty comments only occur in templates older than February 2011, when the preload template was deshoutified by DePiep. I'm less concerned now that I know the shouty ones aren't being added any more. @Gadget850: I'm going to ask people at Template talk:Documentation if they think the comments are really still relevant. — Scott • talk 16:02, 17 January 2014 (UTC)[reply]

Yes. Later on, the interwiki link message has changed too, for wikidata. Maybe a botter would like to clean these. -DePiep (talk) 17:14, 17 January 2014 (UTC)[reply]

Removing the comments would have the disadvantage that all of the templates' transclusions would have to be updated. If it's done by bot, then that would become a very large number of pages, probably in the millions. — Mr. Stradivarius ^{♪ talk ♪} 04:44, 18 January 2014 (UTC)[reply]

Most of them are /doc subtemplates, with few transclusions each (not millions). -Wikid77 00:36, 19 January 2014 (UTC)[reply]

I've usually seen them as a set, with "CATEGORIES AND INTERWIKIS GO ON THE /doc SUBPAGE" placed on the template page, and "CATEGORIES AND INTERWIKIS GO HERE" placed on the /doc subpage. I've no problem with fixing ones on /doc subpages, by bot or by hand. The ones on template pages should probably wait until there is a separate reason to edit the template, so that there is an actual content edit as well as the beautification fix. — Mr. Stradivarius ^{♪ talk ♪} 10:41, 19 January 2014 (UTC)[reply]

"everybody knows how it works:

...except for the hundred-thousand-plus editors who are active now but have never touched a template, and the tens of thousands who have occasionally edited templates, but not often enough to remember how it works. The "everybody" who already knows how this works is actually a quite small percentage of users. WhatamIdoing (talk) 00:16, 18 January 2014 (UTC)[reply]

Yes, and they're the ones who'll fix it when the inexperienced ones get it wrong. Them, or bots. We have innumerable bots crawling around the site making similar grades of fix on a vastly larger scale; this should be one of the things that they look out for. — Scott • talk 21:57, 18 January 2014 (UTC)[reply]

Why waste the time of more experienced editors? Why make it easier to make mistakes? The comments do no harm. They help inexperienced editors learn what to do, and hopefully reduce the time the rest of us spend fixing mistakes. – PartTimeGnome (talk | contribs) 22:04, 18 January 2014 (UTC)[reply]

Like I said, bots could catch these errors in real time. Editor involvement would be minimal. To answer your question, the comments are already doing some harm in the form of accumulating technical debt - notice the effort that will be required to update them. Better to do away with them entirely, have real documentation in a single location, and have systems in place to catch whatever minor errors occur subsequently. This is poor factoring that will only get more messy over time. — Scott • talk 13:46, 21 January 2014 (UTC)[reply]

In fact, this could and should be one of the tasks performed by Wikipedia:WikiProject Check Wikipedia's army of bots. — Scott • talk 13:24, 23 January 2014 (UTC)[reply]

Updated SHOUTy text with new /preload text: The new format should be copied to replace any old, ALL-CAPS comments in /doc pages, as from the current Template:Documentation/preload, especially to control /sandbox use:

<includeonly>{{#ifeq:{{SUBPAGENAME}}\|sandbox\|\| <!-- Categories go here, and interwikis go in Wikidata --> }}</includeonly>

It's not just HTML cmts but also the #ifeq for sandbox use. The plan is for any new /sandbox to omit the category links of the doc subpage. -Wikid77 00:36, 19 January 2014 (UTC)[reply]

I've been guilty of adding those many times. I mainly just copy and paste from Help:Template documentation (just changed it), which did have the shouty comment. I suspect a lot of other people did, too. APerson (talk!) 18:56, 28 January 2014 (UTC)[reply]

Curious inclusion

I recently selected "Printable version" from the "Print/export" drop-down menu for Stop the World (Aranda album). The following text appeared at the bottom of the copied, (ctrl/a), text:

<onlyinclude>{{#ifeq:{{{name}}}|Stop the World (Aranda album)|~~~~}}</onlyinclude>The following suggestions were generated by a semi-automatic [[User:AndyZ/peerreviewer|javascript program]], and might not be applicable for the article in question.

I am curious about the desirability of this text, as well as its origin? AndyZ may have insight as well.—John Cline (talk) 22:04, 21 January 2014 (UTC)[reply]

The origin is likely User:AndyZ/peerreviewer.js, which is mentioned in your vector.js. – PartTimeGnome (talk | contribs) 22:11, 21 January 2014 (UTC)[reply]

Thank you; this is helpful insight.—John Cline (talk) 00:33, 22 January 2014 (UTC)[reply]

Wdsearch.js edit request

Hi everyone. Could someone who knows JavaScript take a look at the protected edit request at MediaWiki talk:Wdsearch.js#vi? It's been open since 9 January and could do with being reviewed by someone who understands the code. — Mr. Stradivarius ^{♪ talk ♪} 23:38, 21 January 2014 (UTC)[reply]

Now done by Salix alba. — Mr. Stradivarius on tour ^{♪ talk ♪} 09:40, 27 January 2014 (UTC)[reply]

How should external protocol-relative links be implemented?

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="/upwiki/wikipedia/commons/thumb/..." and srcset="/upwiki/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="/enwiki//fr.wikipedia.org/wiki/..."
Interwiki links (commons, meta, wikidata, wiktionary etc.) - similarly, the <a>...</a> element has an attribute like href="/enwiki//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]

Protecting a table within an unprotected article

At Wikiproject medicine we're discussing the risk of vandals moving a decimal point on dose information. Is it possible to protect or semi-protect a table or section within an otherwise unprotected article? Could that be done by transcluding a protected template into the article? --Anthonyhcole (talk · contribs · email) 23:16, 23 January 2014 (UTC)[reply]

At the moment, protecting just part of an article is not technically doable, but I'd imagine the transcluding option would work. ~Hue Sat Lum 23:27, 23 January 2014 (UTC)[reply]

(ec) "No" and "yes" in that order, but my understanding is that the general rule is that templates shouldn't be used to transclude article content. See WP:Template namespace: "Templates should not do the work of article content in the main article namespace; instead, place the text directly into the article." Bencherlite ^Talk 23:28, 23 January 2014 (UTC)[reply]

However, see e.g. hydrogen and {{Infobox hydrogen}} - most (all?) of the chemical elements have the infobox separately, see Category:Periodic table infobox templates. --Redrose64 (talk) 00:03, 24 January 2014 (UTC)[reply]

Bencherlite, I wouldn't consider an edit protected table (semi-protected would be fine according to the requestor) being transcluded as a template as "doing the work of article content in the main article namespace" Since there is no way to protect part of a page (without extensions that we don't have, nor I expect will ever have on this wiki). However, that being said, perhaps PC1 protection to the whole page would be more appropriate in this case, no? Technical 13 (talk) 00:09, 24 January 2014 (UTC)[reply]

Well, if the content is being transcluded from a template, then that template is doing the work of article content since to edit the content, one has to go to the template namespace. I hadn't seen {{Infobox hydrogen}} before and I'm not sure that's a great example to follow too widely, although I see that the deletion discussion for the element infoboxes templates was a resounding "keep" a couple of years ago. Protection (semi or PC1) would depend on the level/type of edits rather than being a first step. Bencherlite ^Talk 00:19, 24 January 2014 (UTC)[reply]

Ahh, but if the template is protected, then it is the protection that makes it so that it is doing something the article can't. Technical 13 (talk) 01:47, 24 January 2014 (UTC)[reply]

Transcluding article content is generally a bad idea per the above comments, but WP:IAR is policy. I think I would only go that route if the page were protected to prevent such vandalism AND there was a followup discussion to replace the page protection with using transclusion. There is one other issue: If the page itself is not protected, any editor can just subst: in the transcluded page then edit it to his hearts content. If move-protection on the trancluded page isn't in place, he can move the transcluded page away and unless both the moved-to page and the leftover redirect are protected (they might be, I don't know how moving an edit-protected page that isn't move-protected works), he can do mischief at either the now-moved transcluded page or replace the leftover redirect with whatever he wants, likely avoiding page-watchers in the process. davidwr/(talk)/(contribs) 00:14, 24 January 2014 (UTC)[reply]

You can't move an edit-protected page unless you can also edit it, and when such a move is made, both the old and new titles have the original protection level. Jackmcbarn (talk) 02:33, 24 January 2014 (UTC)[reply]

This is true, and part of why I think it is a waste of time and better to just PC1 or semi-protect the whole page. Why would on;y part of the page need protecting? Technical 13 (talk) 01:47, 24 January 2014 (UTC)[reply]

{{EICAR test file}} and {{OpenDNS IP addresses}} were created to make protected article content, but I'm not sure it's a good idea for a whole table or section with dose information. We would probably want other parts of it to be editable, and we have a medical disclaimer. PrimeHunter (talk) 02:26, 24 January 2014 (UTC)[reply]

We'll address the advisability and policy aspects in another discussion once the technical feasibility is established. I've read all of the above and it seems to answer my question. (I'm a digital foreigner.) I'll re-read it once I've had some sleep. Thank you all! --Anthonyhcole (talk · contribs · email) 01:26, 24 January 2014 (UTC)[reply]

also, note that not only "templates" (IOW, pages in the "template namespace) can be transcluded: it's possible to transclude articles (and, indeed, pages from any namespace except "special"). also, for about a year now, it's possible to transclude arbitrary parts from another page using the little advertised extension mw:Extension:Labeled Section Transclusion. see Help:Labeled section transclusion. whether there's any policy in enwiki governing this kind of use i do not know. peace - קיפודנחש (aka kipod) (talk) 21:58, 24 January 2014 (UTC)[reply]

For context, Anthony is worried about the table in Equianalgesic. He has previously blanked it. WhatamIdoing (talk) 20:30, 27 January 2014 (UTC)[reply]

What's the essential difference between PC1 and PC2

I can't see any meaningful difference between the two forms of pending changes protection in this 2012 RFC description. Can someone tell me how they differ and (sorry the next is a bit off-topic for this thread, so brief would be good) why people would support 1 but not 2? --Anthonyhcole (talk · contribs · email) 06:39, 24 January 2014 (UTC)[reply]

With PC level 1, edits by unregistered and new users must be approved by a reviewer, while confirmed users can edit freely. PC2 means that edits by both unregistered and confirmed users (except reviewers and admins) are subject to review. It was agreed that PC2 shouldn't be used on the English WP by several past RfCs, though I don't know what the main objections against it were. SiBr₄ (talk) 10:22, 24 January 2014 (UTC)[reply]

Thank you, SiBr₄. --Anthonyhcole (talk · contribs · email) 16:20, 24 January 2014 (UTC)[reply]

The last RFC (over a year ago, not the current one) concluded that PC2 shouldn't be used for the first six months, until we figured out whether PC1 was going to be used so widely that the reviewers would be overwhelmed. (It wasn't, so they weren't.) PC2 has been used on a few articles during the time when it was allegedly "prohibited" with some success and no obvious problems, but it's not likely to be appropriate for large numbers of articles. WhatamIdoing (talk) 20:33, 27 January 2014 (UTC)[reply]

Count transclusions/links

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

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

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

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

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

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

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

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

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

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

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

Minor change to HTML diff representation

Something of a PSA here. In the past couple of days a minor change was made to the way diffs are represented in the browser interface with HTML (if anyone screen scrapes and processes that). Also, this is the same HTML that is returned by the Mediawiki API if you ask for a diff. The change caused the processing engine of my WP:STiki tool to go crazy, as I parse that HTML. Any ways, lines that used to look like:

<td class="diff-deletedline"><div>* Ivan Shawbly, a <span class="diffchange diffchange-inline">fiction</span> 
character from the television series ''[[Mona the Vampire]]''</div></td>

have become...

<td class="diff-deletedline"><div>* Ivan Shawbly, a <del class="diffchange diffchange-inline">fiction</del> 
character from the television series ''[[Mona the Vampire]]''</div></td>

The "del" tag can also be an "add". This is happening on relatively few pages (maybe 1 in 100, or 1 in 1000). One example is [1]. This shouldn't affect many, but hopefully my post can save a tool developer some time if they run into similar issues. West.andrew.g (talk) 22:04, 24 January 2014 (UTC)[reply]

I think Max recently made some changes in the diff area... Legoktm (talk) 22:07, 24 January 2014 (UTC)[reply]

That wasn't me but the precending commit, gerrit:78156. Because only I have pressed for wikidiff2 to be updated after changing the code, that change went live with my gerrit:99541 which doesn't alter side-by-side diffs even though it looks scary:) Max Semenik (talk) 00:12, 28 January 2014 (UTC)[reply]

#time: bug?

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

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

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

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

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

Navigation Popups and Mixed Content Blocking in Firefox

Ever since Firefox upgraded to version 23, I have been unable to use WP:POPUPS unless I click on the Firefox Shield Icon in the address bar and select "Disable Protection on This Page". Of course, this only works on the page selected, and only until that page is refreshed or otherwise displayed again. Has anyone come up with a way to have the Firefox Mixed Content Blocking "Feature" not function either with all Wikipedia pages or specifically in conjunction with Popups? I've already searched the Archives and if his was already discussed and solved, I seem to be unable to find it. --After Midnight ⁰⁰⁰¹ 13:52, 26 January 2014 (UTC)[reply]

@After Midnight: see [3], I've fixed it for you. The old code you were loading had "http://" which forced a load over HTTP rather than HTTPS. Legoktm (talk) 21:04, 26 January 2014 (UTC)[reply]

Thank you so very much for fixing this for me. It never occurred to me that this was an issue with my monobook. --After Midnight ⁰⁰⁰¹ 13:59, 27 January 2014 (UTC)[reply]

MediaWiki:Common.js/IEFixes.js

There's an issue being reported with IEFixes.js and IE11. IE Debugger is reporting an error at line 40

document.attachEvent( 'onreadystatechange', fixIEScroll );

that Object doesn't support property or method 'attachEvent'. Nthep (talk) 14:50, 26 January 2014 (UTC)[reply]

I wonder if this fix is still needed in IE8/9/10/11. — Edokter (talk) — 14:57, 26 January 2014 (UTC)[reply]

Apparently not. That fix was used for old IE versions in Monobook. Removed. — Edokter (talk) — 15:16, 26 January 2014 (UTC)[reply]

Consider notifying the mainteiners of forks of MediaWiki:Common.js/IEFixes.js. Helder 19:03, 28 January 2014 (UTC)[reply]

Sidebar shop link for all (but faster)

Due to end-user performance concerns, bugzilla:57939 has just been fixed, meaning that the sidebar will always link to the WMF shop. The current system delays page load by inserting the link after the fact if the IP of the user appears to be in the appropriate location. This change affects only the English Wikipedia, the only project currently ~~slowed down by~~ featuring the WikimediaShopLink extension, and will start taking effect ~~on 6 February 2014~~ tomorrow. --Nemo 20:58, 26 January 2014 (UTC)[reply]

Tech News: 2014-05

Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.

Recent software changes

Pages from Wikimedia sites now load faster in your browser thanks to "module storage", a way for your browser to save data like JavaScript and CSS on your computer to avoid downloading them again. See video. [4]
The code used to show videos has changed. You should be able to play the video on the page, with the play button on top of the video. If you see the play button on the right of the video, or if clicking on the video leads you to the original file, please file a bug or tell User:Bawolff. [5]
The Special:ActiveUsers page will be removed because it's too slow. [6]
The latest version of MediaWiki (1.23wmf11) was added to test wikis and MediaWiki.org on January 16. It will be added to non-Wikipedia wikis on January 28, and all Wikipedia wikis on January 30 (calendar).

Problems

On January 21, Universal Language Selector was turned off on all Wikimedia sites because it makes pages load slowly. If you want to use web fonts, or write in scripts that aren't on your keyboard, you need to add it as an option in your preferences. It will be turned back on when the issues are resolved. [7]
For about 20 minutes on the same day, there were problems with CSS and JavaScript due to high server load.

Future software changes

You can give comments about the new version of "Winter", a proposal to have a fixed toolbar at the top of wiki pages. [8]

Tech news prepared by tech ambassadors and posted by MediaWiki message delivery • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

09:47, 27 January 2014 (UTC)

Articles created link generates error

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

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

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

Fixed—cyberpower ^Chat_Absent 20:18, 27 January 2014 (UTC)[reply]

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

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

I also see, after a long delay:

(502) Proxy Error
The proxy server received an invalid response from an upstream server. The proxy server could not handle the request GET /xtools/.
Reason: Error reading from remote server

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

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

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

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

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

Labs server down?

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

Proxy Error

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

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

Reason: Error reading from remote server.

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

See #Articles created link generates error thread above. ~Hue Sat Lum 03:24, 28 January 2014 (UTC)[reply]

VPT not showing up at VPA again

Once again, some code I can't find (not that I know anything) on this Village Pump is preventing it from showing up at Wikipedia:Village pump (all). Ntsimp (talk) 16:06, 27 January 2014 (UTC)[reply]

Fixed in [9]. PrimeHunter (talk) 17:02, 27 January 2014 (UTC)[reply]

(edit conflict) Fixed, that <onlyinclude>...</onlyinclude> was being processed despite being tucked inside <blockquote><nowiki>...</nowiki></blockquote>. --Redrose64 (talk) 17:04, 27 January 2014 (UTC)[reply]

Kindle "loc" vs. printed page numbers

Footnotes that provide Kindle digital page numbers (loc) are showing up in the articles. Is there a way to convert these into the page numbers included in the hard copy book, i.e., if you provide the ISBN? 36hourblock (talk) 19:29, 27 January 2014 (UTC)[reply]

Many Kindle books will give you the page number, provided you have the right device (some Kindles don't show page numbers at all). If the user is around to ask, you could ask them to check. I don't think it is possible to convert using a service or formula, though. Formerip (talk) 20:20, 27 January 2014 (UTC)[reply]

There is no way to match loc and the page number in a hard copy version. And you should not try to do so, as those versions may differ in other ways. -- Gadget850^talk 20:27, 27 January 2014 (UTC)[reply]

Categories for multiple merge targets

At Wikipedia:Categories for discussion/Working/Manual there are a set of categories that have two merge targets. I am about to close another discussion with a similar outcome. Whilst the bots can do a simple Cat X -> Cat Y then delete Cat X type thing, they can't do a two targets thing, i.e Cat X -> Cat Y and also Cat Z. There doesn't seem to be any multi-step way obviously available either, i.e. I can't do a merge and delete to Y and then use Y to duplicate into Z, because Y will get deleted after it is 'merged'. Does anyone know of any automated way I could cause this to happen? Many thanks, Splash - tk 21:56, 27 January 2014 (UTC)[reply]

AutoWikiBrowser is a good semi-automated tool to do this sort of task - take a look at Wikipedia:AutoWikiBrowser/Regular expression to see how to do a whole group of categories atr the same time. עוד מישהו Od Mishehu 06:31, 28 January 2014 (UTC)[reply]

Splash: the cat-a-lot script can help here. it's a script from commons, which, for a long time, handled files only, but for more than a year now it can do non-file pages also. with "cat-a-lot", you open the category, click the cat-a-lot linkette, click "select all", set the target category, and click "copy". repeat for next one and next one and next one. except that in the last target, choose "move" instead of "copy". i haven't test it on enwiki for a long time, so you probably want to test it on a smaller scale to make sure it still works properly, and also get familiar with it. for anyone who deals with categories a lot, "cat-a-lot" is indispensable tool. see cat-a-lot in WP:US.

(limitation): note that cat-a-lot works through the category page itself, which is limited to 200 entries. if one needs to manipulate categories with thousands of members, this may not be a good choice. peace - קיפודנחש (aka kipod) (talk) 15:51, 28 January 2014 (UTC)[reply]

This sounds like it could have potential. I'll take a look once I've knocked back some more of the CfD backlog, thanks. AWB I know of but seem to have had trouble with in the past, but maybe that can be useful too. Splash - tk 19:57, 28 January 2014 (UTC)[reply]

Who or what is Widr?

Resolved

Why is {{REVISIONUSER:last}} always 122.150.119.59? Is it just me, or is that a MW bug? Technical 13 (talk) 05:01, 28 January 2014 (UTC)[reply]

Ahh-ha! Widr (talk · contribs) is the last editor to edit Last. I see. How would one go about getting the "previous" editor (not the current revision, but the one before) for the current page? Technical 13 (talk) 05:05, 28 January 2014 (UTC)[reply]

Hmm... I guess this officially means that I am around too much. :-) Widr (talk) 06:01, 28 January 2014 (UTC)[reply]
I don't think you can, apart from through the API. — Mr. Stradivarius ^{♪ talk ♪} 06:46, 28 January 2014 (UTC)[reply]

Not a bug, working as documented; see mw:Help:Magic words#Technical metadata of another page, last row of table. This is also implied at WP:VAR, but the impression given there is that only the first bulleted list takes a pagename as a parameter, whereas in fact many (but not all) of the second list do as well. --Redrose64 (talk) 12:52, 28 January 2014 (UTC)[reply]

WP:VAR is outdated and needs to be redone to reflect the changes in the command. mw:Help:Magic words#Technical metadata of another page does seem to be up-to-date. I see that parts of the discussed changes on Bugzilla (particularly comment 12 suggesting that the revision id should be allowed to be used in place of pagename) were never implemented, and that is my bad. I wonder if anyone else will expect to be able to use "curr", "prev", "last" as revision ids to use with this function and will be disappointed. Anyways. I'm glad my understand has been clarified. Technical 13 (talk) 19:37, 28 January 2014 (UTC)[reply]

Parser functions failing

In {{Service award progress}}, I have two #expr statements that consistently do not return the arithmetical sum of their inputs. Does anyone know what's going wrong? Thanks! APerson (talk!) 19:09, 28 January 2014 (UTC)[reply]

It would be useful if you could tell us what you are passing in to the template, and what you are expecting to get back out. Also, let's discuss it on the template's talk page where it should have been asked first. :) I look forward to seeing your response there. :) Technical 13 (talk) 19:40, 28 January 2014 (UTC)[reply]

I was referred here from the IRC help channel. APerson (talk!) 20:29, 28 January 2014 (UTC)[reply]

It looks like there is mismatch between how {{Service award progress/helper}} is called and what it does. If we say it's called correctly now (with a second unnamed parameter indicating a level) then I think it will do what you want by replacing {{Service award progress/level|edits|date={{{year|1970}}}-{{{month|1}}}-{{{day|1}}}|edits={{{edits|1}}}}} with {{{2}}}. PrimeHunter (talk) 23:59, 28 January 2014 (UTC)[reply]

@Technical 13: VPT is appropriate for this kind of request, as there may not be anyone watching the template talk page. — This, that and the other (talk) 02:33, 29 January 2014 (UTC)[reply]

Normally I would agree with you, which is why I said nothing the first time a few days ago when help was asked for on this template. A couple editors responded including my edit on the template. I might also agree if the question was posted on the talk page and got no answer before coming here, I guess the fact that help has been asked for here multiple times and the talk page is still a red link struck me as off and out of process. Perhaps I was having a bad day. I dunno. Technical 13 (talk) 03:35, 29 January 2014 (UTC)[reply]

Strange marks in infobox in edit mode

Could someone take a look at Journal of Near Eastern Studies in edit mode? In its infobox I see things like:

title =

What are those signs (they appear like the bottom-right corner of a square to me, if you can't see them)? Are they supposed to be there? Thanks. It Is Me Here ^{t / c} 19:43, 28 January 2014 (UTC)[reply]

Those look like your browser is rendering tabs with little squares. Since they don't impact the performance of the infobox and are only used as separators, they are not causing any problems. I went and replaced them with spaces, since the tabs ended up mis-aligning many of the parameters. APerson (talk!) 20:32, 28 January 2014 (UTC)[reply]

Random selection, is it possible?

Do we have any parser functions or other magic, that would expand on page saving time to a random page name selected from a category that is given as parameter? jni ^(delete)_{...just not interested} 20:18, 28 January 2014 (UTC)[reply]

Sort of. You can use Special:RandomInCategory/Living people, which will take you to a random page in Category:Living people, but it won't give you the actual page name. You can also get a random item from a list by using Module:Random with the syntax {{#invoke:random|item|list item 1|list item 2|...}}, but there isn't a way to get a list of pages in a category to use with it. — Mr. Stradivarius ^{♪ talk ♪} 21:54, 28 January 2014 (UTC)[reply]

Thanks! I'll see if I can cook something interesting out of those tools. jni ^(delete)_{...just not interested} 22:19, 28 January 2014 (UTC)[reply]

Template problem

I wanted to display the verses of the Bible from which the lyrics of "Turn! Turn! Turn!" were taken. The link makes it appear they come from only one verse, but I was hoping this could display all the verses. However, what I did causes the link not to go to the correct verse.— Vchimpanzee · talk · contributions · 20:25, 28 January 2014 (UTC)[reply]

Fixed - template parameter names are case-sensitive. -- John of Reading (talk) 20:41, 28 January 2014 (UTC)[reply]

Thanks.— Vchimpanzee · talk · contributions · 20:49, 28 January 2014 (UTC)[reply]

Unable to copy at the Teahouse

When I went to the Teahouse, then clicked 'Ask a question', text from the question box coludn't be copied, but text from elsewhere could be pasted into the question box. Blackbombchu (talk) 01:39, 29 January 2014 (UTC)[reply]

Is this the problem exemplified in the screencast I uploaded on bugzilla:60441#c8 or something else? Helder 09:52, 29 January 2014 (UTC)[reply]

No, the problem is in the pop-up window that appears when I click 'Ask a question'. When ever I highlight text that I typed into that pop-up box then press Cntl + C, it acts like I did nothing then when I press Cntl + V, the last piece of text I copied from somewhere other than that question box pastes instead. Blackbombchu (talk) 17:28, 29 January 2014 (UTC)[reply]

Hyperlink going to wrong page

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

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

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

Here's what's happening:

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

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

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

Template issue

Would anyone know why this template is producing the weird images on this page, as well as the extra "}}"s? I suspect it may have to do with the fact I'm modifying a template designed for different parameters than the image thing, but if anyone could help fix it, that would be great! Kevin Rutherford (talk) 02:47, 29 January 2014 (UTC)[reply]

There appears to be an extra }} before , but there may also be other issues. PrimeHunter (talk) 03:36, 29 January 2014 (UTC)[reply]

Many of the parameters in your testcases do not seem to match the parameters in the sandbox template, as far as I can tell. Maybe I'm missing something. — Preceding unsigned comment added by Jonesey95 (talk • contribs) 04:39, 29 January 2014 (UTC)[reply]

I'm not keeping that page up as much, as I am trying to work out this image thing. We have worked out all of the other kinks, but that one is what is holding it back. I could revert to an earlier version and deal with it later, but I would rather get it right now. Kevin Rutherford (talk) 04:54, 29 January 2014 (UTC)[reply]

This edit should fix it. --Redrose64 (talk) 10:47, 29 January 2014 (UTC)[reply]

How to view rev-deleted edits :O

I found a loophole recently.

1. Turn on WikiEd from Gadgets.

2. Find a revdeleted edit, if you can manage to reach the edit's diff page. It should say that you cannot view the contents because it has been revdeleted.

3. Click the WikiEd button to show the differences in each edit (the green triangle). You can now more or less see the revdeletion, kind of. Everything is in red though.

This might have to be patched. Thekillerpenguin (talk) 04:01, 29 January 2014 (UTC)[reply]

That's the revision that wasn't deleted... Legoktm (talk) 04:19, 29 January 2014 (UTC)[reply]

(edit conflict) As far as I can tell, wikEdDiff is simply treating the revdel'ed version as blank, and showing a diff betwen the visible previous version and a blank page. This causes the whole previous version to be red but doesn't reveal anything you couldn't see by just editing that version in the page history. If you really have a way to see revdel'ed content then see "Bugs with security implications" at top of this page and don't post it in public, or we may have to revdel your post (oh, the irony). PrimeHunter (talk) 04:21, 29 January 2014 (UTC)[reply]

Indeed, there's no vulnerability here. Jackmcbarn (talk) 00:48, 30 January 2014 (UTC)[reply]

Module:Documentation

Just a note that I have finished working on Module:Documentation and it's ready to replace {{documentation}} on all of our template and module pages. I'd like people to comment on it before I put it up live, so if you're interested, please join the discussion at the template talk page. Bug reports, feature requests and general questions are all welcome. :) — Mr. Stradivarius ^{♪ talk ♪} 07:55, 29 January 2014 (UTC)[reply]

Help with template code

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

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

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

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

Woops. I actually transcluded the wrong template version. Thanks anyways. Reh man 13:54, 30 January 2014 (UTC)[reply]

Database error

Tracked in Phabricator
Task T62600

For documentation only; this may be an isolated incident rather than indication of a serious problem.

Database error

From Wikipedia, the free encyclopedia

Jump to: navigation, search

A database query error has occurred. This may indicate a bug in the software. Function: AbuseFilter::checkEmergencyDisable Error: 1205 Lock wait timeout exceeded; try restarting transaction (10.64.32.26)

— Vchimpanzee · talk · contributions · 16:49, 29 January 2014 (UTC)[reply]

I have the same problem when trying to save pages. If saving does work, it is terribly slow. Ruigeroeland (talk) 16:52, 29 January 2014 (UTC)[reply]

I'm getting that as well - you can preview but whenever you try to save it (eventually) gives the message above. SagaciousPhil - Chat 16:59, 29 January 2014 (UTC)[reply]

Happened to me again. Same message.— Vchimpanzee · talk · contributions · 17:08, 29 January 2014 (UTC)[reply]

I keep getting this too, especially while using HotCat. De728631 (talk) 17:10, 29 January 2014 (UTC)[reply]

I am facing same problem.--Wikiuser13 (talk | contribs) 17:11, 29 January 2014 (UTC)[reply]

Three times. And I'm about to do some major editing.— Vchimpanzee · talk · contributions · 17:14, 29 January 2014 (UTC)[reply]

@Vchimpanzee: Try coping the content before saving and if it appears again, edit again, paste and save.--Wikiuser13 (talk | contribs) 17:20, 29 January 2014 (UTC)[reply]

This seems to be a problem of the article namespace. I guess 10.64.32.26 is one of the servers there. I've been playing with my user sandbox though and have also done some edits in category namespace and these all went just as smooth as ever. De728631 (talk) 17:24, 29 January 2014 (UTC)[reply]

I'm pleased to see that it's not just me; I've been having this same problem and I noticed that I've been triggering filter 554 with almost every edit I've made to the mainspace in the past couple of hours; as De728631 has said, non-article edits seem to be okay. Acalamari 17:27, 29 January 2014 (UTC)[reply]

Well, if it's a filter problem can someone at least temporarily disable said filter? This is obviously an untenable situation, I've been having the same issue. The Blade of the Northern Lights (話して下さい) 17:29, 29 January 2014 (UTC)[reply]

It also seems that on the occasions it eventually says the edit is saved, it hasn't actually done so? SagaciousPhil - Chat 17:32, 29 January 2014 (UTC)[reply]

Well, after 6 tries I finally just forced it through, not sure if we're in the clear yet. The Blade of the Northern Lights (話して下さい) 17:35, 29 January 2014 (UTC)[reply]

@Wikiuser13:Didn't have to, but thanks. That's what I did just in case.— Vchimpanzee · talk · contributions · 17:35, 29 January 2014 (UTC)[reply]

@Kww: I disabled it. DMacks (talk) 17:39, 29 January 2014 (UTC)[reply]

I've been having the same issue today. And it's really slow. Yesterday, I kept running into "Bad Gateway". — Maile (talk) 17:44, 29 January 2014 (UTC)[reply]
- Seems to be okay for me now... – Connormah (talk) 17:50, 29 January 2014 (UTC)[reply]

My most abject apologies ... obviously completely my fault. My only saving grace is that at least I had it running with no action while I was testing, but obviously that wasn't enough.—Kww(talk) 18:12, 29 January 2014 (UTC)[reply]

What looked weird to me is that the filter was already autodisabled due to exceeding a system limit. The timeouts I got gave error messages specifically mentioning checkEmergencyDisable, not generic database access. Seems like what should have been short-circuiting the too-expensive filter is also too expensive? DMacks (talk) 18:43, 29 January 2014 (UTC)[reply]

Meh... the extension doesn't even known how to count... Helder 18:49, 29 January 2014 (UTC)[reply]

Agreed. The emergency feature that is supposed to stop a filter blocking all edits seems to have had the opposite effect... I've logged bug 60600 for this. – PartTimeGnome (talk | contribs) 22:44, 29 January 2014 (UTC)[reply]

Everything's working for me... I was somewhat reminded of this incident. Stuff happens. The Blade of the Northern Lights (話して下さい) 18:14, 29 January 2014 (UTC)[reply]

Database query error

I've no idea if this matters at all, but, in any case, I just got the following error while trying to make this edit. Thought I should report it. J Milburn (talk) 17:41, 29 January 2014 (UTC)[reply]

A database query error has occurred. This may indicate a bug in the software.

   Function: AbuseFilter::checkEmergencyDisable
   Error: 1205 Lock wait timeout exceeded; try restarting transaction (10.64.32.26)

The same is discussed above.--Wikiuser13 (talk | contribs) 17:43, 29 January 2014 (UTC)[reply]

The problem with filter 554

This problem started with an edit to filter 554. The filter condition was changed to the following text:

article_namespace == 0 
& (
((lcase(added_lines) rlike ("top100\w*\.blog"|"charly1300")|"mickeycharts")| "atrl.net/forums")
)

I've highlighted the matching parenthesis to make this a little easier to follow.

There are two things that jump out at me about this: First, I'm not sure it makes sense to apply the | (OR) operator to quoted strings. I suspect something like "(top100\w*\.blog|charly1300|mickeycharts|atrl.net/forums)" was intended instead, with the | inside the string where it would function as the regular expression choice operator.

Secondly, note that the right-hand side operand for the rlike operator is terminated by the parenthesis after "mickeycharts". The boolean result from rlike is OR'd against the string "atrl.net/forums". I suspect the edit filter coerced the string into a boolean value because it was OR'd against a boolean value. I further guess the resulting coerced value was true. Anything OR'd against true is also true, making the condition have the same effect as article_namespace == 0 & true – i.e. it matched all edits in the main namespace.

(Note: I'm not much of an expert on edit filter syntax. I've guessed most of the above based on my knowledge of similar operators in other languages.) – PartTimeGnome (talk | contribs) 23:40, 29 January 2014 (UTC)[reply]

Yes, I certainly blew it big time.—Kww(talk) 00:35, 30 January 2014 (UTC)[reply]

Cite template

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Technical question about redirects

Moved from Wikipedia talk:Village pump (technical)

An editor just asked a technical question at Wikipedia talk:Redirect. Could one of you pop over there and answer their question, please? Ego White Tray (talk) 15:28, 29 January 2014 (UTC)[reply]

Pages very slow to load today

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

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

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

Scores app?

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

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

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

Citing web sources - ArchiveURL question Suggestion

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

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

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

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

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

Soft redirects

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

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

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

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

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

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

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

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

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

API query response

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

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

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

API query response

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

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

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

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

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

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

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

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

Changes to Education Program interface causing errors

Tracked in Phabricator
Task T62641

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

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

Customizing user experience based on logged-in status

Hi. I'd like to do the following.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Wasted space on right-hand side constraining width

Tracked in Phabricator
Task T61815
Declined

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

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

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

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

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

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

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

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

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

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

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

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

User contributions: "articles created" feature not working

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

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

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

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

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

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

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

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

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

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

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

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

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

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

DPL, revisited: Extension:DynamicPageListEngine

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

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

Templates etc do not get updated automatically

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

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

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

Transclusion count missing at action=info pages

Tracked in Phabricator
Task T62740

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

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

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

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

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

Highlighting within an article from a list of regex expressions

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

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

Do you want this script to run automagically or only if you click a link?
Clicking a link in the left-hand column, as duplinks does. - Dank (push to talk)
Which namespaces do you want it to run in? Surely there is no need for it in Talkspaces?
Articlespace and userspace (for testing)
Where is your ReGex list? If it's not already on a page, could you put it on User:Dank/Highlighter/list for me please?
Done. Comma-space-delimited, because I want to optimize it for readability by, you know, humans, but I can massage it if you like.

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

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

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

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

Indefinitely blocked IP addresses

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

Tech News: 2014-06

Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.

Recent software changes

The latest version of MediaWiki (1.23wmf12) was added to test wikis and MediaWiki.org on January 30. It will be added to non-Wikipedia wikis on February 4, and all Wikipedia wikis on February 6 (calendar).
Global AbuseFilter rules are now active on all small wikis. [10] [11]
The buttons used in pages like log-in, account creation and search are now using the same colors and styles. [12] [13]
You can now link to diffs using [[Special:Diff/12345]] and similar links. [14]
There is no longer an option to hide tables of contents on all pages. [15]
Searching in the File: namespace on Wikimedia Commons is now faster, after a bug was fixed on January 29. [16]
All Wikimedia wikis now have high-resolution favicons. [17]

VisualEditor news

You can now see a list of keyboard shortcuts by pressing Ctrl+/ inside VisualEditor. [18]

Future software changes

Edits and files hidden with the Oversight tool will be moved to the RevisionDelete system. The Oversight tool will then be removed from Wikimedia wikis. [19] [20] [21]
For languages where not all sister projects exist, you will be able to link to other language projects using double interwikis (:ko:v, :v:ko, etc.). [22]
It will soon be possible to use the GettingStarted tool on other wikis than the English Wikipedia. You can translate it on Translatewiki.net. [23]
You will soon be able to include the Special:Contributions page into other pages. [24]
You will be able to see where a file is used inside MultimediaViewer, the new tool for viewing media files. [25] [26]
It will soon be possible to send MassMessage messages using the API. [27]
You will soon see audio statistics on the Special:TimedMediaHandler page. [28]

Tech news prepared by tech ambassadors and posted by MediaWiki message delivery • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

08:30, 3 February 2014 (UTC)

Fraction formats

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

superscript+subscript format: ²⁷⁄₃₂, ³⁄₄ as 3&frasl;4
superscript+small format: ²⁷/32, ³/4 as 3/4

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

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

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

"Search"

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

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

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

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

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

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

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

New extension: Flow

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

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

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

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

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

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

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

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

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

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

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

Cirrus now a Beta Feature

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

@@ Line 761: / Line 761: @@
 :So does this mean that Flow-enabled pages will basically be non-editable by bots and user scripts until the API is done? Documentation on this is all very sparse and poorly organized. Nor is it very clear where the community should provide feedback. <span style="font-family:Broadway">[[User:Mr.Z-man|Mr.]][[User talk:Mr.Z-man|'''''Z-'''man'']]</span> 18:35, 3 February 2014 (UTC)
+:: Yes. The initial project pages flow is being released to were chosen in part because they see very little, if any, bot activity. There is no documentation for the API because we do not want anyone developing against the Flow API at this time.  The API that has been exposed is not an API in the classic mediawiki sense, it is a shim that exposes the internals of Flow's implementation.   It requires knowledge of these internals to construct a proper request currently, and is only intended for use with the AJAX requests used by the web interface.
+:: If you wish to provide feedback on Flow in general i can suggest [[mw:Talk:Sandbox]] for testing and [[mw:Talk:Flow]] for feedback.  The release to enwiki is incredibly limited and targeted, If you are not a member of the two wiki projects we are testing with you wont have a chance to use Flow on enwiki. We kindly ask that users do not disturb the wikiprojects from their normal workflow's by going off-tangent about flow in their project pages. If you are a member of a wiki project that was not chosen and would like to propose the project for being converted to Flow in the future [[User:Quiddity]] is our community point person, but I'm not sure we will be expanding from the current group of two pages too soon.  We expect to find many things, based on this initial test group, that will need to change before its worthwhile for anyone to build a bot or user script integrating with flow.
+::[[User:EBernhardson (WMF)|EBernhardson (WMF)]] ([[User talk:EBernhardson (WMF)|talk]]) 19:42, 3 February 2014 (UTC)
 == Cirrus now a Beta Feature ==