Wikipedia

Wikipedia:Village pump (technical)/Archive 146

< Wikipedia:Village pump (technical)
Village pump (technical) archive  

This page contains discussions that have been archived from Village pump (technical). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR, AS, AT, AU, AV, AW, AX · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212

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 (talk • contribs) 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 contribs
Total
affected		 Affected
addresses		 Given
addresses		 Range Contribs
1 /64 1 /64 1 2601:188:0:abe6::/64 contribs

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?   ~ 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

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

Recent changes

  • The visual editor now works when you use Internet Explorer 9. [4]

Problems

  • There was a security problem with the MobileFrontend extension. It showed information that had been oversighted. This has now been fixed. [5]

Changes this week

Meetings

Future changes

  • Pages could be added to new users' watchlists by default when they edit them. New users could also by default get email notifications when pages they watch are edited. This is discussed on Meta. [7]

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

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 (talk • contribs) 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?

Tracked in Phabricator
Task T34858
Tracked in Phabricator
Task T18683
Tracked in Phabricator
Task T12410

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. N⁄D, 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 N⁄D; 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 [V•T•E] 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 (talk • contribs) 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

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

Recent changes

  • Wikiversities now have better access to Wikidata. They can use data from any page on Wikidata on any page on Wikiversity. This happened on May 3. [12]
  • You can use Wikipedia GapFinder to find missing articles between languages. [13]
  • Users are invited to try Cross-wiki Notifications on all wikis. This is the last test session before the release by default, scheduled for May 12th at 23:00 UTC. [14][15]
  • You can use keyboard shortcuts to open the visual editor (meta+V) or the wikitext editor (meta+E) (on certain wikis, even if you have chosen a favorite editor). [16]
  • Uploading files bigger than 100 megabytes on Wikimedia Commons required to opt-in in your preferences. This is not necessary anymore. [17]
  • The UploadsLink extension is now available on Wikimedia Commons. [18]
  • Deleting a translation unit page didn't remove the corresponding content from the translation page. This is now solved. [19]
  • Translation suggestions based on Apertium are now available on Mediawiki.org. [20]

Problems

  • MediaWiki 1.27.0-wmf.23 has been rolled back from Wikimedia wikis, due to a performance issue. [21]

Changes this week

  •   The new version of MediaWiki will be on test wikis and MediaWiki.org from May 10. It will be on non-Wikipedia wikis and some Wikipedias from May 11. It will be on all wikis from May 12 (calendar).

Meetings

Future changes

  • Today, in categories, a page titled "11" comes before "2". We plan to reorder that: "2" will come before "11". Please tell the developers if the change will cause problems. [22]

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

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"

Tracked in Phabricator
Task T134869

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 (talk • contribs) 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 (talk • contribs) 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 (talk • contribs) 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 (talk • contribs) 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

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

Problems

  • Wikimedia tested a new data center last week. This meant that the wikis could be read but not edited for 45 minutes on April 19 and for 20 minutes on April 21. [25]
  • When the data center was tested, new edits were not shown in the recent changes log for 20 minutes. They are in the logs now. You can read more about how to find the edits.
  • Unread notifications were sometimes counted incorrectly. This has now been fixed. [26]

Changes this week

  • Wikimedia Commons will have better access to Wikidata. They can use data from any page on Wikidata on any page on Commons. This will happen on April 26. [27]
  • It will be easier to choose if you want to watch files you have uploaded with the upload wizard. [28]
  •   The new version of MediaWiki will be on test wikis and MediaWiki.org from April 26. It will be on non-Wikipedia wikis and some Wikipedias from April 27. It will be on all wikis from April 28 (calendar).

Meetings

  •   You can join the next meeting with the VisualEditor team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on April 26 19:00 (UTC). See how to join.

Future changes

  • The "Save page" button when you edit will be called "Publish" instead. This is to help new editors understand what it does. It already works like this on some wikis. [29]

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

21:02, 25 April 2016 (UTC)

Change of "Save page" button to "Publish"

Tracked in Phabricator
Task T131132

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 (talk • contribs) 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 (talk • contribs) 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 (talk • contribs) 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.   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.

Tracked in Phabricator
Task T132806

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 (talk • contribs) 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 (talk • contribs) 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.
 
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)

Requested —TheDJ (talk • contribs) 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)
  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 (talk • contribs) 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 (talk • contribs) 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 (talk • contribs) 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 (talk • contribs) 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:
For other places with the same name, see Borek (disambiguation).
-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 (talk • contribs) 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

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

Recent changes

  • Some image thumbnails now load faster on mobile. They also take up less bandwidth. [37]

Problems

  • Last week's MediaWiki version was late on some wikis. [38]

Changes this week

  • Special:Notifications will have "mark as read" buttons for each day. The non-JavaScript version will get it this week. A JavaScript version will come later. [39]
  • Wikis can now locally decide what wikitext they want the signature button to produce. [40]
  • A one-time welcome message for users will now be shown in the wikitext editor. This will include existing users. [41]
  •   The new version of MediaWiki will be on test wikis and MediaWiki.org from May 17. It will be on non-Wikipedia wikis and some Wikipedias from May 18. It will be on all wikis from May 19 (calendar).

Meetings

Future changes

  • Using self-closing tags like <div/> and <span/> to mean <div></div> and <span></span> will not work in the future. Templates and pages that use these tags should be fixed. When Phabricator ticket T134423 is fixed these tags will parse as <div> and <span> instead. This is normal in HTML5. [42]

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

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 (talk • contribs) 22:40, 17 May 2016 (UTC)
@Epicgenius: I'm guessing may 12th :) —TheDJ (talk • contribs) 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 (talk • contribs) 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 (talk • contribs) 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

Tracked in Phabricator
Task T135773

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 (talk • contribs) 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   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   -- 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 (talk • contribs) 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

Tracked in Phabricator
Task T134067

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 (talk • contribs) 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 (talk • contribs) 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 (talk • contribs) 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 (talk • contribs) 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 (talk • contribs) 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 (talk • contribs) 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 (talk • contribs) 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 (talk • contribs) 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 (talk • contribs) 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 (talk • contribs) 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 (talk • contribs) 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 (talk • contribs) 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 (talk • contribs) 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 (talk • contribs) 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 (talk • contribs) 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 (talk • contribs) 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 issues —TheDJ (talk • contribs) 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 (talk • contribs) 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

Tracked in Phabricator
Task T104541

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: That is a lie. It was I who proposed a patch for it, and you who blocked it. See phab:T104541 and gerrit:261723. That patch could still be merged if anyone wants to "discuss" it with Edokter. Last time I checked, this would work only in Opera 12, Internet Explorer 10 (and later) and Edge. Matma Rex talk 10:37, 22 May 2016 (UTC)
Both Firefox and Chrome were in the process of implementing these properties as well. Your pach was incomplete and inconsistent with other break-related mixins that were using the vendor prefixes; that was my only complaint. -- [[User:Edokter]] {{talk}} 11:49, 22 May 2016 (UTC)
Thank you all of you! It is a shame that the CSS "break-after" is not universally supported yet.--Quest for Truth (talk) 02:46, 23 May 2016 (UTC)

Need developers

Ladies/Gents - I know you're sitting at home right now, probing Wikipedia, and looking for something to soften that boredom. You could work on an article about the 1968 Philadelphia Eagles season, but the tediousness of finishing the whole 1960s collection is just dragging on and on. Let me offer you a new opportunity! The Unblock Ticket Request System is looking to get some additional developers on board. Developers do not have to be administrators, but administrator tools will be required for SSH access and access to the live instance of the tool. Non-administrators can still develop with Github and will have access to UTRS-Alpha and UTRS-Beta. Specifically, we're looking for two associate core developers, a senior user experience developer, and a user interface developer. Specific requirements are listed on the link above, but we're looking for experience with HTML5, PHP, jQuery, CSS3, and bootstrap. Additional cross-platform experience, team management, object oriented design, and secure systems development experience is a huge bonus. Please send an application to utrs dash developers AT googlegroups dot com. We have big ideas and big plans for a v2.0 of the system and we're looking for some folks looking to do exciting work.--v/r - TP 03:15, 23 May 2016 (UTC)

Allow additional Preference options for watchlist pages that have changed? (Hard to distinguish little green dot from little blue dot)

The original thread related to this idea is: Wikipedia:Village_pump_(technical)/Archive_138#Green_marker_in_watchlist_for_pages_that_have_been_changed )

In watchlist I find it difficult to tell the difference between the little green dot indicating a change in a watched page since last visit and the same size blue dots for watched pages that haven't changes after last visit, at least on my system, and I'm not sure bold is working or working well for me, so I'd suggest that Preferences allow some additional choices for marking pages with changes in watchlist:

  • use a much BIGGER GREEN DOT to indicate changes
  • use a GREEN SQUARE marker (bigger than the current green dot)
  • use a BIG RED dot
  • use a BIG RED SQUARE marker

General idea would be to use small marker for unchanged, big marker for changed.
UnderEducatedGeezer (talk) 11:30, 22 May 2016 (UTC)

I think changing it to a square would be simple and easy to do. Also good for accessibility reasons.
But I'm against adding more choices.. Choice for something as minute a detail like this is why people have a personal stylesheet. You can change everything to your hearts delight. When people are talking about their watchlists these days, it's already a guessing game regarding which of the dozens of gadgets they have enabled that has caused 'something' to break. Don't think we need more. —TheDJ (talk • contribs) 13:55, 22 May 2016 (UTC)
Why not try these universally recognised symbols? ♠ ♥ ♣ ♦ The blue ♣ is to contrast better with the black ♠ but the ♦ may as well be red too, since it's more readily discermable from the ♥ than with ♠ and ♣. -- André Kritzinger (talk) 14:07, 22 May 2016 (UTC)
@TheDJ: I suppose most who have a watchlist use stylesheets, but I don't have or use one, so I don't know how to make that work. [Is there a way to make text here 'struck-out', with the text remaining but with a line through it? Strike-out following text, as Redrose64 told me how to address a response to a responder.](Also not sure how to indicate responses to specific individuals here. Should I interrupt the timestamped flow by putting responses directly under post I'm responding to after others have more quickly responded, or do it this way by trying to indicate who I'm responding to and maintaining the timestampedness? ) UnderEducatedGeezer (talk) 22:54, 22 May 2016 (UTC)
@UnderEducatedGeezer: Use the {{replyto}} template, as I did at the beginning of this post.
As a stylesheet example, this edit was inspired by Wikipedia:Village pump (technical)/Archive 113#Green bullets in watchlists. To do the same thing if you use MonoBook skin, go to Special:MyPage/monobook.css, paste in this code
/* [[Wikipedia:Village pump (technical)/Archive 113#Green bullets in watchlists]] */
li.mw-changeslist-line-watched,
li.mw-history-line-updated {
  list-style-image: url("//upload.wikimedia.org/wikipedia/commons/c/ce/ChangedBulletMono2.png");
}
and save. If you use Vector skin, it would be pasted into Special:MyPage/vector.css but some of the code needs changing to suit the different skin. --Redrose64 (talk) 23:16, 22 May 2016 (UTC)
Ok, thank you Redrose64, I looked at the archived Wikipedia:Village pump (technical)/Archive 113#Green bullets in watchlists that you provided, & see that there was quite a discussion about it, but while I'm aware of the general concept of a 'skin' for a display, to apparently achieve a result of easier to perceive personal display of changed watchlist items, I don't use one as far as I'm aware, & don't have (or don't have one that I am aware of) a stylesheet, and just thought it would be easier for a user such as myself to select an option from Preferences than to go through setting up a stylesheet to get that result. UnderEducatedGeezer (talk) 02:02, 23 May 2016 (UTC)
@UnderEducatedGeezer: There are several ways of striking out text, these include the use of HTML tags, for example <s>like this</s> → like this or <del>like this</del> → like this; or a template such as {{strikethrough|like this}} → like this.
Everybody has a skin, it's set at Preferences → Appearance, first box; there are four options. If you've never altered that, and your account was created after about 2010 or so, it's almost certainly set to Vector (accounts created before about 2010 used MonoBook). On the same row are three links "Preview", "Custom CSS" and "Custom JavaScript" - the middle one of those is your stylesheet, which will be a redlink if you've not created one.
To get a preference set up, we can petition the developers (via phab:), and to get that through that takes anything ranging from months through years to never. We can set up a local gadget, which is much quicker (I've known one to be written, tested, installed and available to everybody inside a couple of hours), but we still need community consensus; there are quite a lot already, see Preferences → Gadgets, but most of them add features that are a lot more complicated than changing the style of a list bullet. But we do have one that might help to some extent here: under the second heading ("Watchlist") you may find something like "(D) Display green collapsible arrows and green bullets for changed pages in your watchlist, page history and recent changes (unavailable with the improved Watchlist user interface)" - enable that, and click Save. --Redrose64 (talk) 08:39, 23 May 2016 (UTC)
@Redrose64: Oh! Ok, I think I get it, better to try stylesheet if I want it any time soon, thanks for explaining it. So, using a vector stylesheet, is there some way to make just the bullets for items-changed bullets BIGGER? Preferences → Gadgets → Watchlist → '...green collapsible arrows and green bullets' just gives me the same tiny green-near-blue dots I've wanted to change to something I could see better.

Tech News: 2016-21

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

Recent changes

Problems

  • Commons had problems with server lag. This meant that it took longer time for files to turn up in categories. [45]

Changes this week

  •   The new version of MediaWiki will be on test wikis and MediaWiki.org from 24 May. It will be on non-Wikipedia wikis and some Wikipedias from 25 May. It will be on all wikis from 26 May (calendar).

Meetings

  •   You can join the next meeting with the VisualEditor team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on May 24 at 19:00 (UTC). See how to join.

Future changes

  •   All HTTP access to Wikimedia sites and APIs will stop working. Some bots still use HTTP. They will need to use HTTPS instead. This will happen on June 12. [46]

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

18:40, 23 May 2016 (UTC)

redirects have stopped appearing under "what links here"

As of today, when one clicks on "what links here", one no longer sees redirects. It is important to see those every time one wants to fixed links to "monestary", which redirects to the correct spelling "monastery" (when of course one doesn't know which redirects from unprintable links exist), and when one moves an article and wants to fix double or unprintable redirects. Can this be fixed? (The toggle button that says "show redirects" and "hide redirects" no longer has any effect.) Michael Hardy (talk) 20:08, 21 May 2016 (UTC)

PS: I see that one does see the redirect from "monestary" to "monastery", but one doesn't see redirects from former titles of pages that have just been moved. Michael Hardy (talk) 20:12, 21 May 2016 (UTC)
I think you need to give us the name of a redirect page which you think should be turning up, but is not. (Or explain what you mean by "one doesn't see redirects from former titles of pages that have just been moved.") I see a number of redirects - Monasteries, Nunnery, Monastery, all present and correct. --Tagishsimon (talk) 20:16, 21 May 2016 (UTC)
Possibly related to the OP's report, the number of redirects and number of 'Links to this page' don't seem to be shown. For the article Sky Tower (Auckland), see the page here. "Links to this page" and "Redirects" both show 0, but when the 0's are clicked, it's obvious that there are many links and redirects. Why are 0's showing? Akld guy (talk) 21:51, 21 May 2016 (UTC)
This is a months-old problem, see e.g. Wikipedia:Village pump (technical)/Archive 141#Redirects, Wikipedia:Village pump (technical)/Archive 144#What links here ignoring a redirect, Wikipedia:Village pump (technical)/Archive 144#Three redirects unlisted in WhatLinksHere and Wikipedia:Village pump (technical)/Archive 145#Broken links table. It is apparently closely related to Wikipedia:Village pump (technical)/Archive 141#Category membership issues.
In short: if you move a page, you need to wait for the job queue to update the "what links here" tables before all redirs are listed. --Redrose64 (talk) 23:30, 21 May 2016 (UTC)
@Redrose64: But I created those Sky Tower (Auckland) redirects on 21 February. Are you saying it takes at least three months for the job queue to get around to updating? Akld guy (talk) 05:40, 22 May 2016 (UTC)
I've known the job queue take longer, I think six months. But in the specific case of this URL, it's not a job queue issue - that tool doesn't read the link table directly, it works from a database replication on tool labs, so what we're talking about here is more likely to be a replication lag (replag). Replags usually catch up, but occasionally periods of a few hours are lost entirely. The only fix for lost periods is to copy the whole database over again, and that takes weeks.
Have you tried a different tool? At the top of Special:WhatLinksHere/Sky Tower (Auckland) you should find the entry "External tools: Show redirects only" - that lists 10 redirs at the moment, which matches WhatLinksHere itself. --Redrose64 (talk) 08:50, 22 May 2016 (UTC)
OK on the delay, :( thank you. That other tool worked on the Sky Tower article and a couple of others, so I've bookmarked it; it's going to be really useful, thanks much. Akld guy (talk) 09:07, 22 May 2016 (UTC)
I've known null edits help jolly things along on the what links here front. DuncanHill (talk) 18:34, 23 May 2016 (UTC)
They do on this site, but not sure if they propagate through to toollabs. --Redrose64 (talk) 20:17, 23 May 2016 (UTC)

User Contribution Search for I Hate Everything (YouTube channel)

When searching for the contributions to I Hate Everything (YouTube channel) by any user such as in this example, no results are returned. GeoffreyT2000 (talk) 03:33, 23 May 2016 (UTC)

Labs seems to think that the page is still at its old title, I Hate Everything (webseries). It's out of my control. →Σσς. (Sigma) 03:51, 23 May 2016 (UTC)
This is working now - the Labs database must have caught up with the production database. — Mr. Stradivarius ♪ talk ♪ 22:01, 23 May 2016 (UTC)

Behaviour when undoing edits

I've just noticed a couple slight oddities when clicking "undo". Previously this would generate an automatic edit summary on the lines of "undid revision 1234 by Gubbins". The last couple of times I have used "undo" this has not happened - here. The second oddity is that it undid two edits at once (the two immediately preceding IP edits in the article history). I did want to undo them both, but wasn't expecting it to do both at once. I use Edge on Win10. DuncanHill (talk) 18:32, 23 May 2016 (UTC) (edited by me for some bizarre error on my part DuncanHill (talk) 18:42, 23 May 2016 (UTC))

The automatic edit summary works for me in Firefox. It works by prefilling the edit summary box. It's possible for the user to delete the prefilled text before saving but that has always been the case. Is the edit summary box empty for you right after you click "undo"? PrimeHunter (talk) 19:08, 23 May 2016 (UTC)
Yes, I didn't delete the auto summary, there wasn't one to delete. DuncanHill (talk) 19:12, 23 May 2016 (UTC)
Check your privileges. I suspect you're a rollbacker, since it looks like what you did was [rollback] rather than [undo]. -- André Kritzinger (talk) 19:29, 23 May 2016 (UTC)
I am a rollbacker, but I did not use rollback, I clicked undo. DuncanHill (talk) 19:59, 23 May 2016 (UTC)
The WP:ROLLBACK edit summary is prefilled (in the form "Reverted edits by User1 (talk) to last version by User2") and cannot be blanked or otherwise amended.
If you are viewing the diff of two or more consecutive edits, and click the "undo" link, the edit summary box always starts off blank, but may be amended. --Redrose64 (talk) 20:15, 23 May 2016 (UTC)
And as I did add an edit summary it is obvious I didn't use rollback. I didn't know that about using "undo" when viewing multiple diffs - is that a new thing? DuncanHill (talk) 20:21, 23 May 2016 (UTC)
It's been like that for as long as I've been around - seven years or more. --Redrose64 (talk) 20:40, 23 May 2016 (UTC)
I never use "undo" to revert more than one edit so didn't know this. That means our customized MediaWiki:Undo-success is problematic. It assumes there is only one edit and that there is a default summary. The interface messages used when undoing one or two edits both say "(undo-success)" so the same message is called with no parameter indicating one or multiple edits. This means I don't know a good fix. The MediaWiki default for MediaWiki:Undo-success says: "The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit." This also assumes there is only one edit but there is no reference to a summary so it's less important. The summary for undoing a single edit is made by MediaWiki:Undo-summary. Based on [47] there are no other relevant interface messages so I don't know whether it's possible to make any default summary for undoing multiple edits. PrimeHunter (talk) 21:16, 23 May 2016 (UTC)
While not a solution to the problem you bring up, perhaps our help page (WP:UNDO) should also be amended with an instruction to fill in the edit summary when undoing more than one edit.--William Thweatt TalkContribs 22:03, 23 May 2016 (UTC)

Different byte counts for revisions with the same text

Revisions 721701133 and 171816 of Talk:Scientology/Links have the same text but the revision history says 2,261 bytes for the former and 2,298 bytes for the latter. GeoffreyT2000 (talk) 17:30, 23 May 2016 (UTC)

There can be nonprinting characters which don't appear but which are still in the stream of text. --Ancheta Wis   (talk | contribs) 17:39, 23 May 2016 (UTC)
The diff says no difference. The old revision is from March 2002. The first MediaWiki version is from 2003. Some things in older revisions can appear inconsistent. The source has 38 lines so there are 37 newlines if the last line doesn't end with a stored newline. The size difference is exactly 37 bytes so I guess the issue is one- or two-byte representation of newline. Just ignore it if it doesn't cause problems. PrimeHunter (talk) 18:53, 23 May 2016 (UTC)
Graham87 (talk · contribs) did a history merge at 04:33, 1 December 2011. These always give strange byte counts. --Redrose64 (talk) 19:53, 23 May 2016 (UTC)

Has this scenario been tested?

Suppose a non-admin would like to move a file, without leaving a redirect, to a new name listed on the title blacklist. This action requires tboverride, movefile, and suppressredirect, which means that the user needs the trio of page mover (extendedmover), file mover, and template editor, right? Do we know if this scenario is working for non-admin accounts in all 3 groups? Or has the MediaWiki backend been tested for this scenario? Just a curious thought. — Andy W. (talk · ctb) 00:55, 24 May 2016 (UTC)

Yes, if you are a member of all three of these groups you can move a file, without a redirect, to a blacklist title. example here. — xaosflux Talk 01:44, 24 May 2016 (UTC)

Insert Citation button missing from the editing toolbar

Hello, recently when I go to edit an article or create a new one, I find that the "insert citation" button is missing from the edit toolbar as seen here. I was wondering if this was a known issue or one unique to me. If it helps, I'm running Google Chrome version 50.0.2661.94 on WIndows 10. Americanfreedom (talk) 04:31, 24 May 2016 (UTC)

The "Cite" menu (if that's what you're referring to) is to the left of the "Help" menu for me. Is it not to the left of the "Help" menu for you? — Andy W. (talk · ctb) 04:46, 24 May 2016 (UTC)
You appear to be using RefToolbar 2.0a at Wikipedia:RefToolbar#Versions. With that I have two more icons in Firefox than your image: Between the book icon and "Advanced" are both a signature icon and the insert citation icon {{ }}. Have you tried to clear your entire cache? Have you tried RefToolbar 2.0b by enabling "Enable wizards for links, formatting, tables, citations, and the search and replace function" at Special:Preferences#mw-prefsection-editing? It gives a "Cite" button to the right of "Help" and another citation interface. PrimeHunter (talk) 10:07, 24 May 2016 (UTC)

Austrian_presidential_election,_2016 linked from Main Page, infobox broken

Could be something that I'm doing wrong, or intentional, but it looks like *even though* Van der Bellen is filled in as the elected president, the infobox is showing "Elected President" as blank. This seems like a highly visible issue; could someone take a look at it? Thanks :) Goldenshimmer (talk) 06:13, 24 May 2016 (UTC)

Screenshots: [48] [49] forgot to sign, adding signature Goldenshimmer (talk) 06:20, 24 May 2016 (UTC)
For convenience: Austrian presidential election, 2016 Fred Gandt · talk · contribs 06:37, 24 May 2016 (UTC)
  Fixed. --Edgars2007 (talk/contribs) 06:44, 24 May 2016 (UTC)
Sweet, thanks User:Edgars2007 :) Goldenshimmer (talk) 20:49, 24 May 2016 (UTC)

Featured articles that haven't been on the Main Page

WP:Featured articles that haven't been on the Main Page appears to have been emptied on 17th May, Any ideas ? Thx GrahamHardy (talk) 11:18, 23 May 2016 (UTC)

It was emptied by User:FACBot so User:Hawkeye7 is the one to ask. PrimeHunter (talk) 11:30, 23 May 2016 (UTC)
Just asked, Thanks GrahamHardy (talk) 12:12, 23 May 2016 (UTC)
Now fixed GrahamHardy (talk) 22:26, 24 May 2016 (UTC)

Beta-lactamase

Is anyone seeing this article as a redirect to an identically-named article? What exactly is going on here? Very confused. — Andy W. (talk · ctb) 05:37, 25 May 2016 (UTC)

Can anyone verify that, for one of these articles, the first letter is a Greek "beta", but due to technical issues, renders as "B"? I really feel like this needs to be mitigated. — Andy W. (talk · ctb) 05:39, 25 May 2016 (UTC)
Yes - the article, not the redirect, begins with a Greek capital beta, U+0392. The redirect is a normal capital B. —Cryptic 05:45, 25 May 2016 (UTC)
(edit conflict) The redirect target's title has "Β" (U+0392 GREEK CAPITAL LETTER BETA) as its first character. This character is homoglyphic to (looks basically the same as) B (U+0042 LATIN CAPITAL LETTER B) in many typefaces. Goldenshimmer (talk) 05:47, 25 May 2016 (UTC)
But that's ridiculous. Surely it ought to be either (all Latin) beta-lactamase or β-lactamase. βeta-lactamase is not a style corroborated by any source I can see. Propose move to beta-lactamase Intelligentsium 05:51, 25 May 2016 (UTC)
It seems to have been moved recently from the correct title β-lactamase to βeta-lactamase. Intelligentsium 05:54, 25 May 2016 (UTC)
I proposed the move. I also think that the one with the Greek letter beta should be deleted. (including a number of redirects that seem iffy as well. — Andy W. (talk · ctb) 05:55, 25 May 2016 (UTC)
@Intelligentsium: Yes, I made the move you mentioned, but couldn't figure out how to resolve some of the double redirects (about half an hr ago). — Andy W. (talk · ctb) 05:57, 25 May 2016 (UTC)
Ah yes. I do agree beta-lactamase is a better title per Wikipedia:Naming conventions (use English) but I think the redirect at β-lactamase should remain as it is a style frequently used in the literature and thus would be a common search-term. Intelligentsium 06:00, 25 May 2016 (UTC)
Oh no. I should undo, shouldn't I? (redirect fixes). — Andy W. (talk · ctb) 06:13, 25 May 2016 (UTC)
Requested another move. — Andy W. (talk · ctb) 06:22, 25 May 2016 (UTC)
I don't think there's any particularly compelling need to change the styles from how they are currently used to conform to one or the other, as both are widely used in the literature. In fact, from a Google Scholar search it appears there are more hits for the Greek β-lactamase than the Latinized beta-lactamase. In that case the old title might be more appropriate after all. Intelligentsium 06:25, 25 May 2016 (UTC)
On the other hand there seems to be no established naming convention where only one letter of the name is a non-English character. We have but β-lactamase but Beta thalassemia, Gamma function but Γ-convergence, α-Methylacetylfentanyl but Alpha-adrenergic agonist. It seems to be more or less arbitrary. Intelligentsium 06:32, 25 May 2016 (UTC)
It has been undone, and redirects are fixed. I think it's more in-line with things like Beta-carotene and beta-Carboline in generally the same topic (although we still have β-Lactamase inhibitor)... <-- I'm gonna think about this one. Definitely didn't intend to get this deep into the issue when I just wanted to fix some DISPLAYTITLES. — Andy W. (talk · ctb) 06:54, 25 May 2016 (UTC)

OK to switch English Wikipedia's category collation to uca-default?

Discussion was moved to Wikipedia talk:Categorization#OK to switch English Wikipedia's category collation to uca-default?. עוד מישהו Od Mishehu 13:26, 25 May 2016 (UTC)

Numeric ID

I'm sure every username is assigned a unique numeric ID in wikimedia projects. I searched previous archives of the technical village pump and found this relevant disscussion. My question is how to find that numeric id? I want to make a random selection between two candidates who ended up in a tie in a Persian Wikipedia election. Thank you 4nn1l2 (talk) 07:56, 25 May 2016 (UTC)

One way is looking here at tab "General statistics". --Edgars2007 (talk/contribs) 08:04, 25 May 2016 (UTC)
Thank you Edgar, My user ID on English Wikipedia differs from my user ID on Persian Wikipedia. Considering Wikipedia:Unified login, how that is possible? I just want to know if that is OK. 4nn1l2 (talk) 08:24, 25 May 2016 (UTC)
Yes, my ID is also different here and at my home Wikipedia. This ID doesn't have to do anything with SUL. --Edgars2007 (talk/contribs) 08:39, 25 May 2016 (UTC)
Here is a fast API method: https://en.wikipedia.org/w/api.php?action=query&list=allusers&aulimit=1&aufrom=Edgars2007. PrimeHunter (talk) 10:20, 25 May 2016 (UTC)
At one time it was shown in the "Basic information" section on the first page of Preferences, as "User ID". Here's the method that I now use: for any Wikimedia project, take the site's base URL (for English Wikipedia it is https://en.wikipedia.org/ for French Wiktionary it is https://fr.wiktionary.org/ and so on) and append w/api.php?action=query&meta=userinfo&format=jsonfm to that, i.e. https://en.wikipedia.org/w/api.php?action=query&meta=userinfo&format=jsonfm or https://fr.wiktionary.org/w/api.php?action=query&meta=userinfo&format=jsonfm etc. Paste that in your browser's address bar, and the User ID is displayed after the name "id". --Redrose64 (talk) 11:33, 25 May 2016 (UTC)
Alternatively, go to Special:Export and export a page that the user has edited. The account numbers of all users who have edited the page appear in the XML code. Doesn't work for users without live contributions. --Stefan2 (talk) 12:28, 25 May 2016 (UTC)
@Redrose64: Thank you, that is a clean and nice way, but it only gives my user ID. How can I obtain another user's ID? I don't see any parameter to specify the username in your code, whereas PrimeHunter's code has such a parameter, namely &aufrom=Edgars2007. User:PrimeHunter's code has a downside. It lists all similar usernames including sockpuppets which are sometimes derogatory, for example: https://fa.wikipedia.org/w/api.php?action=query&list=allusers&aulimit=1&aufrom=Mardetanha 4nn1l2 (talk) 15:49, 25 May 2016 (UTC)
My API call only shows the next user in alphabetical order. PrimeHunter (talk) 16:14, 25 May 2016 (UTC)
Another API call --Edgars2007 (talk/contribs) 16:26, 25 May 2016 (UTC)

What links here and a talk page redirect

I've run into an interesting situation that probably has been mentioned before, but my admittedly quick search didn't find.

SummerPhDv2.0's old talk page at User talk:SummerPhD is a redirect to the current talk page. This redirect causes (I think) unintended behavior in the "What links here" area for all articles links on the redirected talk page. For example, spin-off should have only about 295 incoming links from all namespaces. Instead, it has over 13,000 incoming links because of the 12,845 pages that have a link to User talk:SummerPhD (all of the various pages where a signature owas left). The issue is that for those of us that use semi-automated tools, all of those extra incoming links cause the page to load much slower than it normally would.

Does anyone have an idea how to leave the redirect alone (so that anyone clicking on an old signature still goes immediately to the correct talk page) and to get rid of all of the entries in the various "What links here" areas? -Niceguyedc Go Huskies! 06:33, 25 May 2016 (UTC)

Where are you getting 13,000 links? Special:WhatLinksHere/Spin-off has 306 entries for me. When I click "500" the list is complete. If some tools get confused by User talk:SummerPhD being a redirect and also linking to pages it doesn't redirect to then the obvious quick solution is to archive the talk page somewhere so the redirect has no other text. Ideally, the tools should be coded to avoid such confusion. PrimeHunter (talk) 10:38, 25 May 2016 (UTC)
I hadn't actually looked at Special:WhatLinksHere/Spin-off, as I assumed it was the same as what I was seeing in WP:CLEANER. That was a poor assumption by me. This would suggest that the place to ask is at WP:CLEANER, which is where I will go next. -Niceguyedc Go Huskies! 17:17, 25 May 2016 (UTC)

Comment - I don't quite understand what the technical issue is, but I have no objection whatever might need to be done to correct this. I'd like to keep my archives and, of course, clean navigation from old links to my new pages. Thanks. - SummerPhDv2.0 13:29, 25 May 2016 (UTC)

Bizarre linking system-Notifications and RFCs

 

This is a screenshot of a notification for the Archive.is RFC, showing I was pinged in a discussion. The blue link does not go to the RFC in question. Rather, it goes to RFC 4, the real one on the internet. Clicking anywhere else gives me the right page. This is bizarre and unexpected behavior for the end user. Everywhere else on Wikipedia we are told to click on the blue links to get to the page we want, and here it throws you for a loop. Another example of this auto linking behavior may be found on this very page at #Wikipedia:Archive.is RFC 4. I do not remember adding any scripts or checking any preferences that would cause this. Pinguinn 🐧 17:01, 25 May 2016 (UTC)

It's a MediaWiki feature that some strings like RFC, PMID and ISBN can cause automatic creation of links when they are followed by a number. See mw:Manual:RFC and mw:Markup spec/BNF/Magic links. Here it has an unfortunate interaction with the notification. PrimeHunter (talk) 17:57, 25 May 2016 (UTC)
See also phab:T70217 (about magic links showing in notifications as here) and phab:T47942 (about making it possible to disable the magic links entirely). the wub "?!" 21:53, 25 May 2016 (UTC)

Community Consultation on Labs Terms of Use: Round 1

The Wikimedia Legal team is interested in revising, updating, and clarifying the existing Labs Terms of Use governing developers and their projects on labs.

Round 1 of our community consultation is currently open to hear feedback on the Labs Terms of Use. We will try to respond the best we can, but the main purpose of this round is to hear all your thoughts. After the feedback round, we will prepare a draft revision of the Terms based on that feedback and other minor revisions to clarify statements in existing the Terms. We will then engage in a community discussion about the revised Terms.

We plan to leave the discussion open until June 9, 2016. Thank you for all your help and feedback.--ZZhou (WMF) (talk) 23:30, 25 May 2016 (UTC)

svenska?

Every page I visit that does not have a corresponding page on another language wiki, and at least some with working links, has an interwiki link, "svenska". It does not work as expected though. It is greyed out and if I click on it I get the "This page does not exist in svenska yet. Do you want to create it?" dialog. This does not happen on pages with a large number of iw links - a dozen or more maybe – as best I can tell. Checking wikidata for a couple of pages and the link data looks fine. First noticed it I think yesterday and decided to check a few pages today.--JohnBlackburnewordsdeeds 22:46, 25 May 2016 (UTC)

One more thing. If there are multiple entries the "svenska" is always first. E.g. Malwa Sultanate has a grey "svenska" followed by eight normal links. And yes, lower case like that. If there is a proper link to sv:wp as on the main page it’s capitalised.--JohnBlackburnewordsdeeds 22:49, 25 May 2016 (UTC)

I only see the eight interwiki links on Malwa Sultanate, not one to svenska. DuncanHill (talk) 22:53, 25 May 2016 (UTC)
OK, found out how to fix it – change my interface language. I’ve never had it as svenska but changing it to British English then English seems to clear it. Oddly changing it to Scots adds a grey “Scots”, even on the main page, which does not go away when I change back to English. So it seems to be a feature helping you find articles needing translating to your native/preferred language and start translating. But it seems also to be picking up the wrong language and sticking with it even when you are on a language, e.g. English, which you can’t translate to.--JohnBlackburnewordsdeeds 23:00, 25 May 2016 (UTC)
This feature is "Content Translation" at Special:Preferences#mw-prefsection-betafeatures. Just disable it if you don't want it. PrimeHunter (talk) 00:34, 26 May 2016 (UTC)
Yep, that’s fixed it. I had not enabled that recently, but may have enabled it a long time ago wondering “what does that do?” and promptly forgotten about it. I had not noticed it before so guess some part of it was rolled out/enabled in the recent update.--JohnBlackburnewordsdeeds 01:12, 26 May 2016 (UTC)

Statistics for page counts and breakdown of the source of the page counts

Page count statistics are stored and available for all Wikipedia articles for the cumulative number of page hits per day on one of the tabs readily accessible on the edit history page. Does anyone know if these page count statistics are broken down anywhere as to the source of where the page request is coming from? What part of the the cumulative page count at Wikipedia comes from searching and linking from the Yahoo engine, as opposed to the Google engine, as opposed to the Wikipedia search box engine, how many are from desktop, how many are from mobile, etc? Which percentage of page counts for individual Wikipedia articles come from which sources whether from inside Wikipedia or from outside Wikipedia? Can these statistics be readily retrieved? Fountains-of-Paris (talk) 19:07, 10 May 2016 (UTC)

@Fountains-of-Paris: PageViews has a "Platform" and an "Agent" box. The former for all/PC/mobile/app and the latter for all/user/spider/bot. The other information you're looking for is not provided by the API of interest, but I believe you can report the desire for that information at Phabricator; the generic bug for PageViews things is phab:T120497--you can submit another task if you think this is desirable by a wide set of persons. @MusikAnimal: FYI. --Izno (talk) 11:49, 11 May 2016 (UTC)
And phab:project/view/1772/ is the relevant project on Phabricator. --Izno (talk) 11:55, 11 May 2016 (UTC)
@Izno: That sounds like the correct tool, though I cannot locate the tabs for Platform or for Agent which you are referring to. Are they above the graph or below the graph which is posted to illustrate the page counts? Do I need to navigate through other tabs first to find them? Knowing the difference between the sources of how readers are getting to Wikipedia articles is a very important design paramater. How do I get to Platform or to Agent? Fountains-of-Paris (talk) 14:25, 11 May 2016 (UTC)
They should be dropdowns located above the graph, placed to the right of the Dates and Project forms. What browser are you using? The Github repo docs have this line: "IE10 and Safari 8 and below are not supported." Are you using one of the unsupported variants? --Izno (talk) 14:28, 11 May 2016 (UTC)
It wouldn't work at all in IE10 and Safari 8 and below, so I'm guessing you're just missing that dropdown: it's at the top-right next to the date range and platform input. Anyway, what you are after is the HTTP referer, and the API does not offer this information. The old squid reports, has some referer information, but that hasn't been updated since August 2015. If you want to file a feature request on phab, I guess add the "RESTBase-API" tag at that seems to be the place where this information would be made available [50] — MusikAnimal talk 14:50, 11 May 2016 (UTC)
Wikipedia does have software for identifying whether or not an article is an orphan article with no links made to it and no links made from it. This seems like an all or nothing option. Is there a way to get information regarding how many times, by tally or count, that one article refers to another article throughout Wikipedia? Fountains-of-Paris (talk) 14:37, 13 May 2016 (UTC)
Possibly Quarry? --Izno (talk) 15:32, 13 May 2016 (UTC)
How do you set up the SQL syntax for the querry to work for a random article, for example, "Dostoevsky" to get a summary of the usage counts of its links? Fountains-of-Paris (talk) 15:55, 13 May 2016 (UTC)
 
Refererrers and clicks for the article London
@Fountains-of-Paris: A few partial answers:
  • If you are interested in the overall ratio of traffic referred from search engine, the Foundation's Discovery team offers a dashboard here: http://searchdata.wmflabs.org/external/
  • Regarding internal referrers, there is a public dataset which is very occasionally updated: m:Research:Wikipedia_clickstream (used to generate the chart for London on the right)
  • The Pageview_hourly table, which is the source for https://tools.wmflabs.org/pageviews/ contains a "referer_class" field (values: internal, external or unknown) which could potentially be exposed in the tool too. (The full table can't be made public for privacy reasons.) You may want to file a Phabricator task for that if you are interested in this; it might need some wider discussion but right now I don't see reasons why this would be impossible.
  • Lastly, if one has access to these internal tables (only a few people who have signed an NDA, mostly WMF staff like myself who need it for their work - I myself use it as a data analyst in the Reading department, mostly to support the department's software development) can also query recent referrer URLs for a specific article, however this data might still be sensitive depending on the situation. Also, these queries are computationally intensive. Still, if you have a research question that can't be answered via the above options, I might be able to occasionally set some time aside to run some specific queries of that nature for you. It would be easiest if you study the documentation here and generate the queries yourself, and then file a Phabricator task, assigning it to me.
Regards, Tbayer (WMF) (talk) 01:46, 24 May 2016 (UTC)
@Tbayer (WMF): That's actually directly on target, and my intention was to try to extend the current Wikipedia concern that so-called "orphan" articles should be avoided and fixed when possible. Wikipedia currently does allow us to find out if an article is not used at all system-wide within Wikipedia (in other words a two-state "non-zero-or-zero" inter-article request rate) in hoping to remedy such under-used and under-accessed articles. Rather than causing privacy concerns, my interest in raising this issue was to extend the current two-state "non-zero-or-zero" count notification towards trying to keep the actual number of times one article uses another article, and to do this as a natural extension of the "non-zero-or-zero" indication currently being used for identifying orphan articles. If this can be done without causing privacy issues, then the statistics for the quantity of inter-article referrals within Wikipedia would be useful to editors in the future. (Also, its notable of you to offer running these stats as a one-off when needed, though it would be nice if the stats where more readily available to all editors in the future.) Fountains-of-Paris (talk) 15:56, 25 May 2016 (UTC)


Can Wikipedia give stats for more than just mobile and desktop page counts

Recent nice enhancements of the page count graphics and statistics are give us break down information for mobile usage as compared to desktop usage. This was done mostly to keep track of how well Wikipedia was doing in keeping up with the strong shift to mobile computing being reported in the press over the last 2-3 years. Its nice, though should we have information about general refers as documented by Tbayer for Wikipedia's London article in the graphic illustration in the last section just above. Should Wikipedia expand information on page counts to include other important referrers which influence who reads Wikipedia and how they gain the all important first access to information and articles at Wikipedia? Fountains-of-Paris (talk) 14:31, 26 May 2016 (UTC)

Template space

Hi, If you look at Teen_Choice_Awards#External_links there's a space between both templates - I've added both templates to my sandbox and it looks fine so I'm not sure if this is a bug or simply the article layout ?, Thanks, –Davey2010Talk 19:45, 24 May 2016 (UTC)

I've fixed it, but I have no idea why my edit worked! -- John of Reading (talk) 20:29, 24 May 2016 (UTC)
Haha neither do I, Thanks John of Reading - On the laptop it looks like a whitespace ... surely that's not the whole reason for the screw up ?, Thanks tho for fixing it - Much appreciated, –Davey2010Talk 20:53, 24 May 2016 (UTC)
The space was being taken as a paragraph, so the emitted HTML was 
</table>
<p>
</p>
<table ...
the two tables being the navboxes. If you see something like this again, use your browser's "View source" or "Inspect element" feature. --Redrose64 (talk) 00:02, 25 May 2016 (UTC)
The character after the first template was a Unicode "thin space". Unlike a trailing regular space which would be ignored by MediaWiki, the thin space is in this context treated like normal text and placed in its own paragraph between the navboxes.
(In wikilinks on the other hand, thin spaces are treated similarly to regular space characters, so the markup [[&thinsp;]] doesn't result in a link, and an R from Unicode redirect can't be made for the character. These redirects are otherwise often handy for looking up unknown characters.) --Pipetricker (talk) 14:37, 25 May 2016 (UTC)
Ahhh right so that explains it all .... learn something new everyday  , Anyway thanks Redrose64 & Pipetricker, –Davey2010Talk 15:36, 26 May 2016 (UTC)

An actual one-click archiver

Archy McArchface (['ɑɹ.kij mɪk.'ɑɹk.feɪs]) is a script that allows a user to select and archive multiple discussions to another page. Archy McArchface was created to better enable experienced editors to clear out old discussions without having to rely on OneClickArchiver, which functions much awkwardly when used to archive more than one discussion on a given talk page.

Users are encouraged to try it and provide useful feedback. Bugs and other issues can be reported at my talk page. →Σσς. (Sigma) 02:36, 27 May 2016 (UTC)

Why am I seeing a "Welcome" message?

Soon some of you may see a "Welcome" dialog in the wikitext editor, as per my heads-up here. (Remember that the English Wikipedia is a Single Edit Tab wiki now, so if you don't know or remember what this entails, check the related announcement from last month). Best, --Elitre (WMF) (talk) 13:46, 19 May 2016 (UTC)

Lets keep an eye out for user issues in case we need a MediaWiki:Sitenotice. — xaosflux Talk 14:36, 19 May 2016 (UTC)
I just got this stupid popup, I've been editing for seven years and am at no. 185 in the most edits list. I turned off VE as soon as an option to do so was available. I've been an admin since 2011 ferchrissakes. Get real. --Redrose64 (talk) 19:33, 19 May 2016 (UTC)
Joining Redrose64 in not welcoming this in the least. In the best of circumstances I hate these not-really-there phenomena that social media uses nowadays; my screen freezes with the darned thing hovering there and it's never clear what I should click on to be able to use the window again. In this case it almost gave me a heart attack - I was previewing and thought I'd lose the edit. I took the risk of clicking on "Edit" or whatever and thank all the gods, neither lost the edit nor crashed my browser. WMF: I volunteer here, doing the work that makes this wiki popular enough that you get to be handsomely paid for whatever it is you do. Stay out of my workflow. Take your abysmal Visual Editor and shove it, don't thrust it in front of me, I and the vast majority of the people who actually work around here told you it sucks, it sucks, that's it, stop demanding we choose between it and what works! Yngvadottir (talk) 19:49, 19 May 2016 (UTC)
Please relax a bit, it makes everyone's participation a whole lot more pleasant. —TheDJ (talk • contribs) 19:57, 19 May 2016 (UTC)
Don't tell me to relax. It came up again. Do you work for that awful outfit? If so, please report that the experience of having this pop-up freeze one's screen is not pleasant. Yngvadottir (talk) 20:08, 19 May 2016 (UTC)
"Do you work for that awful outfit" No, not that that should have anything to do with how we communicate with eachother. —TheDJ (talk • contribs) 21:08, 19 May 2016 (UTC)
It really is disruptive - I get a box with no "dismiss" option - only "start editing" that is quite jarring - when I clicked on it, it just went away. Completely useless in the workflow for me as an editor, and unexpected. I think we should put up the site notice to warn about this - any objections? — xaosflux Talk 20:20, 19 May 2016 (UTC)
I know that this is a case of hindsight, and given that all I know of this is what I learned from mucking about with scripts in...the other thread, I probably don't have all the information I would need to speak intelligently about this. But just for curiosity's sake, shouldn't it have been possible to prevent the message from popping up for current users by adjusting the starting value of visualeditor-hidebetawelcome in everyone's preferences? New accounts could have the welcome enabled, of course, since it's targeted to them, but would it not have been straightforward enough to just set that pref to "true" for all current users? Maybe this version of the welcome is different though or something, so I might not understand correctly. Writ Keeper ⚇♔ 20:21, 19 May 2016 (UTC)
@Writ Keeper: I made the decision not to do that intentionally, I'm afraid. Doing the fetch of the users' edit count and registration date would have added another few ms to every edit page load for every editor for the rest of time. Pre-setting tens of millions of rows in the databases to fake 'visualeditor-hidebetawelcome' as true would be a pretty major step which we go out of our way to avoid. Note that any account that's seen the dialog before (e.g. in the visual editor) won't get the prompt (unless they've reset their preferences), it's just a one-time thing regardless of which editor you use. Jdforrester (WMF) (talk) 21:38, 19 May 2016 (UTC)
Hmm, I guess I can understand that. I know my ops people always get mad at me when I write update queries for them to execute that hit millions of rows. I wouldn't have said it's a dealbreaker--there are generally speaking ways to do it gradually without totally destroying the database--but I can respect it, as long as it was at least thought about. Writ Keeper ⚇♔ 21:42, 19 May 2016 (UTC)
When I just now brought up a deleted page to check its logs, I got the "Welcome to Wikipedia" popup smack in the middle of my screen, that told me to click on it to begin editing. I've been on Wikipedia for about 7-8 hours today, and this just popped up the first time. If it's an oversight, please give us an opt out. This shouldn't be coming up for anyone but people who have never edited at Wikipedia before. And considering how hard internet users work to keep popups off their screens, maybe this was not the best of ideas. And by the way, in my Preferences, "Temporarily disable the visual editor while it is in beta" has been checked off as long as the option has been there. — Maile (talk) 20:30, 19 May 2016 (UTC)
I just got it straight across the board, testing all the wikis. — Maile (talk) 23:38, 19 May 2016 (UTC)
You should see it once per wiki while logged in. This means once at the English Wikipedia, once at the German Wikipedia, once at the French Wikipedia, etc. – all the languages times all the projects (times all the accounts, if you have more than one, as I do). Most editors don't spend much time doing cross-wiki work, so most editors won't see it more than once or twice. Personally, I've already clicked past it at least six times in the last hour. (Also, it's faster to click "Start editing" on that dialog than to go to Preferences, find an item, and opt-out.) Whatamidoing (WMF) (talk) 00:16, 20 May 2016 (UTC)
\o/ I just got one   Fred Gandt · talk · contribs 20:56, 19 May 2016 (UTC)
I just got it too. DuncanHill (talk) 21:01, 19 May 2016 (UTC)
Yup, looks like we all got a VisualEditor prompt. — Andy W. (talk · ctb) 21:11, 19 May 2016 (UTC)
We are blessed! ;-) Fred Gandt · talk · contribs 21:30, 19 May 2016 (UTC)
Why not link to this angry public flogging thread, since it is going to contain all the answers as time goes on - seriously? Fred Gandt · talk · contribs 21:30, 19 May 2016 (UTC)
Will mock something up and post back soon. — xaosflux Talk 21:38, 19 May 2016 (UTC)
  • Ironically I got the welcome message on Commons but not here .... I feel even more blessed lol, –Davey2010Talk 21:52, 19 May 2016 (UTC)
Teacher's pet ;-) Fred Gandt · talk · contribs 22:07, 19 May 2016 (UTC)
  • Playtime again in the main sandbox.--TMCk (talk) 22:18, 19 May 2016 (UTC)

Site notice

Mockup:

Logged in users may be presented a Welcome Screen once prior to making an edit. (Discuss this.)
Any suggested changes? — xaosflux Talk 23:46, 19 May 2016 (UTC)
What action do you expect typical users to take in response to that proposed message? Whatamidoing (WMF) (talk) 00:07, 20 May 2016 (UTC)
I trust the typical users will band together and demand another site notice to explain the first site notice which explains the trivial pop-up, using There Was an Old Lady Who Swallowed a Fly as a general guide to strategy. --Tagishsimon (talk) 00:12, 20 May 2016 (UTC)
Become aware of what is going on. I'm not about to slam it up there unless there is some agreement here that it will be useful. — xaosflux Talk 00:15, 20 May 2016 (UTC)
Good call. You do not have 'some agreement', or, at least, you do have some dissent. --Tagishsimon (talk) 00:17, 20 May 2016 (UTC)
Xaosflux, there's no clear "call to action", if you don't mind the designers' jargon. It first tells editors something that they'll find out on their own (so it's redundant), and then it offers a place to discuss something or another about "this", but at the time that they're offered this option to discuss something, they don't know what you want them to discuss, because they haven't seen the dialog yet. If I didn't already know what this message was about, I'd be confused by it. The discussion is also unlikely to provide actual value to the participating editors: by the time you know enough to discuss it, you've already dismissed it.
For the record, I don't think it's an unreasonable thing to consider; in fact, I very briefly considered a CentralNotice myself. It's a tool I often consider, but rarely use, for user interface changes. However, I decided that the net result of any such message would be thousands of editors at 800+ WMF wikis spending collectively hundreds of hours trying to figure out what I was talking about. That time would be far more than they would spend in dismissing the one-time dialog when it reached them – and they'd still have to dismiss the dialong anyway. So based on that analysis, it didn't seem like a valuable use of volunteer time and attention, and I abandoned the idea. Whatamidoing (WMF) (talk) 00:45, 20 May 2016 (UTC)
To be clear, unless there is actual support I'm not touching the sitenotice. My goal was to get information in front of people to avoid drama, certainly not make more. — xaosflux Talk 01:00, 20 May 2016 (UTC)
I'm not going to pretend to know exactly why this welcome popup is popping up, but get the jist. Please bare that in mind as I suggest that if there's to be a site notice to act as a heads up, it should be simple, honest and self contained advice.
Something like "Because of a discussion that lead to a decision to implement a thing, the WMF did a thing which lead to a discussion which reversed the decision, and resulted in a technical glitch. This glitch will manifest as a welcome message that pops up as editors begin editing. This popup will only show once on each Wiki thing, and other than getting in the way a little, changes nothing. Welcome to Wikipedia! ;-)" - with obvious editing.
It's not a call to action, or an obscure and confusing riddle; it just says what's happening to alleviate potential surprise and maybe save some freaking out. Fred Gandt · talk · contribs 01:06, 20 May 2016 (UTC)
It may be simpler to just make the popup itself do the talking since I'm sure a lot of editors have not yet been harassed by it. For some reason, it popped up at least twice for me, and the option buttons were, as stated, not very clear on what to expect when selecting the edit option. I, for one, did not know whether to expect the familiar editing format of some newfangled thing to waste my time. -- André Kritzinger (talk) 01:20, 20 May 2016 (UTC)
I'd be in a favor a single [X] in the top right corner, clicking it: dismisses the box forever and keeps all your settings exactly how they were prior to the popup. — xaosflux Talk 01:45, 20 May 2016 (UTC)
An [X] would do it. It was the first thing I was looking for when the popup popped up... André Kritzinger (talk) 02:11, 20 May 2016 (UTC)
Me too. Fred Gandt · talk · contribs 03:40, 20 May 2016 (UTC)
A forever X would be a step forward, click it once and it stays gone for all eternity. Even better, if our Preferences had an option to suppress any and all popups that Wikimedia could come up with, forever and ever and ever. — Maile (talk) 14:15, 20 May 2016 (UTC)
Tracked in Phabricator
Task T135808

@Elitre (WMF):; @Whatamidoing (WMF): -- Any options for tweaking the UI of this popup as suggested above? — xaosflux Talk 14:44, 20 May 2016 (UTC)

I've asked. I don't know whether I'll get a definitive answer today, but I'll let you know. One of the devs also suggested making it possible to dismiss things like this by clicking anywhere outside the box, so there may be more than one 'leave me alone' approach implemented. Whatamidoing (WMF) (talk) 16:31, 20 May 2016 (UTC)
If there's a need for the Welcome message, making it accidentally dismissable is not a good idea. --Pipetricker (talk) 09:02, 21 May 2016 (UTC)
I was gone for a few days, and when I returned a pop-up greeted me when I wanted to edit. I agree with Maile above, quit spamming us with the VE already. I already have just one edit tab, I suppressed the VE one. Manxruler (talk) 15:26, 25 May 2016 (UTC)
Could just use my method of nuking any unwanted stuff with uBlock Origin's element picker; it seems to do the trick most of the time... 02:49, 27 May 2016 (UTC)

Disabling in all wikis

So far this has worked for me: I've added in m:Special:MyPage/global.css a

Extremely bad advice
.oo-ui-windowManager-floating {
    display: none;
}

This should also prevent other past and future similar-looking popups/splashscreens/whatever. I'm also filing a few reports about specific problems, please do the same. Nemo 11:40, 22 May 2016 (UTC)

I think this is terrible advise for people. Anyone going this direction should consider if it is not wiser to disable all Javascript instead. We have two modes of operation, without JS and with. That's what can be supported, not some freak of nature in between state that this would create.
For instance. I'm in the process of removing the jquery UI dialog popup that we have on thumbnail videos, with oojs ui dialogs. By doing this you would have autoplaying but invisible videos after you click them at some point in the future. And though I am now warned, there is no way in hell that I will take this into account when creating my patches. —TheDJ (talk • contribs) 13:49, 22 May 2016 (UTC)
This is really bad advice. It will hide every OOjs UI dialog, on every page, in every tool. And then developers will have to field bug reports from people who thoughtlessly copy and paste this. Matma Rex talk 14:18, 22 May 2016 (UTC)

I wrote the following in my global .js and it seems to be working: 

if (mw.user.options.get('visualeditor-hidebetawelcome') === 0)
	{ var VEBapi = new mw.Api();
	  VEBapi.post({
		'action': 'options',
		'token': mw.user.tokens.get('editToken'),
		'change': 'visualeditor-hidebetawelcome=1'
	  });
	}

BethNaught (talk) 15:16, 22 May 2016 (UTC)

Much better advise, though
  1. You are not declaring your dependencies (mediawiki.api and user.options), by wrapping with mw.loader.using
  2. You are not using postWithToken(), which does automatic token retrieval and token retry (in case it expired)
  3. You are using editToken, but this has since been replaced with the 'csrf' token
  4. You change the preference, but not the local state
And because of all that complexity, we have a wrapper module named 'mediawiki.api.options'
mw.loader.using( ['mediawiki.api.options', 'user.options' ], function () {
	if (mw.user.options.get('visualeditor-hidebetawelcome') === 0) {
		new mw.Api().saveOption('visualeditor-hidebetawelcome', '1');
		mw.user.options.set('visualeditor-hidebetawelcome', '1');
	}
} );
—TheDJ (talk • contribs) 16:11, 22 May 2016 (UTC)
I have a couple of problems with this message, some of which I admit are repeats:
  1. I don't see a use for it
  2. If WMF wants to communicate with me, shouldn't they do it whether I have Javascript enabled or not? Even if there is a Visual Editor that requires Javascript and I have it disabled, shouldn't they tell me about it anyway?
  3. If the WMF wants to communicate with me, why don't they leave me a talk page message like everybody else? Why have multiple methods of communication to maintain and debug?
  4. If the WMF is going to put up a message box that looks like any standard alert anywhere else on OSes or the web, shouldn't it have a standard X in the upper right corner?
The only thing I can think of more useless than the welcome message would be having a sitenotice warning people about the welcome message. Wnt (talk) 12:16, 23 May 2016 (UTC)
  • Adding this to meta User/Global.js works, does anyone know if a meta gadget would be able to provide that (in lieu of having each person have to edit their .js file)? — xaosflux Talk 15:44, 25 May 2016 (UTC)

Gone, but like the cat in the hat, keeps coming back

To all of the above, I was about to say I haven't experienced the popup since I initially encountered them on each wiki. However....I just opened Commons to an image, and the minute I clicked on "Edit", the popup blocked my screen. Nothing really got rid of it until I accidentally clicked on switching to Visual editing. Then I had another popup telling me to click on an icon to get out of Visual editing. Except...there was no icon there. And I don't have noscript on that page. So, I finally shut down the window and came back in, and no popups. If I'm in Visual edit, I don't know what it's supposed to look like.

Get rid of this for everybody. It serves no useful purpose for potential editors. Anyone clicking on the Edit tab already knows they're editing, and they don't need a popup to input a separate step. So the question is...exactly what purpose does it serve? If one encounters popups on the internet, they're most likely tracking something. Is that the underlying purpose with this? Editing on Wikipedia should not require the user to keep clicking away popups just to edit. Clicking on the "Edit" tab should work. — Maile (talk) 13:18, 23 May 2016 (UTC)

Visual editor breaks reference popups

Hi! Idk if this is a bug or intended behavior, but after making and saving an edit using the visual editor, the popups to show footnote references don't show up any more... is this something wrong with my configuration, or a bug? Thanks! :) Goldenshimmer (talk) 01:37, 27 May 2016 (UTC)

Try doing a reload on the page. After doing a Save VE does not do a full reload of the page and this can mess with some scripts. I think this relates to T53565 and something to do with LivePreview. To work after a save scripts need to listen for some specific hook. I don't really know why they decided not to just reload the page after a save, but then there is a lot I don't understand about VE/parsoid. --Salix alba (talk): 06:41, 27 May 2016 (UTC)
Thanks :) Goldenshimmer (talk) 07:48, 27 May 2016 (UTC)

"What links here" query

I've moved this discussion here from VPR - it seems to be more relevant to this page. Previous discussion is between the lines:

When you check the "what links here" list for a page, you get all the pages which link to it in order of the pages' creation date. Is there any way to add an option button (or perhaps there's a script?) which will display all the linked pages in alphabetical order? Grutness...wha? 09:17, 21 May 2016 (UTC)

Support - would make life so much easier. DuncanHill (talk) 11:05, 25 May 2016 (UTC)
This is more of a WP:VPT issue than VPR; there may already be a script to do this. --Redrose64 (talk) 19:37, 25 May 2016 (UTC)
I'll move this discussion there. Grutness...wha? 01:37, 27 May 2016 (UTC)}}

Grutness, DuncanHill: You can add 

if ( mw.config.values.wgCanonicalSpecialPageName === 'Whatlinkshere' ) {
	$( function() {
		'use strict';
		var ul = $( '#mw-whatlinkshere-list' );
		ul.before( '<button id="whatlinksheresort">Sort</button>' );
		$( '#whatlinksheresort' ).click( function() {
			var li = ul.children( 'li' );
			li.detach().sort( function( a, b ) {
				return $( a ).find( 'a' ).first().text().localeCompare( $( b ).find( 'a' ).first().text() );
			} );
			ul.append( li );
		} );
	} );
}

to Special:MyPage/common.js. You can then style the button any way you want at Special:MyPage/common.css. Example: 

#whatlinksheresort {
	margin-left: 1em;
}

Nirmos (talk) 12:22, 27 May 2016 (UTC)

Oh, that's excellent! Thank you! Grutness...wha? 12:43, 27 May 2016 (UTC)

Page last modified footer MediaWiki:Lastmodified

  Resolved

I believe the interface page MediaWiki:Lastmodified (mw:MediaWiki:Lastmodified) is obsolete since MediaWiki 1.8 and should be deleted. The current phrasing of MediaWiki:Lastmodified does not match the footer text that appears on articles (missing the word "on") and I believe the current footer text is the default text from MediaWiki:Lastmodifiedat (mw:MediaWiki:Lastmodifiedat).

If it's unused, I intend to delete MediaWiki:Lastmodified to prevent confusion over the interface. Rather than being bold in this case, I wanted to ask people more familiar with the Mediawiki side of things if there's any reason it should still exist.

Just for completeness, there's also MediaWiki:Lastmodifiedatby (mw:MediaWiki:Lastmodifiedatby) and the obsolete since MW 1.8 MediaWiki:Lastmodifiedby (mw:MediaWiki:Lastmodifiedby). There also an unrelated mw:Extension:LastModified. Jason Quinn (talk) 19:36, 26 May 2016 (UTC)

@Jason Quinn: I checked over on test2wiki, the last modified displays with out it, and even putting nonsense in that field does not replace the footer. — xaosflux Talk 19:54, 26 May 2016 (UTC)
Interestingly, a long deleted version on test2wiki has a fundraising commercial in it! — xaosflux Talk 19:57, 26 May 2016 (UTC)
MediaWiki:Lastmodified is indeed unused and not listed at Special:AllMessages. https://en.wikipedia.org/wiki/Example?uselang=qqx confirms that MediaWiki:Lastmodifiedat is used. PrimeHunter (talk) 21:01, 26 May 2016 (UTC)

I deleted the page as non-controversial technical cleanup, leaving the talk page with an explaination and a link to this discussion. Marking as resolved. Jason Quinn (talk) 17:13, 27 May 2016 (UTC)

Tags for removal of PROD templates?

I posted this message at Wikipedia talk:Tags more than a month ago but have not received a response regarding this. I am perfectly aware that once PROD templates are removed in an article, unless it is a BLPPROD template, the tag should not be re-added. However, in most cases (at least ones that I have seen), there's no indication that an edit removed a PROD template as for whatever reason no edit summary was included. This is particularly the case for newly-created articles which are not appropriate for Wikipedia but do not fit into any of the speedy deletion criteria so are instead PRODded, then the PROD tags are removed by the article creator (frequently without an edit summary), and so sometimes these articles end up outstaying their welcome. Would it be possible to add a tag for PROD removal, much like how there's a tag for CSD, AFD, and BLPPROD template removal, if only for tracking purposes? As far as I know, reading through Wikipedia talk:Tags' archives, such a tag is supposed to exist but for whatever reason has not been implemented. Narutolovehinata5 tccsdnew 02:17, 27 May 2016 (UTC)

Watchlist the pages you PROD, it's that simple. Also NaruSaku 4eva. --QEDK (T ☕ C) 19:23, 27 May 2016 (UTC)

Mobile Wikipedia is totally broken right now

Using a phone, web Wikipedia, no app. In mobile view, you can no longer view notifications, edit pages, or watch pages. It is as if pages are half loaded. Not sure what could be causing this. Section headings are also no longer collapsed, the top left corner menu button doesn't work, and the banner at the bottom of pages which links to the page history isn't displaying properly. There is likely other things. I have only noticed this today. Assuming it will be fixed at some time. —DangerousJXD (talk) 02:02, 27 May 2016 (UTC)

Is anyone still experiencing this problem? Whatamidoing (WMF) (talk) 16:41, 27 May 2016 (UTC)
I saw this yesterday, somewhat later in the day, and it's working okay now on my iPad. Pleasant bonus, today I can switch between Desktop View and Mobile View without (usually) bringing up the app. Better control. Jim.henderson (talk) 22:37, 27 May 2016 (UTC)
The problems I described above appear to have been fixed. —DangerousJXD (talk) 00:18, 28 May 2016 (UTC)

Warning message when moving to a salted title?

Tracked in Phabricator
Task T85393

Am I losing it, or did there used to be a warning message appear when you tried to move a page to a salted title (similar to the message you get when you try to move a page to a title that already exists)? I've just tested at User:Jenks24/Test and User:Jenks24/Test2 and I didn't get any warning, the moves just went through straight away. If this was just a figment of my imagination, would it be at all possible to implement some sort warning message? As someone who often does a lot of page moves, I generally don't check each and every redlink title to see if they're salted. Jenks24 (talk) 21:17, 26 May 2016 (UTC)

This would be super helpful, especially with the advent of the extended-mover right. Writ Keeper ⚇♔ 21:34, 26 May 2016 (UTC)
Page movers will get an error that they can not move a page to a page that is protected against creation "You do not have permission to move this page, for the following reason: You cannot move a page to this location because the new title has been protected from creation.". — xaosflux Talk 03:19, 27 May 2016 (UTC)
Normally, yes, but in this case, Casliber originally placed the salt with "extended-confirmed" protection, rather than full-protection; this would've still allowed users, including extended movers, to move the page. The point I was making about extended mover specifically is more that, if such a thing were to happen again to someone with the extended-mover bit, and if people were to get angry about it, it'd be a rather unfair source of ammunition for the removal of said bit. Writ Keeper ⚇♔ 03:37, 27 May 2016 (UTC)
Which page are we talking about here? Cas Liber (talk · contribs) 04:08, 27 May 2016 (UTC)
The Battle of Fashion. Writ Keeper ⚇♔ 06:52, 27 May 2016 (UTC)
@Xaosflux: Yes, I'm talking about when the person making the move does have permission to move over a protected page (e.g. an admin over full protection, or in this case a page mover over extended confirmed). Would it be possible to create a warning message for these situations? Jenks24 (talk) 13:42, 27 May 2016 (UTC)
Anything should be possible :D It doesn't looks like we can do this locally, would require a software patch, so you will need to fill a phabricator request; if doing so suggest it includes multiple checks: (a)Move target was previously deleted (b)Move target has any type of create protection (c)Move target is on the title blacklist . — xaosflux Talk 13:49, 27 May 2016 (UTC)
phab:T85393 is related. — JJMC89 (T·C) 00:23, 28 May 2016 (UTC)

Preferences

Tracked in Phabricator
Task T136387

On IE v. 11 using Windows 10, I have lost several of my preferences, nor can I get to any but the first Preferences → User profile page. The other tabs show up as links, however when clicked, nothing happens. Examples of lost preferences are my time/purge link at the top right of the page is gone, I can no longer right click a lead section to edit, none of my edit page prefs are appearing and so on and so on. It's been like this most of the day (that I've noticed). Where have all the flowers gone, long time passing?  OUR Wikipedia (not "mine")! Paine  08:36, 27 May 2016 (UTC)

Does the second link of Preferences → Gadgets work for you? --Redrose64 (talk) 08:40, 27 May 2016 (UTC)
Hi, Redrose64! The Preferences → Gadgets second link just takes me to the top page, Preferences → User profile. [added:] I've tried logging out and logging back in, logging out, rebooting and logging back in, but nothing thus far has worked.  OUR Wikipedia (not "mine")! Paine  09:06, 27 May 2016 (UTC)
I just changed my password, and that didn't help either.  OUR Wikipedia (not "mine")! Paine  09:10, 27 May 2016 (UTC)
Preferences aren't only affected - many tools and options based on JavaScript don't function, like NavPopup, tools above/bellow edit field, many sysop's functions (some of which are enabled in Preferences), and many more... I've noticed this in "my nightly shift" on hr-wiki about 4AM CEST. Among IE, also have tried FF and classic view on mobile phone, with the same problem. --Bonč (talk) 09:13, 27 May 2016 (UTC)
I did a Java update today, I think it was 91, so that might be a clue.  OUR Wikipedia (not "mine")! Paine  09:16, 27 May 2016 (UTC)
Same problem for me using Pale Moon and Java 8u91 but all seems ok using Chrome on the same PC. Nthep (talk) 09:27, 27 May 2016 (UTC)
Me too. Gadgets and preferences are broken in Pale Moon 26.2.2, but work fine in M$ Edge. —Wasell(T) 09:32, 27 May 2016 (UTC)
I think that there's a general JavaScript problem, see for example DangerousJXD's thread Mobile Wikipedia is totally broken right now and Jared Preston's comment at Green "Highlighter" spewing across edit history unread sections. Why? above. --Redrose64 (talk) 09:34, 27 May 2016 (UTC)
It's a global problem, first spotted last night on hr-wiki, but also is true for other wikis (de, sr...). On some other sites (like JS examples on www.w3schools.com/) everything is OK. So, it's seems this problem is a result from new "fixing" in WM software. --Bonč (talk) 09:37, 27 May 2016 (UTC)
I meant "general" as in "affects all use of JavaScript within the Wikimedia sites", i.e. Wikipedia, Commons, Meta and so on. --Redrose64 (talk) 09:42, 27 May 2016 (UTC)
Coming to you from Firefox – when I first opened it the v. was 30, and it began to update to v. 46.0.1. At v. 30 the problems persisted; however, at v. 46.0.1 all is well and working properly. Checked Chrome and can confirm that it works as expected.  OUR Wikipedia (not "mine")! Paine  10:53, 27 May 2016 (UTC)
Just reported the IE11 incompatibility with Java 8u91 to Microsoft (endash) fingers crossed. OUR Wikipedia (not "mine")! Paine  11:15, 27 May 2016 (UTC).

This appears to be tracked in Phab T136387. —Wasell(T) 11:28, 27 May 2016 (UTC)

  • Same problems here. Cant even see the "show" link on the collapsed navigation templates. This is crazy. I cant hover over wikilinks and see any of the fancy stuff from where i usually reverted vandals. Twinkle options have also gone i guess.... §§Dharmadhyaksha§§ {Talk / Edits} 12:11, 27 May 2016 (UTC)
And now I can't even log in! (User:Wasell) --151.177.60.175 (talk) 12:27, 27 May 2016 (UTC)
Special:CentralAuth/Wasell currently displays: Exception encountered, of type "Exception". This indicates you are probably hit by the older phab:T119736. PrimeHunter (talk) 12:49, 27 May 2016 (UTC)
testwiki:Special:CentralAuth/Wasell indicates a problem at bewiki. Try if you can log in at be:Special:UserLogin. PrimeHunter (talk) 13:02, 27 May 2016 (UTC)
That worked lovely! Thanks! —Wasell(T) 13:13, 27 May 2016 (UTC)
  • This problem is not limited to IE11. I'm running IE10 under Windows 7 (blame my company's IT department!) and having the same problems: can't access other tabs on the Special:Preferences page, and my WP:Twinkle tools are gone. WikiDan61ChatMe!ReadMe!! 13:23, 27 May 2016 (UTC)
I should think the vandals are having a whale of a time today. CluebotNG has been down for about 18 hours, sTiki, LAVT and Twinkle are not working properly. Here, Twinkle won't even load now on Firefox 24, or IE 11, or Pale Moon 22, or an old version of SRware Iron (a Google Chrome clone). Neither will Popups, or the preferences tabs as noted above. Seems OK on the latest version of Firefox (43.0.1) that I've just loaded onto a laptop. Are we all suddenly expected to only use the latest browser versions? - I have good reasons for not doing so, and of course others don't get the option. This needs fixing! Smallerjim (talk) 13:52, 27 May 2016 (UTC) (aka User:Smalljim)

Problem appears to be fixed now. —Wasell(T) 15:19, 27 May 2016 (UTC)

Partly - things are loading now, but that rollback change is still extant and is still stopping Twinkle from working properly.  —SMALLJIM  15:24, 27 May 2016 (UTC)
This is entirely unrelated to the rollback change. The problematic deployment of CentralNotice changes was reverted. Matma Rex talk 15:37, 27 May 2016 (UTC)
Thanks for forcing this through, Matma Rex. It looks as if we can be hopeful that the change to rollback will be rolled back soon as well. Two separate, erm, unwelcome changes in 24 hours is a record, I think!  —SMALLJIM  15:59, 27 May 2016 (UTC)
I did not "force" anything, I had an obviously broken change reverted ("obviously" as in "syntax errors in JavaScript"). Like I said, that was not related to the rollback thing, and the reverts of them are similarly unrelated. Matma Rex talk 16:03, 27 May 2016 (UTC)
Well, thank you for that, you and all the devs who worked on this to fix things! All is back to normal, and I have no words to tell you how good that is!  OUR Wikipedia (not "mine")! Paine  01:26, 28 May 2016 (UTC)

Getting colour to display properly

Having an issue with the King's Park F.C. and it's one that has baffled me for several years. On the infobox why do the sleeves on the kit display as blue and white rather than claret and white? From what I can see the colour codes (don't know the proper name, sorry) are the same and yet they display differently.I'm sure it's something simple but this sort of thing is beyond me so if some nice person could fix it I would be grateful. As ever, apologies in advance if this is the wrong place but there are so many helpdesk type things on here now that I never know which is which any more! Keresaspa (talk) 00:44, 28 May 2016 (UTC)

The problem is in nested template {{Football kit}} - using _whitestripes breaks it - checking further. — xaosflux Talk 01:34, 28 May 2016 (UTC)
Oh, well, looks like you found it just as I was looking into it. Fixed. -- The Voidwalker Discuss 01:41, 28 May 2016 (UTC)
(edit conflict) @Keresaspa: the "pattern" actually a complete picture File:Kit left arm whitestripes.png, that is replacing the underlying color. You would need to make a new pattern and upload it. For additional help on that see Template talk:Football kit. (Looks like The Voidwalker already took care of it.) — xaosflux Talk 01:43, 28 May 2016 (UTC)
Thanks folks, looks great now :) Keresaspa (talk) 01:46, 28 May 2016 (UTC)

Problem staying logged in

Hi. I'm on Windows 10, MSIE11, all current updates applied. Set to accept cookies. I log in to Wikipedia and select "stay logged in for 30 days", but it only keeps me logged in in that browser window. If I open a link in a new tab or window, it thinks I'm not logged in. If I close the browser Window, it doesn't remember me any more. This problem is new today. Any ideas please? Thanks in advance. --Stfg (talk) 16:26, 27 May 2016 (UTC)

Have you tried allowing cookies for this site specifically, instead of just allowing cookies in general? http://www.technipages.com/wp-content/uploads/2014/07/IE-Per-Site-Cookies.png The Quixotic Potato (talk) 19:44, 27 May 2016 (UTC)
Yes, I've done that for wikipedia.org (and restarted, though I don't think that was necessary). The problem isn't happening on Chrome, only on IE. Another thing that's happening is that the next logged-in session doesn't remember that I've told the watchlist to hide the list of meetups. I strongly suspect that some malware has got in and has arranged for cookies to be deleted at end of session, but I've no idea how to track it down if so. --Stfg (talk) 21:04, 27 May 2016 (UTC)
I don't think it is very likely that malware is deleting your cookies, but you can download the free version of malwarebytes on malwarebytes.org and use it to scan your computer. Also make sure you have a virusscanner that is up to date, and use that to scan your computer too. But I strongly suspect that the problem is something else (but I don't know what). Do you have Norton Internet Security installed? Many people report that NIS can cause this problem. Have you tried to recreate the problem when starting IE with all addons disabled (Win+R to open the Run box, then type iexplore –extoff and click on OK.)? And have you tried clearing the cache and the cookies? The Quixotic Potato (talk) 21:28, 27 May 2016 (UTC)
Surely you've checked that IE is not deleting cookies on exit, haven't you? Tools > Internet options > General. If the box is ticked (checked), untick it. Akld guy (talk) 00:16, 28 May 2016 (UTC)
That wouldn't explain the behaviour the OP described ("If I open a link in a new tab or window, it thinks I'm not logged in.") but it is a good idea to check it. The Quixotic Potato (talk) 00:25, 28 May 2016 (UTC)
He/she also said, "If I close the browser Window, it doesn't remember me any more." which is the classic symptom of ticking the box. Akld guy (talk) 02:33, 28 May 2016 (UTC)
Thanks guys for spending your time on this. I do appreciate it. (I'm a he, by the way.) Yes, I did make sure that box (Delete browsing history on exit) is unchecked. It's certainly worth asking that sort of question, though. It would be silly to miss the solution by being too "polite" to ask if I had done something, however obvious.  
I've tried all the things that The Quixotic Potato suggested yesterday. Malwarebytes found a couple of PUPs, which it has deleted, but the problem persists. Running with add-ons disabled didn't change the situation. (I haven't recently acquired any new add-ons, unless something has found a way to hide.) I don't use Norton. My antivirus is Kaspersky Total Security 2016, and its up-to-date. In two full scans yesterday, it didn't see anything amiss. The problem of being forgotten when clicking a link in a new tab or window also occurs in YouTube (but strangely, it does not occur on my Open University login, which does recognise me after a shift-click).
Yesterday morning when I switched on, I noticed some strange behaviour which I tracked down to the FUvirus. I thought that by lunch time I had got rid of it, and no other strange behaviour has been repeated. What I fear may have happened is that the intruder may have managed to plant some code that overrides the setting that Akld guy asked me to check, and deletes cookies anyway. I've had both Kaspersky and malwarebytes scan the IExplore.exe file specifically, and neither sees anything to worry about. What do you think?
Thanks again. --Stfg (talk) 10:35, 28 May 2016 (UTC)

Main page optimisation

Just a quick question, sorry if it's not the right place, but what resolution are we aiming to have the main page optimised for (not the mobile variant, obviously). Thanks. The Rambling Man (talk) 19:58, 27 May 2016 (UTC)

Not the answer you want: all resolutions, see Responsive web design (but ensuring that it looks good on the most commonly used resolutions may be a good idea). The Quixotic Potato (talk) 21:30, 27 May 2016 (UTC)
Except that we don't use responsive web design on the main page. It uses a fixed table layout which doesn't change in any way (except that the mobile view excludes all content other than TFA and ITN, presumably for bandwidth reasons). For some time I've been meaning to propose that we use media queries to allow the featured picture to appear larger for people with large screens, but have never got around to it. — This, that and the other (talk) 06:29, 28 May 2016 (UTC)
The Rambling Man did use the word "aiming". I think almost everyone agrees that the current homepage is far from perfect. If you ever make that proposal, please think about Viewport Sized Typography. The Quixotic Potato (talk) 10:54, 28 May 2016 (UTC)
Actual answer: none. The main page is a dinosaur from web 1.0, where screensizes could only go up and mobile internet was still sience-fiction. I have been trying for three years to get us out of the stone age. -- [[User:Edokter]] {{talk}} 08:12, 28 May 2016 (UTC)
Pish, we're at least up to the bronze age. I actually kind of miss the stone age version, back when we were more concerned about information density than making things look pretty. —Cryptic 08:59, 28 May 2016 (UTC)

Redirect not listed in NewPages

Tracked in Phabricator
Task T136532

The redirect We Are the Luniz is not shown in the list of redirects created by MBisanz and the recreation of the deleted page is not shown in Special:RecentChangesLinked/Wikipedia:Articles for deletion/We Are the Luniz. GeoffreyT2000 (talk) 17:16, 28 May 2016 (UTC)

No longer getting indications of "Since your last visit" in edit histories

As someone who monitors hundreds if not thousands of articles, I rely on the green highlighting of the "new since your last visit" to show me how far back I should check the changes to an article. I find that highlighting is not there any more in my page view. Can someone please explain or repair this? Thanks. Please ping me as this page is fairly active and I may therefore miss replies. Softlavender (talk) 03:27, 29 May 2016 (UTC)

I saw them first appear just a couple days ago and now they're gone... didn't even know it was a possibility to have them. EvergreenFir (talk) Please {{re}} 04:42, 29 May 2016 (UTC)
@Softlavender: This in your CSS:
span.updatedmarker {
  color: black;
  background-color: #0f0;
}
should produce: updated since my last visit. But you should currently be seeing: updated since my last visit. The latter is set for the English Wikipedia in MediaWiki:Common.css. Are you seeing nothing at all now? PrimeHunter (talk) 10:25, 29 May 2016 (UTC)
I have from time immemorial seen the green highlighting, which I personally need. Now I do not see the green highlighting, only the words ("updated since your last visit"). Can someone explain to me how to fix it and get the green highlighting back, if it is an individual thing? Softlavender (talk) 11:15, 29 May 2016 (UTC)
@Softlavender: Save the above code in your CSS. PrimeHunter (talk) 11:26, 29 May 2016 (UTC)

Tool to close RMs

I was wondering if there's a tool to close requested moves (I think no), if there isn't, there's a job for coders with time on their hands. --QEDK (T ☕ C) 15:22, 27 May 2016 (UTC)

There isn't one, as far as I know. And I doubt one will be built to be honest because it will be largely pointless (like the current TFD closer) where it simply adds the templates to substitute in the closing without actually carrying out any of the actions required after the close (this is what makes the AFD script so great). Jenks24 (talk) 13:10, 29 May 2016 (UTC)
Actually, it should be possible to write a script that does most of the things listed in the closing instructions. I don't think we should try and get a script to do history merges or history swaps, but doing the actual page move, fixing any double redirects, updating free use rationales, and updating the category sort keys all sound like good candidates for automation. It wouldn't be the simplest script to write, but there are plenty of more complicated ones on Wikipedia already. — Mr. Stradivarius ♪ talk ♪ 14:37, 29 May 2016 (UTC)

Watchlist problem

The "mark all as read" button on my watchlist has gone (Windows 8.1, Firefox 46). It's still there on Commons. What's going on? BethNaught (talk) 19:15, 29 May 2016 (UTC)

I'm moving some watchlist styles around; hitting a snag, trying to fix. -- [[User:Edokter]] {{talk}} 19:22, 29 May 2016 (UTC)
Reverted. Please allow 5 minutes for the button to reappear. -- [[User:Edokter]] {{talk}} 19:42, 29 May 2016 (UTC)
It's now reappeared to me. BethNaught (talk) 19:44, 29 May 2016 (UTC)

Bold links in watchlist

Links in the watchlist such as User talk:Shhhhwwww!!‎ in mine next to a green bullet stay bold. GeoffreyT2000 (talk) 19:47, 29 May 2016 (UTC)

Here too. Bug in Gadgets/Resource Loader being stuck in some state, again. -- [[User:Edokter]] {{talk}} 21:36, 29 May 2016 (UTC)
It has happened before, but that was always fleeting. Now it seems to be there permanently until you click on the page concerned. I don't understand the whys and wherefores, and I don't really see any point in the bolding. In addition I find it aesthetically annoying and wish it gone. -- Ohc ¡digame! 08:19, 30 May 2016 (UTC)
@Edokter: try a whitespace change on the resources to trigger it perhaps ? —TheDJ (talk • contribs) 08:36, 30 May 2016 (UTC)
It seems to have cleared. -- [[User:Edokter]] {{talk}} 10:45, 30 May 2016 (UTC)

Tool is down

The ref refill tool is down since a day or two back. I am not sure if this is the correct forum for this request but if someone could take a look at what the problem is that would be appreciated. Or if someone could direct me to the user in charge of the tool. Thanks. [51]--BabbaQ (talk) 17:57, 29 May 2016 (UTC)

I can't help, but I tried to use it a couple days ago and it failed to work, so just corroborating your experience.--S Philbrick(Talk) 21:37, 29 May 2016 (UTC)
Could you provide steps to reproduce the problem? How to get to the "ref refill tool"? Thanks! --AKlapper (WMF) (talk) 08:44, 30 May 2016 (UTC)
WP:REFILL is hosted at toollabs:refill and Zhaofeng Li is the maintainer. I was able to use it without any problems. — JJMC89 (T·C) 10:06, 30 May 2016 (UTC)
@BabbaQ, Sphilbrick, AKlapper (WMF), and JJMC89: I'm the maintainer of the tool, and the problem has been fixed. Sorry for the interruption.   Zhaofeng Li talk (Please {{Ping}} when replying) 10:58, 30 May 2016 (UTC)
Thanks for the notice and, more importantly, thanks for the tool. I manually improve refs when there are a few needing improvement, but when there a lot, the tool is very helpful.--S Philbrick(Talk) 11:53, 30 May 2016 (UTC)

Font problem

I normally use Firefox (version 44) on Windows 7. I wanted to try Chrome. After installing Chrome, I had problems with fonts. Chrome would show an Arial font but instead of in regular, it was in italics. Many things at Wikipedia that had been normal were italicized. I replaced my Arial regular font and it fixed the problem.

However, I still have a problem. Article titles that should be normal are bold italics. Firefox shows the titles properly (although I had to make a long-standing setting change to force it to do so). AFAIK, nothing else in Windows itself is problematic, just Wikipedia, and thus far only article titles.

Is there anything I can do to fix this? Thanks.--Bbb23 (talk) 23:06, 29 May 2016 (UTC)

Possibly: Visit (URL) chrome://flags and enable "Disable DirectWrite". ref = www.youtube.com/watch?v=YkXd7lK8K7A Fred Gandt · talk · contribs 03:22, 30 May 2016 (UTC)
@Fred Gandt: Thanks. Unfortunately, that didn't work.--Bbb23 (talk) 12:19, 30 May 2016 (UTC)

Baffled by escaping characters in an SQL query

I'm trying to run some queries to track use of a particular set of DOI citations, using Quarry. The problem is that DOIs linked through a citation template are partly URLencoded, which means a lot of %3F and so on - and % is the normal SQL wildcard.

Searching for the unencoded form - '%dx.doi.org/10.1093/ref:odnb%' - gives me a few dozen entries, all of which are cases where the DOI is linked directly. The partly URLencoded form is %dx.doi.org/10.1093%2Fref%3Aodnb%2F%, and it seems like the escaped form for a SQL search would be either %dx.doi.org/10.1093[%]2Fref[%]3Aodnb[%]2F%, or '%dx.doi.org/10.1093!%2Fref!%3Aodnb!%2F%' ESCAPE '!' (explicitly calling an escape character). Both of these, however, don't work. It should be returning somewhere around four thousand results, and returns none at all. Any ideas where I'm going wrong? Andrew Gray (talk) 22:17, 29 May 2016 (UTC)

The %2F stuff is what you see in a link, but a slash (/) is stored in the external links table. Same for %3F and colon (:). I think you need to use / and : with no urlencoding. Johnuniq (talk) 22:51, 29 May 2016 (UTC)
That only produces a very small number of results, though. There should be about 4300 articles (everything using {{cite ODNB}} will generate these DOIs) but the non-encoded version gets about seventy or eighty, all from non-templated links. It seems there must be some distinction in the way they're stored, but I can't figure out what. Andrew Gray (talk) 22:55, 29 May 2016 (UTC)
Can you find an example of a link you want the query to list, but which is not? That is, please post a link to the article and the wikitext in that article which generates the link. Johnuniq (talk) 23:23, 29 May 2016 (UTC)
I imagine Alain de Lille would be one such article. There's a DOI in the ONDB ref. I notice in Andrew's escaped version, that the first forwardslash (between dx.doi.org and 10.1093) is not URL-encoded ... sadly my quarry queries are yet to be executed, so I don't know if this is material. --Tagishsimon (talk) 23:42, 29 May 2016 (UTC)
More ODNB DOIs than you can shake a stick at --Tagishsimon (talk) 01:00, 30 May 2016 (UTC)
And, fwiw I got to that by looking at format of EL_to values for the article Alain de Lille in query 10128 --Tagishsimon (talk) 01:03, 30 May 2016 (UTC)
You can use a regex with RLIKE to catch both the normal and URL-encoded versions in one query, using something like RLIKE '.*dx.doi.org/10.1093(/|%2F)ref(:|%3A)odnb(/|%2F).*'. There's a demo query for Alain de Lille using this syntax at query 10132. — Mr. Stradivarius ♪ talk ♪ 01:10, 30 May 2016 (UTC)
Also, performance-wise I am guessing that it would help to anchor the regex to the start of the string, like ^(https?:)?//dx.doi.org/10.1093(/|%2F)ref(:|%3A)odnb(/|%2F).*. — Mr. Stradivarius ♪ talk ♪ 01:16, 30 May 2016 (UTC)
This is amazing - thanks all. So it looks like the database stores the slash encoded but the colon unencoded. Odd! Andrew Gray (talk) 14:27, 30 May 2016 (UTC)

TOC limit overide

Is there a way to set my settings so that limits on Table of Contents (TOC) can be overridden? I find a number of articles where the TOC has been manually limited, and sometimes I've had issues with over-protective editors complaining that the TOC is too long when I remove the limit. (The last "discussion" I had on this issue was a disaster, so I'd prefer some individual setting.) I prefer to see the full contents listed, but I don't know of any way to expand a limited (not hidden) TOC, either through my settings or an individual page. - BilCat (talk) 01:11, 30 May 2016 (UTC)

Assuming there is no built in way, it can (I have no doubt) be done by user script or user CSS. Will you provide an example page where the TOC is limited, so I can see the code? Fred Gandt · talk · contribs 03:14, 30 May 2016 (UTC)
It's usually done by a template like {{TOC limit}}, on e.g. Audi. If you add the following CSS to your common.css then it will always show all of the TOC levels:
/* Always show all TOC levels */
.toclimit-2 .toclevel-1 ul,
.toclimit-3 .toclevel-2 ul,
.toclimit-4 .toclevel-3 ul,
.toclimit-5 .toclevel-4 ul,
.toclimit-6 .toclevel-5 ul,
.toclimit-7 .toclevel-6 ul {
	display: block;
}
Hope this helps. — Mr. Stradivarius ♪ talk ♪ 03:32, 30 May 2016 (UTC)
Thank you both. I'm may be inactive for a few days because of a family illness, but I'll will check this out in a few days when I can. Thanks again. - BilCat (talk) 12:14, 30 May 2016 (UTC)
Thanks Mr. Stradivarius, I've tried it, and works. - BilCat (talk) 14:55, 30 May 2016 (UTC)

Tech News: 2016-22

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

Recent changes

  •   There is now a standard way to get the target of a redirect page from a Lua module. [52]

Problems

  • A new way to handle rollback was introduced. It broke some tools and scripts and was reverted. This will be re-planned after review. [53][54]
  • CentralNotice didn't work in some older browsers. This has now been fixed. [55]

Changes this week

  • When you edit a file or category page with the visual editor the rest of the page will be shown in its normal place. [56]
  • The Translate extension will get an edit summary field. [57]
  • A change to the <charinsert> feature could break some user scripts. Contact Bawolff if the "click to insert special characters" links in the edit window break on your wiki. [58][59]
  • Elasticsearch will be upgraded on Wikimedia wikis this week. This should not affect you, but if you have problems with the search function this is probably the reason. [60]
  •   The new version of MediaWiki will be on test wikis and MediaWiki.org from 31 May. It will be on non-Wikipedia wikis and some Wikipedias from 1 June. It will be on all wikis from 2 June (calendar).

Meetings

  •   You can join the next meeting with the VisualEditor team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on 31 May at 19:00 (UTC). See how to join.

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

16:18, 30 May 2016 (UTC)

Cluebot NG is still down since rollback change

A discussion was happening at User talk:ClueBot Commons/Archives/2016/May#Your bot may need to be restarted. Other than Rich, who looks to be investigating, is anyone else able to assist with the problem? — Andy W. (talk · ctb) 04:19, 30 May 2016 (UTC)

@Andy M. Wang: ClueBot NG is back up and running again. —MRD2014 (formerly Qpalzmmzlapq) T C 17:38, 30 May 2016 (UTC)

Not able to edit

@Bishonen reported on IRC that she can't edit anything in the past hours (seems like T134869, but more severe: appears not periodically but continuously). I don't know much about it, just she asked me to report it. --Tacsipacsi (talk) 12:45, 15 May 2016 (UTC)

Thanks, Tacsipacsi. I've realized I can in fact edit after a fashion using Chrome. But I really really don't want to. In Firefox it's impossible. I have the latest version of Firefox for OSX, and it can neither preview nor save since at least seven hours. All I get when I try is the "Secure Connection Failed" message. Does the phabricator report mean I can look forward to the problem being fixed? Anybody got any idea of the timescale for that? How long a wikibreak should I take? :-( User:RexxS, you got anything? Bishonen | talk 14:15, 15 May 2016 (UTC).
This is a shot in the dark and probably not related, but are you using Avast Antivirus? I had an issue with HTTPS content not loading properly on Wikipedia that was fixed by disabling HTTPS scanning in Avast. clpo13(talk) 16:05, 15 May 2016 (UTC)
Not using it, no. But thanks. Bishonen | talk 16:31, 15 May 2016 (UTC).
@Bishonen: All of the other reports I've been able to track down associate the problem with Firefox version 46 (which was originally released on 3 May 2016 and my version is currently at 46.0.1). I'm currently using Chrome this month as part of my usual anti-checkuser strategy, but I'll get Famously Sharp to attempt a post on your user talk. Hmmz - it works. Ok - only suggestion I can make is for you to try Firefox version 47 which is in Beta - download from https://www.mozilla.org/en-US/firefox/beta/all/ (the OSX version is in blue in the middle column). --RexxS (talk) 19:42, 15 May 2016 (UTC)
  • Bishonen, have you tried reloading the page? These past few days, I have randomly got a Firefox error message about the connection being insecure, but reloading the page always solves the problem. --Stefan2 (talk) 20:41, 15 May 2016 (UTC)
  • Many times, but it didn't help. But actually it has just started working quite smoothly! Long may it last. I don't see myself as a Beta user, much. Bishonen | talk 20:48, 15 May 2016 (UTC).
  • Whatamidoing (WMF), thanks for the reply. When it happens a notice appears saying "try again," so I have to click on that, then a second notice appears, which I think says "resend," and I have to click on that too. Then the edit is saved or the preview viewable, whichever it was. SarahSV (talk) 06:14, 19 May 2016 (UTC)
  • I've been having this problem off and on as well; unlike Bishonen it's not consistent, but rather happens randomly about every tenth time I try to save an edit. I am running Avast, but I've already turned off https scanning as directed when I first Googled to solve the problem — but even with that turned off, the problem still recurs. It appears to interfere more actively with using Twinkle than with conventional editing — for the XFD module in particular I almost always have to undertake a second attempt because the first one fails under an unspecified error message, which I'm presuming is related to this "secure connection issue" because if everybody were having as many Twinkle failures as I've been having, Twinkle's talk page would be flooded with requests. But it's not, which means this is pretty clearly a "just happening to me" problem. Bearcat (talk) 19:56, 23 May 2016 (UTC)
    • I have also been having the issue similar to Bearcat (though probably less severe, and not particularly with AfD) – is there a Phab job on this? Or is no one working on it at all?... --IJBall (contribs • talk) 02:25, 27 May 2016 (UTC)
      • Firefox 46.0.1 here. Had "Secure Connection Failed" problem months ago, and it stopped. Now it's doing this again. I've had this happen several times today. — Maile (talk) 23:58, 30 May 2016 (UTC)

Category:Former monarchies

Hi, Anybody know how to move the last (alphabetically) members of Category:Former monarchies (i.e. Bidar Sultanate and Đinh dynasty) into there correct alphabetical position ? Thanks GrahamHardy (talk) 17:33, 30 May 2016 (UTC)

That's definitely strange. I tried adding {{DEFAULTSORT}} to Bidar Sultanate, but that didn't help, and Đinh dynasty already has one, but it seems to be ignored. nyuszika7h (talk) 17:43, 30 May 2016 (UTC)
I don't have time to investigate further, but I think {{Infobox former country}} is the one to blame for that. --Edgars2007 (talk/contribs) 17:52, 30 May 2016 (UTC)
Right, common_name is required in {{Infobox former country}} and used for category sorting. Fixed in [61] and [62]. It would maybe be better to code the infobox to use {{PAGENAME}} as default but it wouldn't have solved Đ versus D. Do we have a feature to convert letters in a string to similar Latin letters like Đ to D? PrimeHunter (talk) 18:33, 30 May 2016 (UTC)
Do we need it? See Wikipedia talk:Categorization#OK to switch English Wikipedia's category collation to uca-default?, which should take care of that problem, I think. --Izno (talk) 23:58, 30 May 2016 (UTC)
Nice. I guess we don't need it for category sorting then. It might be used in certain external link templates to automatically convert a title to a url if no url parameter is given, but there are few sites where it would be relevant and if the feature exists then editors may fail to check that the conversion produces a working link. PrimeHunter (talk) 03:03, 31 May 2016 (UTC)

Problem with previewing with the API

I have some code at User:Dudemanfellabra/AssessNRHP.js that I've recently expanded to include a preview function by using the API's "parse" capability. I am and have been able to load the parsed HTML of an existing page rather easily using "action=query&prop=revisions&rvprop=content&rvparse=true", but part of the code I'm writing allows the user to modify a page's wikitext (specifically an infobox) and preview the result. To generate the HTML preview, I use "action=parse&text=..." since the wikitext is not saved anywhere before previewing.

A problem arises for large pages, though, since the URL includes the entire wikitext of the preview, and so in some (all? I'm using Firefox) browsers, an error is thrown. Is it possible to generate a parsed preview of some wikitext without having to include the entire text in the URL?--Dudemanfellabra (talk) 23:26, 30 May 2016 (UTC)

@Dudemanfellabra: This should be possible by using an HTTP POST request instead of HTTP GET (which is the default for $.ajax). Data gets appended to the URL in GET requests but not in POST requests. The following code is untested on any actual long pages, but should do what you need:
var api = new mw.Api();
api.post( {
    action: "parse",
    format: "json",
    contentmodel: "wikitext",
    text: pagetext
} ).done( function ( data ) {
    console.log( data.parse.text['*'] );
} );
Best — Mr. Stradivarius ♪ talk ♪ 04:33, 31 May 2016 (UTC)
Also, the docs for mw.Api are here. Or you could use the "method" parameter in $.ajax (docs). — Mr. Stradivarius ♪ talk ♪ 04:35, 31 May 2016 (UTC)
Thanks for that! I just added "method: 'POST'" to the ajax call (which I wasn't aware of), tested it on a long page, and it worked! I'll keep mw.Api in my back pocket for next time. Thanks again!--Dudemanfellabra (talk) 04:46, 31 May 2016 (UTC)

Having issues with the search function

What were you expecting and what was the actual result of your action?
When I click the search bar, I should be able to type my query in, press the ↵ Enter key and be whisked away like normal. What ended up happening was when I am in the process of typing something in the search bar the cursor sometimes disappears completely, not allowing me to type until I click it again. When clicking on a link that is auto-suggested by search, it should lead me to the link. Instead, it leads me to a blank search results page.
Where did you encounter the problem?
I've had this problem with search for a while (can't remember how long though) and it drives me nuts when it doesn't act normally.
What browser and what version of your browser are you using?
I am using Google Chrome 51. In case it is needed, I have a Windows 10 desktop computer.

Thanks in advance! Best wishes,
TheFallenOneGOTH (Talk) 00:18, 31 May 2016 (UTC)

Check if you have any browser extensions enabled. These things tend to interfere at times with your normal browsing experience. —TheDJ (talk • contribs) 08:09, 31 May 2016 (UTC)

Signature question

I'm wondering if anyone would mind taking a look at User talk:LeonRaper#Signature help etc and see if there's a technical issue with the way this user is signing his posts. I understand there is quite a bit of user error, etc. involved, but I am curious if the editor's settings somehow got accidentally tweaked which is causing his signature not to display properly even when he correctly uses the 4 tilde. Thanks in advance. -- Marchjuly (talk) 02:28, 31 May 2016 (UTC)

That use has been indefinitely blocked since 17MAY. The user would have to fix or reset their signature in Special:Preferences if they return. — xaosflux Talk 03:29, 31 May 2016 (UTC)
Thanks for the response Xaosflux. I understand the user is blocked, but I was just wondering if his problem was more technical or more user error. Also, I didn't know that blocked editors were unable to edit their preferences. Anyway, I'll pass that information along. -- Marchjuly (talk) 05:42, 31 May 2016 (UTC)
From what I can see it is purely user error. FWIW, the "default" signature option is to leave the box blank, and not have the checkbox checked. — xaosflux Talk 11:36, 31 May 2016 (UTC)

Highlight of "updated since my last visit"

In page histories the phrase "updated since my last visit" is now highlighted, annoyingly, in a bright green background. Is this just me? Is it intentional? If so, was this ever discussed here? If so, how to turn this off in my personal CSS? ―Mandruss ☎ 21:28, 26 May 2016 (UTC)

I tried what seemed like the logical CSS thing and it caused a style flash and then the bright green comes back aaaaaaaah make it stop before my retinas burn off. Opabinia regalis (talk) 22:14, 26 May 2016 (UTC)
+1 - Why the bloody hell make it bright green ? ... It sure as shit gets your attention and quite frankly I'd rather it didn't. –Davey2010Talk 22:23, 26 May 2016 (UTC)
Mandruss and Davey2010, this has existed for a while now. I've been receiving this notification/phrase when I get beaten to a revert, more often than not. It's not new - the colour may have changed, perhaps, but then I can't see certain shades due to my eyesight. Do let me know if that is the case here! Regards --PatientZero talk 16:41, 27 May 2016 (UTC)
It was only the text colour that was green never the background (which is the case now), Cheers, –Davey2010Talk 17:35, 27 May 2016 (UTC)
The problem was the bright green background, which has now been corrected (see below). It existed for well under 24 hours, so you may have missed it. ―Mandruss ☎ 16:45, 27 May 2016 (UTC)
Thanks for the pointer Mandruss and for explaining that you were indeed talking about the colours. I think I did miss it, thankfully. --PatientZero talk 16:49, 27 May 2016 (UTC)
The styling of updatedmarker was changed at phab:T134515. I think it looks horrible. MediaWiki:Common.css already says:
.updatedmarker {
    background-color: transparent;
    color: #006400;
}
It appears we now need !important to override the default. I suggest we add that:
span.updatedmarker {
    background-color: transparent;
    color: #006400;
}
This also works in your CSS. PrimeHunter (talk) 22:30, 26 May 2016 (UTC)
The obvious design here is to eliminate those messages and draw a horizontal line above which all edits are "new". Not obvious to those who control the design, apparently, so I'll settle for a return to something at least less intrusive. ―Mandruss ☎ 22:41, 26 May 2016 (UTC)
No important needed (it hardly ever is), just use the same selector. —TheDJ (talk • contribs) 23:06, 26 May 2016 (UTC)
@Mandruss: You can put this in your common.js to do that (unfortunately :last-of-type does not work on classes so it cannot be done with CSS):
$('.mw-history-line-updated').last().append('<hr />');
$('.updatedmarker').hide();
– nyuszika7h (talk) 14:47, 31 May 2016 (UTC)
Thanks for the thought. I'm just as interested in the community benefit as in my own. And the more we customize our own individual wiki-worlds, the less effectively we can communicate, help one another, and make collective decisions as to the user interface. I believe in minimizing personal customization (especially that not supported in Preferences) and implementing good design site-wide. ―Mandruss ☎ 15:07, 31 May 2016 (UTC)

Green "Highlighter" spewing across edit history unread sections. Why?

This changed during my night, and now when I look at a page's edit history, all I can see is bright pukey green highlighter where there used to be a soothing green emphasis in text colour only. This is not an improvement to the project. I've messed around in my preferences, but I have no idea how to turn it back, and thus reduce my migraine. Any ideas? -Roxy the dog™ woof 07:41, 27 May 2016 (UTC)

You're not the only one. The same thing happened to me last night already, and this morning I have more problems - including search box not working and javascript problems on Wikidata. A mouse must have gotten into the works! Oh, and I've just noticed other script errors under the edit box here. Either it's a Wikimedia problem, or our browsers I guess (I predict the former)! Jared Preston (talk) 07:50, 27 May 2016 (UTC)
Thanks to RedRose for moving my query to the correct place. Note to self - "read the page first." Unfortunately, the solutions proposed above are written in gobbledegook, a language I don't speak. When the scriptkiddies above have a solution, could they please explain it in english here, preferably highlighted in green? Thanks. -Roxy the dog™ woof 09:07, 27 May 2016 (UTC)
@Roxy the dog: I can put in a CSS rule for you, but I need to know which skin you use - at Preferences → Appearance, in the first large box, which of the four is currently selected? --Redrose64 (talk) 09:39, 27 May 2016 (UTC)
Vector. I have no custom CSS. and Thanks. -Roxy the dog™ woof 09:45, 27 May 2016 (UTC)
I created User:Roxy the dog/vector.css, you may need to WP:BYPASS your cache to see a difference. --Redrose64 (talk) 10:28, 27 May 2016 (UTC)
I have updated MediaWiki:Common.css with .span.[63] This returns the former behaviour for me. PrimeHunter (talk) 10:31, 27 May 2016 (UTC)
My eyes are grateful. -Roxy the dog™ woof 11:02, 27 May 2016 (UTC)
PrimeHunter - I bloody love you!! - Thank you! –Davey2010Talk 17:35, 27 May 2016 (UTC)

I'm used to seeing different styles, since most of the large wikis have different colors. I do miss the green dots from enwiki when I'm elsewhere. But I want something that doesn't exist anywhere: a little button that always gives me the diff of all the changes since my last visit, without needing to scroll down and find the (cur) to click on. In fact, if visiting any page would automagically first check whether the page is on my watchlist and, if so, show me any changes since my last visit, that would be ideal. WhatamIdoing (talk) 16:36, 27 May 2016 (UTC)

Spacing Issues in Infobox

I am new to template creation and I have a few quirky formatting issues in the Template:Infobox_gene that I was hoping to get help fixing. On my talk page User_talk:Julialturner you can see the newest version of the Template:Infobox_gene. If you look at the first gene "RELIN" you will notice under the "Genetically Related Diseases" section the references (ie [1] [2]) align to the center instead of the top like the name of the disease. This has something to do with the fact that it can be a collapsible list in this section. You can see it happening again in the "Orthologs" section ("5649" and "19699" are centered). The other issue can be seen in the "endothelin receptor type B" gene box under the "Orthologs">"RefSeq (mRNA)" those ids that are displayed are bolded and it would be nice if they weren't. If you have suggestions how to fix these or where to look I would greatly appreciate the help. Thanks Julialturner (talk) 20:43, 31 May 2016 (UTC)

Bottom of VPT is fucked up

The last three threads are all showing up on one line. Could someone fix the page? Thanks :) Goldenshimmer (talk) 04:17, 1 June 2016 (UTC) (It should be evident from my post contents why I'm posting in the wrong part of the page.)

Done. Writ Keeper ⚇♔ 04:42, 1 June 2016 (UTC)
Sweet, thanks @Writ Keeper:. :) (Should I move this to the bottom where it belongs chronologically now?) Goldenshimmer (talk) 04:52, 1 June 2016 (UTC)
I'm going to bed now so I'm gonna be bold and put this section where I think it goes. If that's a problem, feel free to revert. :) Goldenshimmer (talk) 07:02, 1 June 2016 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)/Archive_146&oldid=1090590261"