Wikipedia:Village pump (technical)/Archive 146

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search

Contents

Watchlist: pages that have changed

Follow-up to Wikipedia:Village pump (proposals)#Watchlist: pages that have changed

To indicate a change since last visit in items on a watchist, the tiny green dots (bullets) are not as immediately distinguishable from the tiny blue dots as would be yellow or amber dots. Would it not be better to use yellow or amber dots?

I think the previous discussion concentrated on the shape, not the colour, and so I make bold to raise the question again. Theodoxa (talk) 11:18, 27 April 2016 (UTC)

Color was discussed as well. Other colors did not fit the scheme of the interface, while green ususally indicates change. -- [[User:Edokter]] {{talk}} 13:47, 27 April 2016 (UTC)

Some API + javascript help needed

I want to add a link into toolbox portlet to Google with query text: "German Wikipedia's pagename". So I need make an API call to get dewiki pagename. Code, what I have come up with:

$(function () {
	var req = new XMLHttpRequest();
	req.open("GET", mw.config.get('wgScriptPath') + "/api.php?action=query&format=json&prop=langlinks&redirects=1&lllang=de&titles="+encodeURIComponent(title), false);
	req.send(null);
	var response = eval('(' + req.responseText + ')');

 mw.util.addPortletLink(
  "p-tb",
  "https://www.google.com/search?q=" + response,
  "google"
)});

I'm 100% sure, that above is completely wrong, at least the API part (but the query itself should be OK). So maybe somebody could translate that piece into working code. Would be nice, that

  • the link doesn't show up, if there isn't dewiki article
  • variable "response" should get PAGENAMEBASEd (remove parenthesis, if there are such). --Edgars2007 (talk/contribs) 16:14, 27 April 2016 (UTC)
// Guarantee that our dependencies are loaded
mw.loader.using( [ 'mediawiki.api', 'mediawiki.util' ], function() {
  var api = new mw.Api( {
    ajax: {
        // Use a user agent, so that sysadmins can find you and tell you to fix your tool
        headers: { 'Api-User-Agent': 'MyAPITool/1.0' }
    } } );

    api.get( {
      // Use the new output structure of the api
      formatversion: 2,
      prop: 'langlinks',   
      lllang: 'de',
      titles: mw.config.get( 'wgPageName' ),
      redirects: true
    } ).done( function( data ) {
      if ( !data.query.pages[0].langlinks.length ) {
         // no german langlink for this page
         return;
      }
      var title = data.query.pages[0].langlinks[0].title;
      // Strip parenthesis
      title = title.replace( /\s\(.*\)/, '' );

      // Add when page is ready  
      $( function() {
        mw.util.addPortletLink(
          'p-tb',
          'https://www.google.com/search?q=' + encodeURIComponent( title ),
          'google'
        );
      } );

    } ); // add .fail promise if you want to handle errors
} );

Something like this should do it... I didn't test it, but it should show the general direction. —TheDJ (talkcontribs) 16:52, 27 April 2016 (UTC)

I wrote a script that does something like this a long time ago. User:Writ Keeper/Scripts/googleTitle.js. Basically, if I'm just trying to get the name of the page I'm on, I wouldn't bother with the API call-- just use the wgPageName variable (mw.config.get("wgPageName") is the right syntax these days, I think) and remove the parens/urlencode/whatever on my own. EDIT: Oh, crap, didn't realize you're looking for dewiki's article from enwiki. Well, nevermind, I'll just leave this for the record of my poor reading comprehension. Writ Keeper  16:55, 27 April 2016 (UTC)
Thanks, TheDJ! It works. --Edgars2007 (talk/contribs) 17:14, 27 April 2016 (UTC)

Removal of conversion templates from infobox that converts anyway?

This straddles technical and policy issues, so I'll keep it short. Are edits such as this one desirable since the template it's used in appears to automatically convert the measurements into the desired form anyway? (Related to my comments in this thread). Ubcule (talk) 20:35, 26 April 2016 (UTC)

Template:Convert is called twice, (they all use convert), and that does not seem efficient. But don't worry about performance. Stylistically there could be made an issue concerning the "proper number of significant digits" to display (the previous version having three significant digits in the height), and another issue to debate could just be the "cleanliness" of having a straight input with no template. But the source sometimes mandates the template input (WP:Verifiability, and thus conversion (WP:Reliability), per MOS:CONVERSIONS. — CpiralCpiral 22:21, 26 April 2016 (UTC)
@Cpiral: Thanks for the response; I'm still not 100% sure if I was in the right or not- I think your intended answer is that this doesn't really matter anyway?..!
(FWIW, the reason I initially made the edits wasn't for performance or style reasons, but because someone had changed it from the template style to the plain style- without making clear the reasoning or the fact that the parent template still did the conversion anyway. If I'd known that, I might have had second thoughts in the first place).
Ubcule (talk) 18:12, 27 April 2016 (UTC)

mobile view, interwiki and categories

I noticed something that puzzled me, and am curious to know if it's known, is it intentional, and what the community thinks:

I have an android device, with 2 browsers: an inbuilt one (not even sure how it's called: android shows it as "internet"), and google chrome. With the inbuilt one and with Brion's hack ("Mobile sidebar preview" in preferences => gadgets), I have 2 buttons under each article: "Talk" and "Read in other languages" (assuming article has interwiki), and no link to categories. with chrome on android, I have "Talk" and "Categories", but no interwiki. This happens regardless if I'm logged in or not. Can anyone corroborate? Is it something only I can see? And if others see the same thing, is this intentional? should I report a bug? (I noticed some other small discrepancies, e.g., some pages on some browsers show a folding "toc", while other pages/browsers don't). peace - קיפודנחש (aka kipod) (talk) 19:53, 27 April 2016 (UTC)

Is it possible to fix my account create date?

Hi, I'm trying to figure out why my account has the wrong start date (it is probably connected to the switchover from UseModWiki to MediaWiki in 2002). This report says I started Jan 26, 2002. However my edit summary gives my first edit as September 24, 2001. Is there anyway this could be fixed? Manning (talk) 01:10, 27 April 2016 (UTC)

Not from here, no. You would need to ask somebody with sysadmin rights - and they might refuse. The place to make such requests is phab:. --Redrose64 (talk) 10:03, 27 April 2016 (UTC)
Sweet thanks. Manning (talk) 04:39, 28 April 2016 (UTC)

Earth to JDForrester

Wikipedia:Village pump (technical)/Archive 145#Do you want one Edit tab, or two? It's your choice, and especially the subsection "VE was imposed as primary editor", have been archived. User:Alsee was told off last week because he wasn't patient enough and User:Jdforrester (WMF) had no time then to address this, but his interpretation that nothing would be forthcoming the week after that comment (the 14th) was completely misguided.

Sure enough, it's the 21st, and the product manager, who promised before the implementation that VE would not be the primary editor on enwiki, has still not responded anywhere about this. He has edited a lot of other things, and must have seen the messages on his talk page, but apparently acknowledging that something seems to have gone wrong and that you will look into it (preferably with some timeline) is too hard. Easier to just let it archive and forget about it. If only we had some people at the WMF who could drop you a note at your talk page there, some WMF-community intermediaries or something similar. Oh well, we can always dream... Fram (talk) 12:12, 21 April 2016 (UTC)

I left a post for the Executive Director noting that we were assured that this was not going to happen, and that we have been unable to get any response on it. Alsee (talk) 01:51, 24 April 2016 (UTC)
Weren't you told off at some phabricator ticket for saying that Jdforrester wasn't going to respond last week, when they were certain that that would happen and that the lack of communication was only for the week of the 13th? It's the only fast reaction we have had in all this, and it was of course incorrect... It has been archived here once, at least thanks to Flow it can't get archived at his talk page. We have a new deployment this thursday, I presume, if it isn't fixed by then it is just another giant FY against enwiki and another lie by the same people at the WMF. But we need to respect them and work together instead of against each other, of course. Still waiting for that to happen from there to here... Fram (talk) 14:51, 25 April 2016 (UTC)

@Elitre (WMF):, can you ask Jdforrester when he plans to reply to these concerns, and when he plans to actually do something about them? If he has done either meanwhile, great, last time I looked a could find a lot of activity but nothing about this, despite posts on his talk page. If we need to contact him at another (public) location, feel free to post a link to whatever page is best to reach him. It has been two weeks now... Fram (talk) 10:18, 27 April 2016 (UTC)

He has already replied at one of the countless venues where related questions were posted ;) Best, --Elitre (WMF) (talk) 15:41, 27 April 2016 (UTC)
Thanks. Apparently he doesn't even check his talk page, weird... Fram (talk) 06:40, 28 April 2016 (UTC)

table

What is the value to make a table length freeform? It will be the entire length of the page section available. Does this make sense? Moscowamerican (talk) 04:49, 26 April 2016 (UTC)

@Moscowamerican: If I understand question correctly, then answer is - it's by default. --Edgars2007 (talk/contribs) 07:21, 26 April 2016 (UTC)
A table's logical dimensions are governed by the presence or absence of a caption, the number of rows and the number of cells per row; the HTML specs do not set a maximum for either of the latter two, but there is a maximum of one caption. The amount of content in each cell does not affect the logical dimensions.
A table's physical dimensions (measurements in pixels) depend upon many factors, and are not consistent between browsers even when installed on the same computer. It is not a good idea to design a table for a particular width or height, since something as trivial as the fonts that are installed on the viewing user's computer can significantly alter the size of the text, and thus the amount of space occupied by that text, and hence the table dimensions. What looks good on your computer might not look good on mine, and certainly won't look the same on everybody else's. --Redrose64 (talk) 07:41, 26 April 2016 (UTC)

Oh. okay thank you (talk) (talk Moscowamerican (talk) 09:04, 28 April 2016 (UTC)

Possibly unfree file templates

I've just tagged a couple of files as possibly unfree at Wikipedia:Possibly unfree files/2016 April 26 but the templates aren't working on that page and the uploaders' talk pages. The file page template does however show up. I copied and pasted the template from the file page onto the talk pages. Cloudbound (talk) 21:50, 26 April 2016 (UTC)

  • PUF has been closed. Please make your nominations at FFD. BethNaught (talk) 21:52, 26 April 2016 (UTC)
BethNaught and Peter James, thanks for your responses. Cloudbound (talk) 17:19, 28 April 2016 (UTC)

Search Contribs AFTER a Specific Date

Currently Wikipedia allows users to search contribs made before a specific month/year. However, when dealing with IP vandalism who hop around, it would be exceedingly useful to be able to search contribs made after a specific month/year (especially when combined with wildcard and range searches). Is this currently possible? If not, how do I go about suggesting it? Please ping me in reply. Thank you! EvergreenFir (talk) Please {{re}} 06:55, 28 April 2016 (UTC)

Yes, go to their contribs page, click the "older 50" link, and then the "newer 50" link. Notice that the URL's query string now contains something like &dir=prev&offset=20160427095616 (among other things). Here, the dir=prev means "start at the specified date/time and go forwards in time from that point", and offset=20160427095616 is the start point, formatted CCYYMMDDhhmmss, so this works out as 09:56:16, 27 April 2016. You can set your own start point by adjusting that to a different date and time, so to give all contributions made at or after 12:00, 1 April 2016 (UTC) you would use &dir=prev&offset=20160401120000. --Redrose64 (talk) 11:38, 28 April 2016 (UTC)

As a matter of interest, with a certain gadget enabled (see the note below), it is possible to view the contributions of a range of IPv4 or IPv6 addresses, in the last N months. For IPv4, you would need to enter a range, say /24, but for IPv6 a single IP defaults to showing /64. Two examples follow. The first defaults to showing edits in the last month, while the second specifies edits in the last three months.

  • {{blockcalc|142.105.159.0/24}}
  • {{blockcalc|months=3|2601:188:0:ABE6:65F5:930C:B0B2:CD63}}
Total
affected
Affected
addresses
Given
addresses
Range Contribs
256 256 256 142.105.159.0/24 c
Total
affected
Affected
addresses
Given
addresses
Range Contribs
1 /64 1 /64 1 2601:188:0:abe6::/64 c

Johnuniq (talk) 12:01, 28 April 2016 (UTC)

@Johnuniq and Redrose64: Thank you both. I'll make sure I have that gadget enabled (I think I do) and that trick with the url query will work. It would be nice if we could get a less cumbersome way of doing it (like the dropdown menus for seeing edits before a certain date. EvergreenFir (talk) Please {{re}} 19:14, 28 April 2016 (UTC)

Can a template detect if it is called with an uncapitalized (lowercase) initial letter?

Is there any way a template can detect if it is called with an uncapitalized initial letter? E.g., could the (say) {{H}} template distinguish between being called as {{H}} and {{h}}? ~ J. Johnson (JJ) (talk) 23:15, 27 April 2016 (UTC)

No; this isn't limited to templates either, this is a mediawiki built-in on Wikipedia (but not Wiktionary). Any page is case-insensitive in its first letter. MediaWiki sees Main page as exactly equivalent to main page. Intelligentsium 23:18, 27 April 2016 (UTC)
I'm pretty sure a template invoking some specific Lua could, but am a learner and deathly tired so can't currently say exactly how. fredgandt 02:14, 28 April 2016 (UTC)
The question comes down to where the case-flattening is done. E.g., a template {{mw}} exists, showing that the namespace tolerates uncapitalized names. And when a template (like articles) is reached via a redirect, the name actually called is displayed, so some kind of information about the called name comes through.
Of course, if there is some way of distinguishing this, and some idiot applied that some where, then every thing we have told everyone about the first letter being case-insensitive would be wrong, and hell would break loose. So maybe I don't want to know? Face-surprise.svg ~ J. Johnson (JJ) (talk) 18:26, 28 April 2016 (UTC)
{{mw}} only displays lower case at top of the page because it transcludes {{lowercase title}} from {{Mw/doc}}. The real pagename is Template:Mw. PrimeHunter (talk) 18:42, 28 April 2016 (UTC)
Also, Template:Mw and template:mw are exactly the same page - no redirection is performed. Try going to wp:vPT, which is a redirect - you'll see that it says at the top "(Redirected from Wikipedia:VPT) - the capitalisation was already adjusted before the redirect was acted upon. It might be possible (and I promise nothing here) for Lua code to be able to detect if a template (or other page) was reached via a redirect, but Lua cannot tell if capitalisation was altered in the ways I've just demonstrated. --Redrose64 (talk) 19:05, 28 April 2016 (UTC)
Ah, I see. (I did forget about the transclusion.) Thank you all. ~ J. Johnson (JJ) (talk) 21:22, 28 April 2016 (UTC)
It's possible for Lua modules to see what template they were called from by using frame:getParent():getTitle(), but there's no way at the moment to tell whether that template was accessed via a redirect or not. — Mr. Stradivarius ♪ talk ♪ 02:00, 30 April 2016 (UTC)
@J. Johnson: - why do you ask? fredgandt 21:22, 28 April 2016 (UTC)
I was curious. I stumbled across {{mw}}, and got to wondering. And it did occur to me that there might be a use for such a property in a narrow set specialized templates. But they're fairly dubious, so I am glad this property does not exist. ~ J. Johnson (JJ) (talk) 21:33, 28 April 2016 (UTC)
Well as I said, Lua can read (and parse, and execute, and expand ...) the page content, so can (with effort) determine if the markup has an initial capital or not, but with no good reason to do it - meh.
A template could more easily correct itself by substituting a call to it with markup that's guaranteed to be one way or the other (if that was ever a concern). i.e. {{example|foo=bar}} could be automatically replaced with {{Example|foo=bar}}. Note: If either were called to be substituted, the case of the first letter wouldn't matter. fredgandt 22:22, 28 April 2016 (UTC)

Template:Not English/dated prodding pages?

I noticed that the pages User:Chole72/sandbox, Draft:Detective Willy, and User:Fc20/Sequência algorítmicamente aleatória all now show up in Category:Proposed deletions needing attention, due to them being non-articles with prod tags. In each case, the last edit to the pages was an edit by AnomieBOT on November 14, 2015 to subst Template:Not English/dated. It seems that it is that template which is adding the prod tags, but somehow it seems to be malfunctioning. Can someone with more knowledge of templates than me figure out what is going on and how to get the template to stop prodding these pages (being outside article space, they aren't eligible for prod)? Also, should the template even be prodding anything at all? A prod tag is supposed to be able to be removed by anyone for any reason, but in this case when you go to edit the pages, there isn't even a prod tag there to remove. I suppose someone could object to the proposed deletion by editing or removing the Not English template, but I personally don't think obfuscating how to object to prods is a good idea. Calathan (talk) 15:15, 29 April 2016 (UTC)

It looks like User:Liz has removed the Non English template from the pages, which means they are currently no longer proposed for deletion. However, I'm still hoping someone who understands templates can figure out why the template was placing the prod tags on them. Looking at the template code (which I don't understand well), I think the template was supposed to prod them after 14 days, but instead it was prodding them after about 6 months. I would still prefer that it doesn't try to prod them at all. Calathan (talk) 17:50, 29 April 2016 (UTC)
Yes, I removed the PROD tags and posted a note on Anomie's talk page about it. I think the problem was that the {{Not English}} tags had a timestamp which is unusual for a simple tag. Then, they turned into expired PRODs. Since PRODs are not used on User or Draft pages, PRODs are not appropriate deletion tools for these pages. Liz Read! Talk! 17:54, 29 April 2016 (UTC)

I just did some more searching around, and I think I've figured out more about what is going on here. Based on Template talk:Not English#Dated, User:Rayukk tried to make Template:Not English propose articles for deletion after 14 days, and about a day later User:Jac16888 disagreed with that change and undid it. Template:Not English/dated was something Rayukk made to implement this, and Template:Not English was only using the dated template for a brief time until Jac16888 undid the change. So the pages that are getting prodded are just those where Template:Not English was substituted during that brief period of time. I think all that needs to be done is to replace Template:Not English/dated on any page that uses it with the current version of Template:Not English. I'll go ahead and do that. The issue with Template:Not English/dated prodding pages is basically moot, since that template shouldn't actually be used anywhere. Calathan (talk) 18:29, 29 April 2016 (UTC)

Actually, I need to get to work (on my actual work, not Wikipedia), but if someone else could go through the pages that link to Template:Not English/dated and change them to use the normal Template:Not English, I think that would solve the problem. If no one else has time, I'll try to do that when I have more time. Calathan (talk) 18:40, 29 April 2016 (UTC)
Sorted, in most cases I just removed it, it's only left now on a few testing pages--Jac16888 Talk 19:42, 29 April 2016 (UTC)
Template:Not English/dated has now been sent to WP:TFD. GeoffreyT2000 (talk) 04:15, 30 April 2016 (UTC)
Thank you Jac16888 and GeoffreyT2000 for taking care of this. Calathan (talk) 04:36, 30 April 2016 (UTC)

Checklinks

Why is not working [1]? Xaris333 (talk) 14:35, 30 April 2016 (UTC)

What is not working for you? I see the interface and headings but as expected no list of links since Atromitos Yeroskipou has no external links. PrimeHunter (talk) 16:16, 30 April 2016 (UTC)

Sorry. I was using the Greek version. [2] Xaris333 (talk) 16:46, 30 April 2016 (UTC)

The tool appears to be broken for some foreign languages. There is a report about Romanian at User talk:Dispenser#Checklinks. Checklinks is made and run by Dispenser. PrimeHunter (talk) 21:01, 30 April 2016 (UTC)

Is it malicious ?

Preview says:

Code that you insert on this page could contain malicious content capable of compromising your account. If you are unsure whether code you are adding to this page is safe, you can ask at the appropriate village pump. The code will be executed when previewing this page.

What it was inserted was

/* Hide TemplateData from your display */
.templatedata-header,
.mw-templatedata-doc-wrap,
.tdg-editscreen-main {
    display: none;
}

I dont think it is capable of compromising one's account. --にょろん (talk) 13:07, 1 May 2016 (UTC)

@にょろん: It isn't. Just a standard template message. - NQ (talk) 13:12, 1 May 2016 (UTC)
I see. Thanks. I would think adding a preview input form like template or module page to be sure it will not compromise my user page and other article pages, if technically possible. --にょろん (talk) 13:17, 1 May 2016 (UTC)

Deleted pages

On my last few runs of tagging uncategorized articles for the categorization project, the list has been polluted with several phantom entries for non-existent pages, as well as one page which does exist and is properly categorized, but will not drop from the list no matter what I do — a null edit won't work; decategorizing it and recategorizing it again won't work; and even the trick of last resort, deleting and then restoring the page, won't work.

The common element to the deleted pages is that they were all deleted on April 22 — and the page which does exist is a recreation of a page that was previously deleted, again on April 22. So clearly some kind of data corruption issue occurred on that date.

The articles are: Graffiti in Early Modern England, How to create wikipedia page, Ideographic world, LinksManagement, Redmoments, Revatha College, Balapitiya and Rvijayjha.

The last time I reported an issue like this, I was forced to tolerate the phantom titles as permanent speedbumps of the list, which had to be repeatedly worked around for six full months before they finally got cleared from the list. In order to properly work with this tool, however, I need it to be clean. I'm willing to wait a few days of delay if need be, but I will not tolerate it taking six months to get these entries off the list again: this needs to be fixed as close as feasibly possible to right away. Bearcat (talk) 01:09, 1 May 2016 (UTC)

@Bearcat: are you showing something in side of enwiki being wrong, or just in that wmflabs tool? If only on the tool please contact its maintainer here: User_talk:JaGa. — xaosflux Talk 01:16, 1 May 2016 (UTC)
The last time this came up, the issue was not with the tool, but with corruptions within the data that enwiki was feeding to it — JaGa was completely unable to do anything about it the last time, because the tool wasn't the problem and it had to be fixed on this end. Bearcat (talk) 01:18, 1 May 2016 (UTC)
Thank you, so to be clear - everything inside of enwiki looks fine, correct? The tool maintainer may need to help identify what is going on - there could also be a database replication problem on the copy at wmflabs. — xaosflux Talk 01:28, 1 May 2016 (UTC)
I noticed something similar the other day and commented at phab:T115517#2248620. Anomie 22:39, 1 May 2016 (UTC)

Notifications glitch?

I just receive an errant notification "Uncle Milty mentioned you on Wikipedia:Articles for deletion/Bocconi Toastmaste..." The notification links to the closed AfD in which my username does not appear. The edit by Uncle Milty mentions Bbb23, but not me. Does anyone know what might have caused this?- MrX 22:17, 29 April 2016 (UTC)

The cause is an accidental transclusion, like the one that caused /Archive 145#Bogus alerts. --Pipetricker (talk) 22:43, 29 April 2016 (UTC)
I too was pinged, but nowhere in the diff or the page do I see my name. [3]cyberpowerChat:Online 22:47, 29 April 2016 (UTC)
The attempted user-linking {{User:Bbb23}} in that diff caused the page User:Bbb23 to be transcluded, and your signature (with a link to your user page) is on that page. --Pipetricker (talk) 23:06, 29 April 2016 (UTC)
You can transclude pings? Oh wow, am I going to have fun with that!- MrX 00:33, 30 April 2016 (UTC)
Yes, otherwise the {{ping}} template wouldn't work. Unfortunately, with wikitext there's no easy way to tell whether a transclusion was accidental or not, leading to problems like this one. To mitigate this somewhat there is an upper limit on the number of users you can notify in one edit (I think it is 50 at the moment). By the way, if you find yourself pinging the same 50 users a lot, you might consider using {{mass notification}}, which makes the process (rather scarily) efficient. — Mr. Stradivarius ♪ talk ♪ 01:12, 30 April 2016 (UTC)
Ping is always preceded by u| so looks like it isn't a notification problem. 49.148.4.159 (talk) 14:14, 2 May 2016 (UTC)
{{u|Example}} is just one of the ways to make a link to a user page to cause a ping, but wasn't involved here. --Pipetricker (talk) 16:34, 2 May 2016 (UTC)
Notifications are triggered by a link to a user page. It does not matter whether that link was in the form of a wikilink, or through a template like |u=, or by transcluding a page that contains links. The essential feature is that user page(s) are linked. --Redrose64 (talk) 18:53, 2 May 2016 (UTC)

Tech News: 2016-18

20:09, 2 May 2016 (UTC)

Watchlist message problems

Please see MediaWiki talk:Watchlist-details I think something screwy is going on with the styling for this tag. — xaosflux Talk 02:46, 3 May 2016 (UTC)

watchlist-message

^--Ghost header! — xaosflux Talk 02:46, 3 May 2016 (UTC)

Almost wondering why clicking it did not anchor. --QEDK (T C) 19:07, 3 May 2016 (UTC)
It is haunted! But for a longer explanation in progress see MediaWiki talk:Watchlist-details. — xaosflux Talk 19:19, 3 May 2016 (UTC)
Most of MediaWiki talk:Watchlist-details#watchlist--message is not relevant here. The explanation for the "ghost heading" (n.b. not header) is that the HTML for that subheading (omitting the "[edit]" link) is
<h3><span class="mw-headline" id="watchlist-message">watchlist-message</span></h3>
and the normal CSS has the rule
.client-js #watchlist-message { display: none; }
so all you need to do is add, change or remove one character from the heading, which will alter the id= and so it will no longer match the simple selector #watchlist-message, so the declaration display: none; will not be applied. --Redrose64 (talk) 19:24, 3 May 2016 (UTC)
Should be fixed now. -- [[User:Edokter]] {{talk}} 19:52, 3 May 2016 (UTC)
  • Thank you, looks good again. — xaosflux Talk 19:56, 3 May 2016 (UTC)

Enable section link gadget

Hello,

If I recall correctly, a few years ago sections in an article had a link that changed the url to that section's url. This was done, I think, with a header.

For instance, clicking a small chain on the section History on Wikipedia would take us to Wikipedia#History. That function appears to be gone now, is there a way to turn it back on? With a gadget, extension or something else?

I hope this is the correct place for this, thank you. Kripmo (talk) 20:27, 3 May 2016 (UTC)

@Kripmo: Perhaps User:Bility/copySectionLink? - NQ (talk) 20:54, 3 May 2016 (UTC)
Worked as intended, thank you very much. Kripmo (talk) 21:39, 3 May 2016 (UTC)

Help! - email not working

When I attempt to send email to other users the email appears to be accepted but in fact nothing happens. Ie. the recipients are reporting "not received" and when I try with "send a copy to myself" I get nothing. I have gone into my Preferences and tried changing the email address or even cancelling it but it remains obstinately set to its original value. — RHaworth (talk · contribs) 21:53, 3 May 2016 (UTC)

Does the preference page indicate that your email address is confirmed? --Tagishsimon (talk) 21:59, 3 May 2016 (UTC)
Special:ChangeEmail is currently broken (phab:T134246) but there is a workaround for that bug: Request a new confirmation mail. Ignore the original confirmation mail if you received it. Some email services like Yahoo block Wikipedia mails (phab:T66795). Try mailing me. I always get Wikipedia mail in seconds. PrimeHunter (talk) 22:23, 3 May 2016 (UTC)
Small world. Was just looking if this was a wider problem but bumped into the person trying to send me the email! RHaworth graciously tried to send me the email twice too. I get the notification/alert on wikipedia but nothing arrives to my gmail, checked spam and address is verified on wiki. I did get a mail the day before when another person {{ping}}'d me. ShadessKB (talk) 23:51, 3 May 2016 (UTC)

Hopefully now fixed. My inability to send was probably because I was using an @Yahoo address. phab:T66795 was raised two years ago so why has it only affected me in the last few days? After multiple attempts I managed to get the work around to work and have changed the email address. — RHaworth (talk · contribs) 13:56, 4 May 2016 (UTC)

Possibility of a compromised account

I got an email saying an IP (other than my own) requested my password be changed, although the IP did not have my email address so my account couldn't be compromised. Is there a way of reducing the chances of this happening? I'll try to change my password every so often for now. Thanks, Rubbish computer (HALP!: I dropped the bass?) 17:03, 4 May 2016 (UTC)

I don't think so. You get that message if you put an existing username into the field at Special:PasswordReset (for any account with an e-mail address associated with it). So you innocently try to register an account, you guess a username that's already in existence, and you think, "Hey, I must have already created an account, so I'll just go login. Hmm, can't remember the password. Well, I'll just reset it." And then you get a worrisome-looking e-mail message, even though nobody has done anything malicious. (Side note: A strong password on your e-mail account is probably more important than regularly changing the password here.) Whatamidoing (WMF) (talk) 17:31, 4 May 2016 (UTC)

Double padlocks etc. questions

In case of pages with 2 kinds of protection, why don't both show up? Also, why did the padlock change in this case. --QEDK (T C) 19:03, 3 May 2016 (UTC)

There is something deliberately built into Module:Protection banner so that only one prot padlock is displayed. IIRC it's the edit protection one if the page has any level of edit protection; a move-prot green lock is only shown when the move prot level is higher than semi and there is no edit protection. Mr. Stradivarius (talk · contribs) knows more about that module than anybody else, but Jackmcbarn (talk · contribs) comes an easy second. --Redrose64 (talk) 19:30, 3 May 2016 (UTC)
@QEDK: If one kind of protection renders another kind of protection pointless, display of the pointless protection is automatically disabled. See Module talk:Protection banner#Misleading icons and text. Edit and move protection at the same level qualify for this, since you can't move a page that you can't edit. As why the padlock changed in the other edit, it's not valid to specify action as a positional parameter. Also, you're supposed to use {{pp-move-vandalism}} rather than trying to force {{pp-vandalism}} to work for move protection. Jackmcbarn (talk) 19:38, 3 May 2016 (UTC)
I used pp which I assume works for all. Also, why can two banners be displayed if you're using that logic for topicons? --QEDK (T C) 09:50, 4 May 2016 (UTC)
@QEDK: Yes, pp works for all. What do you mean about two banners? Jackmcbarn (talk) 17:48, 4 May 2016 (UTC)
The banner that is displayed when you do not set a |small=yes parameter. --QEDK (T C) 18:22, 4 May 2016 (UTC)

List instances of template

Is there a way to find all pages where a specific template is directly invoked (short of searching a database dump)? That is, places where {{example}} exists, but not pages where a template that transcludes Template:example, for example {{Transcludes example}}, is included. I'm guessing not, but it's worth a try. —  crh 23  (Talk) 20:18, 26 April 2016 (UTC)

@Crh23: try searching: insource:/\{\{example/i. --Edgars2007 (talk/contribs) 20:31, 26 April 2016 (UTC)
Thanks, I think that largely solves it. Are there server loading problems with running complex insource:/ searches? —  crh 23  (Talk) 20:51, 26 April 2016 (UTC)
When a query takes to long to execute, you will get truncated results. But this is relatively simple and unique enough. (complex and common would be problematic). —TheDJ (talkcontribs) 21:09, 26 April 2016 (UTC)
More specifically - insource:/[^{][{]{2}[Ee]xample[}]{2}[^}]/ fredgandt 20:43, 26 April 2016 (UTC)
Out of interest, is there an advantage to using /[Ee]xample/ over /example/i or /[{]{2}/ over /\{\{/? —  crh 23  (Talk) 20:51, 26 April 2016 (UTC)
Since template names are case sensitive, searching insensitively (the i denotes this) is inadvisable. The rest of the changes I suggested filter out {{{example}}} and {{examples are awesome}} etc. Specifying /[^{][{]{2}[Ee]xample[}]{2}[^}]/ is specifying:
  • "E" or "e" followed by "xample" where that word is preceded by two opening braces not preceded by any opening braces and followed by two closing braces not followed by any closing braces.
The end result being only the exact results you want. What it doesn't do is account for the possible use of <nowiki>...</nowiki> or <pre>...</pre> or the like, which would be an epic regex since the tags might not be immediately wrapping the template markup.  fredgandt 23:33, 26 April 2016 (UTC)
Of course (I thought as falling asleep last night) there are a few cases where the template may be used in other templates that would result in preceding and/or following braces. fredgandt 10:51, 27 April 2016 (UTC)
I just tried making it more specific and account for whitespace and the possibility of arguments that I completely forgot to account for before (derp), but the server(s) rejected it. It did however occur to me that the easiest and most effective way to find them (whatever they are) is to add a hidden tracking category to the template you're hunting. fredgandt 19:42, 29 April 2016 (UTC)
@Crh23: A query near the bottom of this page, highlighted the use of the search filter hastemplate:example which might be handy. It's also highlighted that the search regex sucks badly and doesn't work as any rational person would expect. Fred Gandt (talk|contribs) 19:52, 4 May 2016 (UTC)
Cheers, I think I have realised that the regex searching is pretty weird. —  crh 23  (Talk) 20:41, 4 May 2016 (UTC)

Regex - how to newline

I'm working on a regex using mediawiki as a curiosity regarding a particular bot request, and I'm stuck. hastemplate:infobox insource:"infobox" insource:/\{\s*(i|I)nfobox\s*(\||})/ returns ~170 items, and should theoretically return infobox invocations with newlines, but does not appear to from a spot check. Am I doing something wrong, or the regex really returning so few articles? If the latter, why does that not jive with John of Reading's comment at WP:Bot requests#Direct calls to Infobox? --Izno (talk) 13:47, 4 May 2016 (UTC)

@Izno: (Partial answer) The flavour of regex used by the search box does not interpret \s* as "zero or more white space characters" but as "zero or more lowercase-s characters". For example, submarine Monge insource:/Ga\s*pard/ finds articles containing "Gaspard" not "Ga<optional whitespace>pard" John of Reading (talk) 14:26, 4 May 2016 (UTC)
Bah. Do we know what flavor of regex ElasticSearch actually uses? The MediaWiki documentation doesn't have the flavor and neither does the ElasticSearch docs (even though the latter does have a list of special characters--not all). --Izno (talk) 14:27, 4 May 2016 (UTC)
insource:/orange\s*s/i returns as expected; the \s* notation for zero or no whitespace characters is correct. these docs (probably the ones Izno just refered to) don't say anything about whitespace, but in this you can see an escaped \s*. Apparently it's written in Java, and the regex appears to be deconstructed then a JSON query formed from the parts (didn't pay much attention to be honest).
The problem with zero or no... is that no matter what the character(s) is, it's always present at every place in every string. i.e. there is zero or no whitespace between every character in "bippertyboo". It's best to regard these zero or no... parts as possible but not important, rather than the exact thing I'm interested in.
Ideally, if it's newlines you're looking for, then it's newlines you should be looking for - if you catch my drift. Fred Gandt (talk|contribs) 19:28, 4 May 2016 (UTC)
@Fred Gandt: I think your "oranges" example returns results because the \s*s is matching zero or more lowercase-s followed by lowercase-s. Try insource:/pa\s*sionfruit/i which returns articles mentioning "passionfruit". -- John of Reading (talk) 19:38, 4 May 2016 (UTC)
Yep. I'm playing with it now, and there's definitely some giant holes in this code. \n for example matches lowercase ns. Regex without these chars isn't a regex worth having IMO. Fred Gandt (talk|contribs) 19:43, 4 May 2016 (UTC)
hastemplate:infobox insource:/[{]{2}[^a-zA-Z0-9]*?[Ii]{1}nfobox[^a-zA-Z0-9 ]+?\|/ <-- that seems to work. Exclude anything that isn't whitespace and say there might be some of it. Fred Gandt (talk|contribs) 19:47, 4 May 2016 (UTC)
Got it. That's still frustrating, of course, that I have to go the not not whitespace route. ~4k hits is about right. --Izno (talk) 20:45, 4 May 2016 (UTC)
That said, I'm only seeing about 50 results. Why did yours return 4000 and mine return 50? (And why is 4k != 2.7k?) --Izno (talk) 20:52, 4 May 2016 (UTC)
I know this is Twilight Zone weird, but open Special:Search in a new tab to perform the search; I was getting 50 odd too, then figured something was off so used a fresh search and got sensible results (last try is 4316). Whatever is going on in the backend is flat out broke. Fred Gandt (talk|contribs) 22:29, 4 May 2016 (UTC)
If it matters (it probably matters), I get only 64 in the article space. Fred Gandt (talk|contribs) 22:41, 4 May 2016 (UTC)
Oh good. That's where I was searching ;). --Izno (talk) 01:43, 5 May 2016 (UTC)

 ;-p Yeah I can be dumb. But that can't be right, right? A straight search for hastemplate: infobox returns 2.5 million articles; insource:/[{]{2} *[Ii]{1}nfo *box *[^0-9a-zA-Z \|]{1,}\|/ returns 54 articles. So of 2.5mil only 54 instances have a newline (or tab (I'm assuming all the special chars will fail)) after the template name and before the first pipe? I'm just about to have a look at what the API search can do. If I find anything interesting I'll report back. Fred Gandt (talk|contribs) 04:18, 5 May 2016 (UTC)

It appears that Lucene (the flavour) has no handling for newlines as it uses some kind of tripped out tokeniser indexing thing that breaks everything up into chunks, then via its settings, applies weights and calculates the results rather than looks for them. There appears to be ways to force the search to be more thorough, which is when the search will typically timeout (set (here) at 40 seconds max). So we're caught between a rock and a hard place. Searches that might work won't and wouldn't work anyway because the lingo has no idea what we're talking about, and indexed/tokenized searches will work, but aren't strictly searches at all, so you get whatever it thinks seems most useful.
I have purposefully omitted references which include blogs, stackoverflow, forums, documentations 'etc. because I'm lazy.
How are you with SQL and PHP? See: mw:Manual:Database access, mw:Manual:Database layout, mw:Manual:templatelinks table and this for inspiration. Fred Gandt (talk|contribs) 05:26, 5 May 2016 (UTC)
@Fred Gandt: hastemplate: infobox seems to show every page with any infobox - which is why it flags half the articles on the encyclopedia! Sam Walton (talk) 08:05, 5 May 2016 (UTC)
^ Right, any transclusion is counted in hastemplate:TemplateName, and since Template:Infobox is a metatemplate.... --Izno (talk) 11:45, 5 May 2016 (UTC)
I don't know if that's dumb or not... it obviously has value--presumably to make sure a return occurs in more cases than not. SQL/PHP: Not up my alley at this time, nor Andy's at Bot requests obviously. --Izno (talk) 11:45, 5 May 2016 (UTC)

Botched page move

@Timeshift9: reverted my move of the page 2016 Australian federal budget to Australian federal budget, 2016–17. I do disagree with this move, but of course, this is not why I'm here. My concern is with the fact that the move back had been botched. The edit history of the page has remained at Australian federal budget, 2016–17, which comprises a majority of my edits on the page, while the edit history on the 2016 Australian federal budget page completely omits all edits made up to the point of his move. It is my belief that he used a manual page move procedure. A identical problems have occurred with all the edit histories of articles on the Australian federal budget; all results of Timeshift9's actions. Is there a way, as editors, that we can fix this? If not, is there a moderator or somebody with technical powers that can help bring back all the edit histories to their right place? Philip Terry Graham 02:21, 4 May 2016 (UTC)

I was unable to move the articles the normal way as the article names already existed as redirects, but if there is a way to restore just the edit histories obviously I would have no problem with that in itself - I do believe admins can do the moving of article histories in these situations. But as per 2016 United States federal budget, 2015 New Zealand budget, 2016 United Kingdom budget et al, I moved the Australian articles to '20xx Australian federal budget'. As an aside, naming a budget article with eg: '2015-16' is just blatantly wrong, not to mention not used. The budget for 2015-16 is the 2015 budget. Of course, the article leads should state that it is for the period of 2015-16, but the budget itself is the 2015 budget, no ifs ands or buts. Timeshift (talk) 02:25, 4 May 2016 (UTC)
@Timeshift9: Just as a heads up, if you were unable to move the page through the normal procedure, it would've been wise to make do and request a move at Wikipedia:Requested moves. Not only is it a better way to make sure the move will be carried out without harm by a moderator, it also initiates a discussion on the move. The reality is, it may be "no ifs ands or buts" for you, but I'm in disagreement, and would've liked to have put forward an argument for my case. Of course, this is the Village Pump, so here's not a good place to discuss that. Philip Terry Graham 02:38, 4 May 2016 (UTC)
Corrections underway. Timeshift (talk) 02:39, 4 May 2016 (UTC)
(edit conflict)  Done Everything has been merged to 2016 Australian federal budget - please discuss future title moves on the article talk. — xaosflux Talk 02:40, 4 May 2016 (UTC)
@Timeshift9 and PhilipTerryGraham: It's covered by WP:MOVE#Before moving a page, particularly the paragraph beginning "Do not move or rename a page by copying/pasting its content". If you have made other cut&paste moves, please see WP:REPAIR (you might also look at WP:CUTPASTE). --Redrose64 (talk) 09:15, 4 May 2016 (UTC)

It seems the corrections have not been fully undertaken - see here. Can an admin kindly please go over the 10 budgets listed here and move article/talk histories to their current pages. Apologies for not having followed proper procedure for moving articles to existing redirect article names that had previously existed. Despite my 10+ year tenure on wikipedia, it's not often that I move an article and never have I moved an article to a name that had already previously existed. Timeshift (talk) 05:02, 5 May 2016 (UTC)

You only admitted to doing one that way, so we only worked on that one. Each one needs a lot of work to put right: consider 2014 Australian federal budget/Talk:2014 Australian federal budget - I didn't do any histmerge since relatively little had been done to the pages after your cutpaste move, but even with that simplification, these nine edits plus two more were to fix just that one page/talkpage pair. --Redrose64 (talk) 14:17, 5 May 2016 (UTC)
Now done 2015 Australian federal budget/Talk:2015 Australian federal budget as well, I did a partial histmerge on the latter in order to keep Talk:2015 Australian federal budget#Article naming convention visible. --Redrose64 (talk) 14:38, 5 May 2016 (UTC)
OK, I've also done 2013 Australian federal budget/Talk:2013 Australian federal budget; 2012 Australian federal budget/Talk:2012 Australian federal budget; 2011 Australian federal budget/Talk:2011 Australian federal budget; 2010 Australian federal budget/Talk:2010 Australian federal budget; 2009 Australian federal budget/Talk:2009 Australian federal budget; 2008 Australian federal budget/Talk:2008 Australian federal budget. @Enthusiast01, PhilipTerryGraham, and Timeshift9: in future, if a page move might be controversial, please discuss it first, per WP:MOVE#Before moving a page; and similarly, if you find that you can't perform the move, it's normally also a WP:RM matter. In cases of uncontroversial moves that you are unable to perform, you can use {{db-move}} on the target page. --Redrose64 (talk) 18:39, 5 May 2016 (UTC)
Thank you for your efforts. Timeshift (talk) 21:17, 5 May 2016 (UTC)

Dezoomify.py

I'm trying to download full-sized scrolls from the Digital Scrolling Paintings Project. Since this online tool seemingly doesn't work, I started to use Dezoomify.py. However, when trying, for instance, python dezoomify.py https://scrolls.uchicago.edu/scroll/erlang-and-his-soldiers-driving-out-animal-spirits c:\output.jpg I receive this in the command line:

ERROR: Zoomify base directory not found. 

When I try base URL python dezoomify.py https://scrolls.uchicago.edu/scroll/erlang-and-his-soldiers-driving-out-animal-spirits -b c:\output.jpg I get this:

ERROR: Could not open ImageProperties.xml <HTTP Error 404: Not Found>. 

Troubleshooting implies that ImageProperties.xml must be in URL, while URLs at the the Digital Scrolling Paintings Project seemingly lack them. Is there a way to fix this? If Dezoomify is incompatible with the Digital Scrolling Paintings Project, maybe there's another script or free program? Thanks. Brandmeistertalk 19:04, 6 May 2016 (UTC)

moving with a link? (Special:MovePage parameters?)

Does Special:MovePage take any parameters in the URL such that you could create a link that moves a page? Ideally it would actually try to make the move, but I suspect that would pose too many potential problems, so perhaps it could just open the move page with the namespace, target, etc. already selected? — Rhododendrites talk \\ 20:37, 5 May 2016 (UTC)

You can open the move form with source, target and reason filled out: https://en.wikipedia.org/w/index.php?title=Special:MovePage&wpOldTitle=...&wpNewTitle=...&wpReason=.... {{Db-move}} uses all three. PrimeHunter (talk) 20:56, 5 May 2016 (UTC)
Should really be described at mw:Manual:Parameters to Special:MovePage, but it doesn't exist (compare mw:Manual:Parameters to Special:Export). Only mention of a MovePage parameter that I can find is wpReason= at mw:Manual:Parameters to index.php#Special pages. --Redrose64 (talk) 11:38, 6 May 2016 (UTC)
There's also wpMovetalk (whether to move the talk page), whether to watch the 2 pages, whether to move subpages, and whether to leave a redirect behind. Do you know the URL parameters for the latter 3 options? GeoffreyT2000 (talk) 13:56, 6 May 2016 (UTC)
There is wpMovesubpages and wpLeaveRedirect. Set =0 to not do it and =1 to do it. There is apparently something called wpWatch and wpDeleteAndMove (admin only) but I cannot get them to work. PrimeHunter (talk) 20:09, 6 May 2016 (UTC)

Error with categories for discussion through twinkle

Hello - I am not sure what the problem is. I posted manually to Wikipedia:Categories for discussion/Log/2016 May 6 because I got an error message when using WP:Twinkle to nominate a category for discussion. When I got to that page, I saw that Eric similarly commented that they also saw an error message. I am not sure where the problem is. It seems that the process which posts "categories for discussion" to the daily log has been disrupted. Blue Rasberry (talk) 15:39, 6 May 2016 (UTC)

Hello all- When I followed the "Click THIS LINK..." under Wikipedia:Categories for discussion#Procedure, I was brought to an edit window containing only the most recent nomination section, with no commented instructions. Eric talk 15:54, 6 May 2016 (UTC)
I have restored the header and limited instructions which were removed by an IP.[8] PrimeHunter (talk) 22:38, 6 May 2016 (UTC)

Wrong category title

Discussion moved to Category talk:Maritime incidents by year. --Pipetricker (talk) 07:33, 7 May 2016 (UTC)

No link in diff-view to previous revision

See [9]. It's normal for Revision as of [time], [date] to be linked, so that you can see what the page was like when previously edited, but for some reason it's not linked in this specific diff (I've closed and reopened the link several times; it's not just a one-time bad page load) that appeared on my watchlist. I've often noticed this happening when I see a bunch of edits in my watchlist; it's been going on for some months now. It's not something significantly problematic, but I doubt that it's supposed to work this way; the only context in which a link shouldn't be clickable is when the old revision's been oversighted. Nyttend (talk) 14:55, 7 May 2016 (UTC)

Odd, the link is clickable and works fine for me. Sam Walton (talk) 14:57, 7 May 2016 (UTC)
Well, I'm to blame for this Nyttend. The hack I gave in Wikipedia:Village pump (technical)/Archive 140#Custom script to obscure a link? is messing it up on certain diff pages. If you remove that piece of code from your monbook.js, everything should be back to normal. - NQ (talk) 15:36, 7 May 2016 (UTC)
Odd; it affects diffs on occasional pages with {{Infobox NRHP}}, but only a very few. The code you supplied there is still quite useful, and the missing link atop this diff isn't at all useful, so I have no desire to get rid of the code. Thanks! Nyttend (talk) 16:15, 7 May 2016 (UTC)

Category:Articles to harmonize

For Category:Articles to harmonize, what is to be done? Are there instructions somewhere?--DThomsen8 (talk) 16:04, 7 May 2016 (UTC)

Template:Sync puts articles in that category, but no help in saying what is to be done.--DThomsen8 (talk) 16:21, 7 May 2016 (UTC)
See Wikipedia:Templates for discussion/Log/2016 May 7#Template:Sync. Nyttend (talk) 16:33, 7 May 2016 (UTC)

how is RefToolbarLegacy.js getting added to Category:Pages with empty citations?

Category:Pages with empty citations lists MediaWiki:RefToolbarLegacy.js. This has perplexed me for a long time. If I look at the html source for RefToolbarLegacy.js I cannot find any reference to Category:Pages with empty citations. How is this category being added to RefToolbarLegacy.js?

In edit mode, the list of "Pages transcluded onto the current version of this page" includes Template:Citation and Template:Cite book, either of which, when empty, will cause the trancluding page to be added to Category:Pages with empty citations.

Is it this? (at lines 351, 352):

<input type="radio" tabindex=1 name="template" id="cite_book" value="cite_book" checked="1"><label for="cite_book">{{cite book}}</label> <sup><a href="//en.wikipedia.org/wiki/Template:Cite_book" target="_blank">[doc]</a></sup> \
<input type="radio" tabindex=1 name="template" id="citation" value="citation"><label for="citation">{{citation}}</label> <sup><a href="//en.wikipedia.org/wiki/Template:Citation" target="_blank">[doc]</a></sup> \

If so, how? Should javascript be transcluding templates? Why can't I find Category:Pages with empty citations in the RefToolbarLegacy.js html source?

I'm pretty sure that I can make Module:Citation/CS1 ignore this page but, before I do that, I'd like to understand how it is that RefToolbarLegacy.js is getting added to the category.

Trappist the monk (talk) 14:25, 4 May 2016 (UTC)

It's caused by {{cite book}}. It only adds the tracking category in some namespaces. Maybe you tested it in userspace where it's not added. css and js pages are evaluated as wikitext when link tables are built but the result is not used to render the pages. This can be confusing. PrimeHunter (talk) 16:53, 4 May 2016 (UTC)
I'm afraid I find your answer somewhat confusing. Module:Citation/CS1 excludes certain namespaces from its error categorization. These excluded namespaces are identified at the top of Module:Citation/CS1/Configuration in the table uncategorized_namespaces. MediaWiki is not one of those namespaces. {{cite book}} and {{citation}} both use Module:Citation/CS1 so either (more likely both, if the code snippet above is the culprit) could be the the cause. I'm not sure what to make of this sentence: Maybe you tested it in userspace where it's not added. What test? There was no need to test anything to see that MediaWiki:RefToolbarLegacy.js is a member of Category:Pages with empty citations.
What does make sense, mostly, is that css and js pages are evaluated as wikitext ... Perhaps this indicates that there is a small bug in the code that does this processing – clearly it knows that the page is css or js. If these pages shouldn't transclude other pages (is there ever a case where they should?) then there should be no reason to keep the results and and similarly, no reason to keep the side effects (in this case the error category) of transclusions.
Trappist the monk (talk) 18:36, 4 May 2016 (UTC)
Sorry, I misread "either" as "neither" in your first post and incorrectly thought you had tested the empty templates somewhere and found them to not add the category there. The side effects are used deliberately in some situations like adding user css and js pages to speedy deletion categories on user request, and to track imports of js pages via WhatLinksHere. For example, User:Bart133/monobook.js says:
importScript('User:Dr pda/prosesize.js'); //[[User:Dr pda/prosesize.js]]
The part after // is a JavaScript comment so it has no effect on the js page, but it's not a wikitext comment so it's evaluated during wikitext processing and causes the page to be listed at Special:WhatLinksHere/User:Dr pda/prosesize.js (importScript does not cause a WhatLinksHere). I don't know whether these side effects were made by design in MediaWiki but once something exists, it can quickly become a feature. See https://xkcd.com/1172/. PrimeHunter (talk) 20:23, 4 May 2016 (UTC)
This should sort it. --Redrose64 (talk) 20:27, 4 May 2016 (UTC)
I don't know it that script still works (I assume that it does), but Category:Pages with empty citations is now empty for the first time. Well done.
Trappist the monk (talk) 20:37, 4 May 2016 (UTC)
See phab:T34858, phab:T35355#1862685, phab:T18683 and phab:T12410. Helder 21:35, 7 May 2016 (UTC)

frac template

In {{frac}}, e.g. ​ND, I see a slash if my skin is Cologne Blue, but not in Monobook (my favorite), Vector or Modern. The HTML is

<span class="frac nowrap"><sup>N</sup>⁄<sub>D</sub></span>.  

Taking away the <span> has no effect, I still see no slash in ND; but I do see it here: N⁄D, N ⁄ D. Is the problem on my end? (Firefox, MacOS; it's been so through multiple versions of each. My default font is Lucida Grande.) I do see a bar in N/D. —Tamfang (talk) 09:00, 7 May 2016 (UTC)

Sounds like a glitch at your end; the slash is certainly displaying fine to me in both Firefox and Chrome. As an aside, when it comes to display issues the only skin you need to pay any attention to is Vector, since that's what the readers always see. ‑ Iridescent 09:41, 7 May 2016 (UTC)
since that's what the readers always see - Really? A registered reader can't change their skin in their prefs? I wasn't aware of that. So, what, you have to make one edit before that preference is enabled? ―Mandruss  09:45, 7 May 2016 (UTC)
Of course registered readers can set their skin, but we have a multitude of unregisterd readers which cannot set their skin. -- [[User:Edokter]] {{talk}} 10:37, 7 May 2016 (UTC)
That was my understanding, but it is not what the commenter stated. ―Mandruss  10:43, 7 May 2016 (UTC)
When we talk about 'readers', we usually mean unregistered users. -- [[User:Edokter]] {{talk}} 11:36, 7 May 2016 (UTC)
If you say so, but doing so is a terrible idea because it increases the likelihood that we will fail to consider registered, non-editing readers in our discussions and decisions. What we say affects how we think; if we speak imprecisely, we will think imprecisely. For evidence of this, simply refer to Iridescent's statement, that we needn't consider any skin except Vector, implying that no one is affected by the other skins except editors. ―Mandruss  11:52, 7 May 2016 (UTC)
Mandruss, as I imagine you're perfectly well aware, the proportion of pageviews which come from registered accounts is well below 0.1%. Given that 70% of registered accounts have Vector set as their preference (and most of the 20% set to Monobook will be long-abandoned accounts registered back in early days when it was the default), the number of readers reading Wikipedia using anything other than Vector is so low as to be lost in statistical noise. Treat Cologne Blue (used by 0.7% of registered accounts, which at a rather generous estimate equates to one reader in a million) as you would Lynx users, as a group for which Wikipedia has a traditional obligation to cater, but which provides such an insignificant fraction of the readership that it doesn't justify any special effort to cater for and which is likely to be deprecated in due course. ‑ Iridescent 12:56, 7 May 2016 (UTC)
I see, thank you for the considered response. So the number, while nonzero, is not sufficiently large to say "unregistered readers" instead of "readers". It is a fairly long word, requiring several seconds to type, prone to misspelling and typos. Perhaps your calculus is correct, and I retract my comments. I'll continue to say "unregistered readers" and I hope that doesn't cause any confusion. ―Mandruss  14:30, 7 May 2016 (UTC)
FTR, I see the slash in Windows 10, Firefox 46.0.1 and MS Edge 25.10586.0.0, all skins. That intersects the OP's failures, so I'm stumped unless they wish to try a magnifying glass or a different computer. If this thread archives without anyone else reporting a problem, I'll be left to "glitch on your end"; i.e., SOL. ―Mandruss  10:43, 7 May 2016 (UTC)
On second thought, @Tamfang: What OS? It now sounds like the difference is the OS; that could be confirmed by other Mac OS users.Mandruss  10:49, 7 May 2016 (UTC)
Mandruss, I'm seeing the slash normally in Firefox and OS X with Vector:Jay8g [VTE] 03:33, 8 May 2016 (UTC)

URL processing to work around Chrome, etc., flaw

It turns out that the Chrome browser (and variants like Chromium, Opera, etc.) do not do certain kinds of auto-escaping. Thus, if you use one of these browsers and do something like a Google search on the quoted phrase "Manx cat", the URL it gives you for the search results will be something like https://www.google.com/search?q="Manx%20cat" (with various extra parameters about language, time zone, browser). This URL will not work properly in Wikipedia:

The problem is that the double-quote character has to be escaped as %22, and most editors don't know this, so will not know how to fix it. So, MediaWiki should probably do this for us (and look for other characters it needs to escape in URLs, too).  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  20:37, 7 May 2016 (UTC)

Can you not just use {{google|"Manx cat"}}? ‑ Iridescent 21:11, 7 May 2016 (UTC)
In Chrome and Firefox (as tested on OS X), a URL copied in full is always percent-encoded:
If you do a Google search for "Manx cat", the result page will have a URL looking like this, with quotation marks: https://www.google.com/search?q="Manx+cat"&rlz=1C5CHFA_enSE530SE534&oq="Manx+cat"&aqs=chrome..69i57&sourceid=chrome&ie=UTF-8.
If you copy this URL in full from the address bar, either by menu or keyboard action or by dragging the favicon, you will get the URL with the quotemarks percent-encoded as %22. But if you copy only a part of the URL in the address bar, you will get the text copied as it looks in the address bar, with unencoded quotation marks.
(It occurs to me that I've been using this without thinking about it, copying both the percent-encoded URL, and separately unencoded characters from the URL, as I described here.)
With Safari, copying a URL from the address bar using keyboard or menu will give you the text as it looks in the address bar, which usually is with any quotation marks percent-encoded (but a newly entered address can have unencoded quotemarks). Dragging the favicon will always give you the percent-encoded URL. --Pipetricker (talk) 08:40, 8 May 2016 (UTC)
The difference is URI vs. IRI I believe. For the sake of readability at some point the browser vendors introduced the IRI. The problem is that only browsers really support them and even they have had quite a few security problems with them. Implementation of IRI is not a simple feat. unfortunately. And then you still have to keep them apart when a user presses paste, which isn't simple either. —TheDJ (talkcontribs) 09:15, 8 May 2016 (UTC)

Presentation of parent categories

Concerning the discussion here [The Link], I'd like to find out if the technically experienced users consider this idea to be possible, given that it is approved by the majority of all users. CN1 (talk) 23:58, 7 May 2016 (UTC)

Technically, very possible; it is a HTML list, which allows for flexible styling. I have trouble seeing the 'majority of users' though, so this needs more input. -- [[User:Edokter]] {{talk}} 07:13, 8 May 2016 (UTC)
Per WP:MULTI, please discuss on the existing thread. --Redrose64 (talk) 12:24, 8 May 2016 (UTC)

Odd references format

Could anyone explain the format of the sources at Livesey which I've marked as deadlinks? Were they really added in this form? I'm assuming this question would be an easy one for technical geeks like User:Fred Gandt. Thanks. Martinevans123 (talk) 19:47, 8 May 2016 (UTC)

Looks as though they were added like this - they look like search queries to get to the intended page, rather than navigating to the page. At least some of them are archived at the Wayback machine, but the first one (Ref 4) - had a dead link for the actual photo and didn't seem to support the preceding text - replaced this with a similar link from the same site. Fixed Ref 5 with an archive url. The site says its under reconstruction... Good luck with the other dead links! Robevans123 (talk) 20:46, 8 May 2016 (UTC)
Ooh, blimey. A real techno-geek. Thanks. Martinevans123 (talk) 21:02, 8 May 2016 (UTC) p.s. great user name
The site reorganized the content without making the old url's work. Very annoying but websites do it all the time. The references state the title so you could also try searching the site for the titles. It has a search box where "Coal Mining in Cherry Tree" leads to [11]. I haven't tried the others. For another time, note that Template:Dead link#Usage says: "this tag should be placed just before the </ref> that contains the dead link". PrimeHunter (talk) 21:29, 8 May 2016 (UTC)
Yes, thanks very much, Prime, fully noted. Good job they're now alive again. Martinevans123 (talk) 21:58, 8 May 2016 (UTC)

Revising a subst template to be more user-friendly after substing

I would appreciate if a technical whiz would look at Template talk:Rfd2#Template produces hopeless technobabble and see if there are ways for the subst template to produce wikitext that is more user-friendly to non-technical editors. Thanks, Oiyarbepsy (talk) 03:16, 9 May 2016 (UTC)

@Oiyarbepsy: Can you try out {{Rfd2/sandbox}} and see if it does what you'd like? Fred Gandt (talk|contribs) 06:02, 9 May 2016 (UTC)

How to automate display of pages at one per day?

Resolved

There are 1299 mottos in the Motto of the day department. Is there a way to set those up so that they would automatically display one per day, over and over again?

Please respond at the following link:

Wikipedia talk:Motto of the day#Proposal: automate Motto of the day

Thank you. The Transhumanist 15:33, 9 May 2016 (UTC)

Marking as resolved as you've got all the bits now. — Dispenser 17:07, 9 May 2016 (UTC)

Help improve search relevance with Discernatron 🤖

Screenshot of search results being graded in Discernatron

The Discovery department's work to improve search continues with a new tool! We are asking volunteers to help choose, or discern, which search results are the most relevant.

One way of improving search results relevance is to provide search results from multiple search engines side-by-side for comparison. Participants pick the best, most relevant results, which are then used to tune our own search results. It's one way to help improve search with human assistance, by showing articles that are most relevant to search queries. This system is used by many R&D departments and gives great results.

Discernatron is a tool developed by the Discovery department for just this sort of work. Visitors are asked to pick the most relevant results across four different search result sets. The data is then used to help improve our relevancy model for search.

If you are interested in helping, you can access Discernatron at https://discernatron.wmflabs.org/ and authenticate with your unified user account.

To learn more about the tool visit Mediawiki.org.

CKoerner (WMF) (talk) 21:49, 9 May 2016 (UTC)

ClueBot III

The bot is the talk of the town for a while now, after sleeping for a few weeks then resuming editing for a week, then sleeping again. Pages are not getting archived regularly unless they moved to lowercase sigmabot archiving. Sadly, Cobi is not actively editing Wikipedia (is he active on IRC?) I'm looking forward to progress in the situation. Is there any as of now? 49.148.66.44 (talk) 09:38, 10 May 2016 (UTC)

Tech News: 2016-19

23:22, 9 May 2016 (UTC)

11 to come before 2

Definitely a welcome change to ordering. But how exactly will the software determine if there is really a need to do so? Counting the number of successive digits? If 11 will come after 2, will 1001 come after 999? Will 1 001 come after 999? Will 1,001 come after 999? Might be a problem because of how we space out digits. 49.148.66.44 (talk) 09:35, 10 May 2016 (UTC)

Please add your comment on meta:Talk:Community Tech/Numerical sorting in categories so it will be seen and can be discussed in one single place. Thanks. --AKlapper (WMF) (talk) 10:58, 10 May 2016 (UTC)

Scrollbar for map

Hi. Can someone help with creating a vertical scrollbar for the map in List of power stations in Sri Lanka? I need that map reduced 50% in height, so as to reduce whitespacing in a number of screen resolutions. I know of {{Tall image}}, but that cannot be used in this case (right?). Thanks in advance! Rehman 14:48, 4 May 2016 (UTC)

@Rehman: How's this? -- AxG /  10 years of editing 21:15, 5 May 2016 (UTC)
Hi AxG. Thank you. Would you know if the map can be made to look like this scrollable image? (notice the borders and caption). Rehman 15:53, 6 May 2016 (UTC)
@Rehman: Some tinkering later... -- AxG /  10 years of editing 18:05, 6 May 2016 (UTC)
Thanks, AxG! Rehman 15:23, 10 May 2016 (UTC)

Annoying "Secure connection failed"

As much as this has happened to me over the last few months, I'm sure this must have been mentioned before. It happens perhaps less than half a dozen times a day, but that's enough. The phenomenon happens when I click "Preview", no other time. And it's rather sporadic. The message is at the tab heading "Problem loading" And the error message in the body is "Secure Connection Failed. The connection to the server was reset while the page was loading. The page you are trying to view cannot be shown because the authenticity of the received data could not be verified. Please contact the website owners to inform them of this problem." It gives me the option to "Try again", which pretty much loses whatever edit I was doing at the time. Really irritating. Firefox 46.0.1, but it's been doing this when I had older versions of Firefox. Arrrrgh. — Maile (talk) 19:13, 8 May 2016 (UTC)

Not addressing the problem, but here's a hint to avoid losing your edit due to any reason including edit conflict. Before pressing Show preview or Save page, highlight the text and copy it. If you lose the edit, you can reload the page and paste the text back in. Akld guy (talk) 19:46, 8 May 2016 (UTC). Edited to show buttons. Akld guy (talk) 10:10, 9 May 2016 (UTC)
Thanks for the tip. — Maile (talk) 21:38, 8 May 2016 (UTC)
I got that message once, a few days ago, when using Show changes. I didn't use Try again - I clicked the "back" button then Show preview. This one didn't complain, so I clicked the "back" button then Show changes, which worked, so I carried on as normal. Firefox 46.0.1. --Redrose64 (talk) 09:17, 9 May 2016 (UTC)

I've also seen these warning messages recently: their appearance seems to be sporadic. Browser: Firefox on Linux. -- The Anome (talk) 11:14, 9 May 2016 (UTC)

I have seen some SPDY errors in Chrome recently, wonder if that might possibly be related. —TheDJ (talkcontribs) 13:54, 9 May 2016 (UTC)
And it just happened to me again, first time today. I guess the only temporary solution, is to copy every edit before clicking "Show preview", which is where it happens. It's a bit of a glitch, that I guess will keep happening for a while. — Maile (talk) 22:29, 9 May 2016 (UTC)
And it just happened when I was deleting a CSD nomination. At least we know it's not just "Preview" that causes that. — Maile (talk) 23:06, 9 May 2016 (UTC)
I got it again yesterday, this time on a Save page. As before, I didn't use Try again but clicked the "back" button then Show preview, then "back" and Save page again. My changes were saved; nothing was lost. --Redrose64 (talk) 07:30, 10 May 2016 (UTC)
Happened several times to me this morning. Seems to be getting more frequent. I never touch Try again because it doesn't really work; it's like a tease. I just do the back button, then Save page. I see below there is a ticket out on this. The thing is this morning, I was doing detail clean-up that was hundreds of little edits on one article. Glad this didn't wipe those out when it happened, because it would have been time-consuming to re-do. — Maile (talk) 15:34, 10 May 2016 (UTC)
I started getting this very frequently starting either yesterday or the day before - hadn't had it before. The connection I'm using actually isn't 100% reliable (I have to replace a plug) but it seems pretty consistent now. The weird thing is it happens once per edit - if I preview, I get it on the preview, but then not on the post. (but it didn't happen just now, four times in a row...) Wnt (talk) 12:13, 10 May 2016 (UTC)
Same here, six or seven times the last two days, when previewing. Whether it happens when posting, I can't say (I preview a lot more than I actually post). Using firefox 46.0, Ubuntu. Prevalence 15:11, 10 May 2016 (UTC)
Been happening periodically to me, mainly when previewing pages - I've reported in T134869 -- samtar talk or stalk 12:23, 10 May 2016 (UTC)

Email unsubscribed every time I use "Email this user"

Whenever I use the "Email this user" feature, I promptly get a notification that my registered email address "has been unsubscribed due to multiple message delivery failures. You can verify your email address again." So I do, and next time it happens again, four times now. The email address is on Yahoo: other messages get through to it OK. Any ideas what the problem might be? JohnCD (talk) 09:48, 10 May 2016 (UTC)

Wikipedia mail works poorly or not at all with Yahoo (see phab:T58414 and phab:T66795). See Comparison of webmail providers for some free alternatives. PrimeHunter (talk) 10:10, 10 May 2016 (UTC)
Also T123068 and mw:Notifications/Messages unsubscribe-bouncehandler are related. Fred Gandt (talk|contribs) 10:12, 10 May 2016 (UTC)
Thank you. Yahoo must have changed something: I have had no trouble until a few days ago. I have abandoned them and opened an AOL account. I was baffled at first by their insistence on a US zipcode - the answer seems to be, just make one up. JohnCD (talk) 11:16, 10 May 2016 (UTC)

More problems: I set up an AOL account and sent a test message using "Email this user" to my alternate WP account. It arrived, but was put in the spam folder with "Why is this message in Spam? It has a from address in aol.com but has failed aol.com's required tests for authentication." Also (which may be connected) although I checked the "Email me a copy of my message" box, no copy arrived.

Any suggestions for email providers that are known to work trouble-free with Wikipedia mail? JohnCD (talk) 11:53, 10 May 2016 (UTC)

I have never had an issue with Gmail. --Izno (talk) 11:56, 10 May 2016 (UTC)
Gmail for me too - generally excellent. Fred Gandt (talk|contribs) 12:43, 10 May 2016 (UTC)
Gmail it is, and that works. Thank you all. JohnCD (talk) 13:44, 10 May 2016 (UTC)
The problem with spam filters is that if you send an email with a sender in one domain, but the mail reaches your domain from a different one, then there is a risk that it's spam sent by a third party, using a name (s)he thinks you will trust. Domains may not know that Wikipedia email has safeguards preventing such problems. עוד מישהו Od Mishehu 17:27, 10 May 2016 (UTC)

Table convert tool

Is there an easy-to-use tool for converting tables from Microsoft Word into Wiki mark-up? I find construction and amendment of tables to be among the trickiest things at Wikipedia. Many thanks. Martinevans123 (talk) 09:47, 7 May 2016 (UTC)

Have you tried using the table editor of the VisualEditor ? It's a lot easier to build tables with that. The VE surface also allows you to copy paste tables to some degree. Not sure if that works with Word tables however. —TheDJ (talkcontribs) 10:21, 7 May 2016 (UTC)
I made a script for someone only recently for copy/paste of Word tables to wikitext, which I could possibly extend to be more general purpose. As long as there's no hurry, I'll add it to my todo list if you like. Fred Gandt (talk|contribs) 10:58, 7 May 2016 (UTC)
Thank you both for the helpful replies. There's no hurry, thanks. Martinevans123 (talk) 11:15, 7 May 2016 (UTC)
A number of tools are listed at WP:Tools#Importing (converting) content to Wikipedia (MediaWiki) format, WP:Tools/Editing tools#Wikisyntax conversion utilities, de:Wikipedia:Technik/Text/Basic/EXCEL-2003 Tabellenumwandlung VBA. -- Michael Bednarek (talk) 01:59, 8 May 2016 (UTC)
Many thanks, Michael. That seems to cover everything. Martinevans123 (talk) 12:08, 8 May 2016 (UTC)
The visual editor does well with many tables. .csv files are simply drag and drop. But I believe that there's an open bug with Microsoft Word tables. If you did an interim transformation (e.g., maybe save it as HTML from Word, or export it as a CSV?), then you might have better success there. Whatamidoing (WMF) (talk) 18:44, 10 May 2016 (UTC)

Where is this??

Where is the current site notice for "Translate Ibero-America" located? Can't find it using "Message names" nor with "what links here" at the linked project page. Is it not actually on en.wiki? If that's the case I think I have a concern with this, but first things first: there are two glaring, embarrassing typos. --Floquenbeam (talk) 02:13, 11 May 2016 (UTC)

This was added at Meta. Nakon 02:16, 11 May 2016 (UTC)
meta:Meta:Requests for help from a sysop or bureaucrat#Iberocoop Translating Ibero America - NQ (talk) 02:18, 11 May 2016 (UTC)

Page views of non-mainspace pages

I am curious to find the pages with the most views in namespaces other than main. Are there any tools that do this (and if there are do they count transclusions as views)? I've had a look at WP:Statistics#Page views and nothing that would work jumped out at me. Cheers —  crh 23  (Talk) 15:21, 10 May 2016 (UTC)

TopViews jumped to from PageViews would seem to include pages which are not in mainspace. --Izno (talk) 16:19, 10 May 2016 (UTC)
@MusikAnimal: Is there an easy way to add filters for namespaces? --Izno (talk) 16:20, 10 May 2016 (UTC)
Unfortunately, no. The Wikimedia API that's used doesn't offer this functionality, so we'd have to cross-reference the pages with the main API to get the namespaces, and filter accordingly. Especially for the non-mainspace, this could be hugely expensive, and may not even give you what you want, as the API only gives us the top 1000 pages. So for instance, if you wanted the top viewed pages in the portal talk namespace, there will be few if any pages that happened to make the top 1000 overall. I do hope to add a mainspace filter since that's what people are most interested in, and it's feasible to do given the bulk of the top viewed pages are in the mainspace. Best MusikAnimal talk 16:52, 10 May 2016 (UTC)
Thanks all, I appreciate the help. I assume TopViews uses the most view articles bit of Analytics/PageviewAPI. If I were desperate to get the data I assume I could use Analytics/Data/Pagecounts-all-sites or probably the merged stuff at [23] (which I can't find any documentation for on Wikitech): does anyone know of any programs that have been made to process that data? —  crh 23  (Talk) 19:15, 10 May 2016 (UTC)
If you just want to download the data, I can make a "download as CSV" feature for Topviews, as we have for Pageviews. However mind you Topviews data is approximate due to API limitations. The dumps at [24] might be more accurate MusikAnimal talk 14:55, 11 May 2016 (UTC)

Printable/book versions

Two issues:

1. The "printable version" of an article will only give the title of a URL (the same thing that a reader sees on the actual page), but not the URL itself. Could this be changed so that the URL is given in parentheses after the title? An example from today's FA:

What the printable version will currently display:
  • Hubbard, Amy (2012-10-15). "Celebrating Little Nemo by Winsor McCay; his 'demons' made him do it". Los Angeles Times. Archived from the original on 2013-02-13. Retrieved 2012-12-15.
My suggested change would display this:

2. The "download as PDF"/book creator functions are apparently very obsolete/nonfunctional. For example, it appears to completely ignore any content embedded in tables or templates. Should these links simply be removed from the toolbar?

Thanks, postdlf (talk) 16:32, 10 May 2016 (UTC)

1 This is hidden by our local print stylesheet. I don't think it used to be like that. did we change something about references ?
2 Well yes, they have many bugs. Removing the links is the most sure way to guarantee that no one will ever fix them however. —TheDJ (talkcontribs) 17:44, 10 May 2016 (UTC)
The mw:Offline_content_generator certainly supports templates. It does suppress most tables and infoboxes by default, as they've proven very resistant to proper layout; over-wide tables often break the rest of the page. It is supported and maintained, but only by one person (me). Greater support and patches are very welcome! The task for table support is phab:T73808, for instance. One thing I would like to implement is the ability to add hints for the PDF generation, so that we can fine-tune the output on featured articles (for instance). For instance, math-related articles show up better in single-column mode. Some tables or infoboxes might be "whitelisted" using this mechanism. C. Scott Ananian (talk) 17:53, 10 May 2016 (UTC)
It's nothing to do with templates (if it were, then such things as this link - Postdlf - wouldn't print). This issue has come up here before, several times, and is related to such threads as Wikipedia:Village pump (technical)/Archive 144#Mobile version not displaying some content - some box-type structures belong to certain classes (like infobox or metadata), and those classes are given the CSS declaration display:none; for some media types, including mobile and print. There are two routes to fixing it: either remove that declaration from the rules that match those classes, or remove those classes from the boxes in question. --Redrose64 (talk) 19:32, 10 May 2016 (UTC)
I see, so it's more of a CSS issue? I think most templates these days use CSS. postdlf (talk) 21:51, 10 May 2016 (UTC)
Most of the Internet uses CSS, it's not confined to Wikipedia templates. The problem is that the style sheets include some rules whose selectors match certain structures on the web page and whose declaration blocks set the display: property to the value none. That does not have to be done by means of a template; try printing this page, do you see these three words in it? I thought not. But that's not a template, it's pure inline HTML. But you should see these three words, which are inside a template, one which uses no CSS whatsoever. --Redrose64 (talk) 22:52, 10 May 2016 (UTC)

@C. Scott Ananian: omitting the infoboxes from various highway articles is quite problematic. That's where the map of the highway is shown, for example! Also, by dropping tables, the entire junction list on something like U.S. Route 16 in Michigan is lost, and that's considered one of the "Big Three" sections for any highway article along with the Route description and the History. In short, we lose a lot of content on a whole class of articles. It's even worse on an article like Pure Michigan Byway: the main list, the infobox with map and the gallery of photos are gone. (The captions for the gallery are still there, oddly enough.) Hopefully these elements can be restored. Imzadi 1979  09:03, 11 May 2016 (UTC)

@Cscott: reping. Imzadi 1979  09:05, 11 May 2016 (UTC)
Yeah, this is all known. Again, the choice is between never fixing it (remove) or keeping a door open towards fixing it. There is no 'go fix this now'-option to choose. —TheDJ (talkcontribs) 19:33, 11 May 2016 (UTC)

wmflabs 'edit summary' search not working?

Today I wanted to search an editor's edits for a specific phrase in their edit summaries. I know they used this phrase in their edit summaries, I can see it in the first page of their contributions and yet...AND YET... when I use the edit summary search I get zero results. This is not possible. I sat down and hand-counted the edits over some period of months and knew there are at least 30 with this phrase. I tried one part of the phrase, I tried the entire edit summary from Twinkle but both times came up with no results. Is the edit summary search function not working these days? Thanks, Shearonink (talk) 14:24, 11 May 2016 (UTC)

@Shearonink:  Works for me Which user, what phrase? --Redrose64 (talk) 20:13, 11 May 2016 (UTC)
Hmm... well, oddly enough, I just ran it again and it worked. Took a couple minutes to come up with the results though. Shearonink (talk) 20:41, 11 May 2016 (UTC)

Tech News: 2016-17

21:02, 25 April 2016 (UTC)

Change of "Save page" button to "Publish"

The use of Publish instead of Save Page would look more confusing IMO as many experienced users are already used to saving pages. Publishing would mean it's final, and Wikipedia itself is not final. Was there community consensus or Meta discussion on that change? And will this go live together with the new MediaWiki version? 49.148.95.70 (talk) 04:05, 27 April 2016 (UTC)

Some documentation would need to be changed … --Pipetricker (talk) 09:03, 27 April 2016 (UTC)
"as many experienced users".. Please note that these people are far fewer than that globally there are (potential, incidental or inexperienced) users of the MediaWiki software. Just saying. —TheDJ (talkcontribs) 10:54, 27 April 2016 (UTC)
And every save is final, because every action is public and logged eternally. It's a matter of perspective. —TheDJ (talkcontribs) 10:58, 27 April 2016 (UTC)
Comment on the phab tickets - I can't see any good reason this shouldn't be able to be controlled via a local variable such as Mediawiki:Save-button-label. — xaosflux Talk 11:10, 27 April 2016 (UTC)
Is it like a localization to Wikipedia? 49.148.95.70 (talk) 11:17, 27 April 2016 (UTC)
It's currently controlled via MediaWiki:Savearticle but will apparently change to MediaWiki:Publishpage.[30] The wording is also being changed in the VisualEditor interface, in other wikis, and presumably in many foreign languages when they catch up. The transition may cause some confusion but there will probably be more long-term confusion if the English Wikipedia decides to override a coming "Publish page" default. PrimeHunter (talk) 11:33, 27 April 2016 (UTC)
(edit conflict) The current save button uses MediaWiki:Savearticle. Use &uselang=qqx to find it out once its deployed. Also, blah en-gb blah blah always broken. — Dispenser 11:46, 27 April 2016 (UTC)
I missed on that one. Was there a discussion in this Wikipedia about the change? The discussion in the link is to Phabricator, not necessarily about Wikipedia, and many users may haven't been aware until the bot message was posted here. 49.148.95.70 (talk) 11:17, 27 April 2016 (UTC)
  • I think this is very unwise. "Publish" is not a good word and is confusing (especially for non-native English speakers who come here). "Save" (or "Post") is simple, direct, common, and easily understood. "Publish" is entirely inaccurate. How did the word "publish" get so corrupted that someone wants to use it for single impermanent iteration of a Wikipedia page that could get reverted by someone else within seconds? Softlavender (talk) 13:35, 27 April 2016 (UTC)
    • Actually, they've been talking about this for years, and multiple studies with users say that this change needs to be made. Inexperienced people consistently believe that "Save" means "Save inside my personal account, but don't show it on the web". And because of a lifetime of being told to "save early, save often", they often save before trying to do something that feels risky to them – like "Show preview". I'm looking forward to this change, because it looks like there will be less confusion for new editors and consequently less mess for the rest of us to clean up. Whatamidoing (WMF) (talk) 17:19, 28 April 2016 (UTC)
      • @Whatamidoing (WMF): I can believe your argument about "save" versus "publish". But how the hell does "show preview" feel risky? Can you point me to these studies you're talking about? Thanks. BethNaught (talk) 07:07, 3 May 2016 (UTC)
        • Our implementation of Show preview is different from any common UI paradigm in or out of a browser. In my experience it is unique to Wikipedia. The entire edit interface is like that, where clicking Back after a save inexplicably and counterintuitively drops you back into the editor. The whole damn thing seems clunky and 1980s-ish, which no doubt contributes to the difficulty of retaining editors from non-tech backgrounds. But that's off topic.
          As for "save" vs "publish", I can only say that "publish" would have been less intuitive to me as a new editor, since I didn't come here to publish anything. That said, the uncertainty will be very short-lived for the new user. Absent any other button that looks like it will commit their edit, they will probably click Publish and discover what it does. I don't think the problem will turn off many editors who are motivated enough to last in this environment longer than a few days anyway. After a few edits, it won't matter if the button says save, publish, or XYZ; they will know where it is and what it does. ―Mandruss  07:49, 3 May 2016 (UTC)
        • Beth, there really isn't anything to read. Most of these are face-to-face studies, with a researcher and a user sitting down together and seeing whether the user can figure out how to edit a page, and ask them to talk about what they're doing and thinking. The researchers then summarize their notes, which – if we're lucky – eventually get posted to Commons, but (of course) not all the researchers are in the WMF, so not all of them think to do this. And even when the reports are published, the content is unfortunately as minimal as what I've just told you. For example, from a recent one study about the visual editor (still unpublished, AFAICT), the sole content about Save/Publish out of 17 slides is just seven words: "Confusion about whether 'save' also meant 'publish'". If you then go talk to the researcher, you can get more information, but there really isn't anything to read. It'd make a horrible source for supporting a claim in an article. As a result, what I know about "users feel that 'Show preview' is risky" is: users feel that 'Show preview' is risky. Maybe they worry that their computers crash easily? Maybe they had "save early, save often" drilled into them from any early age? Maybe it's just the order of the buttons (Save page, then Show preview, then Show changes)? I don't know. But that's the fact: many newbies feel like 'Show preview' is a risky button, so they want to do something 'safe', like saving their work, before they try it.
          I also agree with Mandruss' comment: Experienced editors really don't look at the button anyway. This change is about getting people past their first couple of edits (well, and doing whatever makes Legal happy, of course). Whatamidoing (WMF) (talk) 17:18, 3 May 2016 (UTC)
          One of the Asian Wikipedias - I think it's zh: - doesn't allow "Save page" until you've used "Show preview". --Redrose64 (talk) 18:02, 3 May 2016 (UTC)
          Yes, it's the Chinese Wikipedia. I suspect that experienced editors here would find that very annoying, but since Chinese is a dual-script wiki (the articles can be written in a mix of simplified and traditional characters, but displayed entirely in whichever one the reader prefers), that has probably saved them a lot of grief. It might make sense for all of the "language variant" wikis (Gan, Inuktitut, Kazakh, Kurdish, Serbian, Tajik, Uzbek) to try that. Whatamidoing (WMF) (talk) 18:11, 3 May 2016 (UTC)
          This is a very strange basis on which to make even fairly trivial UI changes. I don't see how, on the basis of the data you apparently have, you can say this is a "fact". It's a second-hand report of a handful of observations, with no information about how these test users were selected, whether this alleged confusion was a significant barrier to otherwise productive editing, or whether the use of "publish" as the button label actually reduced their confusion. Do an A/B test and show that it makes a difference in the aggregate for a reasonable sample of the actual user population and then roll out the change. Opabinia regalis (talk) 18:41, 3 May 2016 (UTC)
          I'd like to A/B test the world, but what do you measure here? An increase in the total number of edits, a decrease in the number of edits that have to be suppressed to remove non-public personal information, a quarter-second shaved off the average edit time for first edits because a fraction of users spent less time wondering what the button did (How do you even figure out if it's a first edit, rather than someone who has been editing as an IP or under a different account, since you can't ask them directly?), a decline in the number of test edits saved, a decrease in the number of people who are in legal jeopardy because they "Published" libel on the web when they meant to privately "Save" it on a computer? I think that the UX people are right: sometimes it makes more sense to interview people, figure out which ones are truly new users, directly watch what they do, see when they hesistate or get strange looks on their faces, and then directly ask them what their problems are. An A/B test is never going to produce a result that says something like, "I'm not really sure if clicking this button will save my work privately on my computer or will publish it on the web." Face-to-face user tests, however, have produced that result – repeatedly, in multiple studies, with many new users. Whatamidoing (WMF) (talk) 18:16, 4 May 2016 (UTC)
          Well, you said there would be "less mess" to clean up if this change is made, so you must have some idea of what the effects are. What was the observed effect of this "confusion" in the user tests? Did people who professed confusion try to save very short pages, or pages with placeholder text? Did they make more obvious test edits? Post their phone numbers? Were these people able to make productive edits after the confusion was cleared up, even if it took a human directly telling them how the interface worked? Were any users tested with the button labeled "publish" and if so, what if anything did they do differently? I realize this isn't science and isn't a research project and doesn't have unlimited resources, but surely at least the proposed revision was tested to see if it addressed the problem, or created any new ones. The logical metric for a larger-scale sample is whatever observations were made in the pilots. I just don't see how you (or anyone) can be confident that this is a problem, and be confident that this change will solve the problem, and yet have no idea of how to measure whether the problem was solved. Opabinia regalis (talk) 02:12, 5 May 2016 (UTC)
  • Comment: apparently, this is just changing the default, which is overridable with the local MediaWiki: message. So there's no need to harangue the engineers if you don't want this to happen here. BethNaught (talk) 07:07, 3 May 2016 (UTC)
    • It is still valuable to remind said engineers that a change to default mediawiki does not necessitate a change here. Especially one so pointless and unnecessary as this. Resolute 17:10, 3 May 2016 (UTC)
      • I say change it because it will lessen accidental AGF edit tests, not only that but it will be a test to see if the mediawiki default will have good outcome... Ⓩⓟⓟⓘⓧ (talk) 14:15, 6 May 2016 (UTC)
  • Comment: the word "Publish" has commercial implications, so I'm not sure that's the best choice. My suggestion would be "Update". Praemonitus (talk) 21:24, 9 May 2016 (UTC)
    • Many words have many connotations, but that's not necessarily the same as implications. I'm not aware of a commercial implication due to the word publish, however there is a important effect on copyright. That already applies to us, wether we say Save or Publish, and publish would again be more accurate. —TheDJ (talkcontribs) 18:02, 10 May 2016 (UTC)
  • Comment: WordPress uses "Publish" for new posts, but "Update" for changes; Twitter uses "Tweet" (which seems more similar to "Publish" than "Save"), and doesn't permit editing; Nextdoor.com uses "Post" or "Post event" for new posts but "Done" when editing a post ("Save changes" when editing an event). Those are the only platforms I'm familiar with, other than Facebook, which waits for the first [Enter]/[Return] press to save/publish a post (if you subsequently edit that post, you click "Save" to end your editing). I welcome others to add (common) examples (Instagram?); I'll only note that the button label in question doesn't distinguish between creating a page and editing an existing page; that's actually quite unusual for common web platforms. -- John Broughton (♫♫) 19:45, 10 May 2016 (UTC)
  • Comment Yes this may save some clean-up. But the resistance to pressing "publish" is a bad thing, we have too few people willing to make edits as it is. Gender gap research indicates that lack of confidence is one of the key inhibitors for women and girls, this change might exacerbate that issue.
All the best: Rich Farmbrough, 19:18, 12 May 2016 (UTC).

Cross wiki notifications will be released by default on May 12 at 23:00 UTC.

Hello

Cross wiki notifications will be released by default on all wikis on May 12 at 23:00 UTC

During the beta phase, the cross-wiki notifications feature was enabled by over 18,000 accounts across more than 360 wikis. We receive great feedback from a lot of very happy users. After that 3-months long beta period during which we made adjustments and that feature is now ready for a release by default.

Users who don't want to receive cross-wiki notifications will be able to turn them off on their preferences on each wiki. If you haven't activated Cross-wiki Notifications during the Beta phase, you may receive old unread notifications from other wikis.

More information is available on the documentation. The talk page is still open for any questions or feedback, in any language.

All the best, Trizek (WMF) (talk) 16:43, 12 May 2016 (UTC)

User:Trizek (WMF) Hm... I like the feature. I suspect that a lot of people will get, as I did when I enabled it, a slew of years old notifications, which I didn't like. May I suggest you limit this to notifications to those left after the change to the default? All the best: Rich Farmbrough, 19:21, 12 May 2016 (UTC).
I might also suggest that 6 hours and 17 minutes is not very much notice. Face-tongue.svg All the best: Rich Farmbrough, 19:23, 12 May 2016 (UTC).
We had discussed about that with the team and some users, and we have decided not to add a limit because that amount of old notifications was not that important on average and sometimes people had great surprises. did you received a lot of old notifications at the same time? Trizek (WMF) (talk) 19:30, 12 May 2016 (UTC)
They appeared to arrive in two batches. All the best: Rich Farmbrough, 19:44, 12 May 2016 (UTC).
These old notifications did in fact arrive in batches during the first few weeks of the beta feature release, because we made the beta feature available while we were still populating all the tracking information. This process took three weeks and went through all wikis in alphabetical order. It finished on March 22nd, so anyone who enabled the beta feature after that date should not have had the batched arrival experience, nor should anyone who first gets it when we enable it by default today. Any old notifications should be visible immediately, so while people will have to dismiss some old notifications, they'll only have to do that once. Besides, some people have reported finding useful things in there that they had missed before :) --Roan Kattouw (WMF) (talk) 20:03, 12 May 2016 (UTC)
I only activated it a few days ago. So I am expecting that you will see some unexpected behaviour! All the best: Rich Farmbrough, 22:06, 12 May 2016 (UTC).

How much is VisualEditor used?

Currently, what percentage of Wikipedia editors use VisualEditor? Related question: what percentage of Wikipedia edits use VisualEditor? --Guy Macon (talk) 09:31, 12 May 2016 (UTC)

Enwiki, article namespace only, bots excluded: 95% of the edits are made using wikitext, 5% are made using VE.[31].
VE has every day about 2,500 unique editors (less in the weekends, somewhat more during the week), while wikitext has about 21,000 unique daily editors. Excluding IPs, we have every day about 2K editors using VE and 8K editors using wikitext.
More statistics can be found here. (Note that according to the WMF, these WMF-provided statistics are now useless to make the distinction between newly registered editors and other ones, as "newly" starts a few years back). Fram (talk) 09:51, 12 May 2016 (UTC)
@Guy Macon: To answer your question, for the English Wikipedia, last week (roughly) 23% of logged-in editors and 6% of logged-in editors' edits (about 5% of all edits). Note that (e.g.) AWB edits push down this percentage as they technically count as wikitext edits (even though it's mostly a bot).
However, I think the more interesting numbers are how successful edits are in using VE vs. WT for their first few edits (which is one of the main reasons why we're building VE, after all); see [32]. For this wiki last week, VE was 126% more successful than the wikitext editor at getting newbies to make their first edit (30.3% vs. 13.4%), and 26% better at making their 2nd through 5th edits (42.2% vs. 33.6%). For IP editors on the German Wikipedia (where VE is enabled by default for IPs, unlike here), it's even more pronounced – VE is slightly more than 600% better (9.2% vs. 1.3%) at getting people to actually make and save an edit.
Jdforrester (WMF) (talk) 23:30, 12 May 2016 (UTC)

A polite version of "Fooled you again suckers, haha" from Jdforrester (WMF) to enwiki.

Some of you may remember Wikipedia:Village pump (technical)/Archive 145#VE was imposed as primary editor and the subsequent Wikipedia:Village pump (technical)/Archive 146#Earth to JDForrester. Basically, before the new release of the choice of editing environment (wikitext or VE) in April, User:Alsee asked User:Jdforrester (WMF) explicitly that wikitext would be the default for new editors at enwiki, and was promised quite clearly that this would be the case.

Surprise, surprise, after the release it turns out that this is not true and VE is the primary editor. This issue is raised here, at Phabricator, and at Jdforrester's talk page, but no reaction follows. Despite this being the only post to his talk page in that period, he claimed that his very late response was because he hadn't seen the message and had too many notifications.[33] That's why we have the "you have new messages" orange notice here, of course, but perhaps that's too difficult.

Now, the Phabricator task has suddenly been declined by Jdforrester with the following text

Yup, sorry about this.

I didn't configure the wiki exactly as I had intended, which indeed had the effect that new users who've never edited before will get the visual editor on first edit (unless their machine is incompatible). The plan was to make that part of change subsequently to the main change, which was to provide only one edit tab (with the editor chosen by the user) instead of having two.

Now that both these changes are deployed, I think going back and then forward would cause confusion and disruption with no benefits for our editors. The benefit for users following the plan would have been a lack of unexpected changes. However, this is not something I can create from the spilt milk we now have, sadly.

Consequently, I won't be undoing this change, as I don't think there is overall value in so doing. In future I'll take more care in writing these kinds of changes, sorry.

(end of quote) This, of course, is not only going back on earlier promises without any further discussion, but also seems to be a, what is the acceptable way of saying this, right, an "incorrect statement". Please, Jdforrester, explain how it would be confusing to present new editors on enwiki from now on with wikitext as the primary editor instead of VE, as planned and promised? The editors who have registered meanwhile (between early April and now) don't need to be set back, that damage is done, but the discussion is only about first edits by new editors. How will it be confusing if from now on, they get wikitext as the primary editor? And why then wasn't this a problem when you made your promise earlier? Please provide us with a much better explanation of why you closed this as "decline", as the current one is utterly unconvincing.

Please reopen the phab ticket and do what has been asked of you and promised by you, instead of inventing excuses why it just happens that the WMF-wanted situation is the one we end up with, again, for the umpteenth time, with the minority editor imposed as the default.

User:Elitre (WMF), since you are a community liaison who actually functions in that job, could you please liaise in this situation and convince Jdforrester that simply sending us a polite "sorry, I never planned to do this but told you otherwise, now fuck off" is not really acceptable? It sens the same old unacceptable message of the disconnect between WMF and enwiki, and the disregard some of the people there have for concerns expressed here. Fram (talk) 09:45, 11 May 2016 (UTC)

@Fram: Hey there. As always, I'm totally happy to be convinced to change my mind. I'm not sure escalating from people working in partnership to a 'confrontation against WMF' is the right move here. :-(
The series of changes (secondary access to the visual editor for users; secondary access for IPs; SET; prompted choice of editor for users; prompted choice of editor for IPs) has been underway for almost a year now. I really didn't mean to do steps three and four together, and I'm sorry that it happened like this. That said, I don't think undoing step four and then almost immediately re-doing that it in a week's time is valuable for anyone. Am I missing something?
(Also, it's worth noting that the impact of this change has been to slightly reduce the number of users using the visual editor, because people stick to the last editor they used. I'm not pushing it so much as pulling it back to users who regularly use it. I think continuing to give new accounts a choice of editor – as voted for by community RfC in August – is important to preserve.)
Jdforrester (WMF) (talk) 19:40, 11 May 2016 (UTC)
@Jdforrester (WMF): Don't wave your RfC about. Neither the September RfC nor the July RfC (I couldn't find an August one, could be wrong) supports making enwiki VE-primary; both operated on the assumption of having two edit tabs. The "choice of editor" is also more or less meaningless now that single edit tab has been implemented: whereas before there were two clear options, now there is a pop up with a "switch to source editor" which is visually de-emphasise. Therefore you can't claim that making VE primary is insignificant, since, there being only one edit tab, VE is now thanks to human nature and some de-emphasising design the effective default for new accounts.
Did you plan to ask before the next stage, had you not made this mistake? If you want to be "working in partnership" like you wrote, you should have done so. BethNaught (talk) 22:10, 11 May 2016 (UTC)
"As always, I'm totally happy to be convinced to change my mind. I'm not sure escalating from people working in partnership to a 'confrontation against WMF' is the right move here. :-(" Then why did you change your mind without any indication of what convinced you or any attempt to discuss this with e.g. Alsee or the enwiki community before closing this, and why did you stop "working in partnership" and instead choose to go for the confrontation against enwiki yet again? You are good with hiding your intentions after smooth words (hence the "polite" in my header here), but you are much better with showing your true intentions with your actions. Can you explain why it is so hard for your team of developers to change the default editor for newly registered editors from Ve to Wikitext? It was possible to deliver this, you never claimed it wasn't, but apparently now you can't do this any longer without rolling back a previous rollouot. Which looks from here like you (the team you are product manager of) are totally incompetent, or you (personally) are lying. The two, sadly, aren't mutually exclusive. User:Jdforrester (WMF), feel free to provide a better explanation, just make sure it is convincing this time. Fram (talk) 07:03, 12 May 2016 (UTC)
.. while this of course, easily, could be on-wiki configurable settings .. but that would be result in '.. a website which allows collaborative modification ..', which we of course are not. --Dirk Beetstra T C 11:18, 11 May 2016 (UTC)
However, this is not something I can create from the spilt milk we now have, sadly. - It is scarcely believable that Forrester could be so openly dismissive of anyone disagreeing with his action. Which, by the way, is a textbook example of a fait accompli, made not by volume of actions, but by a single action from power.  — Scott talk 17:04, 11 May 2016 (UTC)
  • So. Hypothetically speaking, what would y'all think of a script that would automatically disable the VisualEditor for new users on our end? Say a coder that we'll call "M. Hypothesis" had developed a script to detect new users (perhaps via checking mw.user.options.get("visualeditor-hidebetawelcome") == 0). One might imagine this script would then change the user's preference to default to "always use source editor", and one might further imagine that this script would then set the aforementioned hidebetawelcome to 1, to avoid overwriting any further settings. Maybe, to be even more safe, M. Hypothesis might also add a check that could look something like mw.config.get("wgUserEditCount") == 0, because I'm imagining that M. Hypothesis is a nice person who doesn't want to change a preference that someone is already using. Now, this is all wild speculation, of course, but if M. Hypothesis added this script to Mediawiki:Common.js (or maybe just vector.js; M. Hypothesis might imagine that someone who can change their skin can intelligently choose for themselves what editor to use), such a script would have the effect of making new users default to the source editor, which is what seems to be wanted here. I wonder what would happen in such a hypothetical scenario? Writ Keeper  18:35, 11 May 2016 (UTC)
    Hypothetically, this basically happened with the ImageViewer and is what caused the whole superprotect debacle. Sounds like a Great Plan™. --Izno (talk) 18:48, 11 May 2016 (UTC)
    Technically, dewiki did that. But the difference here is that this (nominally) isn't a change that the WMF is forcing on us; this is a bug that the WMF has refused to fix (again, nominally). I'd think that a user like M. Hypothesis simply can't abide bugs, and so they want to simply fix it. How could the WMF complain about some hyothetical coder who just wants to fix bugs? Writ Keeper  19:07, 11 May 2016 (UTC)
    "Technically, dewiki did that". Eh no, they did something much more intrusive. I don't see a technical problem with what you suggest (unlike with what de.wp did). —TheDJ (talkcontribs) 19:38, 11 May 2016 (UTC)
    They say that they are sorry for superprotect, but we haven't put up any resistance to their ongoing "we know what's best for you better than you do" attitude lately. I strongly suspect that they will do to M. Hypothesis what they did before -- use superprotect or something like it to get their way. --Guy Macon (talk) 19:14, 11 May 2016 (UTC)
i do not like the actions taken by Forrester more than the next person likes them (that is, not at all), and i had one or two more encounters with this person which left me very disappointed with his attitude.
that said, i think the idea of simply "disabling" VE for new editors is atrocious, and in effect, is just as arrogant and bad (or worse) as Forrester's behavior. you are absolutely entitled not to like VE and not want to ever see it in action, but this can't justify depriving other users of the choice. if i misunderstood User:Writ Keeper's question "what would y'all think of a script that would automatically disable the VisualEditor for new users on our end", and by "disable" he actually meant "making sure it's not the default", then i think he should clarify. if by "disable" he meant disable, then this is awful idea, as bad or worse than Mr. Forrster's arrogant and dismissive behavior. קיפודנחש (aka kipod) (talk) 19:44, 11 May 2016 (UTC)
Yes, "making sure it's not the default" would be the behavior. Any user would be free to switch to VisualEditor if they like; this wouldn't interfere with their choice. Writ Keeper  19:46, 11 May 2016 (UTC)
What are the reasons for doing this, aside from "they turned it on without asking"? Reverting for the sake of it is stupid and unproductive. Could you please point me to where this change is causing disruption to the encyclopedia that would actually warrant such an action? It sounds to me like you're wanting to pick a fight over a power grab, plain and simple. Keegan (talk) 19:54, 11 May 2016 (UTC)
Not only did they turn it on without asking, they did so after recently promosing they would not do so, and after promising to fix it when they did. Translated out of mollification language, you last sentence means "just let the WMF break its promises, and meekly comply as they steamroller over you." 3 years after the original fight, the WMF still hasn't learned. In my opinon, yes, the WMF needs to be taught that it can't lie and mislead and mamipulate. Of course, as a staffer, you would be comfortable with that when you like VE. BethNaught (talk) 20:04, 11 May 2016 (UTC)
BethNaught, I've been a Wikipedian and an admin of this site for a decade now, and I'm writing as such. I have the right to comment here, and I will not refrain from doing so. There is no need to bring a staff label onto me to discredit me. Please explain to me how an eye-for-an-eye is appropriate? While you're at it, please explain how your personal jab at me is appropriate as well? Keegan (talk) 20:08, 11 May 2016 (UTC)
The fact is that you just completely ignored BethNaught saying "Not only did they turn it on without asking, they did so after recently promising they would not do so, and after promising to fix it when they did" tells me that "as a staffer, you would be comfortable with that" is likely to be an accurate prediction of future behavior. What you should have done, assuming that you are not comfortable discussing the behavior of a fellow WMF staffer (I know I wouldn't be) is to simply state that you will bring this to the attention of the appropriate level of WMF management so that they can get ahead of this before it becomes one more WMF debacle which gets posted to Slashdot, Wikipediocracy, Reddit, etc. You should do this even if you personally think there is nothing to it. Clearly multiple Wikipedia editors are pissed off. After the broken promises associated with Pending Changes (I have a document with full details I can post if anyone is too new to know about that one) the WMF needs to work to regain our trust. --Guy Macon (talk) 07:36, 12 May 2016 (UTC)
What's it like, telling people what to do on the internet? I'm writing here as a volunteer, I "should"n't do anything that you suggest, nor did I ask for your instruction. Take your unpleasantness to someone else, because your words are hollow when they are full of spite. Keegan (talk) 16:43, 12 May 2016 (UTC)
(edit conflict)Well, on some level, yes, I *do* want to pick a fight over a power grab; the thing about power grabs is that they keep happening if you don't challenge them. also for the lulz. But this isn't a thing I'm just going to go do on my own; even apart from WMF reprisals (and how is that even a thing), pushing unvetted, unfinished code into production is a bad idea.

Which, y'know, is the more important reason why we should do this. The VisualEditor is still in beta; it is not complete code. We should not be pushing new users toward it, and certainly not without a disclaimer that it's still in beta. Yet right now, that's exactly what we're doing. That's what I'd like to fix.

Because keep in mind that this has been presented to us as a bug. While the whole "M. Hypothesis" was obviously me being facetious about the fact that WMF reprisals are in fact a thing, I wasn't totally kidding--from what we've been told by the WMF, and also according to what we wanted, this is a bug, not a feature, and I want to fix the bug, since the WMF won't. The only way that this is "sticking it to the Man" is if the WMF really was lying the whole time, and never intended to make the normal source editor the default. So, if we AGF and all that that the WMF *wasn't* lying, then this shouldn't be controversial to them at all; we're just fixing a bug and making the software behave in the way that both the WMF and we wanted. If. Writ Keeper  20:18, 11 May 2016 (UTC)
"We" wanted it that way? From what I can tell, it was done that way so that the people who are upset right now wouldn't be upset, not some kind of community consensus. So when y'all talk about "we", stop pretending to speak for the community. Show me evidence that this is harmful and needs reverted, not that you want to make a power grab to prove a point. That behavior is unbecoming of an administrator. If you can show that this move has harmed the encyclopedia and thus you are fulfilling your duty as an admin, then I might support you. Y'all are playing petty politics, admins are to be more civilized than that. Keegan (talk) 20:27, 11 May 2016 (UTC)
I never claimed to be speaking for the community. In fact, when I was typing all this out, I had originally used the word "community", and I deleted and replaced it with the pronoun "we" specifically so that I wasn't speaking for the community. This is a bug that I'm trying to fix. It's only a power grab if the WMF wants it to be, if the WMF had duplicitously grabbed first. We don't need widespread community consensus to fix bugs, nor do we need to do A/B testing to see if the bug is harmful. It is harmful by definition: code that is not production-worthy has been pushed closer to production than it should have been or was intended to be. We can fix that; assuming the fix works, why wouldn't we? This shouldn't be controversial; "petty politics" is the only reason it is. Writ Keeper  20:36, 11 May 2016 (UTC)
It's not harmful by definition, but by your definition. Visual editor is stuck labeled "beta" because of pushback here three years ago. It's about as beta as MediaWiki is, so we can just shut this whole thing down and go homejoking!. In all seriousness, you're saying bug=harmful. That is not true. Our own software bug starts with "A software bug is an error, flaw, failure or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways." It does not say harmful. I am asking you to show the harm that you intend to fix. It shouldn't be hard for you to do if it's as bad as you say. Keegan (talk) 20:47, 11 May 2016 (UTC)
en.wiki is a source-editor-default wiki. The settings for new users are not honoring that. Whether you consider that harmful or not is irrelevant; it is incorrect behavior, and fixing incorrect behavior does not require widespread consensus (at least, not when it doesn't hurt anything else, and this doesn't). If you want "harm", then imagine a user who's been editing as an IP for a while. As an IP, they've been using the source editor, which is correctly the default for IP users. One day, they finally decide to make the jump and register. When they do so, instead of the source editor they're used to, they get this weird VisualEditor thing, but it so happens that they are doing so while trying to edit something that VisualEditor doesn't handle well. It flubs their edit, messes up the table, they don't know how to fix it, get frustrated, and give up. That is harm. Pointing new users to beta software without indicating that it's beta is harmful. If, by the way, you're really insisting that VisualEditor isn't in beta, then I guess it's my turn to ask for evidence to back up your statement; it's clearly indicated as beta in both the preferences and the internal variables. Hell, the dialog box we're talking about is even labeled "betawelcome" internally--not that it mentions that in the box itself. But even if not, the mere fact that it's providing an unnecessary and undesired behavior--particularly when that behavior is at odds with other site behavior, e.g. IP editing--is enough to fix it. Again, the only thing this change costs is the time we spend discussing the petty politics; there's no other reason *not* to do this. Writ Keeper  21:04, 11 May 2016 (UTC)
I don't want your imagination. I want evidence of harm. I don't want labels as proof, because all anyone here is trying to do is use labels to defend things. That's not responsible administration of this website. Look, you asked, essentially, if anyone would have a problem with you reverting the change. You've got two yes's already. Nip this idea in the bud before this gets ugly, the choice is yours to make here. If you want to go down this road under the argument of "I'm right, they're wrong," then you are making a poor decision, in my opinion, and other community members will be upset with you, as I am now. Keegan (talk) 21:13, 11 May 2016 (UTC)

Right, you're asking for something that you know I physically can't give you, because the only actual evidence that would be worthwhile would be an A/B test of new users, which is laughably beyond any one user's capability--I'm not even sure the WMF itself is currently equipped to do that. I know they're gearing up to test it, but I don't think they've actually done it yet. But absence of evidence is not evidence of absence, and given that we *know* that this is currently not working to specifications, and that we *know* we can fix it without any other negative impacts, why would we not fix it? How does it make sense to demand that this behavior, which everyone has admitted is wrong behavior, must do some other unspecified "harm" beyond its wrongness to implement a painless, essnetially free fix for it?

Remember that both this bug and this fix only affect new users--nobody that's currently part of the community would even be affected by either. So what exactly are you looking for? Because if I'm being quite honest here, it looks like you're just moving the goalposts. also, the only "no" I'm counting is yours, unless I guess you're counting Izno. That's not how consensus works; we don't stop RfAs as soon as they get their first "oppose" Writ Keeper  21:25, 11 May 2016 (UTC)

You have my "no". We also have data suggesting engagement is higher with VisualEditor, through this somewhat difficult to read tool at [34]. Not saying we shouldn't move forward with an RfC, but let's definitely not write this script without consensus first. The problem is of course the people whom this RfC will concern are very unlikely to participate in it MusikAnimal talk 21:34, 11 May 2016 (UTC)
Well, like I say, I definitely wasn't planning on going rogue and deploying it sitewide myself--I've had other people do that with my scripts before (the OBoD thing), and I'm definitely not a fan. Besides, what's the point of asking for people's opinions if I'm not going to care about their answers? If people want an RfC, that's fine; I don't think it should really be necessary, but whatevs at this point. Writ Keeper  21:58, 11 May 2016 (UTC)
I'll also add my no. —TheDJ (talkcontribs) 22:31, 11 May 2016 (UTC)

Suggestion

  1. Get someone who knows how to write such a script, if Writ Keeper hasn't already.
  2. Propose an RfC about whether the script should be implemented.
  3. Deploy the script if the RfC is successful.

This procedure would have several benefits:

  1. Opportunity for code review
  2. Find out whether VE has support in the community
  3. Make any WMF reprisals illegitimate

BethNaught (talk) 21:27, 11 May 2016 (UTC)

My draft of the script is at User:Writ_Keeper/Scripts/hypothesis.js. Works as near as I can tell (I've been adding it to teh common.js of test accounts before I create them). Writ Keeper  21:30, 11 May 2016 (UTC)
I would much rather see this fixed server-side than client-side. It's not best coding practice to fix obvious bugs in such a roundabout manner. Perhaps just push for a phabricator request to be allowed, and then a community coder can get this simple change reviewed & deployed during SWAT. Mamyles (talk) 21:40, 11 May 2016 (UTC)
Agree in principle, but after Forrester's remarks, what hope of that is there? If anything, we may hope this RfC itself would make the WMF relent. BethNaught (talk) 21:42, 11 May 2016 (UTC)
Yes, fixing it serverside is always the ideal. In lieu of that, though, I don't think this is so bad. Writ Keeper  22:00, 11 May 2016 (UTC)
I'd like to reiterate that, aside from it being not what we were promised, the main issue for me is that this bug creates an inconsistency in the user experience between IP editors and newly-registered users: IP editors get the wikitext editor, but newly-registered users get the VisualEditor by default. I think that's a signficant issue (not site-breaking of course, but not trivial either), and one I'd hoped my script could fix. Writ Keeper  22:17, 11 May 2016 (UTC)
It is not site breaking, but it is an inconsistency that will make new editors who first edited as an IP wonder what happened to 'their' editor (I wouldn't be surprised if some stepped back go back to IP editing). I therefore support activating this script now (as per discussions, and repeated broken promises of WMF), and do what the WMF should have done in the first place: start an RfC to gauge what the community thinks should be the standard situation. --Dirk Beetstra T C 03:45, 12 May 2016 (UTC)
I support activating such a script as well. Fram (talk) 07:04, 12 May 2016 (UTC)
Do we really need another RfC? I could have sworn I participated in at least one last year where there was a clear consensus against making VE the default for new/inexperienced editors. And I don't recall any new discussion in the meantime. I support flicking the switch back now, provided Writ Keeper's code is good (and I see no evidence that it isn't). Jenks24 (talk) 07:31, 12 May 2016 (UTC)
@Jenks24: No, I don't think we need another RfC - unless the WMF wants to convince us that the situation since the last RfC has changed drastically and that maybe the situation is different and they strongly perceive that the community has changed their mind. What could use another RfC is to just blanket override VE completely and completely disable it, whatever WMF is implementing (the few editors and the WMF people who really want it can then in their common.js override the override) - at least until they first ask the community (and preferably until the community agrees). --Dirk Beetstra T C 08:03, 12 May 2016 (UTC)
inconsistency in the user experience between IP editors and newly-registered users - please don't go there. The WMF will just "solve" that by foisting VE on our IP editors too. —Cryptic 11:24, 12 May 2016 (UTC)
@Cryptic: And you think that that is not the whole plan yet? --Dirk Beetstra T C 11:32, 12 May 2016 (UTC)
@Beetstra: Oh, I'm sure it is. I just don't want to accelerate it. —Cryptic 11:34, 12 May 2016 (UTC)
@Writ Keeper, Beetstra, and Cryptic: Yes, you're right, enabling VE as the primary editor for all IP uses is the eventual plan, as discussed at length last year. That's what the A/B test was going to be for – to provide data for the community RfC to help decide whether we were ready yet. Jdforrester (WMF) (talk) 18:53, 12 May 2016 (UTC)

I support deploying the javascript now to fix this bug community-side, per the fact that is an acknowledged bug, per the existing consensus regarding VE for new users, per the burden of having to clean up after so many VE edits, and per the fact that that we have hard data that VE is worse ( May 2015 study found much slower editing and lower rate of new users being able to successfully complete an edit, as well as a complete failure of the purported help more users make a first edit and complete failure to increase editor retention - which were the entire rationale for VE in the first place). If we're not prepared to deploy a javascript fix base on the old consensus then I support an RFC to establish a fresh consensus to do so.

Jdforrester (WMF), this sort of crap is why so many people don't trust anything the WMF says, why so many don't trust the WMF to engage in reasonable collaborative engagement. For half a year you and other staff have been promising you would not try to sneak in a goddamn VE default as part of the single edit tab deployment. Please fix this on your end - that is much preferable to a community side javascript fix. Alsee (talk) 19:43, 12 May 2016 (UTC)

@Alsee: See below. It looks like you haven't seen it. Jdforrester (WMF) (talk) 19:56, 12 May 2016 (UTC)
Ah, I didn't see it because you posted it after I started editing this section. (I was in the edit mode for quite a while before saving.) Alsee (talk) 21:05, 12 May 2016 (UTC)

Resolution

OK, there's way too much shouting right now, and no proper discussion. :-( With the fix that we've done, going out next week, we'll now show the welcome dialog to all users, regardless of editor; this will be in this week's Tech/News newsletter (as it will affect all users everywhere). This will improve the flow for new users (giving them the choice of editor), and then I'll undo the accidental part of the config change for this wiki. No point getting into a war, I'm here to work as a partner. Jdforrester (WMF) (talk) 18:49, 12 May 2016 (UTC)

Of course we want collegial working. For that reason I've changed the section title from "Resolution" to "Proposed resolution". All the best: Rich Farmbrough, 19:58, 12 May 2016 (UTC).
Since we the community have no control over software deployment, the 'proposed' part seems completely redundant, so I'll remove it. Folks, I do think the "community" should let go of the idea that it controls the Foundation and their decisions reagrding the development of MediaWiki. They own Wikipedia, and we are merely granted the privilege to edit it. We do not get to dictate the foundation on how they choose to operate Wikipedia, develop their software or run their servers. Sure, we have the right to yell when things go seriously wrong, but these days, every minor change is perceived as a disaster. This can only develop into a "boy who cried wolf" situation, where the foundation is growing numb to all the shouting, and may ignore it when there is a real problem. So you know what? Just swallow your pride and accept the changes already. -- [[User:Edokter]] {{talk}} 20:27, 12 May 2016 (UTC)
Disagree. They are granted the privilege to host it. The Foundation was created by the community, not the other way around. All the best: Rich Farmbrough, 20:39, 12 May 2016 (UTC).
Uh, it was incorporated by Wales and Sanger to fund wikipedia. So yes, the foundation owns Wikipedia. Editors have no legal position within the foundation whatsoever. -- [[User:Edokter]] {{talk}} 21:01, 12 May 2016 (UTC)
Side note: ideas and discussion about communities' participation in software development are welcomed in mw:Technical Collaboration Guideline and subpages / Phabricator tasks. And one request related to this specific topic: please don't single out WMF individuals when criticizing WMF decisions. It is not fair for the person fulfilling a role in a team, and it doesn't help understanding and resolving the issue at stake. For instance, Fram singles out "Jdforrester (WMF)" in the title of this topic and other places. That is not necessary, and it is not too late to amend it (please). In Wikipedia terms, all I am saying is no personal attacks, please.--Qgil-WMF (talk) 08:54, 13 May 2016 (UTC)
I refuse to edit at Mediawiki, where the admin atmosphere is toxic (if I acted like some of the admins there, Jdforrester would long have been blocked here). I tried to discuss and correct things there at the start of VE, but thanks to people like Jdforrester (who seemed to have forgotten what a wiki was) and Erik Möller (now luckily gone from the WMF) I have no interest in repeating that experience. And I stay away from Phabricator as well, where discussion is welcome as long as the WMF has the last word (take e.g. the issue at hand, suddenly closed at Phabricator by Jdforrester: reopening of such a ticket by non-WMF people or noon-developers is not allowed there. So why would I go there?). As long as WMF sees fit to use enwiki as the most common testing ground, they can come here to discuss community participation and the like. As for your specific request. I can find no evidence that the comment by Jdforrester was a "WMF decision", it was his comment, with his name attached to it (and his role also means that he is responsible for such decisions in any case). I'm not going to blame all of WMF for the decision and communication of one person. And contrary to what you claim, it did succeed in "understanding and resolving the issue at stake". So no, I'll not amend it. Jdforrester can start with retracting his lies and apologizing for them. WP:HONESTY and WP:COMPETENCE, if you want Wikipedia terms. If there are errors in my statements, you are more than welcome to point them out and I'll correct them. But then also do the same for people with (WMF) in their name. Otherwise it only looks like yet another WMF employee coming here to support one another instead of tackling the issue at hand and the nonsense told about it by colleagues. Fram (talk) 12:44, 13 May 2016 (UTC)

NOT RESOLVED. Jdforrester (WMF), to quote you on your talk page the fix is the first editor that loads will still be the wikitext editor. If that is not fixed then the community javascript should still be deployed to prevent VE from loading by default.

If there is a dialog then "Continue Editing" simply clears the the dialog revealing the first-loaded wikitext editor. The "Switch" option on that dialog will need to be rewritten to say it's switching to Visual Editor. Alsee (talk) 21:21, 12 May 2016 (UTC)

@Alsee: Yes. Jdforrester (WMF) (talk) 21:25, 12 May 2016 (UTC)
Jdforrester (WMF) thank you. Alsee (talk) 21:48, 12 May 2016 (UTC)

Translate tool

The translate tool seems to be having problems with English:

  1. The language doesn't appear in the "to" list
  2. If forced by manipulating the URL it says the translation to English is not supported.

What's going on?

All the best: Rich Farmbrough, 19:50, 12 May 2016 (UTC).

@Rich Farmbrough: It works fine for me. Here's an example link, and screenshots of the selection interface and translation interface (one and two, tested in both chromium and firefox). I suggest filing a phabricator task, if you can't get it working, with details on the specific links you are using, and your browser/OS. Quiddity (WMF) (talk) 21:01, 12 May 2016 (UTC)
I can get the screen you show by manipulating the URL. But even then the automatic translation is not available.
No English translation tool.png
All the best: Rich Farmbrough, 21:55, 12 May 2016 (UTC).
@Rich Farmbrough: Oh, the "machine translation" is the specific part that you were referring to! That is because the language pair fr->en is not currently supported by Apertium or Yandex, according to mw:Content translation/Machine Translation. If you can and want to help, details are at mw:Content translation/Machine Translation#How can I improve machine translation support for my language?. HTH. Quiddity (WMF) (talk) 22:47, 12 May 2016 (UTC)
But.. but.. I have used it in the past! All the best: Rich Farmbrough, 23:54, 12 May 2016 (UTC).
@Quiddity: That section does not exist. All the best: Rich Farmbrough, 21:35, 13 May 2016 (UTC).
@Rich Farmbrough: Whoops, I pasted the wrong pagename, after carefully getting the non_underscored_section name >.< mw:Content_translation/Documentation/FAQ#How can I improve machine translation support for my language? was the intended target. Quiddity (WMF) (talk) 00:05, 14 May 2016 (UTC)

OneClickArchiver misarchiving

Today's usage of OneClickArchiver on WP:Village pump (miscellaneous) has caused archiving to the wrong archive pages (in two cases inserting {{WP:Village pump/Archive header}} before a section appended to an old archive page). Seems like OneClickArchiver is somehow broken, which is why I bring the issue here. Unless the script can be quickly fixed, I guess it should be disabled in some way. @Sunekit. --Pipetricker (talk) 20:55, 13 May 2016 (UTC)

My apologies Pipetricker. I archived them because no one had responded within the discussions for quite some time, and/or a consensus was ultimately reached. Also a lot of the discussions didn't belong at Village Pump in the first place. However, I did notice that the discussions were archiving in different places, which did concern me. I'm honestly not very sure what to do about it... It may just be broken, but maybe it could just be something that I am doing wrong... Sunekit (talk) 21:03, 13 May 2016 (UTC)
@Sunekit: The same problem occurred with Wikipedia:Village pump (idea lab). All the village pumps are set up for automatic archiving; in general, you should not manually archive any page that is set up for automatic archiving. OneClickArchiver (which counts as manual archiving) has always had problems with automatically-archived pages - it moves threads to old archive pages, and doesn't respect bot settings, and can interfere with bots. Technical 13 was asked to fix this, which they refused to do - IIRC they claimed that the script was correct, it was the archiving bots that were wrong.
If a discussion is concluded to the satisfaction of all involved in that thread, just put {{resolved}} at the top and let the bot archive it. --Redrose64 (talk) 22:27, 13 May 2016 (UTC)
@Pipetricker: I undid all recent archiving on Wikipedia:Village pump (idea lab) and Wikipedia:Village pump (miscellaneous), including putting their archive pages Wikipedia:Village pump (idea lab)/Archive 12, Wikipedia:Village pump (miscellaneous)/Archive 44, Wikipedia:Village pump (miscellaneous)/Archive 45, Wikipedia:Village pump (miscellaneous)/Archive 46 and Wikipedia:Village pump (miscellaneous)/Archive 52 back to how they were prior to Sunekit's edits. I suggest we just let ClueBot III (talk · contribs) get on with it. --Redrose64 (talk) 22:52, 13 May 2016 (UTC)
Good job, thanks! (sidenote: Sunekit was indef-blocked shortly after posting here.)
Perhaps the Village pumps could be put in Category:Pages that should not be manually archived to avoid this happening again? --Pipetricker (talk) 23:09, 13 May 2016 (UTC)
  • The Miszabot archive settings template has a parameter called archive number (or similar). I think Oneclickarchiver uses that to determine where to put the archive. However, I don't think Cluebot uses this parameter, nor does it update it. If you want to use one click archiver, you should check the Miszabot template at the top of the page and make sure the archive number parameter is correct, and then it should put the discussion in the right place. Oiyarbepsy (talk) 07:54, 14 May 2016 (UTC)

Disambiguating link in image metadata

At File:Bunk'd cast and characters.jpg, the metadata links to the disambiguation page Phase One, it should link to Phase One (company). Not sure how to fix that. nyuszika7h (talk) 10:02, 14 May 2016 (UTC)

RequestedTheDJ (talkcontribs) 10:11, 14 May 2016 (UTC)
Fixed. Graham87 11:17, 14 May 2016 (UTC)

gif

hi, how do you slow down the rotation speed of a gif?--Ozzie10aaaa (talk) 23:36, 14 May 2016 (UTC)

You could use a browser plug in like Play-the-gif for Chrome. — xaosflux Talk 01:45, 15 May 2016 (UTC)

Mozilla doesn't allow me to use Wikipedia.

I am having problems entering Wikipedia with Mozilla Firefox which quite fast. It says "The OCSP response is not yet valid (contains a date in the future)." As a result, I had to use Google Chrome where it is quite slower.Tintor2 (talk) 01:29, 15 May 2016 (UTC)

Certain firefox addons may cause this problem if your computer clock is wrong. Check your computer clock, if in am/pm mode be sure to check that too. — xaosflux Talk 01:42, 15 May 2016 (UTC)
Thanks. I can't believe it was just the time.Tintor2 (talk) 01:48, 15 May 2016 (UTC)

"[edit] F" appended whenever I copy paste article titles (triple click)

Hi, I often want to link to an article or refer to a section with a long name using its #anchor id. (Hope that # does not get turned into a hashtag.)

So I go there, triple click the title, and copy-paste it. — Can't use the URL bar as it's tedious to get rid of underscores from links. (Policy says no underscores in links.) And sometimes even replace some URL encoded entities such as %20, %3A, %3D, etc. But I digress.

As I said, I like to use the handy triple click mouse shortcut to select the entire title, all words. But unfortunately — even though it is visually not shown as highlighted — the otherwise very handy [edit] link added after each title is included in this triple click selection. (I believe it should be a separate entity, not part of the title.) And for some very, very strange, possibly engine-specific reason, (webkit only, I think) the first letter of the tagline From Wikipedia, the free encyclopedia is also highlighted and copied. (Or, if I copy section titles, then it's the first letter of the first paragraph after the title that gets copied. Example: History[edit] M)

This problem was found using Google Chrome. Also reproducible in Opera. Partially reproducible in Microsoft's Edge and IE browsers. ([edit] is there but at least the next sentence's first letter isn't strangely copied.) Firefox is not affected.

Conclusion; What!? Why is this happening? Can we fix it for all browsers? (Especially the random letter F adder ones...) Would a CSS rule on the edit links, something akin to user-select: none; help? And what about putting the titles (or the [edit] links) in their own <div> to separate them properly from each other. Sincerely, •ː• 3ICE •ː• 02:13, 15 May 2016 (UTC)

This isn't a solution to the copy-paste problem, but I usually use {{url2wiki}} to make links like this. I just copy the URL bar, and paste it into the template like this: {{subst:u2w|https://en.wikipedia.org/wiki/Foo#Bar_baz|display text}}. That results in the wikitext [[Foo#Bar baz|display text]]. — Mr. Stradivarius ♪ talk ♪ 02:36, 15 May 2016 (UTC)
Thanks for the url2wiki recommendation, I added it to my toolbar. This workaround will make my life much easier. •ː• 3ICE •ː• 02:44, 15 May 2016 (UTC)
User:Js/urldecoder - NQ (talk) 03:08, 15 May 2016 (UTC)
(double-editconflict-resolved-resolved) Also I always laugh when lazy* people copy from Wikipedia and their subsequently pasted text is filled with numbers: [1] [2] ... [27]. Should we get rid of those? By preventing text selection of all reference links. Best joke from the past was the many [citation needed] tags that were also preserved in their plaintext pastes. *Lazy or technologically not so advanced (people who can't do regex /(\[\d{1,4}\])/g for example) •ː• 3ICE •ː• 02:33, 15 May 2016 (UTC)

Fixing some erroneous categories

Back in 2014, an editor went around adding some "Landforms of X County, Kentucky" categories to a lot of articles about lakes in Kentucky, but unfortunately, some of them accidentally ended up in nonexistent Kansas categories. See [35] for an example. Is there a way to find all of them? I'm imagining someone with a database dump (whether new or old, it doesn't matter, since they've been like this for two years now) producing a list of all articles with nonexistent categories ending in "Kansas"; it would presumably find all of these (with the potential exception of articles in categories for which the Kansas category already exists) as well as finding a bunch of other articles that need to have their categories tweaked or removed. Nyttend (talk) 17:09, 13 May 2016 (UTC)

I've written a query in Quarry for you, which should give you the data you need after it finishes executing. (That is, unless I made a mistake in the SQL or it takes more than 30 minutes to run, both of which are very possible.) — Mr. Stradivarius ♪ talk ♪ 08:47, 14 May 2016 (UTC)
Aaand, it's been killed for taking more than 30 minutes. Let me try running it on Labs directly. — Mr. Stradivarius ♪ talk ♪ 09:13, 14 May 2016 (UTC)
@Mr. Stradivarius: for future - maybe articlecat.cl_to LIKE '%Kansas' changing to articlecat.cl_to RLIKE 'Kansas$' would help not exceeding the limit. --Edgars2007 (talk/contribs) 10:41, 14 May 2016 (UTC)
Does search insource:/\[\[[Cc]{1}ategory\:Landforms of [A-Za-z ]+, Kansas\]\]/ help? Fred Gandt · talk · contribs 10:23, 14 May 2016 (UTC)
@Nyttend: My query on Tool Labs finished, and the list it generated is only 27 articles long, so I'll just put it here for you:
  1. AMC Theatres
  2. Baldwin City Blues
  3. Big Creek (Kansas)
  4. Brash Books
  5. Dean Sturgis
  6. Fort Leavenworth National Cemetery
  7. Iola's fort
  8. Johnston Library
  9. Junction City Brigade
  10. K-19 (Kansas highway)
  11. K-39 (Kansas highway)
  12. K-47 (Kansas highway)
  13. K-51 (Kansas highway)
  14. Kansas Day
  15. Kansas statistical areas
  16. Kiewit Power Constructors Co.
  17. Leavenworth Plaza
  18. Norman No. 1 Oil Well
  19. Odee Township, Meade County, Kansas
  20. Oklahoma Joe's
  21. Pawnee River
  22. S.T. Zimmerman House
  23. Topeka High School
  24. U.S. Route 69 Alternate
  25. Wichita Wild
  26. William E. "Pinky" Newell
  27. Woodsdale, Kansas
Enjoy. :) — Mr. Stradivarius ♪ talk ♪ 09:06, 15 May 2016 (UTC)
The insource searching found well over 100 articles, most or all of which were really in Kansas, so it wasn't hugely useful, but thanks for the idea. I've fixed all 27 of the articles from the tool search; they were all Kansas articles with nonexistent categories, so I fixed all those. Nothing more for Kentucky, so I know that those are all fixed. Thanks to both of you! Nyttend (talk) 12:09, 15 May 2016 (UTC)

License selection lists when uploading images

When uploading images (both via the wizard and the traditional way), there is a selection list of licenses. Where and how is this configured? Is it local, or a phab: matter? Please comment at Wikipedia talk:Contact us#Updating to CC-BY-SA 4.0?. --Redrose64 (talk) 08:14, 15 May 2016 (UTC)

Resolved. Nyttend (talk) 12:11, 15 May 2016 (UTC)

Missing menu tab

First of all, bear with me please - unfortunately I forgot how that specific tool is called, and checking my .js files didn't jog my memory either. Anyway I'll try to descibe it: until recently it added several additional menu functions to the main menu in a tab on its own (I believe). On an article page it added "Page" and then various useful scripts and functions listed (like "copyvio check", "check external links", and several more partly system functions, partly user scripts). On a user-related page it would show additional user-related functions (like listing the user's contributions or block log, and more). Of course all these functions are still available somewhere, but the great advantage of this approach was their convenient direct accessibility in 1 spot. 1) Does anyone know, which tool created these tool tabs? 2) Why are those tabs no longer visible? (my system is Firefox 46.0.1, Windows XP and Vector skin). Any help is appreciated as always :). GermanJoe (talk) 13:11, 15 May 2016 (UTC)

Sounds like the "MoreMenu" gadget. See the Gadget tab. -- [[User:Edokter]] {{talk}} 13:42, 15 May 2016 (UTC)
Thanks a lot. That checkbox was disabled for some reason (I don't remember touching it in the last months, maybe just misclicked) - all OK again. GermanJoe (talk) 13:53, 15 May 2016 (UTC)

Toolbar cite journal template not working

Lately, whenever I try to edit a page and add a journal citation by copying and pasting the doi/pmid into the cite journal template in the toolbar (which you access by clicking "cite" and then "templates"), the template is not filling in like it's supposed to when I click the magnifying glass next to the doi or pmid field (depending on which one I copied into the template). Other times, as now, when I edit a page and click on the "templates" window in the toolbar, nothing even happens, so I can't even try to fill out the template as described above at all. Usually, I have to then open another WP page and edit that in order to fill out a cite journal template in the toolbar. Does anyone know how I can fix this problem? Everymorning (talk) 02:53, 5 May 2016 (UTC)

Could you open your web browser's "developer tools" and reload the page on which you see the problem and perform the steps leading to the problem? If there is a problem or an error with JavaScript it should be printed in the 'console' of the developer tools. For more information please see:
--AKlapper (WMF) (talk) 09:38, 5 May 2016 (UTC)
Related discussion /Archive 145#Citation autofill on toolbar not working for journals. Fred Gandt (talk|contribs) 23:07, 5 May 2016 (UTC)
It looks like the error is "Use of "wgTitle" is deprecated. Use mw.config instead." However, I've gotten two other errors in the console tab besides "wgTitle": "wgArticlePath" and "wgUserName". Hope this helps identify the root of the problem and a solution to it. Everymorning (talk) 01:57, 6 May 2016 (UTC)
Although directly using those global values is deprecated Everymorning, they're still usable for now, and won't shouldn't cause any issues. They should however be updated, as eventually they may not exist. In your console, you will often see warnings which are usually informational and yellow. Red messages are usually more likely to be errors which will affect functionality. However, both these types of console output are set by the writer of the code, and can be used erroneously or even whimsically. You can experiment in your browser's JavaScript console if you like; where you see the warnings, place your caret underneath, and type wgTitle (or others) and press ↵ Enter. You'll see the value of the variable and should get another warning about using it. If you then type mw.config.get( "wgTitle" ); and press ↵ Enter, you'll get the same value but no warning. I realise this info doesn't help trace the problem with the ref toolbar, but I hope it helps you understand more about JavaScript code and your browser. Fred Gandt (talk|contribs) 06:10, 6 May 2016 (UTC)
@Everymorning: Can you revert this change and try again? Also, if you have the proveIt gadget enabled in your preferences, please remove ProveIt.js and associated code from your vector.js - NQ (talk) 02:30, 6 May 2016 (UTC)
@NQ: I undid the change you requested and removed ProveIt.js stuff from my vector.js, but I still can't fill out cite journal templates on the toolbar as described above. Do you have any idea why this might be happening? BTW, I am using Google Chrome Version 50.0.2661.94 (64-bit). Everymorning (talk) 00:10, 10 May 2016 (UTC)
@Everymorning: It might be due to a conflict with another script or gadget you have enabled. Could you create an alternate account and see if you have the same issue? The reftoolbar and all that should come pre-enabled so you don't have to do anything, just check if you're able to use the autofill feature. - NQ (talk) 00:58, 10 May 2016 (UTC)

I was able to fill out the cite journal template using a doi when I edited logged out of my account, though I still can't do it using this account. Everymorning (talk) 20:17, 10 May 2016 (UTC)

Update: this problem seems to be fixed (at least in article space; I still can't fill out journal templates on this page for some reason, but since I really only need to do this in article space, that doesn't really matter). Everymorning (talk) 20:21, 10 May 2016 (UTC)
Update 2: It's back again. Now when I start editing a page and try to fill out the cite journal template with either a PMID or DOI, it sometimes works, but sometimes doesn't. Everymorning (talk) 17:23, 15 May 2016 (UTC)

'Book-related' needs its hyphen

Hi folks. This'd be a simple change for somebody who can tweak templates.

Article Our Kind of Traitor has a hatnote. That uses template:cleanup book, which currently results in the text "... this book related article may require cleanup.".

Now, IMHO, there should be a hyphen, making it "... book-related article ...". Who's up for a quick tweak? I don't think I've ever changed a template before. Tell me how, if you prefer, if you think it's easy for me to have a go at?

Cheers, Trafford09 (talk) 16:55, 15 May 2016 (UTC)

@Trafford09: I'm not a native speaker so I don't know which version is the correct, but you can modify Template:Cleanup book. --Tacsipacsi (talk) 18:22, 15 May 2016 (UTC)
 Done — JJMC89(T·C) 19:36, 15 May 2016 (UTC)

CAT:AFD/U

I noticed that CAT:AFD/U is quite populated this morning. Do we have a script for adding cats to uncategorized AfD pages? Sam Sailor Talk! 07:19, 13 May 2016 (UTC)

Don't think so - but it's not difficult. Pick a letter, and slot it in. --Redrose64 (talk) 07:53, 13 May 2016 (UTC)
Face-smile.svg Quite what I'm doing now, Redrose64. Sam Sailor Talk! 08:07, 13 May 2016 (UTC)

RfC: Wikidata in infoboxes, opt-in or opt-out?

Wikidata has begun to be automatically imported into infobox fields. Should this be opt-in or opt-out? Please take part in the discussion at Wikipedia:Village pump (technical)#RfC: Wikidata in infoboxes, opt-in or opt-out?. Curly Turkey 🍁 ¡gobble! 01:18, 16 May 2016 (UTC)

Define "imported", "opt-in", and "opt-out", please. It's mildly ambiguous, and precision matters for this issue. I'm guessing that by "imported" you mean "transcluded-cross-wiki", by "opt-out" you mean that by default infoboxes should be updated to transclude Wikidata values, and that by "opt-in" you mean that a specific local consensus would be needed to update an infobox to transclude Wikidata. By those definitions I support "opt-out" updates. {{Nihiltres |talk |edits}} 02:58, 16 May 2016 (UTC)
Nihiltres: The discussion is at Wikipedia:Village pump (technical)#RfC: Wikidata in infoboxes, opt-in or opt-out? Curly Turkey 🍁 ¡gobble! 04:21, 16 May 2016 (UTC)
I think Curly Turkey means the discussion is at Wikipedia:Village pump (policy)#RfC: Wikidata in infoboxes, opt-in or opt-out? --Worldbruce (talk) 04:54, 16 May 2016 (UTC)
Yikes! What a screwup. Thanks, Worldbruce! Curly Turkey 🍁 ¡gobble! 05:12, 16 May 2016 (UTC)

Page view statistics

Hi, does anyone have any feel about what proportion of hits shown on the "Page view statistics" pages (tools.wmflabs.org) are likely to be from human users and how many from automated processes? 86.171.43.203 (talk) 02:12, 14 May 2016 (UTC)

The page has a dropdown (Agent) to filter just that. By default it only shows human user views. —TheDJ (talkcontribs) 10:05, 14 May 2016 (UTC)
Wow, thanks, I didn't notice that. Well, I may have noticed "Agent: User", but it did not mean anything to me. In an ideal world I think that could be labelled in a more friendly way. But anyway, it's good. 86.171.43.203 (talk) 20:07, 14 May 2016 (UTC)
By the way, any idea how it knows? 86.171.43.203 (talk) 21:06, 14 May 2016 (UTC)
This basic information is recorded from the client's user agent, which is why in the tool it's labeled "Agent". I am very curious and open to suggestions on what a more user-friendly label would be MusikAnimal talk 00:03, 16 May 2016 (UTC)
@MusikAnimal: Maybe make link to WP article? :) Optionally - to that language WP article, which user interface language is set. If the particular WP doesn't have article about agent, then link to enwp. --Edgars2007 (talk/contribs) 10:22, 16 May 2016 (UTC)

Problems uploading files from 'Edge' browser

Hi, I hope this is the right place to ask this. I am unable to load images from my PC to Wikipedia using the 'Edge' browser that comes with Windows 10. This used to work (it worked at least once), but now it doesn't work at all. When I get to the screen that says "your file is uploading; this may take a few minutes", or words to that effect, it just stays there forever but the file is never loaded. These are small files < 1 MB. I can upload them successfully through Chrome (they take a few seconds), but I do not want to use Chrome. Any ideas anyone? (Please note that I am not asking for advice to use a different browser, I am asking why this procedure does not work using 'Edge'.) Mypix (talk) 17:53, 16 May 2016 (UTC)

What is in your browser console? (Press F12 to get the developer tools) Ruslik_Zero 18:16, 16 May 2016 (UTC)
I assume you mean on the upload page, at the point when the upload is happening (or not happening)? Well, I had shut down that page so I just tried another upload, and, guess what, it worked fine. Wouldn't you know it. Next time it fails, if it fails, I will check the Console at that time. If you (or anyone) can delete the test file "Mypix test.jpg", please do so. Thanks. Mypix (talk) 19:25, 16 May 2016 (UTC)
File:Mypix test.jpg has been deleted. -- GB fan 19:28, 16 May 2016 (UTC)

Periodic table related templates /sr:Медијавики:Common.css/

I have written .sr article Periodic table. Now a lot of templates should be made and I stuck on some of them. Could someone help me a bit? /I don’t ask on .sr Village pump because nothing technical gets resolved there.../ --Obsuser (talk) 16:32, 13 May 2016 (UTC)

Borders

Why are additional borders shown here but not here? I am referring to the Example legend with three themes table i.e. extra grey borders around "Border shows natural occurrence of the element" ["Руб показује налажење елемента у природи"] and such cells. Extra borders can also be seen when comparing .sr and .en versions of one of the periodic table templates.--Obsuser (talk) 16:32, 13 May 2016 (UTC)

Because sr:Медијавики:Common.css contains very old definitions for wikitable, which should have been removed years ago, since better ones are provided by the Core software. That stylesheet file needs a SERIOUS cleanup, it is filled with years of additions, but few removals. (if it's not in en.wp's version of that file, double check if you really need it.) —TheDJ (talkcontribs) 23:01, 13 May 2016 (UTC)
Hmmm, I did actually proposed on .sr several times to update whole sr:Медијавики:Common.css but there is nobody that wants to do that. You can see hatnote update (very small update) but almost everything else is deprecated (even hatnotes are not working when right to the image). Nothing to do then to fix this... --Obsuser (talk) 23:24, 13 May 2016 (UTC)
@Obsuser: Meta has global users who can help out with stuff like that if the homewiki no longer has people able to assist with those kinds of things. Unfortunately, the only volunteers lefts in that group seem to be: User:He7d3r, User:Jack Phoenix, User:Tpt and User:Pathoschild. It could really use a few more volunteers honestly.. —TheDJ (talkcontribs) 10:18, 14 May 2016 (UTC)
FYI, that group is populated with people who hold the rights for a specific task or set of tasks. There is no "general use" interface editors at the global level. Ajraddatz (talk) 20:38, 15 May 2016 (UTC)

Still Not fixed. --Obsuser (talk) 12:53, 16 May 2016 (UTC)

Table inside footnotes

How to get table displayed here? I am referring to the 15th footnote and cannot find mistake. In the preview, error about {{refn}} template calling |style= and |class= parameter with more than one value is being shown (due to the table inside of refn template). I don’t know how to get table displayed there... --Obsuser (talk) 16:32, 13 May 2016 (UTC)

hmm, i made some attempts, but this is such a wikitext soup, i don't really feel like spending a few hours matching brace by brace. If i were you i'd just move the entire section into a scratchpad, then rewrite the wikicode from scratch (without copy pasting), to make sure that you align up all your braces and tags. —TheDJ (talkcontribs) 23:01, 13 May 2016 (UTC)
I used translator on Meta to check for extra left or right braces and numbers are equal. It cannot display any table by refn template or inside any other footnote. Thank you however. --Obsuser (talk) 23:24, 13 May 2016 (UTC)

Still Not fixed. I excluded table from refn template as it cannot show class="wikitable" tables but only those with HTML <tr></tr> etc. tags and those with wikimarkup {| etc. with no class="wikitable" class specified.

Biggest problem is refusal of admins on .sr to update sr:Медијавики:Common.css.

Could some admin from here or other user with bigger rights who knows how to deal with Common.css (@Edokter, TheDJ, Redrose64, PrimeHunter, and Jackmcbarn:) PLEASE update it and other related pages on .sr? Many things are deprecated there, including even dotted lines being shown below sections. --Obsuser (talk) 12:53, 16 May 2016 (UTC)

English administrators have no rights to edit protected pages on other wiki's. Not much we can do about that. As TheDJ mentioned, find an interface editor on meta. -- [[User:Edokter]] {{talk}} 13:15, 16 May 2016 (UTC)
Yep. I have zero edits at sr:, therefore no rights above the basic unconfirmed set. --Redrose64 (talk) 18:39, 16 May 2016 (UTC)
I asked User:Jack Phoenix and User:Pathoschild for assisstance. --Obsuser (talk) 00:27, 17 May 2016 (UTC)
Hello Obsuser. That's beyond my remit as interface editor, but there are several active admins on srwiki. Most of those who edited sr:MediaWiki:Common.css seem to be active; in particular I recognise Dungodung, a former steward. I suggest asking the local admins first. It may help if you ask for specific changes (like removing the wikitable/prettytable styles), instead of suggesting a major cleanup. —Pathoschild 01:19, 17 May 2016 (UTC)
Yes, I did ask once for hatnote templates but there is still a lot of deprecated text, and if one adds or changes only one small part (maybe affected by others too) – it is still not updated. I am not well experienced for proposing such updates but can make some templates that are sometimes not completely functional because of this. Thank you however, someone on .sr will update it in (probably far) future. --Obsuser (talk) 06:29, 17 May 2016 (UTC)

upload.wikimedia.org SSL problem?

(Cross posted on commons) - Is anyone else hitting this issue I'm seeing this morning: Using Firefox, not able to load images that are stored on commons - appears to be an SSL issue with upload.wikimedia.org (An error occurred during a connection to upload.wikimedia.org. security library: improperly formatted DER-encoded message. (Error code: sec_error_bad_der)). I've got a feeling it is a local browser problem though. — xaosflux Talk 15:18, 16 May 2016 (UTC)

Well whatever it was has gone away. — xaosflux Talk 12:56, 17 May 2016 (UTC)

Looking for Wikipedia Adventure thingy

I don't even know what to call it but have been searching for it all over WP, gave up and came here... I am looking for the NOTICE that I have seen placed on some new users' talk pages by HostBot, not the Wikilinkage to the full page but the clickable/"playable" little notice like this invite (dating from 2014). I've looked under templates, I've looked under WikiProjects, I've tried different spellings, etc., etc. I know I can cut/paste the entire code from that user page but surely there must be - somewhere within WP's pages - a neat little subst/template/whatever. Please, Village pump (technical) folks, you're my only hope... Thanks, Shearonink (talk) 18:19, 16 May 2016 (UTC)

@Shearonink: I think Wikipedia:TWA/Invite is what you're looking for? --Jakob (talk) aka Jakec 18:31, 16 May 2016 (UTC)
YES. Thank you. I know Wikipedia hoards all possible info & coding and so on but sometimes I just can't quite figure out where to look to find things in all these different cupboards. Thanks, Shearonink (talk) 19:14, 16 May 2016 (UTC)
Shearonink, for future help finding stuff, here's how I would/did find the page. First I selected some text from it: "learn how to edit Wikipedia in under an hour". I put that in search, with the quotes to only match the exact phrase. On the search result page I clicked ADVANCED options to customize the search. We're looking for the original template, so I changed to to search in Template namespace - which found nothing. Next I searched Wikipedia namespace, that found it. There are 22,741 hits in namespace User Talk (where people were being invited), and only three hits in any other namespace. Alsee (talk) 13:37, 17 May 2016 (UTC)
That makes sense to look for a phrase that seems unique to the template. I run into the issue of JUST WHERE THE HECK DID THEY PUT [this thing]?!? every so often around Wikipedia...the nomenclature can be challenging, even for experienced editors. Is [the thing] under Help? or maybe Template? What was [the thing I can't find] called when it was created? Not the page all about it, not the page about the project, but [the thing]... in my case it usually is the invite [to the thing], usually for new users. Heh, I have a little section in my user pages for [things I don't use that often but that I like to post on new users' pages occasionally and that I am tired of searching for]. Thanks for your hint, that is brilliant. Shearonink (talk) 13:59, 17 May 2016 (UTC)

Twinkle: Proposing to merge undefined with undefined

I'm not sure what caused this. What did you do to trigger that, Andrzejbanas? – nyuszika7h (talk) 14:43, 17 May 2016 (UTC)

Ahh. Okay, didn't realize it did that. Was trying to suggest merging some album article with three others, it was just a compilation of three albums together. But my browser seems to have frozen mid-way through. I didn't think it did anything, but I suppose it did that! What a bizarre error. Andrzejbanas (talk) 15:14, 17 May 2016 (UTC)

User top icon ordering

I have added the |sortkey= parameter to {{top icon}} and most user top icon templates. For a short time, it used to be |number=, but that was a poorly chosen name, as the sortkey accepts any string (it sorts alphabetically). So anyone can no can now control their user top icons on their page. If a template does not work as expected, add |sortkey = {{{sortkey|}}} to the template. Note that article space icons should alsways be auto-sorted. -- [[User:Edokter]] {{talk}} 14:48, 17 May 2016 (UTC)

Thanks @Edokter: - for anyone who wants to see an example see Special:PermaLink/720737609. — xaosflux Talk 17:32, 17 May 2016 (UTC)
That example actually uses the non-functioning |number=. See Special:PermaLink/720739638 instead. -- [[User:Edokter]] {{talk}} 17:44, 17 May 2016 (UTC)

Template:other people

A change to {{other people}} (by Nihiltres) has changed the functionality of this template. When used with zero or one parameter, the template is supposed to pipe the link through the (disambiguation) redirect to indicate that the link to the disambiguation page is intentional (per WP:INTDABLINK). Can someone either modify the module code or revert this change to restore this functionality. This template is used on a large number of pages (the template protection edit says >20000) and as such has caused a large number of false positives for disambiguators. -Niceguyedc Go Huskies! 22:27, 15 May 2016 (UTC)

I'm currently out and about, but I've temporarily reverted my update from my phone, and I'll get the problem fixed once I'm home. {{Nihiltres |talk |edits}} 23:50, 15 May 2016 (UTC)
@Nihiltres: Thanks for the quick response! -Niceguyedc Go Huskies! 00:04, 16 May 2016 (UTC)
@Niceguyedc: Fixed now, and the Lua version's reimplemented. {{Nihiltres |talk |edits}} 02:35, 16 May 2016 (UTC)
@Nihiltres: Looks good. Thanks again! -Niceguyedc Go Huskies! 03:17, 16 May 2016 (UTC)

@Nihiltres: A similar problem now exists in the {{other places}} template. With one parameter, the link is supposed to be [[{{{1}}} (disambiguation)]], not [[{{{1}}}]]. Every page using this template with one parameter now shows up containing an ambiguous link needing to be fixed. Please revert this change (it's template protected) until it is fixed. -Niceguyedc Go Huskies! 17:52, 17 May 2016 (UTC)

@Niceguyedc: Nope, in that respect the Lua module matches the behaviour of the last wikitext version (source), which only applied a disambiguation parenthetical as part of its default. The Lua module only varies from that wikitext version in that it supports an indefinite number of parameters, and uses code from Module:Other uses to inherently keep it in sync with similar templates. {{Other people}} was an exception because of its special first parameter. {{Nihiltres |talk |edits}} 18:16, 17 May 2016 (UTC)
@Nihiltres: That's not correct. The source is {{Hatnote|For other places with the same name, see [[{{{1|{{PAGENAME}}}}} (disambiguation)]].}} With zero parameters, that source links to {{PAGENAME}} (disambiguation). With one parameter, it links to {{{1}}} (disambiguation). I've made User:Niceguyedc/sandbox/other places a copy of the template (before the Lua change), and you can see the result of {{User:Niceguyedc/sandbox/other places|Borek}} here:
-Niceguyedc Go Huskies! 18:29, 17 May 2016 (UTC)
@Niceguyedc: Damn, I miscounted the braces, just now as well as earlier. This means that the behaviours of the various "other x" templates were out of sync before; I'd assumed they were fine and missed this difference. Mea culpa for the mistake, but I still think that the current behaviour is better: It better matches every other "other x" template (none of the others apply parentheticals except to defaults) and allows for the possibility of pointing to pages that don't end in "(disambiguation)".
This can be systematically fixed with AWB and some deviousness: replace the regex string \{\{\s*other places\s*\|\s*([^\|\{\}]*)\}\} with {{other places|{{subst:#ifeq:{{subst:#invoke:Redirect|main|$1 (disambiguation)}}|$1|$1 (disambiguation)|$1}}}} and the wikitext'll fix itself on save. {{Nihiltres |talk |edits}} 19:28, 17 May 2016 (UTC)
@Nihiltres: The template is to be used specifically to link to disambiguation pages (from the documentation, Also, do not use this template to link to an article that is not a disambiguation page; instead, one of the other hatnote templates listed below may be more appropriate for that purpose.) This template is used to link to disambiguation pages in this way about 10,000 times. My view is that restoring the template functionality would be better than making 10,000 edits. -Niceguyedc Go Huskies! 19:35, 17 May 2016 (UTC)
@Niceguyedc: The alternative is having the templates behave differently; this is repaying technical debt. If it's the cost of getting all the templates in line, I'd rather do that, since hatnote template consistency is important and I don't see a way around doing the many edits to reach that goal. With the regex replacement already written, it'd presumably be trivial for me to request the approval of a bot account/task to run the fix completely automatically. {{Nihiltres |talk |edits}} 19:56, 17 May 2016 (UTC)
@Nihiltres: Very well. Please make that request today. -Niceguyedc Go Huskies! 20:06, 17 May 2016 (UTC)
@Niceguyedc: Done. See Wikipedia:Bots/Requests for approval/NihiltresBot. {{Nihiltres |talk |edits}} 21:11, 17 May 2016 (UTC)

limits on Template:Preloaddraft

Hello all. Are there alternatives to the #ifexists function that do not hit the limitations on expensive functions? I recently put together {{Preloaddraft}}, which is used in redlink lists (e.g. WP:MISSING/Art of the Middle East). However because each copy of the template contains two #ifexistss, after 250 names or so, the template malfunctions.

Therefore if there is any advice on how to increase the limit on expensive parser functions, or code equivalent functionality more cheaply, it'd be very useful! Thanks in advance for any help, T.Shafee(Evo﹠Evo)talk 12:29, 17 May 2016 (UTC)

Not really. These kinds of systems usually end up on toollabs, since performance wise they cannot scale inside the wiki. —TheDJ (talkcontribs) 18:14, 17 May 2016 (UTC)
@TheDJ: Thanks anyway. I'll just make sure that it's clear in the documentation not to put too many in a single page. I've also asked at the MW:Project:Support_desk just in case there's a way to edit the maximum number of expensive functions allowed for a particular template. T.Shafee(Evo﹠Evo)talk 01:34, 18 May 2016 (UTC)

Why does a file have a very different name here than at Commons?

File:Mesopotamian cylinder seal impression.jpg is at https://en.wikipedia.org/wiki/File:Annunaki.jpg here but at https://commons.wikimedia.org/wiki/File:Mesopotamian_cylinder_seal_impression.jpg at Commons. What's particularly annoying is that it was evidently originally uploaded in 2005, then someone uploaded presumably a copy in 2007 in an attempt to link this to a fringe idea of Z. Sitchin's about the Annunaki. The claim that this image is related to them is repeated all over the net on fringe sites, but shouldn't be in the url or even the 2nd description. This is, as it says, a "1st Millennium seal showing a worshipper and a fish-garbed sage before a stylised tree with a crescent moon & winged disk set above it." Not Sitchin's fantasies. Doug Weller talk 15:10, 17 May 2016 (UTC)

File redirects - such as File:Annunaki.jpg - are not forbidden, although they do make tracking image use more difficult. --Redrose64 (talk) 15:15, 17 May 2016 (UTC)
Thanks. And it appears there's no "redirects for discussion" at Commons? I don't like the idea of misleading redirects. Doug Weller talk 17:44, 17 May 2016 (UTC)
It looks like you probably want Commons:Deletion requests. עוד מישהו Od Mishehu 18:27, 17 May 2016 (UTC)
But please be aware of c:COM:Dupe. --Redrose64 (talk) 19:25, 17 May 2016 (UTC)
Note that the redirect was made by a move: [36]. The old name is still used in some wikis where images would break if the Commons redirect is deleted. The current name is File:Mesopotamian cylinder seal impression.jpg both here and at Commons, and it can be referred to as File:Annunaki.jpg in both places due to the Commons redirect. The difference is that https://commons.wikimedia.org/wiki/File:Annunaki.jpg makes url redirection to https://commons.wikimedia.org/wiki/File:Mesopotamian_cylinder_seal_impression.jpg while https://en.wikipedia.org/wiki/File:Annunaki.jpg merely displays the content of the redirect target without changing the url. PrimeHunter (talk) 01:22, 18 May 2016 (UTC)
Sigh, that would have been me making the move request. I forgot - it's been over 5 years. I'll leave it alone. Doug Weller talk 15:16, 18 May 2016 (UTC)

Tech News: 2016-20

16:01, 16 May 2016 (UTC)

Template-fixing gnomes may want to track the last item on this list. If you click through to the phab ticket, you'll see a discussion about the number of templates that contain self-closing tags, and you'll be able to track progress on deployment of whatever error category or tracking mechanism is created. We might want to track this sort of syntax using CheckWiki. I don't know enough about how these back-end checks work to know what the next step is, but some editors here probably do. – Jonesey95 (talk) 21:11, 16 May 2016 (UTC)
I think I nabbed most of the easy self-closed html in the article space--that is, anything of the form <tagname/> (minus a handful of pages where multiple returns were). There may still be things of the sort <tagname attributename="attvalue"> or with uppercase rather than lowercase... I'll poke some more at the latter case, but I'm not smart enough to take care of the former. --Izno (talk) 23:00, 16 May 2016 (UTC)
Pardon my technical naivete, but is this going to mess with references like <ref name="theglobeandmail1"/>?? Ocaasi (WMF) (talk) 08:55, 17 May 2016 (UTC)
I don't think so. As far as I understand, this only concern real HTML such as <span />, <div />, <hr /> and <br />. -- [[User:Edokter]] {{talk}} 08:58, 17 May 2016 (UTC)
@Edokter: Actually, <hr /> and <br /> are called void tags in HTML 5--where an agent sees that there is a ?/> in a void element, it's to render the tag as if it were >. This does affect other real HTML non-void tags, such as <span />, <div /> and many, many others.

https://en.wikipedia.org/w/index.php?title=Special:Search&profile=default&fulltext=Search&search=insource%3A%2F\%3C%28div%7Cspan%7Cs%7Cb%7Ci%7Cbase%7Cstyle%7Ctitle%29%3F[+]%3F\%2F\%3E%2F&searchToken=e6p35uqxu0375b1kgzwtqyg8b and https://en.wikipedia.org/w/index.php?title=Special:Search&limit=500&offset=0&profile=default&search=insource%3A%2F\%3C%28li%7Col%7Cabbr%7Ccite%7Ccode%7Cdfn%7Cem%7Csmall%7Ctime%7Cu%7Cvar%7Cdel%7Ctd%29[+]%3F\%2F\%3E%2F&searchToken=6ynrxnmuvdgctxwral9awjd77 have some tags to clean. I'm almost through the list of html tags. --Izno (talk) 11:54, 17 May 2016 (UTC)

Last batch of the easy ones: https://en.wikipedia.org/w/index.php?title=Special:Search&profile=default&fulltext=Search&search=insource%3A%2F\%3C%28input%7Coption%7Ctextarea%7Cbig%29[+]%3F\%2F\%3E%2F&searchToken=bnt4tnlbzgjlgriz9bp9myw1k and big, which should be removed completely: https://en.wikipedia.org/w/index.php?title=Special:Search&profile=default&fulltext=Search&search=insource%3A%2F\%3Cbig[+]%3F\%2F\%3E%2F&searchToken=7rlbu3yj83zydv1u00suxbgtb . --Izno (talk) 12:04, 17 May 2016 (UTC)
<hr /> and <br /> are perfectly valid HTML5, these are void elements so the slash is permitted and optional, see HTML5 spec, section 8.1.2 Elements, or more specifically, 8.1.2.1 Start tags. <span>...</span> and <div>...</div> are not void elements; and <ref /> is a MediaWiki extension, it never gets as far as HTMLTidy, let alone your browser. @Izno: Square brackets break URLs. --Redrose64 (talk) 12:22, 17 May 2016 (UTC)
I know <hr /> and <br /> are valid; the sanitizer will convert them to <hr> and <br> regardless, and they will remain valid. -- [[User:Edokter]] {{talk}} 12:26, 17 May 2016 (UTC)
@Redrose64: A fact of which I am imminently aware, but care little to amend. Copy and paste works just as well for anyone visiting this section as myself. --Izno (talk) 12:41, 17 May 2016 (UTC)
@Izno and Redrose64: because I'm very lazy person, I created such simple script for that :) --Edgars2007 (talk/contribs) 15:28, 18 May 2016 (UTC)

Lot of stuff not working for me

Recently, within the past week, I noticed that a lot of gadgets and scripts haven't been working for me. User:Epicgenius/common.js has a whole load of scripts, but all of them worked fine for a long time, even though I had over 30 user scripts installed.

A short list of the scripts that aren't working, by no means comprehensive, is:

Can someone test out the scripts to see if they do what they're supposed to do?

Strangely, some other scripts work, such as Wikipedia:Popups, User:Ohconfucius/script/MOSNUM dates.js, User:Meteor sandwich yum/Tidy citations.js, and User:Evad37/duplinks-alt.js, to name a few.

It's not a problem with my computer or with my browser. Browser version is Mozilla Firefox version 46.0.1, operating system is Mac OS X El Capitan version 10.11.2. I tried using Safari and my iPad, but neither of these modifications caused these scripts to work.

Is there anything I should do before restarting my computer? (It probably won't work.) epicgenius (talk) 22:20, 17 May 2016 (UTC)

You need these changes. The one element had a typo, the other is broken, because it references a dependency that no longer exists.. —TheDJ (talkcontribs) 22:40, 17 May 2016 (UTC)
@Epicgenius: I'm guessing may 12th :) —TheDJ (talkcontribs) 22:50, 17 May 2016 (UTC)
@Epicgenius and TheDJ: The js pages use importScript, which will be removed entirely as part of wikibits by the release of MediaWiki 1.28 in November 2016. All instances of importScript should be converted to mw.loader.load. GeoffreyT2000 (talk) 00:16, 18 May 2016 (UTC)
@TheDJ and GeoffreyT2000: Thank you both for helping me fix this problem. I didn't realize I used an outdated dependency that broke everything. Should I start converting to mw.loader.load right now? Thanks again. epicgenius (talk) 00:40, 18 May 2016 (UTC) (And I realize the scripts work now. I just tested autocomplete and advisor, and it works. epicgenius (talk) 00:41, 18 May 2016 (UTC))
One solution which works, and take very little effort, is to place a definition for importScript - see the very beginning of User:Od Mishehu/common.js, everything up to the first blank line. עוד מישהו Od Mishehu 02:54, 18 May 2016 (UTC)
calling mw.loader.load() is BS. it does not make one iota of sense - the loader does not support simple loading of scripts contained in wiki pages, and require gymnastics that looks, roughly, like /w/index.php?action=raw&title=<url encoded page name>&ctype=<some mime type>. i expect that between now and november someone in WMF will finally get their head out of their rear end and will add a sane substitute, say, "mw.importScript()" and "mw.importStyleSheet()" that will do what wikibits' importScript() and importStylesheet() are doing today. if they won't, i expect some sane person here will simply add those functions to the local common.js, so you won't even have to prepend mw. .... peace - קיפודנחש (aka kipod) (talk) 05:23, 18 May 2016 (UTC)
mw.loader.load does basically the same thing as importScript (except working with raw JavaScript files instead of enwiki JavaScript pages), and it's more versatile because you can import script from other wikis. However, mw.loader.load it's a little longer and more unwieldy than I'm used to. And I code JavaScript in my free time, so yeah, it's unnecessary deprecation. epicgenius (talk) 19:51, 18 May 2016 (UTC)
Don't worry about importScript, we will solve that at the en.wp level when we need to, —TheDJ (talkcontribs) 06:54, 18 May 2016 (UTC)

Hotcat not working for me

Have just noticed that the Hotcat tools have disappeared from the bottom of articles. Am using Edge on Win10. DuncanHill (talk) 12:52, 19 May 2016 (UTC)

Hum, having looked at a few more articles, the it seems to work on others just not on Liskeard and Looe Railway. The "edit" link for the top section is also missing on it, but present on others. DuncanHill (talk) 12:55, 19 May 2016 (UTC)
Both HotCat and edittop gadgets  Works for me at Liskeard and Looe Railway, using Firefox 46.0.1 under Windows XP. --Redrose64 (talk) 13:58, 19 May 2016 (UTC)

Nowrap template and full stop glitch

I find, since yesterday, that Template:Nowrap misbehaves when the "no-wrapped" words are at the end of a sentence. For example, to prevent end-of-sentence words like "...engine no. 3." from wrapping to
...engine no.
3.
I used {{nowrap|no. 3}}.
But the result was
...engine no. 3
.
with the poor full stop all by its lonesome in the next line.

I've not seen this happen before yesterday, so it looks like a new glitch. FWIW, I'm using Chrome on a Dell PC. -- André Kritzinger (talk) 18:35, 19 May 2016 (UTC)

Live example
Code
...engine {{nowrap|no. 3}}.
Result
...engine no. 3.
I personally (Chrome v. 50.0.2661.102 m on Win 7 Home Premium SP1) am not seeing the described problem; we may need more details. Fred Gandt · talk · contribs 18:50, 19 May 2016 (UTC)
Yes, it works correctly when there's room in the line. Try by adding preceding letters to force it to wrap to the next line. (Or make your screen display narrower or wider.) Then remove one letter at a time of the added letters. -- André Kritzinger (talk) 19:39, 19 May 2016 (UTC)
All that {{nowrap|no. 3}} does is emit <span class="nowrap">no. 3</span>. The {{nowrap}} template hasn't changed in six months. There is a matching CSS rule that we provide, it is
.nowrap,
.nowraplinks a,
.nowraplinks .selflink,
sup.reference a {
  white-space: nowrap;
}
which uses the white-space: property. There's not a lot we can do to control how your user agent (i.e. your browser) handles that property if it varies from the documentation. --Redrose64 (talk) 19:44, 19 May 2016 (UTC)
I suspect the problem isn't with Template:Nowrap (unless it somehow adds a space after itself), but rather with the way the full stop behaves following the template. For example "...{{nowrap|no. 3}}, or" does it as well, wrapping ", or..." to the next line. Full stops and commas are not supposed to wrap by themselves. -- André Kritzinger (talk) 20:01, 19 May 2016 (UTC)
Thanks for clarifying how the issue manifests. I have reproduced the effect; the period sitting immediately after the <span> will wrap to the next line alone. By removing the nowrapped <span>, and not changing the line of text in any other way, the 3 and the period wrap to the next line together. The issue it seems, is that the period is effectively orphaned by its previous sibling being an element rather than a text node. Fred Gandt · talk · contribs 20:50, 19 May 2016 (UTC)
No, it's not that. I replaced "no. 3." with "no. A." and the fullstop (period) still wraps all alone. -- André Kritzinger (talk) 21:06, 19 May 2016 (UTC)
I would expect that; the character "3" and the character "A" (or any other (more or less)) are in this regard treated equally (lets not get into character encoding, family widths and all that).
What I described above is the HTML markup behind the curtain. Let's say we have a sentence "She sells sea shells on the seashore." displayed on its own line. It will typically be wrapped in <p>...</p> tags to form a paragraph element. All the text within the <p>s are a text node within the element. If we then divide the text into parts that have different properties defined by wrapping those parts with <span>s, we get an element containing a series of element delimited text nodes e.g. <p>She sells <span>sea shells</span> on the seashore.</p> where on the seashore.'s previous sibling is an element - not a text node.
I'm pretty sure that's the root of the cause, since as I said, removing the span rendered as you said, correctly, with the period wrapping to the next line with its previous sibling word. Fred Gandt · talk · contribs 21:26, 19 May 2016 (UTC)
OK, thanks, got that, I think. It doesn't solve the problem, though. The "3." by itself wrapped just fine, and without the fullstop there was sufficient room for "3" by itself to not have to wrap to the next line. It was when I used the nowrap template to make "no. 3." stay together that the fullstop decided to move along on its own. I've reported it, so I'll now leave it to the tech guys to sort out and get on with editing... ^_^ -- André Kritzinger (talk) 22:13, 19 May 2016 (UTC)

  1. No it doesn't, but as Redrose said, we can't fix browsers from here, and the issue is not specific to MediaWiki or Wikipedia.
  2. A solution is to wrap more text; I'd recommend {{nowrap|engine {{abbr|No.|Number}} 3.}}
  3. Note the use of {{abbr}} for semantic/accessibility markup of abbreviations? I was just looking at you contribs to see if I could find the specific sentence you're talking about, and see you deal with a lot of engines! {{abbr}} should be liberally sprinkled. Fred Gandt · talk · contribs 22:29, 19 May 2016 (UTC)
I have mentioned this before; this is a bug in Chrome where it allows a break in certain conditions just before or after a nested element inside a text node. As Fred and Redrose say, nothing we can do about it. -- [[User:Edokter]] {{talk}} 22:42, 19 May 2016 (UTC)
@Fred Gandt, Yes, especially the infoboxes have "abbr=off" all over the place. And no, the specific sentence is not "there" yet, I'm still editing the article and have not saved it yet - at this pace I'll only get to saving it tomorrow afternoon since I prefer a lot of previews and one big change when editing, rather than a zillion 3-byte saved edits.
Workarounds won't solve this issue, since it will still be there. For example, I have one of those wide flatscreen PCs, hand-me-down from my daughter, which makes editing easy by opening two windows next to each other for editing, e.g. Wikipedia on the left half of the screen, and Word on the right. So, window widths can be changed, but all that does is make a problem like this disappear in one spot of the visible text and pop up elsewhere. Therefore, problem not solved, just not visible at that particular narrower/wider window width. -- André Kritzinger (talk) 23:06, 19 May 2016 (UTC)
(edit conflict) The use of {{abbr}} is recommended at MOS:NUMERO but people who mainly edit railway pages (mea culpa) often use plain "No." as it comes up so often in articles like NBR 224 and 420 Classes. --Redrose64 (talk) 23:09, 19 May 2016 (UTC)
The workaround I've suggested does solve the problem - for all users, no matter their screen size, shape, resolution and browser. The issue is as Edokter says (and he is usually right about these things) a bug in Chrome, that we can't do anything about, so workarounds is all we have, but they mustn't affect other users. So working within the rules and within good reason, we just glue together more parts than usual to stop the parts going their separate ways. Try it; nowrap the end of the sentence including the period. You'll see (you should anyway), that the issue goes away. Fred Gandt · talk · contribs 23:15, 19 May 2016 (UTC)
Yes, during this discourse I found that out too. It works. Should one not mention this in the template usage, then? Rule: When the template is used at the end of a sentence, or preceding a comma, colon, semicolon - any punctuation, actually - the punctuation has to be included inside the template brackets. -- André Kritzinger (talk) 23:26, 19 May 2016 (UTC)

DISPLAYTITLE behavior change

Note
this refers to Category:Pages with disallowed DISPLAYTITLE modifications RF 2019-06-29

A user alerted me on my talk that they were seeing a big red warning on their user page that was transcluding {{User info}}. It turns out to be a behavior change with DISPLAYTITLE (a warning that the text does not match the page name), and I removed the DISPLAYTITLE call. The English-language warning is happening cross-wikis (I tested this at the Spanish Wikipedia, for instance).

This is more or less just an FYI, although I'm curious of there is some gerrit code change that went into effect for this to happen. — Andy W. (talk ·ctb) 20:39, 19 May 2016 (UTC)

DISPLAYTITLE has always required that what is displayed be the same (sans some HTML) as the page title. --Izno (talk) 20:43, 19 May 2016 (UTC)
No, I wasn't referring to that. This warning is definitely new. Before May 13, DISPLAYTITLE did not return a warning if the displayed string is not the same as the page name. Some time between May 13 and now, the warning was implemented (for better). — Andy W. (talk ·ctb) 20:47, 19 May 2016 (UTC)
FYI, nothing funny here with Durban Harbour's Congella. Yet. Maybe South Africa will be hit by this in a few years... -- André Kritzinger (talk) 20:54, 19 May 2016 (UTC)
@Andre Kritzinger: There wouldn't be, because Durban Harbour's ''Congella'' matches the page title. If you put {{DISPLAYTITLE:A}}, you'll see the error (which is new). — Andy W. (talk ·ctb) 21:04, 19 May 2016 (UTC)
This is new indeed, it is the result of phab:T28546 it seems. —TheDJ (talkcontribs) 21:06, 19 May 2016 (UTC)
Cool, thanks! — Andy W. (talk ·ctb) 21:08, 19 May 2016 (UTC)
(edit conflict) Yes, this is new after phab:T28546 and gerrit:158098. It displays MediaWiki:Restricted-displaytitle. Most languages have no translation yet so the English version is displayed. On this page, {{DISPLAYTITLE:Example}} produces:
Warning: Display title "Example" was ignored since it is not equivalent to the page's actual title.
It becomes bigger if the page has surrounding wikitext to make big text like font-size: 270% in your Special:Diff/720136111/721105644. PrimeHunter (talk) 21:10, 19 May 2016 (UTC)
Are any articles currently showing this ugly banner? — xaosflux Talk 21:16, 19 May 2016 (UTC)
If so, please provide samples below - putting this in front of readers would be a disservice. — xaosflux Talk 01:02, 20 May 2016 (UTC)
@Xaosflux: PrimeHunter has made the tracking category and updated the MediaWiki page. The category is here. :) — Andy W. (talk ·ctb) 01:10, 20 May 2016 (UTC)
Different issue, but Category:Pages with DISPLAYTITLE conflicts contains articles that have a DISPLAYTITLE conflicting with a transcluded DISPLAYTITLE from an infobox, I think. — Andy W. (talk ·ctb) 21:24, 19 May 2016 (UTC)
(edit conflict) I currently get 20 mainspace hits on a search for "was ignored since it is not equivalent to the page's actual title". We should add a tracking category to MediaWiki:Restricted-displaytitle like Category:Pages with DISPLAYTITLE conflicts in MediaWiki:Duplicate-displaytitle. PrimeHunter (talk) 21:26, 19 May 2016 (UTC)

PC1 seems to be broken

Does anyone have any idea why my edit to Freetown Christiania had to be accepted by a reviewer? The article is configured to PC1 so autoconfirmed people should be automatically accepted provided there are no other pending changes to be reviewed. There weren't any other changes. I am certainly autoconfirmed. But my edit was not auto-accepted. Has anyone else experienced anything like this before? --Majora (talk) 02:26, 20 May 2016 (UTC)

My regular edit to that page with my testing account didn't require any acceptance - will check a revert. — xaosflux Talk 02:31, 20 May 2016 (UTC)
I was able to duplicate your symptom - not sure if this is "new" behavior - the version you reverted to was prior to the PC being enable and itself was not reviewed, there are beany ways around that situation but this may be "by design" because of the "if no previous pending changes remain to be accepted" part of PC1. — xaosflux Talk 02:35, 20 May 2016 (UTC)
Ah ok. Just seemed like an odd bug but that makes sense and if it is by design so be it. I really don't need to know more details if it is a BEANS matter. Expect perhaps to confirm if this is in fact by design. --Majora (talk) 02:49, 20 May 2016 (UTC)

Wikipedia:Archive.is RFC 4

There is a new RfC about archive.is blacklisting: Wikipedia:Archive.is RFC 4.--Staberinde (talk) 16:15, 20 May 2016 (UTC)

WhatLinksHere broken

The layout of Special:WhatLinksHere appears to be broken. What's up? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:11, 19 May 2016 (UTC)

The new design appears to be intentional. MediaWiki 1.28.0-wmf.2 was just installed here. mw:MediaWiki 1.28/wmf.2#Core changes includes:
PrimeHunter (talk) 21:18, 19 May 2016 (UTC)
Thanks; it's a very BIG UI isn't it? Fred Gandt · talk · contribs 22:07, 19 May 2016 (UTC)
The developers also broke Special:MovePage like this some time ago. Is there some way to get the old version back? A lot of unnecessary scrolling is required, and it also takes more time to load the page, and if I change anything in any of the lists or text boxes before the page has finished loading, then those changes are discarded once the page has finished loading. --Stefan2 (talk) 22:35, 19 May 2016 (UTC)
One hour on from TheDJ's post, and the dialog box at Special:WhatLinksHere still takes up more than half the screen, with big gaps between selection items. This is MonoBook, and it's trying to be like Vector - why? --Redrose64 (talk) 22:46, 19 May 2016 (UTC)
My mistake in UTC timezone translation. it should have been 1,5 hours when I posted that. 10 mins left, and then the deploy slot will start. —TheDJ (talkcontribs) 22:50, 19 May 2016 (UTC)

The old layout is back. The filters had unlinked "Hide transclusions | Hide links | Hide redirects" for a few minutes but also work now. The default MediaWiki:Whatlinkshere-hidetrans and friends apparently reverted a little later than the layout. PrimeHunter (talk) 00:11, 20 May 2016 (UTC)

@Stefan2: "if I change anything in any of the lists or text boxes before the page has finished loading, then those changes are discarded once the page has finished loading" – are you sure this is still occurring? I fixed that bug months ago. I just tried and this doesn't happen for me. (Loading time should not be noticeably affected and no scrolling should be required unless you have a tiny screen.) Matma Rex talk 15:23, 20 May 2016 (UTC)
The filter links are still missing on Swedish and Finnish language versions. Can we do anything to fix that or should we just wait a little longer? --Pipetricker (talk) 09:47, 20 May 2016 (UTC)
You can just wait. If you want a quick local fix then a local admin can create MediaWiki:Whatlinkshere-hidetrans, MediaWiki:Whatlinkshere-hidelinks, MediaWiki:Whatlinkshere-hideredirs. If they contain $1 it should already work. If not then the local word for "hide" should be replaced by $1 (no promise this works in all languages). When the planned global fix goes through (or if my suggested fix doesn't work), the three messages can be deleted. PrimeHunter (talk) 10:01, 20 May 2016 (UTC)
It's also still broken for users here with a foreign langauge selected at Special:Preferences, for example Swedish. I don't recommend creating these messages in other languages here at the English Wikipedia. The foreign language users must live briefly without it. User:PrimeHunter/English interface.js gives a one-click option to see the working English interface on a given page. PrimeHunter (talk) 10:12, 20 May 2016 (UTC)
It now works in all tested languages. PrimeHunter (talk) 18:38, 20 May 2016 (UTC)

Regex question

Using WP:AWB. Find: #REDIRECT \[\[User:(.*)\1 Replace with: #REDIRECT [[User:$1\n{{R to user namespace}}
Why did AWB append the backreferece $1 to the end (DIFF), rather than insert it where it was supposed to? wbm1058 (talk) 18:45, 20 May 2016 (UTC)

@Wbm1058: Try #REDIRECT \[\[User:$1\n\{\{R to user namespace}} ? I think the unescaped characters might be causing problems. EvergreenFir (talk) Please {{re}} 18:57, 20 May 2016 (UTC)
Actually... scratch that... let me tinker. EvergreenFir (talk) Please {{re}} 18:57, 20 May 2016 (UTC)
Get rid of the \1 in your find and it will work (tested on regex101 dot com). EvergreenFir (talk) Please {{re}} 19:01, 20 May 2016 (UTC)
Got it, thanks! Now I see, I don't need to name or number the capture group, and even if I did, the syntax for that is different. wbm1058 (talk) 19:09, 20 May 2016 (UTC)
(edit conflict) Yep! Adding that \1 makes the regex look for the first defined capture group (.*) again. So it was looking for a repeat. Something like #REDIRECT [[User:FOOBARFOOBAR would hit since it would pick up FOOBAR twice (once for the initial capture and once for the \1). EvergreenFir (talk) Please {{re}} 19:14, 20 May 2016 (UTC)
\1 doesn't do what you think it does. (.*)\1 basically matches the same string twice in a row, e.g. "aa", "abab", etc. In the diff, $1 is "" (the empty string), since no longer repeated string is found; the remainder of the line (Dl2000/Band names - plural or singular?]]) isn't matched at all and is left alone. To be sure the entire line is matched, try #REDIRECT \[\[User:(.*)$ ($ matches the end of a line). SiBr4 (talk) 19:12, 20 May 2016 (UTC)

Cross-wiki notifications - how to clear?

Following the introduction of cross-wiki notifications, I now have a few messages from other projects. Clicking on "view messages" shows the list, but doesn't display the message text or any links - clicking on the hamburger icon and selecting "Mark as read" doesn't seem to do anything (the message count doesn't change and the message list is still populated). Do I have to visit each project individually to clear the messages, or is this a bug? I'm using Monobook on IE11, and en-wiki messages seem to be working correctly. Tevildo (talk) 07:38, 13 May 2016 (UTC)

There's a link in the notifications list, towards the bottom of the section. Can't remember what it's called, they disappear once you've used that link. --Redrose64 (talk) 07:51, 13 May 2016 (UTC)
I had to visit 8 separate wikis to clear the messages...Jokulhlaup (talk) 11:30, 13 May 2016 (UTC)
I used the "X" delete button on the supernotification that says "You have 5 notifications on other wikis", and that mostly worked. Except that it seems like it only actually loaded 2 of the 5 non-local notifications the first time and so only cleared those 2, leaving the other 3. Then I reloaded and it loaded 2 of the remaining 3, then I reloaded again and the "X" finally got rid of the last one. Anomie 12:44, 13 May 2016 (UTC)
Thank you for you feedback!
@Tevildo, where do you have a hamburger icon? You are supposed to havesomething like that. Can you provide me a screenshot next time you will have some cross-wiki notifications?
@Redrose64, cross-wiki notifications disappear when you mark them as read on your wiki. Is it what you observed?
@Jokulhlaup and Anomie, you experienced a problem which was supposed to be fixed. It is already reported.
Thanks all, Trizek (WMF) (talk) 12:48, 13 May 2016 (UTC)
Sorry, yes, I meant the three dots which brings up the pop-up menu. Selecting "Mark as read" (the only menu option) closes the popup, but the indicator value doesn't change. It seems to be working in Firefox, so I've used that browser to clear out my list. Tevildo (talk) 14:54, 13 May 2016 (UTC)
@Tevildo: I've filed phab:T135250 for the empty per-wiki sections within the cross-wiki bundle. Quiddity (WMF) (talk) 17:53, 13 May 2016 (UTC)

@Trizek (WMF): - I clicked 'mark as read' and the big X to clear - no luck. In the end had to go to Wikidata and clear from there, then refresh the browser at en.wikipedia, only way it worked. Will this be fixed? GiantSnowman 14:55, 13 May 2016 (UTC)

Yes, Giant. I'll ask it to be our #1 priority as soon as the developer in charge wakes-up (you know, timezones! :)) Trizek (WMF) (talk) 14:58, 13 May 2016 (UTC)
@Trizek (WMF): - completely understood, thanks Face-smile.svg GiantSnowman 15:03, 13 May 2016 (UTC)
Thanks for reporting this! There was a bug where the global notification counts (the numbers that tell you how many notifications you have) weren't updating correctly. That bug should now be fixed. As for dismissing cross-wiki notifications, that's working for me. If it's not working for you, please let us know, and also tell us if you're using a browser plugin like Privacy Badger or AdBlock. Those plugins have been known to interfere with cross-wiki requests (we worked around them for showing notifications cross-wiki, but not for dismissing them). --Roan Kattouw (WMF) (talk) 22:09, 13 May 2016 (UTC)
  • I have an alert saying I have 99+ cross-wiki messages that suddenly appeared a few days ago that I cannot get rid of. They are of no interest to me as I do 95%+ of my work on en.wp. Even though the bug may be fixed, the message alerts refuse to go away and I have 99+ perpetually on my messages icon. Do I have to click on each one individually, as was suggested by a user above? I bloody well hope not Face-wink.svg -- Ohc ¡digame! 17:13, 16 May 2016 (UTC)
    • Ohconfucius, if many of the notifications were from the same wiki, then try going to zh:Special:Notifications or wherever you were notified (or go to your talk page on that project if you have talk page messages). The notifications from that wiki should then be marked as read, and the total notification count will drop. If you don't want cross-wiki notifications at all, then you could try disabling them at Special:Preferences#mw-prefsection-echo, but maybe you will get a useful notification at some point in the future which you want to see. I find this feature very useful as I can see both Commons and Wikipedia notifications on both projects, but I had to visit Special:Notifications on a lot of different projects in order to mark everything as read. --Stefan2 (talk) 21:18, 18 May 2016 (UTC)
      • Stefan2, The very strange thing is that I have apparently over 99+ interwiki messages, many of them from MediaWiki, where I don't seem to even have an account, and the messages there don't have anything to do with me. :-( - Ohc ¡digame! 21:35, 18 May 2016 (UTC)
        • Ohconfucius You should have a standard global account. It might take a few seconds (and require a page-reload) to auto-login, or if you have strict cookie-permission settings or other privacy extensions, you might need to login manually using the same account details). Re: too many notifications, it's probably because you're watchlisting a busy page there, e.g. I see you have a 4 year old edit at mw:Project:Support desk - I suggest unwatching that. To fix the existing profusion, the easiest way is to open the flyout/popup, and click "Mark all as read" at the top-right corner (screenshot). Note: This will only mark 25 at-a-time (the limit that are visible in the flyout), so you'll need to click a few times. Let me know if that doesn't work, or you encounter any other (specific) problems. Quiddity (WMF) (talk) 18:41, 20 May 2016 (UTC)
I don't know where this stands, but I've had a phantom message (bell 0 boxes 1) for the past few days... if I go to a project like Wiktionary, it says I have no notifications when I click on the boxes, and here, there's nothing obvious coming up. I mean, it's good to have notifications cross-wiki, but I sure wish I knew *where* .. I've run through the likely suspects. At least it ought to link to the list of what wikis you're on so you have something to go through, because right now I have to think how to look up even how to get that list. Wnt (talk) 12:01, 19 May 2016 (UTC)
@Wnt: Please could you try marking a single "message" notification as unread, using the "..." menu (screenshot), at another wiki, and then clear all cross-wiki notifications (using the "X" at the top of the bundle)?
Actually, I'll send you 2 test messages elsewhere, to make it easier. Let me know if it doesn't work, in which case I'll ask the devs to look deeper. Quiddity (WMF) (talk) 19:00, 20 May 2016 (UTC)
@Quiddity: Initially I had no luck - didn't see the three dots or the X you were talking about, had no way but trial and error to find your messages. I tried enabling javascript, which I'd done before, with no luck (in fact, all the edits I've made in Module: space recently were with javascript enabled, but possibly not mediawiki or something). However, once I went back and forth, enabled Wiktionary javascript, then went to meta, then came back here, *after that* when I was preparing to post here that nothing worked, then I got the "welcome to wikipedia" message everyone was talking about, and saw the other format of notifications like in your screen shot. Apparently the notification was on mediawiki.org, which I'd forgot to check. After that I have them cleared out. As I believe I was ranting on below lately, I tend to have a low opinion of javascript for various purposes... among other things, it seems like if the WMF server makes up its mind to show you something, you shouldn't need to run a script to see it. Wnt (talk) 19:25, 20 May 2016 (UTC)
@Wnt: Nod. Thanks for the details. There are some planned improvements for the Special:Notifications page, including making it possible to see cross-wiki notifications there. I've filed a task (phab:T135877) specifically about the no-JavaScript version, just as a reminder. Cheers, Quiddity (WMF) (talk) 21:03, 20 May 2016 (UTC)

Underscores in URL

Never mind, I went insane for a moment - I see exactly what I was doing now — xaosflux Talk 00:03, 27 May 2016 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

When following pages, have I gone nuts or are spaces " " no longer present in URL's, hard placing underscores "_" instead? I've noticed because I keep making ugly links when copying next from the address bar. Do we have any hacks to turn this back to spaces? — xaosflux Talk 23:53, 26 May 2016 (UTC)

Spaces are not allowed in URLs. The MediaWiki software has used underscores to represent spaces for as long as I've been here (7+ years). --Redrose64 (talk) 23:58, 26 May 2016 (UTC)
Thank you, please disregard my insanity here - unfortunately you replied before I could remove this! — xaosflux Talk 00:03, 27 May 2016 (UTC)

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

UserStatus template

Just curious as to why the {{UserStatus}} template has stopped working? When I type in a code at User:Paine Ellsworth/Status}} for another status besides the default, it is still the default status that is seen on my user page. Have there been any recent software changes that would cause this?  Stick to sources! Paine  12:22, 20 May 2016 (UTC)

I've made an edit at User:Paine Ellsworth/Status which I think has helped. -- John of Reading (talk) 15:34, 20 May 2016 (UTC)
Thank you, John of Reading! – yes, that did the job. I was concerned that it might be widespread, since it has worked so well for a long time and only recently stopped working, but that concern is improbable under the circumstances. Thank you again for your help!  Stick to sources! Paine  08:18, 21 May 2016 (UTC)

Strange things

OK, I'll try to explain what happened. For some time, "[[Category:Grand Lodges|England]]" appeared on the top of the article United Grand Lodge of England whether or not the category was present or removed. After checking the edit history, I found that it all started after this (seemingly unrelated) edit (if you check the previous versions of the article, it is not there). After seeing this, I decided to (manually, of course) undo what was done in this edit and this thing disappeared. My question is, what was the relation of this edit to the appearance of this thing? 94.65.133.34 (talk) 16:19, 17 May 2016 (UTC)

I just figured that it happened because he had linked to England at the "jurisdiction" area. I will re-add the others, but this means that Infobox Grand Lodge might be a little broken if it leads to the appearance of such things. 94.65.133.34 (talk) 16:26, 17 May 2016 (UTC)
{{Infobox Grand Lodge}} doesn't expect |jurisdiction= to be linked, since it uses that value as the sortkey for a category. Effectively, by using |jurisdiction=[[England]] what you have is [[Category:Grand Lodges|[[England]]]], and you can't put links inside links. --Redrose64 (talk) 17:25, 17 May 2016 (UTC)

I copied this discussion to Template talk:Infobox Grand Lodge#Jurisdiction can't be linked. --Pipetricker (talk) 11:32, 21 May 2016 (UTC)

Interactive chess game viewer at VPR

Hi VPT,

There's an ongoing discussion about the development/implementation of an interactive chess board over in this thread at VPR. Basically, there's one being tested and another intended to be lighter-weight that just began development. I think the discussion(s) would benefit from some having some additional technically competent eyes, though it's kind of unwieldy to move to this venue (and it's a concept that has been brought up and momentum lost multiple times before, so I'm hoping to keep the inertia going by using the same thread). Thanks. — Rhododendrites talk \\ 12:56, 21 May 2016 (UTC)

Newly created articles needs to be double patrolled

I came across an ANI post, where one user is accused of patrolling pages without checking them properly. There are are many users with auto-confirmed rights who can patrol pages. Unpatrolled pages appear Yellow. Patrolled pages appear white in new pages list.

I suggest unpatrolled pages should appear Orange. If it's patrolled by one user it will appear Yellow, and then if second user patrols it, then only it will appear white. --182.66.9.122 (talk) 16:59, 21 May 2016 (UTC)

ReFill not working

The past couple of days, every time I've tried to use reFill it hasn't worked. I can bring up the main ReFill page, and enter the title of the page I want to fix, but when I click on the "Fix page" tag it merely goes to a completely white screen and then nothing happens. The tool was fine last week because I used it then. White Arabian Filly Neigh 20:23, 18 May 2016 (UTC)

Same issue here. Very frustrating when trying to clean up drafts. Happy Squirrel (talk) 21:35, 20 May 2016 (UTC)
You might consider using the visual editor while this is down (click the [[ ]] button in the wikitext editor's toolbar to get there). It's running the mw:citoid service, which has a 'convert' option for refs that contain bare URLs. Whatamidoing (WMF) (talk) 22:47, 20 May 2016 (UTC)
nitpick: the [[ ]] button is for switching from VE to wikitext editor. in the other direction it's the small pencil in the right-hand side of the toolbar. peace - קיפודנחש (aka kipod) (talk) 00:52, 21 May 2016 (UTC)
This can be Exhibit A for my ongoing quest to get the same icon in both places. ;-) Whatamidoing (WMF) (talk) 21:54, 21 May 2016 (UTC)
It worked for me again this afternoon. Yeah! Happy Squirrel (talk) 19:20, 21 May 2016 (UTC)
I'm glad it's working again. Whatamidoing (WMF) (talk) 21:54, 21 May 2016 (UTC)

MediaWiki::API and SSL

Resolved

Apparently my various "Null bot" operations (see User:Joe's Null Bot, will break on June 12th if I don't update the somewhat ancient code to https. Thanks, WMF. :)

I've been using MediaWiki:API, and when I update the URL from http to https I get "500 Can't verify SSL peers without knowing which Certificate Authorities to trust". I've checked what would appear to be the appropriate documentation at [43], and while I get what the error message is saying in the abstract, am fairly lost about what it actually wants me to do, given the lack of CA-related apis in the documentation. Any assistance appreciated, and apologies that I'm fairly out of date on all this. --joe deckertalk 21:51, 20 May 2016 (UTC)

The first thing to do when you receive an error message is to search for it. How about this? Max Semenik (talk) 22:01, 20 May 2016 (UTC)
$ENV{PERL_LWP_SSL_VERIFY_HOSTNAME} = 0;
as a workaround? --37.188.143.116 (talk) 22:17, 20 May 2016 (UTC)
That latter works great Mx. 37.x.x.x, thank you! --joe deckertalk 22:23, 20 May 2016 (UTC)
And people wonder why so many creditcard numbers get stolen all the time.. —TheDJ (talkcontribs) 00:29, 21 May 2016 (UTC)
LOL, but yes as this is the TECHNICAL pump - that setting will leave you open to a man in the middle attack for stealing your credential. — xaosflux Talk 00:44, 21 May 2016 (UTC)
Depending on other settings you may not be "wide open" just "more open". — xaosflux Talk 00:47, 21 May 2016 (UTC)
The setting is 'perl'; it is a question of how wide. John Vandenberg (chat) 01:46, 21 May 2016 (UTC)

joe decker, if you are not wedded to your Perl, pywikibot has mw:Manual:Pywikibot/touch.py which means each of those tasks is a one liner shell command, which can be scheduled using cron. If there are any features missing, I will add them. John Vandenberg (chat) 01:46, 21 May 2016 (UTC)

When I have a bit more time I'll probably look into it--it'll be a bit more than a one-liner (I doubt your one-liner includes the rate-limiting requested by BAG), but I'm sure it'd be a heckuva lot simpler, and that will certainly be what I do if there's ever need for more than a trivial upgrade.
Thanks. --joe deckertalk 04:42, 21 May 2016 (UTC)
Pywikibot has a put throttle as a command line argument. John Vandenberg (chat) 00:26, 22 May 2016 (UTC)

Watchlist getting stuck

For quite a while now, ever since the last big update, when I try to bring up my Watchlist it takes ages - much MUCH longer than bringing up Contributions or getting to the Main Page. But this afternoon I have been unable to even get to my Watchlist. Sorry if I missed the memo (lol) but does anyone know what is going on? Thanks, Shearonink (talk) 21:11, 28 April 2016 (UTC)

  • I'm having this problem too, Safari 6.1.6 (yes, I know, haven't updated). I managed to log on using Chrome, deleted my watchlist, then tried logging in with Safari and had no problem. I started reloading the watchlist a bit at a time, and after adding all the As, which was okay, then the Bs and then I got a message telling me there are too many pages to load (the entire watchlist - all of it – is barely over 2000, so As and Bs is a small number). Have we stopped supporting old versions of Safari? Victoria (tk) 01:21, 29 April 2016 (UTC)
  • Adding: I tried to go to my contribs to comment out the scripts I have on my .js and other pages and hung when I clicked "contribs" so I think it's more than the watchlist. Victoria (tk) 01:28, 29 April 2016 (UTC)
Nice to know I'm not the only one. Haven't tried Chrome, am running on Safari atm, but haven't been able to access my Watchlist at all today. Is anyone else having this issue? Shearonink (talk) 03:09, 29 April 2016 (UTC)
Yes, I can't see my contributions page either. Richard75 (talk) 08:59, 29 April 2016 (UTC)
"Have we stopped supporting old versions of Safari?". Officially not yet, but that is probably because no one thought about taking that action yet. It is really hard to support older versions of Safari, because it is a tiny group of the userbase, and because it is very difficult for developers to run older versions of Mac OS Safari (basically you need a 2nd mac that you don't upgrade). I would say that Safari 8 and up is what is effectively supported. —TheDJ (talkcontribs) 09:08, 29 April 2016 (UTC)
Thanks for the answer. But upgrading sounds like a hassle, especially since I don't have any trouble on any other website; I think I'll just stop editing. Richard75 (talk) 09:12, 29 April 2016 (UTC)
You can consider using a different browser. Also, reports like this, will probably cause older Safari versions to be degraded from our list of 'Modern' to 'Basic' support, where all Javascript enhancements (the most likely cause of any problems) are no longer enabled for you. —TheDJ (talkcontribs) 09:17, 29 April 2016 (UTC)
Ok, thanks. The problem might not be with the browser, though, and I'm not sure how to respond to the "the reports like this … " part of this. I managed to load 500 pages back to the my watchlist and it worked, then it hung again when I loaded the next 100. So basically, just reporting that when I try to log in, when I try to view my watchlist, (and last night trying to view diffs, page history, and contribs) it hung. So there's an issue somewhere. Victoria (tk) 12:16, 29 April 2016 (UTC) Struck old - these conditions no longer apply. Victoria (tk) 21:37, 29 April 2016 (UTC)
  • Since yesterday I've gone from being unable to view the watchlist, contribs, page histories, spent many hours trying to troubleshoot, and now get a complete freeze trying to log in. I think that it would nice if the three people posting to this thread who are experiencing similar difficulties could have a little more troubleshooting help other than being told that the browser isn't supported, please update. I get update messages from other websites and usually I have months to do the updating. Here it has to be done after the fact. And in the meantime you're locked out. Victoria (tk) 21:37, 29 April 2016 (UTC)
    • Here's what I found out: My guess is you are using Lion or Mountain Lion as your operating system, and this means you are unable to upgrade to a more recent version of Safari. Safari 6.1.6 came out in August 13, 2014. It's not realistic for us to have to maintain compatibility with outdated browsers indefinitely. It looks like you have two options at this point: Switch to Chrome, or upgrade your browser to El Capitan so that you can upgrade to the most recent version of Safari. I use Chrome almost exclusively, as I find it is the best browser for the type of work I do here on Wikipedia (operating system is Mavericks). I suggest you give it a try, as this is a simple fix. — Diannaa (talk) 14:09, 30 April 2016 (UTC)
      • Hi Diannaa, thanks for replying. You're right, I need to update to El Capitan, but don't have the time to do it immediately (and it wasn't on my list of things to do during the winter), and I think that's my frustration that this came out of nowhere. The issues are to do with loading any page and it doesn't matter if I'm logged out or not, i.e. if I'm reading an article while logged out and click a wikilink it freezes (and it's a really terrible freeze). Surely I'm not the only person who is lazy about updating. I understand that we can't support all browsers or older browsers; I do get that. But it seems a disservice, is the point I'm trying to make, and I don't have trouble reading or accessing any other websites. When that begins to happen, I know that it's time to update, but I'm surprised that it's Wikipedia that's forcing it, is all. In the meantime, I dumped my entire watchlist, which allowed me to log in and I was able got here using the search function. Victoria (tk) 16:38, 30 April 2016 (UTC)
        • The problem is very simple. We need to find someone with enough technical skill who can 'figure' out why this is occurring. Now those people generally tend not to run Safari 6 on Lion, can't easily downgrade to that, and can't easily install it from scratch. Simple problem, hard solution. It's not a disservice, it's a practicality. In the mean time, I've filed a bugreport (which anyone could have done), but Victoria, could you please check if you have the same problems on other language versions of Wikipedia or sister sites ? Just to make sure that it is not a problem specific to this site ? —TheDJ (talkcontribs) 17:37, 30 April 2016 (UTC)
          • Hi TheDJ, that's a good point. While logged out I went the main page and clicked today's featured article, clicked through the first link, tried to click that page's history and froze. Also, while logged out, I went from the TFA to the German version, was able to click through a few links, and was able to open the page history without freezing. I can log into Commons and load my watchlist there. I was also able to click history on a file without freezing. So it seems to be an issue with en.wp. Basically if I click anything that's blue here, whether or not I'm logged in, it freezes and I have a very hard time getting out of the freeze. My concern is not so much whether I can edit, because I haven't been much recently, but whether it's feasible to add some sort of notification to anyone using Lion/Safari 6.xx that Wikipedia doesn't support the browser, instead of causing an ugly freeze. P.s trying to preview causes in edit conflict, so apologies for mistakes. Also, thanks for filing the bug report. Victoria (tk) 18:20, 30 April 2016 (UTC)
          • Hm, that is strange. Do you have any Gadgets enabled in your preferences per chance ? —TheDJ (talkcontribs) 19:53, 30 April 2016 (UTC)
            • TheDJ, yes, I have gadgets and I can turn them all off and then work through to test each one, but until I'm able to put back my watchlist I won't be working under normal conditions. Before posting here, while still logged out, I tried to get click the history tab of the TFA on the main page and froze again, so it seems the issue is more to do with the OS/browser rather than whether logged in user or not. My sense is that during the server updates something got changed with the way pages are called and it's now not compatible with Lion/Safari 6.xx Victoria (tk) 21:15, 30 April 2016 (UTC)
              • Victoriaearle Right, after the earlier reply, I realized i myself had an old mac in storage somewhere, so I spent some 4,5 hours to revive it and I can confirm that I see the same problem. It has nothing to do with Javascript, since it still crashes if I disable Javascript. It very much looks like the Safari rendering engine just dies on something that we feed it (probably a CSS statement of some sort). I see the same problem on the german Wikipedia, but not on the Dutch wikipedia, which is .... most peculiar to say the least. The cause is most definitely a bug in Safari, but which one it is and what the exact trigger is will take a bit more time to figure out. —TheDJ (talkcontribs) 23:04, 30 April 2016 (UTC)
                • TheDJ, yeah I've hacked at it a bit too since Friday and it does show very odd and inconsistent results, but I've been doing a lot of cache-clearing and restarting, which might have something to do with it. The thing is, my machine isn't ancient - 2012 model Macbook pro – and I chose to skip the Mavericks update because it had problems when released. If we're finding these issues on the other wikipedias then I have to wonder how many people in the world run four-year-old machines who haven't updated in two years and are experiencing these freezes/crashes and if that's what we want? I don't have any issue with other major websites at all yet – only here. If I want to edit here I'll use Chrome as Diannaa suggests above until I get around to doing the necessary backing up (I have tons of files ). Thanks for spending time with this. Victoria (tk) 01:15, 1 May 2016 (UTC)
Root cause found. I knew this started to sound somewhat familiar. Together with valhallasw, I reported this issue to both Safari and Chrome before (but neither ticket was ever closed it seems). It's apparently fixed in newer versions of Safari and Chrome, but not in old versions of course. We saw something similar happened in august 2015. —TheDJ (talkcontribs) 09:24, 1 May 2016 (UTC)
I have the same problem. I'm using Safari 6. Everything is working good in my Wikipedia account (Talk, Sandbox, Preferences, Beta, Read Edit, View History) except when I go to my "Contributions" and Watchlist", my wiki page hangs/freezes and unable to proceed.--Richie Campbell (talk) 02:48, 2 May 2016 (UTC)
I was having this problem yesterday on iOS7. Updating the iPad to 9.31 cleared it up, though this option won't be available to everyone.LeadSongDog come howl! 13:28, 2 May 2016 (UTC)
  • Update: TheDJ - I'm now on Mavericks and using Safari 7.0.6. Bad news is that it still freezes - i.e. if I try to load the history of a page it freezes (with the swirling colored circle). Good news is that it's a softer freeze - I can back out of it, I can close Safari, all things I couldn't do with Safari 6. To digress slightly, the update to Mavericks was done after a lot of backing up, researching El Capitan and a trip to the Apple store where I was advised that these machines designed for Lion don't do great when updating all the way to Yosemite or El Capitan, so we compromised. Mavericks will allow me to go all the way to Safari 9 (a big jump), which I'll do in a few days, but I'd like to hack around with this first and see what else I find. I've not yet tried to replace my watchlist. Victoria (tk) 15:33, 2 May 2016 (UTC)
    • We have decided to rollout a patch that will bypass the problem, since so many people are affected (also quite a few iOS devices) and because it's a page freeze that is not related to Javascript but to CSS. This change will mean that Safari users will not get the improvement for text with bidirectional content that the developer originally intended to make, instead only chrome and firefox users will get the improvement. —TheDJ (talkcontribs) 17:39, 2 May 2016 (UTC)
      • TheDJ thanks for putting in the patch. I'm not sure what's happened, but I had all of two pages on my watchlist, was able to log in this morning, and now can't get past the log in screen without the hard freeze again. I deleted the two pages from my watchlist (using Chrome) and was able to get back in, but I don't think it's quite there yet for Safari users. Victoria (tk) 20:26, 2 May 2016 (UTC)
  • PS - Even though I have switched to Chrome for this issue, I have noticed over the past several days that my Watchlist seems to be slowing down on Chrome. Not hanging up or getting stuck but slower... Shearonink (talk) 00:36, 6 May 2016 (UTC)
  • JFTR I haven’t experienced any of the described problems with Safari v5 on OS X v10.6 “Snow Leopard”. There are quite a few sites that don’t work properly any more (I use Firefox for those) but so far this isn’t one of them. (Although I had to switch my math preference to use PNG, because formulæ were getting rendered much too small to read.)—Odysseus1479 21:53, 8 May 2016 (UTC)
  • It's still happening for me. I'm using Mac OS X 10.9.4, Safari 7.0.5. More info: it appears to be related to the amount of data to display. It hangs on my "Contributions", or the "History" of most pages. But it doesn't hang for my Watchlist (which is very short), or (it seems) when the article History is very short. Adpete (talk) 03:52, 9 May 2016 (UTC)
I assume the fix got extended to Safari 7, because it's fixed today for me. Adpete (talk) 06:46, 10 May 2016 (UTC)
Yes, MediaWiki 1.27wmf23, containing the fix was redeployed today, after another regression occuring when it was first (very shortly) deployed last thursday was explained. —TheDJ (talkcontribs) 17:54, 10 May 2016 (UTC)
  • THANK YOU to everyone who spotted replies/issues and everyone who came up with the fixes. My Safari now plays nicely with my Watchlist. Shearonink (talk) 19:24, 13 May 2016 (UTC)
    • The Firefox and Opera browsers are viable alternatives. --VanBuren (talk) 06:08, 17 May 2016 (UTC)

It works fine for me on Safari now; thank you to all concerned. Richard75 (talk) 17:09, 22 May 2016 (UTC)

Watchlist & contribs corruption

I imagine this is relevant to a discussion above: Watchlist getting stuck. I've got Mac OS X Lion 10.7.5 [with Safari 6.1.6 (7537.78.2)] and keep getting a "some webpages are not responding" message whenever (and only when) I try to check my WP watchlist and contributions. Any other activity on Wikipedia, e.g. accessing mainspace or pages such as this, or online generally is fine. The same error message was identified on apple.com back in January 2014; for me it's only been an issue in the last two days. Has something changed on Wikipedia in that time? I also use an ancient iPad, btw, but I can access Watchlist, etc. no problem on that. Frustrating – but my question is, why is this suddenly an issue? Cheers, JG66 (talk) 14:13, 30 April 2016 (UTC)

Because the code of website has a couple hundred changes per week, and because old browser are not as capable as new browsers. Oh and because browsers have hundreds and hundreds of bugs in them. And apparently those conditions came together to create a problem :) —TheDJ (talkcontribs) 18:01, 30 April 2016 (UTC)
Btw, I have Mac OS X Lion 10.x.x & have been running a higher version of Safari than yours. At this point I've given up using Safari to access my Watchlist - Chrome works but it's annoying to have to switch between the two. Would be nice to know why the Watchlist has been misbehaving - but apparently only for Safari users. Shearonink (talk) 03:28, 1 May 2016 (UTC)

Page jumping

Whatever WMF is doing with banners or other bullshit STOP IT. I am so fucking sick of the page jumping after I click edit and try to start doing something, leading me to click on the wrong thing. Just fucking stop adding whatever crap is making pages jump when we try to edit. Yes I am frustrated. Jytdog (talk) 03:18, 19 May 2016 (UTC)

Can you give a bit more details? I'm seeing some unwanted page movement on edit, namely the "Template, Named references, Error check" bar unfolds in to the edit window and pushes it all down a couple of lines. — xaosflux Talk 03:22, 19 May 2016 (UTC)
The adverts that appear on pages, in particular watchlists but more and more on other pages, move the page after it has finished rendering. This leads to me misclicking on things as they jump a few lines just as I click. It’s especially annoying as it’s not caching anything: use 'back' to go back to the page and it runs the same slow code to redraw the adverts and again jumps the page after it’s loaded. I don’t notice it so much on my PC but it is tediously annoying on an Android tablet I sometimes use for browsing.--JohnBlackburnewordsdeeds 03:34, 19 May 2016 (UTC)
That's part of it. I'm also getting edit windows reset to the top after the page completes loading, after I've found my text that I want to correct while the page is loading, which is very often much farther down. Dhtwiki (talk) 03:40, 19 May 2016 (UTC)
  • Enable "Suppress display of fundraiser banners" and "Suppress display of CentralNotices" and disable "Geonotice: display notices on your watchlist about events in your region" in Special:Preferences#mw-prefsection-gadgets - NQ (talk) 03:43, 19 May 2016 (UTC)
  • I experience this constantly, not just one jump but two. A page seems to stop loading. I now know not to click "edit" because if I do, it will jump and open "view history" instead. Nearly a year ago, a second jump appeared, so I have to wait until that has completed too. It has happened with different computers and browsers. SarahSV (talk) 06:10, 19 May 2016 (UTC)
This is because of javascripts changing the page after it has been delivered to you. navboxes, twinkle being inserterd,, notifications etc. —TheDJ (talkcontribs) 06:39, 19 May 2016 (UTC)
TheDJ, for me it started when Wikipedia:Notifications/Thanks was introduced. SarahSV (talk) 16:49, 20 May 2016 (UTC)
This is also a sign of bad web page design (related issue: there is no way to suggest improvements that will actually reach the ears of those on the WMF staff who actually do the page design work). A proper design puts greyed-out tabs in the page that loads first, then has the Javascript replace the greyed-out tab with a working tab. Result: no jump, no misclick. --Guy Macon (talk) 10:08, 19 May 2016 (UTC)
You can contact the designers directly at mw:Design, on Phabricator, by e-mail, and even on Twitter. Whatamidoing (WMF) (talk) 16:38, 20 May 2016 (UTC)
Not really. It's a sign of old Javascripts that are hard to fix. Besides we cannot know upfront if someone has hidden a notice. If you use a vanilla MediaWiki you have none of these problems, it's all the ancient stuff we have on en.wikipedia that is the problem mostly. —TheDJ (talkcontribs) 10:18, 19 May 2016 (UTC)
It is actually very easy to not display the banner when editing, just need to add this to Common.css:
.action-edit #siteNotice, .action-submit #siteNotice { display:none; }
This should be the default behaviour everywhere. Darkdadaah (talk) 13:01, 19 May 2016 (UTC)
n.b. that's Special:MyPage/common.css, with a small c - subpages are case-sensitive on all letters. --Redrose64 (talk) 14:02, 19 May 2016 (UTC)
Well, yes, but I was thinking about Mediawiki:Common.css since it impacts everyone, including anonymous and new users. Darkdadaah (talk) 14:31, 19 May 2016 (UTC)
Changing Common.css can be a problematic action - last time, as I recall, the admin involved was forcibly desysoped by WMF which then created some kind of "superprotect" power to stop it, all over a less significant format issue. But, who knows? The communication system would seem to be a bit like the red phone in Cabin in the Woods, working one way and rather late in the game. Nonetheless, for purposes of historical accuracy only, I should note that MediaWiki:Sitenotice is a mechanism by which, AFAIK, any fundraising banners could be placed on this site as part of the wiki itself, without any jumping around, and fixed present and past versions on the record. It would make instant sense to make the reform suggested above and switch any fundraising banners to be part of the wiki. However, it would frustrate mad scientists who want to do "A/B testing" giving different users different versions of the message at the same time to see how it affects them. I view that as a feature, not a bug, but WMF mad scientists likely disagree. I wonder if they did A/B testing of the page jumping around. Wnt (talk) 16:13, 19 May 2016 (UTC)
  • "AFAIK, any fundraising banners could be placed on this site as part of the wiki itself" Yes, and then they would be cached for a month, without the option to change them
  • "last time, as I recall, the admin involved was forcibly desysoped by WMF", that was Common.js and yes, only people who really understand what they are doing should mess with those pages. And the average admin is distinctly unqualified. Atm, I only trust Edokter with that actually.
  • "MediaWiki:Sitenotice is a mechanism by ...without any jumping around". Also incorrect.. site notice has the same problems. —TheDJ (talkcontribs) 16:32, 19 May 2016 (UTC)
I'm not opposed to this as an intermediate solution. It would mean hiding all notices from those types of pages, but that isn't a bad, since it is still a minority amount of pages. —TheDJ (talkcontribs) 16:40, 19 May 2016 (UTC)
@TheDJ: I don't understand why the ads would have to be "cached for a month" when the Main Page changes every six hours. Also, I had been under the impression the sitenotice is transcluded onto the page, i.e. part of the wiki source (example - note use of Wiki double bracket links), which ought to make it immune to the Javascript-related display problems. Once a non-Javascript page is finished loading, it's finished loading. Wnt (talk) 18:17, 19 May 2016 (UTC)
offtopic
The following discussion has been closed. Please do not modify it.
I haven't noticed this because I almost always keep Javascript off. The sole [no wait, it's also good for wikitable sortable] exception, which is a justifiable one I think, is to edit Lua scripts. The editor there is actually fast and has a lot of powerful features like debugging the whole script pretty much as you type, which should emphasize how pathetic it is that an image loading script fails to do so rapidly. Still... my overall feeling is more and more that Javascript has little legitimate purpose on the web, that it makes no sense to use it even for advertising - in the sense of pushing products rather than in the sense of violating user privacy, that is - and that sites that require it are fundamentally illegitimate sites that deliberately intend to "accidentally" push spyware onto their readers at some point within the next few years. I think Wikipedia would do well to break with the mafia-industrial complex on this point and start killing javascripts whenever doing so does not immediately and irretrievably break something. I can't say I especially relish the notion of seeing ad banners pop up on my Javascript-free view of the site when they finally just make them part of the normal served pages, but I'll grudgingly admit that would be fairer, and certainly it should be faster and more stable. Wnt (talk) 15:57, 19 May 2016 (UTC)
Wnt, if you use words like "mafia-industrial complex" no one is taking you seriously anymore, and you have just wasted your 218 words and 1282 characters and 2 minutes of every readers attention span instead of dealing with the problem. Our problem is collapsible content, especially the fact that the state of said collapsibility is conditional. It's part of why the collapsible sidebar got removed btw. But collapsible content is highly integrated with the expectations of the community, so this is a hard problem to solve one-sided. —TheDJ (talkcontribs) 16:32, 19 May 2016 (UTC)
@TheDJ: I may have displayed a certain irateness, but I don't feel like computer professionals really understand how disreputable their science has come to appear. People like us have been saying for years that stuff like having webcams built into laptops and now even "smart" (i.e. really stupid) TVs without a physical cover or even so much as a physical on-off switch is really dumb. Yet it goes on and then people report on it as if it were a law of nature. Well it's not: there's something rotten in the computer industry, and it can't be trusted, and there is no distinction for us, say, between the online publisher that uses Outbrain, or Outbrain, or the hacker who distributes malware code via that route. We're tired of drive-by downloads and billion-dollar computer bank heists and privacy policies that are fluffy ways of saying "we'll do whatever we damn well please". And so when Wikipedia has Javascript becoming prominent and making a nuisance out of itself, what do we expect computer professionals to do? Make it worse, naturally. But Wikipedia is supposed to be a nonprofit with a better mission than that (even if it does feature Square Enix ads on its front page every six months or less) with a chance for its people to fight back and be something different. Wnt (talk) 18:12, 19 May 2016 (UTC)
Wnt, if you have something to say specifically about this issue, say it. Otherwise do not derail this thread with offtopic ranting. Yes, I am telling you to shut the fuck up. This page jumping thing is a concrete problem that needs to be fixed. Jytdog (talk) 05:18, 20 May 2016 (UTC)
  • I have nothing fancy loaded in my settings, just the default stuff. No javascript crap or gadgets, not even twinkle. Telling me to turn default shit off so that I can edit in a sane way is fucking bullshit. Things weren't always this way. WMF has fucked something up. Jytdog (talk) 17:07, 19 May 2016 (UTC)
    • Yes something changed. JS now load asynchronous and 'late'. This is intentional. It makes everything else significantly faster. It's just highly problematic for stuff that has JS state. We will need to reassess how we show things like central notices I think. —TheDJ (talkcontribs) 18:55, 19 May 2016 (UTC)
      • Also, I like to reiterate, that in the case of notices, as soon as you dismiss a notice it should not show up and also NOT cause a flash. As long as you keep using the same browser at least. It is only the new/changed notices that cause this effect.. —TheDJ (talkcontribs) 19:49, 19 May 2016 (UTC)

BTW. For Centralnotice, the overal tracking task for this is phab:T109634. For dismissable sitenotices, the task is phab:T125323 and for collapsed content it is phab:T42792 (though on en.wp we still use the even older collapsible div's and tables code that is kept in MediaWiki:Common.js). And for Twinkle, it is this Github issuesTheDJ (talkcontribs) 19:22, 19 May 2016 (UTC)

We really should get rid of that dinosaur code and move to mw-collapsible. -- [[User:Edokter]] {{talk}} 22:50, 19 May 2016 (UTC)
Please whatever you do to fix this without screwing up other stuff would be great. Please. Jytdog (talk) 05:19, 20 May 2016 (UTC)
Last week I asked Edokter to deploy a change that should help with some jumps caused by (by default) collapsed content elements. This should help with jumps etc due to collapsed content in infoboxes for instance. I've also just submitted two patches to reduce the amount of jumping by the WikiEditor. I hope those will land somewhere next week. Baby steps —TheDJ (talkcontribs) 20:38, 22 May 2016 (UTC)
Thank you very much. Very. Jytdog (talk) 01:15, 23 May 2016 (UTC)

Heading at the bottom of category

It is a poor formatting style to put a heading of a section at the bottom of a page and put the following paragraph in the next page. Yet in wiki categories, e.g. Category:1974 in Gaelic games, when "pages in category" were split into 2 columns, the heading "L" is at the bottom of the first column, while the page link 1974 All-Ireland Senior Ladies' Football Championship (its sort key is "Ladies' Football" due to the infobox so it belongs to "L") is at the top of the second column. I would like to suggest that the heading should always keep with at least the first page link. I know this issue may seem minor, but it is really awkward and not so reader-friendly. --Quest for Truth (talk) 11:18, 21 May 2016 (UTC)

The "L" is an <h3>...</h3> and the page links are <li>...</li> items in a <ul>...</ul>. Sounds like CSS "break-after: avoid" on the header or "break-before: avoid" on the list would fix it. Is it supported widely? DMacks (talk) 11:45, 21 May 2016 (UTC)
Support is in its infancy. I had code ready that might work in the near future, but the devs refused the CSS code that targeted modern browsers using vendor prefixes because they were not implemented (yet!). -- [[User:Edokter]] {{talk}} 13:37, 21 May 2016 (UTC)
For the record: this is probably dublicate and should be merged at phab. --Edgars2007 (talk/contribs) 16:31, 21 May 2016 (UTC)
@Edokter:<