Wikipedia:Village pump (technical)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

The technical section of the village pump is used to discuss technical issues about Wikipedia. Bug reports and feature requests should be made in Phabricator (see how to report a bug). Bugs with security implications should be reported differently (see how to report security bugs).

Newcomers to the technical village pump are encouraged to read these guidelines prior to posting here. If you want to report a JavaScript error, please, follow this guideline. Questions about MediaWiki in general should be posted at the MediaWiki support desk.

« Archives, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215

Save changes buttons - accessibility

At some point between 23:23 and 23:34, 18 July 2017 (UTC), the edit interface has changed. Is it Thursday already? I notice that the buttons at the bottom (Save changes, etc.) have changed, are bigger and less readable: there's a contrast problem. Accessibility is something to be careful of. --Redrose64 🌹 (talk) 23:57, 18 July 2017 (UTC)

+1 I am not entirely sure what was wrong with the old version either, and it is certainly not yet Thursday. ^_^ Double sharp (talk) 00:00, 19 July 2017 (UTC)

They've been dutifully warning us of the buttons' fuglification for weeks, including that there's no practical way to repair them with user css. I'd have complained earlier, but of course it would've done no good. —Cryptic 00:07, 19 July 2017 (UTC)

Redrose, accessibility for people with low vision is one of the main points. The contrast has been dutifully checked (several times by now, at least for Vector) and easily clears all of the standards.

Note that this is more than an aesthetic change, so a few old editing scripts may also break. See mw:Contributors/Projects/Accessible editing buttons for information on how to fix anything that's broken.

(P.S. It's a config change, which means it can descend on you on any day of the week. ;-) So far, it's only reached the Wikipedias and Meta. Other wikis will happen in a couple of weeks.) Whatamidoing (WMF) (talk) 01:20, 19 July 2017 (UTC)

They look perfectly fine to me. I don't see where any potential readability issues would come from even for those with eyesight issues. They're compliant. Amaury (talk | contribs) 01:27, 19 July 2017 (UTC)

Whatamidoing (WMF), could you please explain how making various interface elements exceedingly disproportional (like buttons being about 4 times bigger than hyperlinks) improves accessibility? If you care so much about these people (by the way, what is their fraction among the editors?), then maybe it would be better to make a special "accessible" style for them, with everything large and contrast? I can tell about my own experience with "accessibility": when I need to use a website with small fonts, I just press Ctrl++, and my browser magnifies everything proportionally. If I would do that with the current WP design, these ugly buttons will take half of the screen, actually decreasing the usability. And I also wonder very much: how artificially limiting the summary line to 80% of the width is supposed to help people with low vision? — Mikhail Ryazanov (talk) 09:46, 19 July 2017 (UTC)

The intention, at least as stated in prior posts here, was to improve accessibility for readers using the desktop version on mobile devices. Never mind that this affects editors, not readers, and significantly degrades the desktop version on the desktop. —Cryptic 16:50, 19 July 2017 (UTC)

Not just mobile devices. Touch devices. This includes things like Windows Surface laptops for instance. —TheDJ (talk • contribs) 18:49, 19 July 2017 (UTC)

I thought that all modern OSs have user preferences for sizes and colors, such that any interface built from standard elements will have a comfortable look and feel. Am I wrong? I do not have much experience with touch devices (believing that text editing on a keyboardless device is a bad idea), but how can it be that these users can tap hyperlinks, but cannot tap standard buttons (which are usually about twice bigger)? And again, how reducing the summary width to 80% helps them? Especially considering the problems (discussed below) with its wrong alignment and an overlapping counter. — Mikhail Ryazanov (talk) 22:57, 19 July 2017 (UTC)

Web pages cannot access OS user preferences (it would be a leak of privacy if they could), nor directly use the user interface elements provided by the OS (they use the user interface elements provided by the web browser, which may or may not resemble those natively provided by the OS). isaacl (talk) 23:54, 19 July 2017 (UTC)

Web pages do not need to access OS user preferences because the browser itself should. In any case, browsers have user preferences for default colors, fonts, and overall magnification. — Mikhail Ryazanov (talk) 04:42, 20 July 2017 (UTC)

Sure, the browser could retrieve and expose this data to web servers, but I don't believe there's currently a mechanism for web servers to retrieve this info from web browsers, and it would still be a potential privacy issue. There are defaults for colours and fonts, but not size information for user interface elements. Most users, though, appreciate greater variety in the web sites they visit, and would not want all of them to use only the default background and text colour. Even just considering the implications on a single site, visual elements such as side bars would blend into the main text flow without a distinguishing background colour. isaacl (talk) 18:31, 21 July 2017 (UTC)

Browser do not need to expose these preferences to web servers, they use them locally for rendering pages. If you have no idea how it works, please see [1], [2], [3], [4].

A variety in the web sites is fine, but kind of interferes with the accessibility, which was the declared reason for the changes we discuss here. And I still assert that neglecting user's setting actually does not "improve accessibility". — Mikhail Ryazanov (talk) 10:02, 24 July 2017 (UTC)

Thanks; I am familiar with how the default settings work. I was only responding to your original post regarding using the OS user preferences. Sure, it's possible to go back to the late 1990s look, with the web site using only defaults, and a single flow of content such as seen on many sites that are designed with mobile devices in mind as the primary viewing experience. But it's unlikely for any highly popular site such as Wikipedia to drop all styling, and in particular judicious use of background and foreground colours. For better or worse, most readers today expect both accessibility features to be respected and an engaging site design. Specifically regarding buttons: the key problem is that browsers don't offer good customization options to tailor their accessibility, and there is uneven support in adjusting their appearance via CSS. Accordingly sites will substitute their own button elements for the default ones. It's not a perfect solution, but it's what we have available. isaacl (talk) 16:29, 24 July 2017 (UTC)

Mikhail, the use of 80% width on the edit summary box has nothing to do with this change. It's been like that for years (possibly since the creation of the MonoBook skin). However, the team can change it, and if people don't like the result, then they can complain. Whatamidoing (WMF) (talk) 17:37, 24 July 2017 (UTC)

Yes, they have tried their best to impede user's CSS. I have added to my common.js some code to remove the offending classes:

// remove ugly styles from buttons:
$(".oo-ui-buttonInputWidget").removeClass("oo-ui-buttonInputWidget")
$(".oo-ui-buttonElement-button").removeClass("oo-ui-buttonElement-button")
// and checkboxes:
$(".oo-ui-checkboxInputWidget").removeClass("oo-ui-checkboxInputWidget")
// remove inflated field margins:
$(".oo-ui-fieldLayout-header").removeClass("oo-ui-fieldLayout-header")

This seems to help against the most evil stuff, at least so far... — Mikhail Ryazanov (talk) 09:31, 19 July 2017 (UTC)

What a relief! The awful new buttons couldn't be styled by CSS (by me at any rate), but this returns them to a usable legible state. And fixes my widgets too. Lithopsian (talk) 14:02, 19 July 2017 (UTC)

I regret that I have but one thanks button to click for this edit. A css solution would be better - removing the classes in javascript still shows the irritatingly immense buttons briefly until the page finishes loading - but this is still a huge improvement. —Cryptic 16:50, 19 July 2017 (UTC)

@Cryptic: Since they are classes, you can redefine them using user CSS. For example, I have changed the color. If you want to have boring grey buttons again, you can use

.oo-ui-buttonElement-button {
border: 1px solid black !important; 
background-image: linear-gradient(to bottom,#eee,#eee 100%) !important;
border-radius: 0 !important;
padding: 0.5rem !important;
transition: none !important;
}

for example. Regards SoWhy 12:29, 20 July 2017 (UTC)

Is there a CSS style that is just "look like a button, like all the other buttons - eg 'Go' and 'Search' in Monobook"? Mitch Ames (talk) 11:28, 24 July 2017 (UTC)

I just took a screenshot at File:Save_dialog_Wiki.jpg (FF 52.0.2, Windows desktop, Vector skin). Maybe that helps a bit to find remaining problems and script incompatibilites (obviously the buttons need fixing, and the "edit summary" field is cut by 1-2 pixels on the left side). GermanJoe (talk) 02:45, 19 July 2017 (UTC)

wikEd is making it's own style modifications. It will need an update. —TheDJ (talk • contribs) 07:17, 19 July 2017 (UTC)

I think they're awful – unattractive and huge, but I am more concerned with the fact that I no longer have any ability to leave an edit summary. Gone. The field is not even presented to me. I do/did have my interface tweaked to get rid of the gallons of material at the bottom of the page, and order it better. I'm assuming that is the issue. Can anyone advise if there's any way to tweak my customization or can identify the issue between my common.js and my my common.css?--Fuhghettaboutit (talk) 12:03, 19 July 2017 (UTC)

@Fuhghettaboutit: Eh, yeah you are doing some very uncommon manipulations there with both JS and CSS on your editOptions. If you want to hide something, you should always target as narrow as possible, not go high level and then selectively move things out of it with JS... —TheDJ (talk • contribs) 15:37, 19 July 2017 (UTC)

• Any chance we have a preference like with VE ?, My main dislike is the huge blue button as well as the rather big tick (image) - Wouldn't be so bad if it was smaller, ofcourse I realise it's been designed for people with eyesight issues however without being disrespectful we're not all blind so surely there should've been common ground in terms of the design ?,

It pleases those with eyesight issues (which is absolutely great) but it pisses those off that don't have eyesight issues (FWIW I am short sighted and do wear glasses however the previous design was never an issue),

If we could have a preference option like with VE that'd be great - I know we can't please everyone I understand that but atleast to me the big blue button/tick is rather extreme... –Davey2010^Talk 16:41, 19 July 2017 (UTC)

Davey, I know it seems like a pretty big visual change, but my bet is that if you wait a couple of weeks, you won't notice it as much any longer. Most people adapt to visual changes pretty quickly. Also, since most of us here are experienced editors, most of us don't really look at the buttons much anyway: It's just Tab ↹ to the edit summary box, type the edit summary, and Return to save the page. The buttons don't even need to be above the scroll.

We made this change at half a dozen big wikis two weeks ago. There were a few comments about the size and color there on the first couple of days, but I've seen nothing about it since then. Whatamidoing (WMF) (talk) 20:04, 19 July 2017 (UTC)

Ah see I don't do that - I usually hit any part of the scrollbar thus making it "ping" to any place - I then type whatever or use the arrow keys for autofil and then hit return,

Ofcourse I mean changes happen everywhere and not all are liked but we live with it but usually if something changes to my dislike I'll "dislike it but live with it" but here and I hate to be a little drama-queen but I actually hate it, The button is "too in your face" if that makes sense, I love the colour Blue always have so I love the colour choice here no problem but the button and tick are too big,

It would've been better to have it the same size as the previous and perhaps have implemented a tool where it could be made bigger in preferences or something, But I suppose it all goes back to "you can't please everyone",

Ah well it's changed and I guess there's nothing I can do except look in anger! , –Davey2010^Talk 20:37, 19 July 2017 (UTC)

Is this why the button is green?— Vchimpanzee • talk • contributions • 20:52, 20 July 2017 (UTC)

Show changes clicks Editing help on Android

Tracked in Phabricator
Task T171495

On Google Android phone (Google Chrome) browser, the new oversize "Show changes" (button 3) clicks into "Editing help" (cheatsheet link) which is very bizarre because no "Cheat" buttons onscreen, and "Show changes" really should show changes on mobile phone edits (which are hard enough already). This glitch shows the horrors of user-hinterface experiments which can hinder simple processing, as the inverse consequence of wanting a modest improvement in user interfaces. "Kids don't do this: never move the brake pedal, gas petal or steering wheel while a car is being driven". We need an essay, "wp:Computer Screwups 101" to remind people to use alpha/beta testing steps on crucial user-interfaces, where experimental glitches can have horrific impacts (over 20,000 mobile phone edits per month). -Wikid77 (talk) 08:32, 20 July 2017 (UTC)

This report misses critical information. which page, which editor, which skin, which android device, which version of google chrome, did you test with disabling all your gadgets and userscripts ? How to report bugs effectively —TheDJ (talk • contribs) 07:05, 21 July 2017 (UTC)

It happens on any page (wikitext editor) in Vector skin (Monobook skin ok) while suppressing License blurb, but when logged out then "Show changes" clicks Show preview, on Android phone LG Escape2, version 5.1.1. To avoid preview horrors, the Monobook skin can be used (which shows avocado " Save_changes " rather than Vector blue  Save changes ). -Wikid77 (talk) 06:08, 24 July 2017 (UTC)

New Edit summary window

The redesigned Edit summary window has the text left-anchored, with the result that most of the time you can't see what you're typing because it's off the right-hand end of the window (on an ordinary 13" laptop). Can that really be what the designers wanted to achieve? The remaining-character count is good, though. Justlettersandnumbers (talk) 08:27, 19 July 2017 (UTC)

@Justlettersandnumbers: It is supposed to right align. If it is not for you, then that might be a browser specific bug. Please report what browser and version of it you are using. —TheDJ (talk • contribs) 09:11, 19 July 2017 (UTC)

Safari Version 5.1.10, TheDJ. Justlettersandnumbers (talk) 09:14, 19 July 2017 (UTC)

Ah, that browser is not really supported anymore, so I guess it's not too surprising. I've been saying that we should disable JS support for Safari 5, but so far it seems it's still included. —TheDJ (talk • contribs) 09:51, 19 July 2017 (UTC)

Similar but not identical problem in Chrome Version 49.0.2623.112; Firefox 48.0.2 is OK, though. Justlettersandnumbers (talk) 09:20, 19 July 2017 (UTC)

I use Chrome 36 (after I abandoned Firefox because v. 51 got waaay too slow - five minutes to load a Wikipedia diff, and ten mins to click "back" from that? Ridiculous) and I find that it's right aligned, but the last two or three characters are hidden by the bytes-remaining counter. Pressing End reveals them though. Perhaps that counter could be put outside the box? --Redrose64 🌹 (talk) 10:06, 19 July 2017 (UTC)

Counter, what counter? Using the latest version of Chrome with Vector. Doug Weller talk 10:58, 19 July 2017 (UTC)

Are you using wikEd? That makes its own edit summary box with no counter. PrimeHunter (talk) 12:38, 19 July 2017 (UTC)

@Doug Weller: I suspect this might be interfering. And indeed so will wikEd. —TheDJ (talk • contribs) 12:57, 19 July 2017 (UTC)

@PrimeHunter and TheDJ: I got rid of the CSS but I want to keep WikiED, I'm ok without the counter, just nice to know why I can't see it. Doug Weller talk 15:40, 19 July 2017 (UTC)

@Doug Weller: I'm not going to fix wikEd though, you will need to contact it's maintainer. —TheDJ (talk • contribs) 15:50, 19 July 2017 (UTC)

@TheDJ: Of course not, why should you? As I said, I'm not bothered, I want to keep WikiED. Doug Weller talk 19:09, 19 July 2017 (UTC)

@Doug Weller: By "that counter", I mean the one described at Help:Edit summary#The 250-character limit (the bit about the figure 143). --Redrose64 🌹 (talk) 20:02, 19 July 2017 (UTC)

I have the same problem on Firefox 52.2.1. Deli nk (talk) 12:43, 19 July 2017 (UTC)

I have the same problem with latest version of Chrome for Windows. When I undo a change, I find myself removing most of the default stuff in the box so I can see what I'm doing. Annoying. Any way to go back until they fix it?--Bbb23 (talk) 14:04, 19 July 2017 (UTC)

• Please roll back the change to the edit window. This makes it harder to write edit notes. It is cute to have the little twitter character counter but it actually gets in the way many, many characters from the end. This must go'. Jytdog (talk) 22:19, 19 July 2017 (UTC)

Edit summary field hidden

Not sure if this is related, but I came here wondering about why I was not able to see any edit summary field at all. I'm editing on a Kindle fire at the moment with the vector skin. older ≠ wiser 08:57, 19 July 2017 (UTC)

You have #wpSummaryLabel hidden in your vector.css (as did I). Just remove the line.[5] -- zzuuzz ^(talk) 09:06, 19 July 2017 (UTC)

Hmm, that seems like an oversight in one of the IDs.. Please file a bugreport. —TheDJ (talk • contribs) 09:11, 19 July 2017 (UTC)

(edit conflict) The id wpSummaryLabel ended before the box in an old version I compared to. You can currently place the below in your CSS to hide the heading but not the box. PrimeHunter (talk) 09:32, 19 July 2017 (UTC)

#wpSummaryLabel .oo-ui-labelElement-label {display:none;}

@Bkonrad and Zzuuzz: You can increase the specificity of the selector, like this. --Redrose64 🌹 (talk) 09:31, 19 July 2017 (UTC)

Thanks @Redrose64 and PrimeHunter:. Both your suggestions work, though I noticed PrimeHunter's suggestion also hides the count of remaining characters (something I had not seen before and is nice touch). older ≠ wiser 10:02, 19 July 2017 (UTC)

What is this number?

When I'm in the edit window in Firefox 54.0.1, logged in, there is an odd 3-digit number outside and to the right of the Edit Summary box. That same number appears no matter what article I open up. So, I opened Microsoft Edge without logging in. That same number appears no matter what article, except it's inside the Edit Summary. Are you tracking us? What is this number, and why is it the same number no matter what article, no matter if I'm logged in or not? — Maile (talk) 11:54, 19 July 2017 (UTC)

@Maile66: Type some letters into the edit summary box and you will see what it means! See also the first point at Help:Edit summary#Edit summary properties and features. — This, that and the other (talk) 11:57, 19 July 2017 (UTC)

Ahhhhh ... it counts the characters in our edit summary and tells us when we've reached the limit. Thanks. — Maile (talk) 12:00, 19 July 2017 (UTC)

@Maile66: Specifically, it counts bytes rather than characters; if you type in non-Latin characters like "카나다", "Канада", or "קאנאדע" you'll see it drop more quickly. My colleagues in the MediaWiki team are working on making it possible to write more than the current limit of 250 bytes, which was a highly-rated Community Tech wishlist item recently. Jdforrester (WMF) (talk) 15:56, 19 July 2017 (UTC)

Seems pretty pointless TBH. Another good reason why I ditched using edit summaries years ago. Lugnuts ^{Fire Walk with Me} 13:04, 19 July 2017 (UTC)

Actually, it counts the bytes, not the characters. This distinction is what makes it particularly useful for people who aren't typing in English. Whatamidoing (WMF) (talk) 15:34, 19 July 2017 (UTC)

@Maile66 and This, that and the other: A better link is Help:Edit summary#The 250-character limit, in particular the bit about the figure 143. @Jdforrester (WMF): 255 bytes, not 250. Same link. --Redrose64 🌹 (talk) 20:00, 19 July 2017 (UTC)

The counter is cool but should be outside the text field. The rest of the changes are just ugly. Rivertorch^FIRE_WATER 23:28, 19 July 2017 (UTC)

Last characters in summary are hidden

Tracked in Phabricator
Task T169982

I came here to ask a related question, and saw this thread. How do I turn off the count box? I couldn't find anything in preferences. Is there a .css or setting that will kill it? On Google Chrome (with MonoBook skin), the box hides the last couple characters typed in the Edit Summary box - as a result, it just gets in the way. To verify I didn't leave off anything I need to back arrow then forward arrow to trick the UI to show me all the typed characters. If I type again at that point, they are again hiddent and I need to use the stupid back arrow/forward arrow thing again to view all my typed characters. --- Barek (talk • contribs) - 17:06, 19 July 2017 (UTC)

Put

.oo-ui-textInputWidget > .oo-ui-labelElement-label { display:none !important; }

in your common.css. —Cryptic 17:13, 19 July 2017 (UTC)

Doesn't work—the countdown is still there. I'm sure this was implemented with the best of intentions but please, disable it until you can get it working properly—not being able to see what you're typing is remarkably irritating. We survived for 15 years without it, I'm sure we can survive another week while you work the bugs out. ‑ Iridescent 17:18, 19 July 2017 (UTC)

You're right - I was able to change the positioning and opacity with that selector, but display doesn't stick. I've added an "!important" to the above, which does work. (At least for me, in cologneblue, in preview.) Try that? —Cryptic 17:24, 19 July 2017 (UTC)

Even if CSS allowed to hide it, note that this will not prevent the extra scripts from loading and running (every typed character will still be processed by them). —PaleoNeonate - 17:21, 19 July 2017 (UTC)

Works here. It is an element and so it can be easily hidden. The selector is correct, make sure you copied it exactly and placed it in the correct file. Not to say it won't change tomorrow though. Also the count doesn't hide anything for me, so might be a browser-specific issue. Or just that skin? Either way, might work one day! Lithopsian (talk) 17:25, 19 July 2017 (UTC)

Sorry, my mistake, I was using a different selector:

#wpSummaryWidget > .oo-ui-labelElement-label

Lithopsian (talk) 17:28, 19 July 2017 (UTC)

Since "that browser" is Chrome and "that skin" is Vector, this is the most frequently occurring combination among Wikipedia editors by an order of magnitude—we're talking a major issue, not some obscure glitch that only affects a few users using archaic systems. ‑ Iridescent 17:30, 19 July 2017 (UTC)

I figured out why this is occurring. Let's hope someone can find a fix for it soon. —TheDJ (talk • contribs) 18:31, 19 July 2017 (UTC)

I also experience a strange bug where sometimes characters become hidden under the counter when typing using FF, after typing enough it resets and I can see the new characters again. I would really like if most of those new features systematically came with corresponding disable/enable preferences (large buttons, interwiki search, this counter are examples of recent features which lacked systematic toggling options. There's now a gadget to disable the search aspect (and it could be hidden by CSS), but that was still introduced afterward and does not prevent unnecessarily loading extra scripts (and all the interdomain pages, as can be seen in inspectors or security control addons); I also noticed that page loading time increased in the last months, scripts often lagging behind the actual page. I commonly click on the watchlist star before all scripts are loaded, causing the page to reload with the "add/remove" question like if JS was disabled. Another common occurence is for the page to load and jump at the proper anchor with scripts lagging, which when loaded cause sudden scrolling/jump, where I have to select the address bar and press enter again to scroll to the anchor. It's unfortunate for this bloat to become obvious for features I don't need, even on a fast system and fast connection... —PaleoNeonate - 22:50, 19 July 2017 (UTC)

• Yes please turn this "counter" off. It is a bug, not a feature. Jytdog (talk) 22:23, 19 July 2017 (UTC)

Character counts on subject/edit summaries?

I'm seeing character counts on the Subject and Edit summary boxes now, which I wasn't before a few days ago. However, for long edits (such as after a revert) the cursor and last few characters are hidden.

Is this on for everyone, or is my Javascript (currently only OneClickArchiver) somehow causing this? Power~enwiki (talk) 21:37, 19 July 2017 (UTC)

see #What is this number? above, sounds like the same. Nthep (talk) 21:46, 19 July 2017 (UTC)

yup, same thing. Closing. Power~enwiki (talk) 23:44, 19 July 2017 (UTC)

Process

What is the process through which this "Improvement" was implemented? Jytdog (talk) 22:24, 19 July 2017 (UTC)

God only knows. At the very least, there should have been a banner warning users of it. When I first saw it yesterday, I wondered for a moment if I'd somehow wound up on a spoofed site. Rivertorch^FIRE_WATER 23:26, 19 July 2017 (UTC)

Obviously someone at WMF who never uses this site thought it would be a great thing to implement. Hats off to them! Lugnuts ^{Fire Walk with Me} 12:11, 20 July 2017 (UTC)

It was pointed out to me here that this was done via phab:T36984. That in turn was related to phab:T165856. It ~appears~ to me that User:Jdforrester (WMF) was the person who implemented the request? I don't understand how the process of changing code works or how decisions are made to actually implement things. I suppose somebody thought this was a trivial tweak. I have no idea.

There is a Tech news thing where the devs communicate what they are doing, but I looked through the current issue and one previous issue and don't see this mentioned. Jytdog (talk) 12:31, 20 July 2017 (UTC)

Obviously someone at WMF who never uses this site is wrong per Jytdog's phabricator link (which I dug up). The original feature had implementations on other wikis in gadget form (especially the non-Latin alphabetic wikis) and has anyway existed in VisualEditor for 5 years (without seeming complaint anywhere on phabricator, besides a handful of breakages). --Izno (talk) 12:37, 20 July 2017 (UTC)

User:Izno - I have appreciated your providing information but the implementation in the WikiEditor was crappy and broke things. Period. Whether it worked somewhere else is entirely irrelevant. People get angry when their tools get broken - irrelevant argument pours oil on the fire. Jytdog (talk) 13:10, 20 July 2017 (UTC)

Indeed. So I guess we all need to start using VisualEditor so that we'll be forewarned about interface "improvements". It never ceases to amaze me: there are so many areas of the editing experience that could be improved, and WMF developers have repeatedly shown themselves capable of coming up with brilliant solutions, but they keep fixing things that aren't broken. And failing to give fair warning. Rivertorch^FIRE_WATER 13:57, 20 July 2017 (UTC)

It is rather amusing to see that almost everything now on my common.js and common.css pages exists solely to reverse various changes WMF developers made. And I certainly cannot thank enough everyone who has contributed here with wonderful solutions, with a special shout-out going to Mikhail Ryazanov and Cryptic! ^_^ Double sharp (talk) 14:36, 20 July 2017 (UTC)

@Rivertorch: Not having an indicator of how much information I could pack into an edit summary was more-or-less broken behavior and I'm personally surprised this change wasn't made earlier. "No-one got around to it because it would have been a pain before the train got rolling on the big blue Publish button" seems to be the indication from the phabricator task for the "why" of that. --Izno (talk) 15:11, 20 July 2017 (UTC)

@Izno: As I indicated elsewhere in this ever-growing section, the counter isn't a bad thing; the implementation of it is. The implementation is half-baked and was rolled out without proper notification. (It certainly wasn't urgently needed; one becomes rather adept over the years at estimating summary length and trimming as needed.) Rivertorch^FIRE_WATER 18:19, 20 July 2017 (UTC)

@Rivertorch: Agreed, generally. --Izno (talk) 18:31, 20 July 2017 (UTC)

@Jytdog: Having feelings about an (un)expected change is understandable. Communicating that in a non-collegial manner (that is, dripping sarcasm and obvious lack of research) is not. I am perturbed that you did not state an issue with his behavior but instead targeted my response, but sure, I'll move along. --Izno (talk) 15:11, 20 July 2017 (UTC)

User:Izno this was not feelings about an unexpected change - it is frustration with a change that broke something I rely on for every edit I make, that adds a "feature" that provides no value for me. Your initial responses were helpful and provided information. These last responses have not been helpful but are causing "feelings" that are decidedly not good. Jytdog (talk) 05:12, 22 July 2017 (UTC)

Make it stop

Tracked in Phabricator
Task T169982

Please kill this counter. It is turning my edit notes into garble. This is so unbelievably stupid. TURN THE COUNTER OFF.Jytdog (talk) 03:00, 20 July 2017 (UTC)

This issue is being worked on. —TheDJ (talk • contribs) 09:32, 20 July 2017 (UTC)

The counter should be removed and made an option for people who want to see how much space they have left. I do not want this clutter. Removing it should be simple and fast, no? Whatever it takes to fix it can be worked out at leisure then, and It can be re-implemented as an option. Jytdog (talk) 13:13, 20 July 2017 (UTC)

The counter gets in the way of editing on a mobile / tablet and makes it impossible to leave a meaningful edit summary when reverting an edit using the web interface on an iPhone. For example: Undid revision 12345689 by Example (talk) consensus on the talk page is that this information violates the biographies of living persons policy and should not be used. Ritchie333 ^{(talk) (cont)} 09:43, 21 July 2017 (UTC)

• It stopped!! Thank you devs, very much. Such a relief not to have to fight with the software to leave an edit note. We take simple things that work for granted, so I wanted to be sure to say thanks. I would prefer not to have the counter re-implemented but if it must be, please keep it out of the way. Jytdog (talk) 21:42, 21 July 2017 (UTC)

Hello again, Jytdog. Recently, the number counter has been reinserted per Phabricator task, which was about fixing the bug itself... maybe? I think filing a Phabricator task to disable the feature is not a good start as it needs consensus. Some of the tasks that I started got rejected (for various reasons, I think). I sense some disdain toward the counter, but I don't think the Technical subpage is the right place as this is a mere complaint rather than an error report. I wonder whether you or I can propose adding the user option to opt-out/opt-in the number counter in the editing page at the WP:Village pump (proposals). You can see how my advice led to a proposal discussion. Thoughts? --George Ho (talk) 08:12, 1 September 2017 (UTC)

Yeah i saw it when they reinstated it. it stays out of the way now so i no longer HATE it. now it is just a distraction that i would just as soon not have but cannot get exercised over... Jytdog (talk) 13:26, 1 September 2017 (UTC)

Cancel button no longer a button

Why is the Cancel button no longer a button, just a bolded red text link?

What on earth is that about? --BrownHairedGirl (talk) • (contribs) 09:20, 20 July 2017 (UTC)

The link has changed colour and size, but it wasn't a button before: 2014 screenshot -- John of Reading (talk) 09:29, 20 July 2017 (UTC)

The word "Citations", also without button, is floating just above the line between "Show changes" and "Cancel". (Monobook, desktop, current Firefox): Noyster (talk), 12:32, 20 July 2017 (UTC)

That sounds like you have a user script or gadget that needs updating. Anomie⚔ 12:45, 20 July 2017 (UTC)

The color change was not a good idea, because now it looks like a redlink, instead of just an editing page option. kennethaw88 • talk 00:00, 22 July 2017 (UTC)

Well... to experienced Wikipedians perhaps.. to the rest of the world, probably not as much. —TheDJ (talk • contribs) 10:05, 28 July 2017 (UTC)

It may not have been a button before but it looked okay then. It doesn't now. It looks wrong. Jason Quinn (talk) 10:19, 31 July 2017 (UTC)

@TheDJ: In Vector it is a bit more readable - do we have an wiki-side options for increasing the font weight in monobook? — xaosflux ^Talk 11:35, 31 July 2017 (UTC)

I've added bolding to the cancel button in MediaWiki:Monobook.css. — xaosflux ^Talk 01:44, 1 August 2017 (UTC)

Jason Quinn, I agree entirely. The new implementation is visually, and cognitively jarring. "Cancel" is an option at least as important as "Save" or "Preview". For workflow option choices such as this my brain would expect to be choosing between a set of equally prominent buttons, or a set of equally prominent links, not an odd, indiscriminate mixture. If it was "wrong" before then it never really caught my attention as such, so, for me at least, it must now be more jarringly "wrong" - probably due, in part, to the increased prominence of the buttons. I use vector. -- Begoon 11:44, 31 July 2017 (UTC)

Shortened edit summary

Nobody else seems to have mentioned it, so I will: Since the implementation of the accessible save buttons, the length of the edit summary seems to have been cut in half. I usually edit on a Windows 7 machine using 64-bit Firefox 54.0.1, using WikEd and these scripts; here is my CSS. Any suggestions? If I undo an edit, the automatically generated portion of the edit summary (the diff number and the links to the editor's contribs and talk page) take up more than half the length of the (shortened) edit summary. Thank you. — Malik Shabazz ^Talk/_Stalk 02:47, 21 July 2017 (UTC)

I was wondering about that, but I think it's unchanged. There is a bug in that when scripting is disabled in the browser, there is no visible cursor in the edit summary box once the cursor hits the end of the box (129 characters in my browser window at the moment—that depends on how wide the window is). I can continue typing (with no visible cursor) until 200 bytes have been entered. I think that is the same as it used to be, although 255 bytes are available when scripting is enabled. Johnuniq (talk) 01:40, 23 July 2017 (UTC)

The 200-byte limit was lifted for everybody with the release of MediaWiki 1.17 back in February 2011; making this gadget somewhat redundant (it's no longer listed at Preferences → Gadgets). --Redrose64 🌹 (talk) 08:42, 23 July 2017 (UTC)

OK, but I tested before posting my comment above, and 200 bytes is all I can put in an edit summary box with scripting off, and 255 with it on. Johnuniq (talk) 09:57, 23 July 2017 (UTC)

I think it is just wikEd racing the oojs ui. If wikEd is first, it gets 200 limit (because that is the fallback if OOjs UI has not finished enhancing the view). —TheDJ (talk • contribs) 15:06, 24 July 2017 (UTC)

Thank you all for your comments and assistance. I tend to agree that it's probably a conflict with WikEd, because it doesn't happen on every edit. Just the ones for which I need a long edit summary. — Malik Shabazz ^Talk/_Stalk 02:02, 26 July 2017 (UTC)

No preview of edit summary with live preview

Tracked in Phabricator
Task T171156

I'd like to also express my disapproval of the new bigger "Save changes" etc buttons. More importantly though, I no longer get a the preview of edit summary that I used to get when I clicked "Show preview" or "Show changes". I use the MonoBook skin, but the same problem occurs when I switch to Vector. The preview of the edit summary itself is quite useful because I frequently include wiki-links in my edit summaries - most often to the relevant MOS guideline shortcut (eg MOS:BOLD) when editing pages to meet those guidelines. The summary preview showed me a clickable link (red if I've mistyped it) which I can ctrl-click (open in new tab/page) to check. Can we have the summary preview put back please. Mitch Ames (talk) 09:52, 24 July 2017 (UTC)

When I try it, in both Monobook and Vector, the preview shows up just under the edit summary input. I don't think it has even moved due to this change. Anomie⚔ 12:11, 24 July 2017 (UTC)

If I try in in a "private browsing" window, so I'm effectively not logged in, the preview appears, so perhaps there's something in the new style that conflicts with one or more of the settings in my preferences. I could reset them all to defaults and work through them all, but that will be tedious. Does anyone have any suggestions as to specific settings to try? Mitch Ames (talk) 13:34, 24 July 2017 (UTC)

Mitch Ames, if you are using the Live Preview option of your preferences, then there is currently a bug where the preview of the summary doesn't work. This is ticket phab:T171156. —TheDJ (talk • contribs) 14:59, 24 July 2017 (UTC)

Thanks - that's the cause in my case. I do have live preview enabled, and if I disable it the summary preview reappears. Mitch Ames (talk) 11:22, 25 July 2017 (UTC)

Tracked in Phabricator
Task T172844

By the way, does anybody know how to get "Templates used in this preview" working with "live preview"? Now it shows "Wikidata entities...", "...member of categories" and a rather useless "Parser profiling data", but not the templates, so getting to template documentation is a nontrivial task. (In :ru, "live preview" is invoked by a different button, so a "regular" preview can still be easily done as a work-around. But why can't it just work properly?). — Mikhail Ryazanov (talk) 22:42, 8 August 2017 (UTC)

Show Preview and Show Changes on a single button

Tracked in Phabricator
Task T41666

Since everyone's focused on this general topic, can I renew my plea for a single button that will give "Preview" and "Changes" at the same time? It's such a perfectly obviously useful thing, and there should be zero design issues. I'll just sit here and hold my breath until that's done. Thanks. EEng 13:43, 27 July 2017 (UTC)

@TheDJ:: What's the status of your experimental script for this? Whatamidoing (WMF) (talk) 16:13, 27 July 2017 (UTC)

@TheDJ:, I'd kill for this feature. EEng 12:53, 29 July 2017 (UTC) Note: Not actual threat to kill anyone.

You didn't say that you'd kill a person. How about killing off your choice of maintenance categories instead?  ;-) Weeding the stale templates out of Category:Pages actively undergoing a major edit looks a fair trade, if the script is still viable. WhatamIdoing (talk) 05:56, 31 July 2017 (UTC)

Completely fair. I'll do it in dribs and drabs today over the next few days (visitors). EEng 13:29, 31 July 2017 (UTC)

A month of visitors, it turns out. I sure hope you're ready to make good on your side of the bargain. I'm counting on you. EEng 17:26, 18 August 2017 (UTC)

August can be like that. Please give it a try before you get any further; it may do more than what you want, or it may have broken in the last four months (since the last edits). The installation instructions are at User:TheDJ/Actual Live Preview. Whatamidoing (WMF) (talk) 06:03, 21 August 2017 (UTC)

With continued apologies for not having upheld my end of the bargain (yet), that's not at all what I'm looking for. Normally, when editing, below the edit window there are four buttons: Save changes; Show preview; Show changes; Cancel. I want an additional button (or maybe it replaces Show preview and Show changes) called Show changes and preview, which gives you the diff (like Show changes gives you) at the top, a preview (like Show preview gives) in the middle, and then the edit window at the bottom. This way, I can review how my unsaved version diffs from the current live version of the page and I can preview the rendering of my unsaved version, at the same time. This seems so perfectly obviously desirable that I'm astounded it's not just the way it was designed in the first place, instead of (as we have now) two separate buttons forcing you to choose which of two ways (diff vs. rendered) to review before saving. EEng 13:17, 21 August 2017 (UTC)

If anyone's still curious, I've retooled my four-year old script that does just this. Should be working again. :) Writ Keeper ⚇♔ 05:48, 24 August 2017 (UTC)

@Writ Keeper: This works wonders, thanks! I would second EEng's request to display changes at the top of page, then preview, and finally edit window. The reason is that diffs are generally small whereas article or section preview can be several screenfuls; with diffs on top, they are easier to quickly review for typos and such. — JFG ^talk 06:53, 24 August 2017 (UTC)

@JFG: done! Writ Keeper ⚇♔ 13:22, 24 August 2017 (UTC)

Splendid! — JFG ^talk 15:18, 24 August 2017 (UTC)

• THIS IS THE GREATEST THING IN THE WORLD! EVERYONE INSTALL IT!

mw.loader.load("https://en.wikipedia.org/w/index.php?title=User:Writ_Keeper/Scripts/previewAndDiff.js&action=raw&ctype=text/javascript");

EEng 22:15, 30 August 2017 (UTC)

Citation expander

The Wikipedia:Citation expander gadget adds as "Citations" link that hasn't been beefed up for the new button scheme. Would somebody more familiar with whats going on with the buttons right now be willing to file a phab report about that? Jason Quinn (talk) 14:51, 31 July 2017 (UTC)

@Smith609: I assume that you don't actually want a Phab task about MediaWiki:Gadget-citations.js. Whatamidoing (WMF) (talk) 16:45, 31 July 2017 (UTC)

I came here to report something about this, too. The "Citations" button is no longer a button, but just the word "Citations", in a very small font, in a superscript position for some reason, and it doesn't even look like a link, much less a button (conditions: Mac OS 10.12, Chrome 59).  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  18:37, 24 August 2017 (UTC)

I don't know what a Phab task is, but it looks like the link has now been buttonified? Martin (Smith609 – Talk) 09:26, 8 September 2017 (UTC)

Delete page

The Delete page button looks like a redlink. --Redrose64 🌹 (talk) 21:53, 6 August 2017 (UTC)

Email change reports don't (with changes in Wikidata)

I've recently started receiving email reports of changes in pages I'm watching that claim "No change". One such change was attributed to User:Sintakso. I asked about this on User talk:Sintakso. Sintakso replied saying s/he had NOT recently edited that article directly but had "recently edited the corresponding Wikidata item (Q131143)".

As the usage of Wikidata increases, emails notifying users of changes like this will clearly increase as well.

I thought you might want an official report of this. Thanks, DavidMCEddy (talk) 14:36, 24 August 2017 (UTC)

@Lydia Pintscher (WMDE): might be of interest to you Lydia ? —TheDJ (talk • contribs) 15:26, 24 August 2017 (UTC)

Thanks for the ping, TheDJ! @Sintakso: You should not be getting email notifications about changes happening on Wikipedia. This is very strange. Is there any chance you can forward such an email to me? My address is lydia.pintscher at wikimedia.de. Then I'll have a closer look at it and try to figure out what's going on. Is anyone else getting similar emails? --Lydia Pintscher (WMDE) (talk) 18:12, 24 August 2017 (UTC)

@Lydia Pintscher (WMDE): I didn't get any email about changes on Wikipedia - the problem is that DavidMCEddy has received an email claiming that I have edited the article Pseudomonas while I have only edited the connected Wikidata item (Q131143). --Sintakso (talk) 18:34, 24 August 2017 (UTC)

@Sintakso: ah sorry. I mixed it up. @DavidMCEddy: My above text was for you. --Lydia Pintscher (WMDE) (talk) 20:35, 24 August 2017 (UTC)

@DavidMCEddy: Have you enabled both "Email me when a page or a file on my watchlist is changed" at Special:Preferences#mw-prefsection-personal, and "Show Wikidata edits in your watchlist" at Special:Preferences#mw-prefsection-watchlist? So the problem is not that an email is sent but that it doesn't say the edit was at Wikidata? On the watchlist itself there should be a bold D to indicate "This edit was made at Wikidata". PrimeHunter (talk) 14:16, 25 August 2017 (UTC)

@Lydia Pintscher (WMDE):@PrimeHunter: Yes, I have enabled options like that. And I just sent an email documenting this to lydia.pintscher at wikimedia.de. Thanks for looking at this.

The Watch list is very powerful for managing vandalism. It should not be contaminated with unexplained "(No difference)" messages.

I think the best fix might be to generate an official entry in the history of each page that uses a Wikidata item when that item is changed. I want to know of changes in Wikidata that affect an article I'm watching: I would want to be notified of a change in Wikidata that affects the Pseudomonas article, for example. Currently I get a notice, but it says, "(No difference)", even though there is a difference. If it's vandalism, I'd want to know so I could revert it. If it might challenge my understanding of pseudomonas, I'd want to know.

Are people discussing the use of Wikimedia projects like Wikipedia, Wikiversity and Wikinews with Wikidata to crowdsource research? If yes, where can I find such a discussion. (If it's in German, French or Spanish, I can probably handle that.)

A moderately sized project of this nature would involve updating the 2008 RAND study on "How terrorist groups end": The authors identified 648 terrorist groups active between 1968 and 2006. Some splintered. Some were still active in 2006. They found 268 that had ended in that period.

In v:Winning the War on Terror I describe how these data suggest that the West is using the least effective approach to terrorism:

• Terrorists were more likely to win than be defeated militarily (in this data set).

However, a retired senior US military officer recently told me that RAND did NOT have a good reputation among serious policy makers.

My response is to port those 268 cases to Wikidata and invite the world to add fields and cases to test the robustness of the conclusions. There are many different definitions of terrorism as well as different definitions of whether and how the groups ended. All these issues could be discussed openly in Wikiversity and Wikipedia -- rather than being restricted to elites, many of whom have conflicts of interest in getting answers that please their funders. Many discussions of these issues are classified and therefore not available for public discussion.

In this way, the Wikimedia system can help limit this insanity, I think. (Wikimedia threatens venal elites, as acknowledged most explicitly by both Turkey and China.) DavidMCEddy (talk) 15:38, 25 August 2017 (UTC)

Update: I've looked into it some more and there indeed seems to be something fishy happening here. I've opened phabricator:T174794 for it. --Lydia Pintscher (WMDE) (talk) 14:18, 1 September 2017 (UTC)

Commons images

I've been having a problem recently with photos hosted on Commons not showing up in articles, and Commons itself showing a server error message when accessed. When this happens, photos just show as their filename or alt text. This been a regular thing for the past few weeks. I've tried the latest versions of Chrome, Edge and Firefox and had exactly the same issue with each. Cloudbound (talk) 23:41, 24 August 2017 (UTC)

Me too, Opera 36, except I get a blank space until the image arrives. Which can sometimes not occur before I give up after 20 mins. --Redrose64 🌹 (talk) 00:10, 25 August 2017 (UTC)

Links to examples are always helpful. I had one today that would not show up in an article (I got a broken image icon), but I was able to click through to Commons, where I saw that the thumbnail was broken. I was able to regenerate a thumbnail using a tip I found on Commons, which fixed the image in the article. For what it's worth, the image was File:Winter Go West Tour - Portland,OR - Paramore.jpg. I can see the thumbnail on Commons now. – Jonesey95 (talk) 03:13, 25 August 2017 (UTC)

For the start, the exact server error message would be helpful. --AKlapper (WMF) (talk) 07:08, 25 August 2017 (UTC)

@AKlapper (WMF): See commons:Category:1882 in Finland which currently shows a blank page. When I appended ?action=purge a few minutes ago, it displayed "Our servers are currently under maintenance or experiencing a technical problem ... Error: 503, Service Unavailable at Fri, 25 Aug 2017 08:07:02 GMT". That was reported at T170039 about a probably unrelated issue. Johnuniq (talk) 08:11, 25 August 2017 (UTC)

Ouch, see commons:Category:Pages with script errors! Johnuniq (talk) 08:14, 25 August 2017 (UTC)

To be honest, it is sporadic, and when it does happen it's within any article with a file hosted on Commons. I don't even get the outline of the thumbnail frame in an article, it just leaves the caption. Cloudbound (talk) 12:57, 25 August 2017 (UTC)

Commons is itself still down, with the following message when I attempt to connect to any Commons page:

"Request from [IP] via cp3048 frontend, Varnish XID 411806751 Upstream caches: cp3048 int Error: 404, Requested domainname does not exist on this server at Fri, 25 Aug 2017 13:32:06 GMT" Cloudbound (talk) 13:33, 25 August 2017 (UTC)

The Commons problem is discussed at T171392. It appears to be due to an unusual template, namely commons:Template:Countries of Europe which uses commons:Module:UnNowiki. The out-of-memory error may be due to infinite recursion although it's faster at getting that error than occurred when one of my modules died like that. Johnuniq (talk) 00:07, 26 August 2017 (UTC)

A page at Commons which just works is commons:Category:Netherlands. The html source of that page includes "Lua memory usage: 49.69 MB/50 MB". I have been thinking about a fix by replacing commons:Template:Countries of Europe with a call to a new module that would do the work much more efficiently. However, the real bottleneck may be the intense work that it does, and using a module might not fix the excessive memory usage. The template generates a horizontal list of 61 country names, each linked to the Commons category for the country. For each country, it uses #ifexist to test if the category page exists, and it uses Wikidata to display the localized name for the country depending on the reader's language preference. Does anyone know if the 50 MB memory limit might be hit simply from using #ifexist (expensive) 61 times, and doing 61 Wikidata reads? Johnuniq (talk) 05:03, 29 August 2017 (UTC)

Yes. Simply using data from an arbitrary wikidata item (not connected directly to page in question) increments the expensive parser count( see mw:Extension:Wikibase_Client/Lua#mw.wikibase.getEntity), and seems to use about ~930KB (for Q42), e.g. mw.wikibase.getEntity( 'Q42' ):getLabel(). Basic lua usage without any special coding is about 500KB. So it will probably max out at around less than ~70 arbitrary wikidata calls (for heavy items), unless some of it is cached. The actual memory usage is variable and seems to depend on the amount of data stored within each wikidata item, e.g. Q1 uses about ~400KB.

The real problem is that the template was designed in an incredibly inefficient manner, it has template calls inside lua calls inside template calls inside lua calls, and doesn't seem to cache its data. 11:00, 29 August 2017 (UTC) — Preceding unsigned comment added by 197.218.91.149 (talk)

Thanks. Yes, the strange internals of the template initially made me think replacing the lot with a module would quickly fix the problem, but when I unraveled more of what the template does I wondered where the bottleneck really was. I guess I could do a Q&D module to call ifexist and fetch some wikidata for 61 countries and see what happens. Johnuniq (talk) 11:37, 29 August 2017 (UTC)

The bottleneck is probably commons:Template:Label and its related module, and this seems to have been reported already in the talk page. It is called multiple times through multiple nested templates. It will be considerably more efficient to extract all labels for countries and load them locally using mw.loaddata. Countries don't change their names that often. 13:29, 29 August 2017 (UTC) — Preceding unsigned comment added by 197.218.91.149 (talk)

Module:Convert/wikidata/data does that for {{convert}} and I was contemplating that for a new Commons module, but it's tricky because the result varies depending on the user's language. We could cache en + fr + de and others, but then only people with a less frequently used language would see a problem, and it would never be fixed. Johnuniq (talk) 22:08, 29 August 2017 (UTC)

I created commons:Module talk:Country to test what happens when a very small module uses getLabel to fetch the Wikidata label for each country in Europe. The results are as predicted by the IP, namely the memory usage is near the limit, and the time usage is high as well. I'll think about how caching might work, but I don't see how it would be feasible to cache every country label for every language. Johnuniq (talk) 10:51, 30 August 2017 (UTC)

It is not clear why there is a need to use mw.wikibase.getEntity, unless one wants to fetch a label in an arbitrary language. : If the goal is to obtain labels in the user language wikibase.label works much better, and seems to use a negligible amount of memory probably because it just fetches one element rather than the whole entity. Caching would still be useful for the more popular languages, and to reduce the impact of vandalism.197.218.92.43 (talk) 11:53, 30 August 2017 (UTC)

Thanks. On review I see that I used mw.wikibase.label in Module:Convert/wikidata but had not realized it applied language fallbacks. I updated the test module and the results at commons:Module talk:Country show the Lua time usage has dropped from 3.6 to 0.03 seconds, and Lua memory usage has dropped from 42.92 MB to 683 KB. I will work on finishing the module in due course. Johnuniq (talk) 02:22, 31 August 2017 (UTC)

My first version of a module to replace the template is available for testing; see commons:Module talk:Country. A quick look suggests it is working well. Johnuniq (talk) 12:31, 1 September 2017 (UTC)

How do I make a new infobox template?

Hi there. I'm interested in making a new infobox that is specific to Canadian legislation, as the current infobox is based on US parliamentary procedure, and does not translate well to Canadian procedure (e.g. the committee stage is different). But, I've not found an easy "how-to" for designing a new template. Are there any resources on Wikipedia that anyone could point me to? Thanks! Mr Serjeant Buzfuz (talk) 05:49, 28 August 2017 (UTC)

@Mr Serjeant Buzfuz: Hi, what are you proposing exactly that is not covered under the extensive list in {{Infobox officeholder}}? Alex Shih^Talk 06:45, 28 August 2017 (UTC)

@Alex Shih: It's not the office holder template that I'm interested in, but the template for legislation: Template:Infobox legislation. The main difficulty is that this template assumes that the committee stage comes at the end of the legislative process, after all of the readings in both chambers, when there is then a conference committee between the Representatives and the Senate to resolve discrepancies between the versions of the bill passed by the two chambers. However, that process is an American one. In Canada, there are two committee stages, between second and third reading, in both the Commons and the Senate. There is no conference committee between the Commons and the Senate, which is how the template is structured. If I try to use the current infobox template, the committee stage always follows the third reading, even though the date of committee stage was before third reading. And, it leaves the reader with the impression that the Canadian parliamentary practice for committees is the same as the US practice, which is just plain wrong. I have suggested in the past that the current legislation infobox be amended to provide this as an option, but no-one was willing to do that. There are already specific templates for EU legislation and UK legislation, so creating one that accurately sets out the Canadian legislative process would consistent with those precedents. Mr Serjeant Buzfuz (talk) 07:16, 28 August 2017 (UTC)

@Mr Serjeant Buzfuz: I see. I don't think there is a easy guide for advanced templates. It would be much easier to work as you go based on existing pages (in this case, the UK version is probably a good starting point). I have started a page at Template:Infobox CA legislation if you would like to work together on this. Alex Shih^Talk 08:21, 28 August 2017 (UTC)

@Alex Shih: Thanks very much. But what do we do now? Mr Serjeant Buzfuz (talk) 03:36, 6 September 2017 (UTC)

Instead of a new template, consider getting the existing infobox modified to suit your needs. If you are unable to build consensus, consider a wrapper instead of a fresh new infobox. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 09:51, 28 August 2017 (UTC)

My personal view is that it's counter-productive to try to have a "one size fits all" template for something that has no much national variation as legislative process. I would prefer a separate template, customised to the Canadian practice. Mr Serjeant Buzfuz (talk) 03:36, 6 September 2017 (UTC)

@Mr Serjeant Buzfuz: The Canadian process is based upon the British process (First Reading → Second Reading → Committee Stage → Report Stage → Third Reading in one House, then the same five in the other House, then ping-pong until both houses agree or one rejects outright). So have a look at {{Infobox UK legislation}}. --Redrose64 🌹 (talk) 11:47, 28 August 2017 (UTC)

True, there are similarities, but the Canadian legislatures have gradually departed from the UK model. For example, at the provincial level, the Legislatures are all unicameral, and in Quebec, they have abandoned the terminology of "Readings" of bills. The template should reflect that, rather than try to be all things to all nations. Mr Serjeant Buzfuz (talk) 03:36, 6 September 2017 (UTC)

Thumbnail not displaying

On British baseball, File:Wales Vs England Baseball International ball.jpg won't display. Any ideas? ―Justin (koavf)❤T☮C☺M☯ 19:22, 29 August 2017 (UTC)

 Works for me Maybe it was https://upload.wikimedia.org/ being slow again. --Redrose64 🌹 (talk) 20:45, 29 August 2017 (UTC)

@Redrose64: https://screenshots.firefox.com/McTzPHHZq9c8m2gb/en.wikipedia.org ―Justin (koavf)❤T☮C☺M☯ 00:52, 30 August 2017 (UTC)

@Koavf and Redrose64: I meant to comment on this -- at the time Koavf reported this, I saw the image on British baseball, but when I clicked on it to show it in MediaViewer or view the file page, it wasn't there. I do see it now, though. Anyway, JudeccaXIII is apparently having a similar issue with File:WikiFilterLogo.png, see their post on my talk page. Someone else reported the same issue to me almost 2 years ago, so I don't think this is a new bug, or maybe it's a regression. Trying to search Phabricator but haven't found anything yet... — MusikAnimal ^talk 22:29, 8 September 2017 (UTC)

@MusikAnimal: It seems your topicon has updated, and I'm able to view the updated file now when I click on the image on my user page. — JudeccaXIII (talk) 22:38, 8 September 2017 (UTC)

For what it's worth, it displays just fine now. Thanks all. ―Justin (koavf)❤T☮C☺M☯ 23:25, 8 September 2017 (UTC)

Proposal: XTools ArticleInfo gadget

Hello! The XTools team is happy to announce the revival of the popular XTools gadget. Before this was offered as a user script (meta:User:Hedonil/XTools), but now we'd like to propose it as a proper gadget here on the English Wikipedia, meaning you could turn it on in your gadget preferences. The gadget will work with all skins. Here's a screenshot:

The XTools ArticleInfo gadget, as seen when viewing the English Wikipedia article on Jimmy Wales.

Documentation can be found at mw:XTools#ArticleInfo gadget. If you'd like to try it out now, add the following to your common.js (or global.js to install for all wikis):

mw.loader.load('//www.mediawiki.org/w/index.php?title=XTools/ArticleInfo.js&action=raw&ctype=text/javascript');

Thank you for your consideration! — MusikAnimal ^talk 19:44, 29 August 2017 (UTC)

Seems useful, works, no objections from my part. —TheDJ (talk • contribs) 21:07, 30 August 2017 (UTC)

Agree with TheDJ. Can't hurt to have as a gadget. Regards SoWhy 07:57, 1 September 2017 (UTC)

 Done I'm hoping this is OK based on this limited but positive feedback :) — MusikAnimal ^talk 01:45, 6 September 2017 (UTC)

@MusikAnimal: Could you change the HTTP links to HTTPS links? Jc86035 (talk) 11:27, 9 September 2017 (UTC)

All the links are using HTTPS for me, except the links to XTools itself. I'm not sure why our framework isn't returning HTTPS when we're querying the service over HTTPS, but either way phab:T170989 will redirect any non-secure requests to HTTPS. We'll hopefully have that done before too long — MusikAnimal ^talk 18:22, 9 September 2017 (UTC)

Wikipedia:Graphics Lab/Photography workshop

Resolved sections on this page are not being archived anymore. Could someone please attempt to fix that issue? Thanks. --Leyo 08:25, 30 August 2017 (UTC)

@Leyo: it's because ClueBot III (talk · contribs) is down (again). So it's a problem for the botops, nothing we can do here at VPT. --Redrose64 🌹 (talk) 09:54, 30 August 2017 (UTC)

The last archiving was 15 July [6]. ClueBot III has only been down since 25 August. PrimeHunter (talk) 10:16, 30 August 2017 (UTC)

Indeed, but this disabling of the archiving was not re-enabled until 22:33, 28 August 2017 - after the bot went down. That "temporarily disable autoarchive" on the part of AntiCompositeNumber (talk · contribs) explains the lack of archiving between 15 July and 28 August. --Redrose64 🌹 (talk) 12:20, 30 August 2017 (UTC)

Oh right. So I wasted a lot of time investigating the situation because Leyo failed to say that archiving had been disabled until two days ago. Sigh. I did look for recent edit summaries mentioning archiving but Leyo didn't say it when enabling it. PrimeHunter (talk) 15:39, 30 August 2017 (UTC)

I didn't expect that digging into the history was needed to answer the question. Sorry about that. Let's hope that the issue ClueBot III will get resolved soon. --Leyo 22:13, 30 August 2017 (UTC)

@Leyo: and everyone else, I disabled the archiving because the current configuration will archive every section, as the appears the same as {{resolved}} to ClueBot. The proper way to fix that would be to change the instructions to an edit notice. I started working on one at Template:Graphics Lab/editnotice. Now that I'm back from wikibreak, I'll also be manually archiving the page regularly again, at least until we can get the bot working as intended. --AntiCompositeNumber (Ring me) 01:00, 3 September 2017 (UTC)

@AntiCompositeNumber: I'm having difficulty understanding your phrase "as the appears the same as {{resolved}} to ClueBot". Have you missed something out here? --Redrose64 🌹 (talk) 08:23, 3 September 2017 (UTC)

Based on the source, AntiCompositeNumber may have tried to display "as the <nowiki/> appears the same as <nowiki>{{resolved}}</nowiki> to ClueBot". I'm not sure what it means but I think I know the archiving problem. The new request link at Wikipedia:Graphics Lab/Photography workshop preloads Template:Graphics Lab/new request/preload which includes: <!-- mark request as {{resolved|1=~~~~}} when finished or {{stale|1=~~~~}} when inactive for at least one month -->. The removed archive instructions [7] said: |archivenow=<nowiki>{{resolved|</nowiki>. See User:ClueBot III/ArchiveThis#Optional parameters for archivenow. It causes the bot to archive all sections with the preloaded text because the comment contains the archivenow string.[8]. It was only intended to archive sections where an editor has added {{resolved}}. A possible but inelegant solution would be to complicate the preloaded instructions like: <!-- mark request as {{RESOLVED|1=~~~~}} but with lowercase "resolved" when finished, or {{stale|1=~~~~}} when inactive for at least one month -->. If a user keeps uppercase {{RESOLVED}} then the template works via a redirect but the bot doesn't archive until an editor changes it to lowercase. PrimeHunter (talk) 10:43, 3 September 2017 (UTC)

Exactly. ^{I should really stop using {{subst:CoNo}} and ignoring it in the preview, it seems to cause more trouble than it's worth.} --AntiCompositeNumber (Ring me) 12:12, 3 September 2017 (UTC)

@AntiCompositeNumber: Are you aware of the various template-linking templates? The basic one is {{tl}}, but I find {{tlx}} to be more useful, also {{tlxs}}. So in your last comment you could have written {{tlxs|CoNo}} which displays as {{subst:CoNo}}; and earlier on you could have used {{tlx|resolved}} which displays as {{resolved}}. --Redrose64 🌹 (talk) 13:10, 3 September 2017 (UTC)

@Leyo: ClueBot III was restarted at 01:23, 6 September 2017 and archiving of Wikipedia:Graphics Lab/Photography workshop occurred at 22:40 the same day. --Redrose64 🌹 (talk) 10:33, 7 September 2017 (UTC)

Well, but it's done incorrectly as you can see in the diff you provided. --Leyo 18:53, 9 September 2017 (UTC)

You wanted to know why it wasn't being archived. We explained it. Archiving started again. Why is it now a problem? --Redrose64 🌹 (talk) 22:57, 9 September 2017 (UTC)

I explained why it archives too much above and gave a possible but inelegant solution. You have to do something or the same will repeat every day. PrimeHunter (talk) 23:11, 9 September 2017 (UTC)

Pywikibot on Toolforge

Hi. I want to run some pywikibot scripts automatically. I have this line on my corntab: "30 * * * * jsub -N script python3 $HOME/pywikibot-core/pwb.py script.py". Actually, I receive emails with this content: "Your job 8988710 ("script") has been submitted" but nothing happens on the Wiki. BTW, the script works when I type run it manually. How can I solve this?--ԱշոտՏՆՂ (talk) 23:01, 30 August 2017 (UTC)

It could be a number of things. Check script.err (in you're tool's home directory) for errors. — JJMC89 (T·C) 03:56, 31 August 2017 (UTC)

IPAc-en misrendered in beta version on Android phone

On my Android smartphone* I usually have two ways of using WP: through a browser (usually Firefox, sometimes Chrome) or through the Wikipedia Beta app. Just now, reading Couscous in the Beta app on my phone, I was surprised to see in the second paragraph of § Etymology the sentence

Couscous is or in the United Kingdom and only the latter in the United States. As far as I have been able to test it, the problem occurs only on my Android phone* in the Wikipedia Beta app.

The wikicode has {{IPAc-en|ˈ|k|ʊ|s|k|ʊ|s}} and {{IPAc-en|ˈ|k|uː|s|k|uː|s}} respectively where the icons appear. These are displayed in a browser (Firefox or Chrome) or on my laptop, in either the mobile or the desktop view, as /ˈkʊskʊs/ and /ˈkuːskuːs/. The icon indicates that this is a sound file, specifically of speech, but when you click on it there is no sound, only a large version of the IPA notation

/ˈkʊskʊs/ or /ˈkuːskuːs/

centered in a white strip overlaid on the text, which is greyed out. Since there is no graphics code for the icon in the viewable template code, it must lie deeper inside, where I have neither the knowledge nor the authorization to go.

I see no value displaying an icon instead of the IPA and forcing the user to click on it to see the notation; and I see only negative value in using for this purpose an icon that leads the user to expect to hear a pronunciation.

* 
Samsung S-6 Verizon SM-G920V
Android version 7.0, Nougat
Baseband v. G920VVRS4DQE1
kernel version 3.10.61
Hardware version G920V.07

Please {{Ping}} me to discuss. --Thnidu (talk) 01:44, 31 August 2017 (UTC)

Seems deliberate (https://phabricator.wikimedia.org/T164310). The apps can essentially change the output to whatever they like, they aren't bound by what editors add. One should also expect the unexpected when using of beta versions of anything . 10:16, 31 August 2017 (UTC) — Preceding unsigned comment added by 197.218.90.62 (talk)

Not just the apps.. EVERYONE can do whatever they want (within reason of course). Google, Facebook and Apple Dictionary integrations also modify a variety of things that editors add. —TheDJ (talk • contribs) 11:21, 31 August 2017 (UTC)

Wikipedia app vandalism

Tracked in Phabricator
Task T174993

Is anyone familiar with the app and how main page sections like "In the news" for it are put together? There's a rash of vandalism occurring adding porn pictures to articles that are featuring in "In the news" e.g. North India and I can't work out how to remove the vandalism. Normally I'd look through related changes for template changes but I don't see any - mind you the new way of filtering related changes may be hindering me here. Nthep (talk) 11:24, 31 August 2017 (UTC)

@Nthep: they read this feed, from our Rest content api. If vandalism stays in the app, then this might be due to aggressive caching that the apps usually apply for anything they download. —TheDJ (talk • contribs) 11:44, 31 August 2017 (UTC)

I'm assuming that the vandalism in question was this revdel btw. —TheDJ (talk • contribs) 11:46, 31 August 2017 (UTC)

Yes, well the image at least. Nthep (talk) 11:52, 31 August 2017 (UTC)

I've made a couple of null edits to the main page thinking (bear with me, I just woke up and have never looked into the app) that will accomplish at least nothing (if not result in some beneficial accident). Ian.thomson (talk) 11:51, 31 August 2017 (UTC)

Hello there: I have filed https://phabricator.wikimedia.org/T174993 for the related team to figure out whether there's a new bug. Thanks! Elitre (WMF) (talk) 06:19, 5 September 2017 (UTC)

Popups enabled briefly on 2017-08-30 evening?

Hi All -- I am sure I didn't imagine it! Did anybody else notice something like Wikipedia:Tools/Navigation popups on the main English Wikipedia, for half an hour or so on the evening (UTC) of 2017-08-30? I have very conventional Firefox without extensions, and nothing changed on my browser, not even restarted. I wasn't logged in, so have no way I know of to enable those popups. I noticed popup images of George Plimpton and Wikipedia logo for certain, and it happened enough to make me go ask in IRC, but then it stopped. Anybody know anything about this? Kind regards to all. Jonathan. 82.69.229.22 (talk) 12:43, 31 August 2017 (UTC) (Firefox 41.0.2 on Ubuntu 15.10)

Indeed , see https://meta.wikimedia.org/wiki/Tech/News/2017/29 . 13:12, 31 August 2017 (UTC) — Preceding unsigned comment added by 197.218.84.73 (talk)

They are called mw:Page Previews (previously Hovercards), and they are indeed partly inspired on navigation popups. —TheDJ (talk • contribs) 20:59, 31 August 2017 (UTC)

Perhaps they meant that it stopped working. Looking at the console error. It seems that they've recently changed the code to use a function that is only available in jquery 3. So it will fail on all wikis that don't load it in some manner, e.g. a userscript.

P.S. It is possible to enable them for anonymous users (when they are working) by clicking a link in the footer, although that seems to only work on wikis that have the a/b test. 197.218.84.22 (talk) 07:32, 1 September 2017 (UTC)

columns-list and keep-together

Does the {{columns-list}} template have a keep-together function? See South Asia#Climate, in the caption to File:South Asia map of Köppen climate classification.svg, <br><br> was added at the end of the second column to avoid a break in {{legend|#96FF96|[[humid subtropical climate|(Cwa) '''Subtropical humid''' summer, dry winter]]}} i.e.

  (Cwa) Subtropical humid summer, dry winter

which, without the <br><br> added at the end, would break between "humid" and "summer".

I would like something like

• {{No Col Break{{legend|#96FF96|[[humid subtropical climate|(Cwa) '''Subtropical humid''' summer, dry winter]]}}}}

Does anything like this exist now? —Anomalocaris (talk) 02:56, 1 September 2017 (UTC)

It doesn't have that right now, but references lists do, so I think we might be able to solve this with some site CSS. I'll have a look later today. —TheDJ (talk • contribs) 08:18, 1 September 2017 (UTC)

@Anomalocaris: It's because that kind of linebreak prevention only works for lists, and this thing doesn't use a list.. Which in itself might be something that should be fixed... However, as to not have perfect be the enemy of good, I made a change to {{legend}} that should at least fix the linebreaking problem for those specific elements. Is it any better ? —TheDJ (talk • contribs) 08:32, 1 September 2017 (UTC)

@TheDJ: This is a start. {{legend}} now does "keep together" within columns, but, unfortunately, it moves the "kept together" item to the second column, meaning that the second column is longer than the first, and normally if the columns are unequal, the first is longer than the second. —Anomalocaris (talk) 10:06, 1 September 2017 (UTC)

@Anomalocaris: that's probably due to those extra br's. I removed them. How about now ? —TheDJ (talk • contribs) 10:58, 1 September 2017 (UTC)

@TheDJ: I tried what you did; I got the results you did; I described the results you got. See how "(Csa) Mediterr. dry, hot summer" is at the top of the second column instead of at the end of the first column, so the first column is shorter than the second, which doesn't look right. That's why I left the br's in. —Anomalocaris (talk) 11:09, 1 September 2017 (UTC)

Then I have no fix. These decisions are browser dependant and not well defined in the HTML specificatin unfortunately. —TheDJ (talk • contribs) 11:23, 1 September 2017 (UTC)

@TheDJ: Thank you for your efforts, anyway. —Anomalocaris (talk) 07:49, 3 September 2017 (UTC)

Feedback requested for new tools: Deletion analyzer and AFDCloses

Hi there. I'm not a prolific coder but I tinkered a bit and created (with valuable help from MusikAnimal) two tools to analyze deletions on Wikipedia:

• DelAnalyze.php attempts to parse all deletions (up to 100,000) by a single user and displays them in some graphs and tables, allowing to see which areas a user most works in and which speedy deletion criteria they use most often
• AFDCloses.php parses AFDs closed by a single user and displays the outcomes in a graph and table (that one I created because some users claimed I was biased towards keeping and I was genuinely interested if I really tend to close many AFDs as keep)

Since I am not a great coder, I am asking for feedback on these tools, especially bug reports. Regards SoWhy 08:07, 1 September 2017 (UTC)

@SoWhy: Naturally, I tried the deletion tool on myself to see what it would say. I was initially surprised to see so few FFD, because I had worked in that area recently (prior to a bot taking over the boring task), but I'm now guessing that it reviews the first 100,000 and stops. I wonder if it would be useful to allow searching the most recent deletions rather than starting with the first.

I note that almost 43,000 of my deletions fall into the type "other". I'm curious what's included in that category.

I was initially surprised that G8 was the largest single category for me but, on reflection, maybe I shouldn't be so surprised. Many of the deletions in other criteria also have a talk page, so the article deletion may be Gx, but the associated talk page deletion will always be G8.

The output looks nice, although I confess I haven't figured out what use I would make of this.--S Philbrick(Talk) 14:48, 2 September 2017 (UTC)

@Sphilbrick: Yes, I added a hard limit of 100,000 to avoid 504 errors. I'm still experimenting where the limit should be, so I will probably increase it. It should display the most recent deletions first though. limiting the script to 1 yields a G13 which corresponds with your deletion of User:XBobcat/Kris Knoblauch.

As for other, the script now allows you to display those. Most of them seem to be you using "g 3 (TW)" and similar, which the script does not parse because it does not include a link to the CSD policy. As noted, it relies on parsing the deletion comment for things found in MediaWiki:Deletereason-dropdown and other standardized deletion summaries. Start using those and the script can parse them

As for "what use", I think it's useful to see where admins work most. Regards SoWhy 16:29, 2 September 2017 (UTC)

@Sphilbrick: I increased the limit to 500,000 which means all your deletions are now to be found, however, I cannot find any FFD deletions - not under "Other" as well. Either you did them without a comment or they are not caught in the query. Can you point me to one deletion so I can check? Regards SoWhy 16:57, 2 September 2017 (UTC)

@SoWhy: I did say FFD, but I was thinking F5, for example I see the updated table shows 70 F5, but I believe I had 17k in June. I also see the new table has 12,532 Old file revisions, but that's too low if it counts deletions of old versions of fair use images. Let me emphasize that this is not a big deal to me, but I am assuming you are interested in making sure the tool is accurate. Almost all entries in this list (except the last one, also qualify.)

@Sphilbrick: Thanks for the reply. The script previously only parsed deletions where the page was completely deleted. It now also parses revdels, check it out. You have 54,213 F5 deletions now =) Regards SoWhy 19:54, 2 September 2017 (UTC)

I hope you appreciate I wasn't being critical, but just wanted to help you sort out any issues.If you don't mind checking one more thing, I do a number of rev dels in connection with copyright work. It hadn't occurred to me until now that deletion of an unused version of a file might count as a revision deletion. When I recently looked at User:JamesR/AdminStats I was surprised at how many rev dels I had, but I am now wondering two things - does the admin stat tool count the deletion of unused image (F5) as a revision deletion? And second, you report 941 revision deletions for me, so how does that differ from the Admin stat tool definition?--S Philbrick(Talk) 20:39, 2 September 2017 (UTC)

Don't worry, I am happy for the feedback :-) As for the question, "Revision deletion" in my tool means under WP:CRD. Other revision deletions, like for F5, are sorted into speedy deletion. I'll put splitting the tool in page and rev deletions on my to-do list though, it needs just two different queries and parsers. Regards SoWhy 21:13, 2 September 2017 (UTC)

@SoWhy: I tried the tools on myself. I'm not sure what the first is representing; is it articles nominated for deletion, or actually deleted? I have a whopping nine speedy deletes, and three mysteriously marked as "other". The AfD analyzer unsurprisingly lists all closes as "keep", since I haven't been able to close with "delete" since 2012, but there are only two articles listed, and I know there are more closes. I presume this is because of the way I closed them. The March 2016 case is unusual. I closed, then reverted my close because although the nomination was withdrawn, there was a good-faith delete vote, and you can't use SK1 in that case. Another editor subsequently closed it on consensus to keep. Hawkeye7 (talk) 22:22, 2 September 2017 (UTC)

@Hawkeye7: Thanks for trying. Yes, the first tool analyzes only actual deletions, not taggings, since that would require analyzing deleted pages and the database does not contain them for logical reasons. 12 deletions corresponds with your public log. The other deletions can be shown when you check the parameter [9]. As for AFD closes, it relies on edit summaries created by XFDCloser or Mr.Z-man's script. If you closed them manually, there is no standard edit summary to parse. If you used a script and it did not parse them, please mention an example. As for the March 2016 example, I am still looking for a sure way to detect such reverts... Regards SoWhy 10:44, 3 September 2017 (UTC)

The other way around. I didn't expect to see anything, because I thought I had closed them all manually. (I was also surprised by the deletion log - how did I manage to speedily delete two pages in November 2016?) Hawkeye7 (talk) 12:34, 3 September 2017 (UTC)

Anyone can have G6 deletions. These occur when you move a page over a redirect. (This action was previously not logged.) — JJMC89 (T·C) 21:29, 3 September 2017 (UTC)

What he said. As for the AFD closes, the AFD you mentioned and Wikipedia:Articles for deletion/Contagious shooting used the same wording as Mr.Z-man's script does, thus it matched them. Regards SoWhy 13:03, 4 September 2017 (UTC)

Move log

If a user moves a page (from mainspace to draftspace) without leaving a redirect and the draft page is then speedy deleted, does the move still show in the user's move log (with source and target both red links? Thank you in advance (but I'll also give thanks retrospectively!). Thincat (talk) 09:13, 1 September 2017 (UTC)

Yes. See my move log for JUne 20. Regards SoWhy 09:20, 1 September 2017 (UTC)

Thank you. That has enabled me to check that of about 100 mainspace articles wrongly moved to draft (and now restored), none were G13-deleted whilst in draft space. Thincat (talk) 10:10, 1 September 2017 (UTC)

Care to share? Legacypac has asked for such a list over at WT:CSD#Edit_filter_solution. Regards SoWhy 10:43, 1 September 2017 (UTC)

One of the dis­tin­guished editors of WikiProject Cricket

–EEng 23:26, 1 September 2017 (UTC)

When I joined in trying to sort out the fiasco at WT:WikiProject Cricket#Draftification of over 500 cricket biographies I discovered the relevant move log and checked (visually) to see if any move had red source and target. No, except for a move to an incorrect title followed by a move to correct it. The individual has apologised for their mistaken moves but not, I think, for using this as a technique for "quality control" claiming authority from the consensus at AN. And, at the cricket discussion, someone else is saying if any drafts not meeting their personal article quality standards are returned to main space they will move them back to draft space. Speedy deletion hardly comes into it. There does seem to be consensus on both sides that approval was required. We urgently need a guideline and an approval procedure. Thincat (talk) 21:24, 1 September 2017 (UTC)

@Thincat: I see. There is a discussion over at WP:VPPR#Upgrade WP:DRAFTIFY to policy or guideline and disallow moves to Draft- or userspace without discussion or consent you might be interested in then. Regards SoWhy 11:31, 2 September 2017 (UTC)

URLs in special wikilinks can't handle question mark

URLs in external links have no problems with special characters, but special wikilinks can't handle the question mark. For example:

• I can link to https://en.wikipedia.org/wiki/Special:LintErrors/bogus-image-options?namespace=0 or Lint errors: Bogus file options.
• I can't link to the same URL expressed as a Wikilink, unpiped: Special:LintErrors/bogus-image-options?namespace=0 or piped: Lint errors: Bogus file options, because even though the Wikilink looks good in the unpiped link, in both cases the question mark becomes %3F and the equals sign becomes %3D after clicking.

In a URL, Wikipedia can handle %3D as a synonym for equals, but it can't handle %3F as a synonym for question mark.

Since the problem is that after clicking the question mark is escaped to %3F, which Wikipedia can't parse back to question mark, it doesn't help to escape the special characters in the markup. For example, the above bullet pre-escaped renders as above and when you click on it, the same problem occurs:

• I can't link to the same URL expressed as a Wikilink, unpiped: Special:LintErrors/bogus-image-options?namespace=0 or piped: Lint errors: Bogus file options, because even though the Wikilink looks good in the unpiped link, in both cases the question mark becomes %3F and the equals sign becomes %3D after clicking.

—Anomalocaris (talk) 11:05, 1 September 2017 (UTC)

Wikilinks don't support query parameters and never have. You have to use them as full urls. —TheDJ (talk • contribs) 11:27, 1 September 2017 (UTC)

Yes, the pretty and portable way is to use fullurl at mw:Help:Magic words#URL data. You can use Wikipedia:Plainlink to omit the external link icon. <span class="plainlinks">[{{fullurl:Special:LintErrors/bogus-image-options|namespace=0}} Lint errors: Bogus file options]</span> produces: Lint errors: Bogus file options. But fullurl gives the same limitations as external links made in other ways. It doesn't work in edit summaries, it doesn't show up at WhatLinksHere, and at mobile it gives a link to the desktop version. Users on a mobile device may remain at mobile but not desktop browsers on the mobile site. PrimeHunter (talk) 13:07, 1 September 2017 (UTC)

Some mathematical etc. symbols replaced by emoji

At Gold#History my phone browser (Chrome 59 on Android) "cleverly" decided to represent the sun symbol as an emoji. Likewise at Nicholas Bourbaki#Influence on mathematics in general, the "dangerous bend symbol" is represented as an emoji that looks completely different, which is singularly unhelpful. Firefox 54 doesn't have this issue. Is there a way to force it to show the proper symbols instead of these stupid emoji glyphs? I thought of {{font}} or <span style="font-family:...">...</span> but several choices of font-family didn't work. Hairy Dude (talk) 14:12, 1 September 2017 (UTC)

I don't think there is a sustainable way to correct for a problem like this. I'd suggest to file a bugreport with the manufacturer of your phone. (Not very likely to succeed, but it's where the problem is). —TheDJ (talk • contribs) 14:52, 1 September 2017 (UTC)

I just checked: the Wikipedia app also has this issue. I think it uses the Chrome rendering engine, complete with its choice of typefaces. Hairy Dude (talk) 15:14, 1 September 2017 (UTC)

@Hairy Dude: can you check Nicolas_Bourbaki#Influence_on_mathematics_in_general again now (clear cache) and see if it renders different? I added a manual variant selector. — xaosflux ^Talk 14:55, 2 September 2017 (UTC)

Sadly, that has made no difference. I still see the yellow triangle with an exclamation mark. Hairy Dude (talk) 22:45, 2 September 2017 (UTC)

Some more cursory research turns up the following:

1. No variation sequences are defined for U+2621 or U+2609 (see [10]), so (if I understand correctly how they work) one would not expect any change. The fact that emoji glyphs exist is a bug in the font, or (since just having emoji glyphs isn't really unreasonable) in the browser for using it as the basic font. (Previously a similar lack of restraint in typeface design led to Greek chi using a glyph identical to Latin x in the Android system font, making certain IPA sequences unintelligible.)
2. For code points for which varition sequences are defined, e.g. U+2640 FEMALE SIGN (compare text style ♀︎ vs emoji style ♀️), there is a known bug in Chrome: it simply ignores variation selectors.

When I find time, I'll file a bug in Chrome about (1). @Xaosflux: Thanks for the hints, I should get a better bug report this way. Hairy Dude (talk) 23:37, 2 September 2017 (UTC)

Mobile app localization?

Hello. I'd like to know if and how I can localize the Wikipedia app to show the featured article and picture, in the news, and DYK on the Scots version. --AmaryllisGardener ^talk 17:51, 2 September 2017 (UTC)

@AmaryllisGardener: See mw:Translation of app string resources. --AKlapper (WMF) (talk) 21:07, 3 September 2017 (UTC)

@AmaryllisGardener: Actually to get the content, which I think is what you mean, you apparently need to configure Featured feeds. We have then on English Wikipedia as well, see https://en.wikipedia.org/wiki/Special:PrefixIndex/MediaWiki:Ffeed —TheDJ (talk • contribs) 11:45, 4 September 2017 (UTC)

@TheDJ: You're right, that was exactly what I was looking for. Thanks! --AmaryllisGardener ^talk 16:50, 4 September 2017 (UTC)

Some math content showing as SVG pictures?

Tracked in Phabricator
Task T147319

I'm using Firefox 52.1.0. When I open pages (e.g. Conformal_gravity) that include math content, it shows in SVG pictures instead of normal: I can fix it by changing the CSS (in the Firefox devtools) to remove these rules:

element {
    display: none;
}
.mwe-math-mathml-a11y {
    clip: rect( 1px,1px,1px,1px );
    overflow: hidden;
    position: absolute;
    width: 1px;
    height: 1px;
    opacity: 0;
}

and to add

.mwe-math-fallback-image-inline {
    display: none;
}

.

Why is this bugged? I set it as MathML with SVG fallback in preferences, but I'm getting the SVG even though the browser is MathML capable. Thanks! —{{u|Goldenshimmer}}|✝️|ze/zer|😹|T/C|☮️|John15:12|🍂 19:58, 2 September 2017 (UTC)

I've asked this before Wikipedia:Village_pump_(technical)/Archive_155#Why_doesn.27t_MathML_display.3F, and it's on Phabricator https://phabricator.wikimedia.org/T147319.User:GKFX^talk 14:20, 3 September 2017 (UTC)

Thanks GKFX! —{{u|Goldenshimmer}}|✝️|ze/zer|😹|T/C|☮️|John15:12|🍂 17:21, 3 September 2017 (UTC)

Page move selector not available under More due to interaction with GoogleTrans

I'm noticing that Page move is not available under 'More' to the right of the watchlist star. No other function is available either. Mousing over 'More' pops up 'GoogleTrans (on)' (which I don't want and haven't noticed before) and clicking 'More' merely highlights the box that it is in. Purged the page, same problem. Went to another article, same problem. Switched browsers (from Chrome, to Opera, IE, Safari) same thing. Mathglot (talk) 04:35, 3 September 2017 (UTC)

I clicked the 'GoogleTrans (on)' to turn it off, which brings up a dialog box, where I selected GoogleTrans off but that doesn't help. Please roll back this release. Mathglot (talk) 04:39, 3 September 2017 (UTC)

'Move' can be accessed from article Talk space but still not from article mainspace. Mathglot (talk) 04:46, 3 September 2017 (UTC)

@Mathglot: can you verify you can select the page in Special:MovePage? — xaosflux ^Talk 04:50, 3 September 2017 (UTC)

Also check in Special:Preferences#mw-prefsection-gadgets to see if you have that gadget enabled. — xaosflux ^Talk 04:51, 3 September 2017 (UTC)

Yes, it's fixed now; thanks for quick work! If it recurs, here's a workaround: Special:MovePage/Article_pagename.   Mathglot (talk) 04:57, 3 September 2017 (UTC)

And you're right, that item was selected in Preferences; I've unselected it. Thanks again, Mathglot (talk) 04:58, 3 September 2017 (UTC) Adding ping @Xaosflux:. Mathglot (talk) 05:01, 3 September 2017 (UTC)

Ping to @Endo999:, GoogleTrans maintainer. — xaosflux ^Talk 15:07, 3 September 2017 (UTC)

the call for placing the GoogleTrans gadget in the MORE combo box is a Wikipedia standard, and this code hasn't changed for years. I did notice that MOVE appears when I go to Platoon_535, Embree–Trefethen constant, in fact, any random article, but the MOVE doesn't appear on the main page. I suggest this is intended because most users aren't allowed to move such pages. Anyway, this weekend I'll look at the code to see if any new standard call has replaced the old one. Endo999 (talk) 15:29, 3 September 2017 (UTC)

It was broken on every (article) page I looked at until 04:55, 3 September 2017 (from numerous browsers) and working properly on every page I looked at after that. HTH, Mathglot (talk) 18:40, 3 September 2017 (UTC)

Lint sometimes reports outer template instead of inner template that is the real culprit

Right now on Lint errors: Tidy whitespace bug Lint errors: Tidy whitespace bug, it shows Yesh Atid and says that the error is in {{Infobox political party}}. On clicking on the edit link, it highlights the entire {{Infobox political party}}. But in reality, I believe the error is in the {{nowrap}} template nested within. It should list the inner {{nowrap}} on the Lint Errors page and the edit link should highlight the {{nowrap}} call. I have intentionally not corrected the whitespace bug so that greater gurus can see the Lint Errors bug. By the way, is there a way to run an edit preview through Tidy? —Anomalocaris (talk) 08:02, 3 September 2017 (UTC)

You have just been told at #URLs in special wikilinks can't handle question mark that Wikilinks don't support query parameters. A working link is Lint errors: Tidy whitespace bug. The post is about this link. PrimeHunter (talk) 09:46, 3 September 2017 (UTC)

PrimeHunter: Thank you, but I don't think you understand the issue I have raised here. I am saying that Lint is localizing the Tidy whitespace bug too broadly and it should narrow it down. —Anomalocaris (talk) 09:53, 3 September 2017 (UTC)

I understand the issue but didn't reply to it. I just fixed your broken link to help others looking into it. PrimeHunter (talk) 09:57, 3 September 2017 (UTC)

Update: Because I have fixed many Tidy whitespace bugs, Yesh Atid is now on the first page, viz.: Lint errors: Tidy whitespace bug.—Anomalocaris (talk) 09:53, 3 September 2017 (UTC)

Nested templates are generally always a headache (for developers and end-users). It seems like something or someone has already fixed the underlying issue. What is left there is a cache of the previous lint error. So it is hard to tell whether that was actually the case. Generally though, individual templates may not trigger such errors but sometimes they do when combined. It might be worth getting a bot to purge all those pages with high priority lint errors. To reduce the time people waste chasing down ghost errors.

> By the way, is there a way to run an edit preview through Tidy?

There is a parser migration extension / preference that allows one to see what it would look like once the parser is switched, see mw:Parsing/Replacing_Tidy/FAQ . 10:13, 3 September 2017 (UTC)

Someone is editing the Tidy whitespace bug pages with great speed, so I don't know how much longer Yesh Atid will be listed, but it is listed right now. The true error is {{nowrap|[[Liberalism]]<ref name="DW">{{Cite news |first=Günther |last=Birkenstock |title=Yair Lapid, the big winner in Israel's elections |publisher=Deutsche Welle |date=24 January 2013 |url=http://www.dw.de/yair-lapid-the-big-winner-in-israels-elections/a-16546766 |accessdate=26 January 2013}}</ref><br>[[Secularism]]<ref name="Secularists">{{cite news |author= Jodi Rudoren |date=29 January 2013 |url=https://www.nytimes.com/2013/01/29/world/middleeast/israeli-secularists-find-their-voice-in-yair-lapid.html?pagewanted=all |title=Israeli Secularists Appear to Find Their Voice |newspaper=The New York Times |page=A4 |accessdate=19 September 2013}}</ref><br>[[Social liberalism]]<ref name="AFP">{{Cite news |first=Judith |last=Evans |title=Israeli election: Live Report |agency=AFP |publisher=Yahoo! News Singapore |date=23 January 2013 |url=https://sg.news.yahoo.com/israeli-elections-live-report-173532066.html |accessdate=14 June 2015}}</ref><ref>{{cite news |url=http://www.jpost.com/Opinion/Editorials/A-capitalist-government-306747 |title=A capitalist government|author=Editorial |newspaper=The Jerusalem Post |date=2013-03-17 |accessdate=2015-02-02}}</ref><br>[[Zionism#Liberal Zionism|Liberal Zionism]]<ref>{{cite news |author=[[Carlo Strenger]] |url=http://www.haaretz.com/blogs/strenger-than-fiction/.premium-1.578511 |title=Israel today: a society without a center |publisher=Haaretz |date=7 March 2014 |accessdate=14 June 2015}}</ref> }} and what's required is to remove the space before the closing curly braces. But the Tidy whitespace bug is reporting the bug as being in the surrounding {{Infobox political party}}. The outer template is not the problem. The problem is within {{nowrap}}. —Anomalocaris (talk) 10:43, 3 September 2017 (UTC)

It might have been the case at some point. But they deployed a recent update that improves the reporting: https://phabricator.wikimedia.org/T173096 . The problem of course is that they don't currently refresh the pages when they deploy these updates, so there are certainly a lot of false positives in those lint errors. Although new ones will pop up eventually as users edit pages. 197.218.90.181 (talk) 10:55, 3 September 2017 (UTC)

TemplateData on documentation pages not working

Wikipedia:TemplateData/Tutorial#TemplateData says that "The TemplateData is added to the template page itself inside tags, or anywhere on the template's documentation page if it has one." However, when I added some TemplateData to Template:Float box/doc, and then went to the sandbox to test it, I could only see it having an effect if I tried to insert Template:Float box/doc itself, rather than Template:Float box. Is this normal, or have I done something wrong? User:GKFX^talk 14:12, 3 September 2017 (UTC)

There is usually a considerable caching delay on TemplateData, that might have something to do with it. —TheDJ (talk • contribs) 14:25, 3 September 2017 (UTC)

Wikipedia:TemplateData/Tutorial#Limitations and questions mentions a delay. PrimeHunter (talk) 14:31, 3 September 2017 (UTC)

That's possible, but I see the same effect for Template:Biochem reaction subunit, whose template data is about 19 hours old at the time of writing, and it seems a bit odd that the data takes effect immediately for the /doc page but not for the intended target. I'll wait a bit longer. User:GKFX^talk 14:53, 3 September 2017 (UTC)

I just null-edited both templates. Did it help? I don't use or edit TemplateData, so I can't test it myself. – Jonesey95 (talk) 15:37, 3 September 2017 (UTC)

I don't think that a null edit is necessary; a WP:PURGE on the template (not the doc subpage) should do it. --Redrose64 🌹 (talk) 15:42, 3 September 2017 (UTC)

A purge will update the display of the template page itself. TemplateData is used when you add or edit template calls with VisualEditor. It shows up now for {{Float box}} but I don't know whether it was triggered or the normal delay just ended. PrimeHunter (talk) 16:00, 3 September 2017 (UTC)

Wonderful, they both now work. Thank you all! User:GKFX^talk 19:23, 3 September 2017 (UTC)

Jonesey95 is correct: TemplateData requires a null edit (or patience). A purge has no effect. Whatamidoing (WMF) (talk) 17:11, 4 September 2017 (UTC)

"Enable previews" button when logged out -- where is "Disable previews"?

The problem

When logged out, I can enable article previews, but cannot figure out how to disable them. The image on the right is illustrative of the problem. Eman235/talk 21:48, 3 September 2017 (UTC)

When you open a page preview, there is a cog wheel inside it, which allows you to disable. You can also do it straight from the preferences, at "Appearance" -> "Page previews". —TheDJ (talk • contribs) 10:07, 4 September 2017 (UTC)

Aha, thank you. (And of course I would have just used the preferences, but this was a logged-out problem.) Eman235/talk 20:11, 5 September 2017 (UTC)

Watchlist cuts off at 250 entries

No matter how long a timeframe ("Period of time to display") I select, I only seem to be getting at most 250 entries. I know in the past I've been able to select longish timeframes and see the full timeframe, which based on the usual edit loads is well over 250 entries. Is this a new hardcoded limit, or is something timing out somewhere? DMacks (talk) 04:18, 4 September 2017 (UTC)

@DMacks: This is new. You can set a maximum of 1000 in Preferences. Jc86035 (talk) 04:25, 4 September 2017 (UTC)

Thanks! DMacks (talk) 04:33, 4 September 2017 (UTC)

Wikidata description editing in the Wikipedia Android app

Wikidata description editing is a feature being rolled out on the Wikipedia app for Android. While this primarily impacts Wikidata, the change also addresses a concern about the mobile versions of Wikipedia. Now the mobile users will be able to directly edit the descriptions shown under the title of the page and in the search results from the Wikipedia app. We began by rolling out this feature months ago to a pilot group of Wikipedias in the beginning (Russian, Hebrew, and Catalan), then to all the others, and have seen very positive results including numerous quality contributions in the form of new and updated descriptions, and a low rate of vandalism. We are now ready for the last phase of rolling out this editing feature, which is to enable it for English in a few weeks.

As always, if you have any concerns, please reach out to us on wiki at the talk page for this project or by email at reading@wikimedia.org. Thanks!

Elitre (WMF) (talk) on behalf of-DBrant (WMF), 13:31, 4 September 2017 (UTC)

We have recently removed the Wikidata description from the mobile site, see Wikipedia:Village pump (proposals)/Archive 138#Rfc: Remove description taken from Wikidata from mobile view of en-WP, where the reading team agreed to turn this off. Either this description is not visible in the app, in which case this new "feature" will do absolutely nothing here, or it will at the same time make the description again visible, which would be rather surprising and premature. Like I said at the RfC, this is the wrong solution for this problem (but a typical effort in pushing Wikidata instead of looking for the easiest and best solution). Descriptions, being language-dependent, don't belong in Wikidata, which is meant for common things across language versions. Descriptions should be (if we need them at all) stored on local wikis, where changes to them will be much easier and faster spotted by people fluent in the language and actualy watching the article, and then wouldn't require an extra "edit wikidata through this link" on every page.

Please don't rollout this "feature" here.

Oh, and I don't edit Mediawiki, and these discussions should be out in the open, not done by email, so please check concerns here instead. Fram (talk) 14:07, 4 September 2017 (UTC)

Hi Fram, I think some clarification will help here, but definitely let us know (I know you will ;)) if you continue to have concerns. Wikidata descriptions have been in the Android and iOS apps for several years now and we are talking about a feature in the Android app that will allow a user to edit what they see. For the apps, this makes the feature more robust, solving a primary concern people have raised about having something appear that previously could not be edited from Wikipedia. We have launched it in all languages except English (English is our last) and the contribution quality and rate has been stunning. The mobile web is a different situation: Wikidata descriptions were launched on the mobile web of en-WP in January of 2017, and the RFC in March was to remove them from mobile web of en-WP, which we did. We are not talking about rolling any new features out onto the mobile web at this time.

As to the overall issue mentioned in the RFC about wikidata description storage in the first place, I agree that descriptions, being language specific, add the least marginal value to being in Wikidata--I think the argument for having them becomes one of simply storing all of the structured data in one place. If we store them instead on each Wiki, it becomes very hard to pull it, as each project uses different rules, etc and Wikidata is expressly designed to store this effectively. But you are right that there are downsides, which the team has acknowledged from the beginining. If we make it so that you can edit it from Wikipedia and you can track it from wikipedia (as though it were an article edit), I think we can get the benefits without the downsides of storing it on Wikidata. This feature is a step in the direction of mitigating an issue that has been there for several years as we progress towards making it even better. Jkatz (WMF) (talk) 15:41, 4 September 2017 (UTC)

Let me get this straight (as I may misunderstand): when we discovered that Wikidata descriptions were shown in mobile (which most admins and editors, being editors, don't use that often if ever), we got you (WMF) to remove it after some discussion. But no one at your side thought to inform us that the same descriptions, with the exact same serious issues, where also shown in the andoid app (and presumably elsewhere), and that they should have been removed there as well at the same time? That's... staggering.

The feature doesn't make this "more robust", that's like calling two snowflakes more robust than one; it makes it marginally less problematic, while adding a link and siphoning mobile editors to Wikidata, which is problematic (as these editors now will have to learn mutliple editing environments instead of one, with different approaches and policies (or in the case of Wikidata, a severe lack of them)).

Please first remove the Wikidata descriptions from anywhere they are shown on enwiki, and then discuss a) solutions and b) timelines to roll them out. Fram (talk) 15:54, 4 September 2017 (UTC)

I'm glad we can at least agree that the present change (enabling users to edit descriptions in a situation where they already see them, rather than "mak[ing] the description again visible") is a step in the right direction regarding the concerns raised in the context of the RfC, even if we disagree about the step's size ("marginally" - I think it's actually a large and important step; it was listed as blocker back then). Regarding "adding a link and siphoning mobile editors to Wikidata": The new feature is limited to editing descriptions and no other Wikidata content, while keeping the app's full existing Wikipedia editing capability. The feature includes an onboarding experience educating users about what content is appropriate (based on the corresponding content guideline, which does actually exist, despite the insinuation above), plus notifies them if their edit has been reverted. In both aspects, this is ahead of the normal (Wikipedia) editing experience on mobile (web or app).

"when we discovered " - who exactly is "we"? "thought to inform us" - As far as I recall, the fact that the app shows these descriptions had been highlighted and discussed several times on enwiki village pump pages since 2014, both by WMF staff and volunteer editors. And in the context of the withdrawn March/April 2017 RfC, several WMF staff mentioned the app too, e.g. Chris ("They [Wikidata descriptions] are used in the mobile app for searching and in the articles as short descriptions"), and Olga (the product manager of the team responsible for mobile web) who highlighted the exact Android app editing feature that we are talking about now. The need for such a feature was also expressed subsequently in a thread on this very page: "How can I edit the subtitle used in the official (Android) mobile app?".

BTW: '"most admins and editors, being editors, don't use [mobile versions of Wikipedia] that often if ever" - I find that a rather surprising claim. Is there data to back it up? (The fact that most editing happens on desktop does not imply that people make edits are not also using their phones to read Wikipedia in other situations.)

Regards, Tbayer (WMF) (talk) 18:01, 4 September 2017 (UTC)

@Tbayer (WMF): You misunderstood me, I didn't claim that this is "a step in the right direction", I consider it a step in the wrong direction, a band-aid across a festering wound. Please link to the appropriate content guideline which you claim exists. ""when we discovered " - who exactly is "we"?" The enwiki admin and editing community which cares about these things? When I raised this issue for the first time, most editors indicated their surprise (and dismay) about this. ""thought to inform us"" at the RfC, where the WMF indicated that they would remove this from the mobile view. Instead of asking these questions, you could have read the discussion I linked to in my first post, and the discussions linked to from there, like Wikipedia:Administrators'_noticeboard/IncidentArchive950#Hard_to_detect_mobile_vandalism. Then you would see that this came to many people as a surprise, and that the request was to remove these descriptions from mobile view (without an exception for e.g. the android app). The official communication from the WMF was "Hi all, based on the raised concerns, we have decided to turn the wikidata descriptions feature off for enwiki for the time being." I don't see anything there indicating "but we will keep it on the app, and perhaps on other places as well, haha!". At no time in that RfC was there any indication that this feature was kept alive at the app (and perhaps elsewhere?).

As for that later Village pump discussion; comments include "You can only edit it on what's rapidly becoming my least favorite website, Wikidata", "I will leave it to the community to decide if the spirit of the RFC is being complied with by those results.", "this is not just a problem when viewing a page (which the English Wikipedia community has expressed concerns with) but that this non-enwiki data is also being shown on English Wikipedia search results. Is this being addressed? ". I don't see any enthusiasm for getting that description from Wikidata though. Fram (talk) 06:57, 5 September 2017 (UTC)

So you made an assumption about mobile web and the app being the same thing and now that your assumption is proven wrong you make this someone else's problem ? That doesn't seem entirely fair to me either. I'm sure assumptions were made by multiple people. —TheDJ (talk • contribs) 09:09, 5 September 2017 (UTC)

?? No. I made the assumption that WMF people would be competent and fair. Why I still make that assumption is not clear, I am probably fooled by those that are and forget that usually one encounters the other type (most only lacking one or the other trait, sometimes both). Please indicate how and where at the RfC it was made clear that the app would not be affected by the promised shutdown by the WMF, considering that it was included in the discussion and faced the exact same problems? The RfC was to remove descriptions from mobile view, and one of the ways to get a mobile view of enwiki is through the android app (see List of Wikipedia mobile applications and Help:Mobile access). How you can equate this with "make this someone else's problem" is not really clear. Fram (talk) 09:41, 5 September 2017 (UTC)

We were having an RFC where we directly talked to the mobile WEB team, and hardly ever mentioned the mobile apps (it was clearly in the original complaint, but not so explicit in the RFC). There is also a BIG difference between app development and web development, as releases for the App team are much more involved and rare than for the weekly web releases and they have different product managers and teams. The feature was also already enabled in apps for months, before it was intially brought to mobile web, so I don't think it's illogical for the mobile web product manager to not consider the desired and 'assumed' impact for a totally different team. If you want to be combatitive about something like that, then that is up to you, but I prefer to keep this discussion constructive. —TheDJ (talk • contribs) 10:02, 5 September 2017 (UTC)

No, we were having an RfC where we talked to the WMF, and everyone (bar you) could give a flying fuck what TEAM we were talking with. Furthermore, according to the RfC, our contact at the WMF was someone from the Reading team, not the mobile WEB team or the App team or whatever. I would much like to see some constructive criticism from you here, instead of the obstructive comments you have made so far. When we get a promise from the "WMF reading team" (their words), and when the "Senior Director, Head of Reading" is directly involved as well, I don't think it is really useful or fair to claim that it should have been obvious that we were talking to the mobile web team only, and that they are incapable of contacting other WMF teams to raise our concerns. Fram (talk) 10:11, 5 September 2017 (UTC)

I'm walking away from this 'discussion', as this will not lead to anything good. —TheDJ (talk • contribs) 11:05, 5 September 2017 (UTC)

"Discussion" as in "The DJ tells something wrong, gets corrected, tells something else that's even more incorrect, gets corrected again, and walks away"? No idea why you even bothered to show up. Fram (talk) 11:24, 5 September 2017 (UTC)

Before the RfC started, TheDJ actually tried to clarify the issue (in a post you replied to) at Wikipedia:Village pump (technical)/Archive 154#Wikidata description in mobile view on enwiki: "It should be pointed out that the descriptions are used in many more areas (including the mobile app, search results and dozens of downstream tools like https://tools.wmflabs.org/monumental etc). I don't see how turning it off in one place, would move us much forward, and I fear that with reduced visibility of Wikidata labels the problem will become larger instead of smaller." PrimeHunter (talk) 16:11, 5 September 2017 (UTC)

Good for him. That doesn't change the mistakes in his above statements, making it seem as if it is our (or my) mistake that this is only turned off in one form of mobile Wikipedia view and not others, because I only talked with the Reading team which obviously only deals with one kind of reading and not others. Urging the WMF to turn the descriptions off in those other areas would be much more useful. Fram (talk) 04:53, 6 September 2017 (UTC)

(Moving and outdenting the following two comments, as they appear to pertain to the original post rather than forming part of the subsequent conversation. --Tbayer (WMF) (talk) 03:02, 9 September 2017 (UTC))

I can't help but have misgiving about this Having had a rash of image vandalism recently where the vandalism even after purging on the desktop or mobile sites remains visible on the app, we now have the facility to easily vandalise article descriptions that is a) not going to be seen by most people who are in a position to do something about it and b) may remain visible even after the descriptions are corrected on Wikidata. Doesn't sound like the best advert for Wikipedia, and yes I have read the mediawiki page and the protections proposed. Nthep (talk) 21:54, 4 September 2017 (UTC)

I don't see the logic here. We have seen similar problems with google, apple dictionary and museum websites etc after vandalism. If we don't want to have an open door for vandalism, get pending changes introduced already and stop pretending that we are an open wiki. As long as make things as complicated for ourselves as we do, problems like these are inevitable and you should just file bug reports for them. —TheDJ (talk • contribs) 09:07, 5 September 2017 (UTC)

For the record, the image vandalism was referring to the "In the news" problem reported above, now being investigated at phab:T174993. This looks unrelated to the descriptions (it's a different part of the app and a different data source).

In general, vandalism is of course always a possibility, both on Wikipedia and Wikidata. Enabling users to fix it if it happens (or to make other improvements) is in fact among the benefits of this new editing feature on the app. Conversely, ensuring that contributions via that new button aren't becoming a major new source of vandalism on Wikidata has been very much on the team's mind when developing the feature. (As a reminder, the main (Wikipedia) article content has been editable from the app for a long time.)

At this point, over 60,000 description edits have already been made with this app feature; and we have been monitoring it closely (in particular the revert rate) since February, when it was activated for the first few Wikipedia languages. Nthep, you mentioned that you already looked at feature's documentation page which mentions e.g. the tools that the Wikidata community has made available this year which allow improved monitoring of description edits. There is also a subpage with the results of the data analysis.

When the initial data looked good, the feature was gradually rolled out to more languages. Since July, it has been active on all languages except English. Of course the positive results in the other languages do not offer an absolute guarantee for English, so we're going to monitor the impact of the rollout there as well. Regards, Tbayer (WMF) (talk) 03:02, 9 September 2017 (UTC)

Bug in mobile view

In Wikipedia articles, subsections are collapsed by default. But in Wikipedia templates, you will have to scroll down through entire documentation. There no collapsible section. Can this be made collapsible so that scrolling can be reduced? -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 18:55, 4 September 2017 (UTC)

@Capankajsmilyo: No. See T173168 and T114072. I also don't think this would be seen by WMF as worth the effort just to fix a non-reader-facing problem, since articles are never enclosed entirely in a div. Jc86035 (talk) 09:36, 5 September 2017 (UTC)

Tech News: 2017-36

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

Tech News

• We are asking Tech News readers five questions to make the newsletter better. You can answer the questions here. We are grateful for every reply we get.

Recent changes

• The RevisionSlider user interface has changed. You can now select revisions by clicking on the bars. You can move the blue knob past the yellow one and the yellow one will move along, and the other way around. [11][12]

Problems

• Some users have problems loading very large watchlists. It is working better than earlier but the problem has not been solved. The developers are working on fixing it. Until it has been fixed you can turn on "Expand watchlist to show all changes, not just the most recent" in your preferences and see if it helps. [13]

Changes later this week

• New filters for edit review is a beta feature to improve recent changes pages. It will work on watchlists from 5 September. [14]
• The new version of MediaWiki will be on test wikis and MediaWiki.org from 5 September. It will be on non-Wikipedia wikis and some Wikipedias from 6 September. It will be on all wikis from 7 September (calendar).

Meetings

• You can join the next meeting with the Editing team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on 5 September at 19:00 (UTC). See how to join.
• You can see a presentation about and discuss the new Technical Committee on 5 September at 17:30 (UTC). There will be a presentation on YouTube and a discussion in #wikimedia-office on Freenode. You can use the web chat. [15]

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

22:14, 4 September 2017 (UTC)

Am I only one with unresponsive API?

Can't edit via VE. I see through the browser's developer tools requests to api.php that are sent, but never responded to. In fact, manually entering https://en.wikipedia.org/w/api.php?action=blah results in at least 10s response time, unusually. What's up? KPu3uC B Poccuu (talk) 02:12, 5 September 2017 (UTC)

It was working for me at almost exactly the time that it wasn't working for you.[16] What's your browser/OS? Is there anything unusual about your internet connection? Is it working for you now? Whatamidoing (WMF) (talk) 03:22, 5 September 2017 (UTC)

Vivaldi latest stable on Win10x64. My connection is most likely to be working, as I can visit anything w/ no trouble, including heavy content like videos or online stores, and the same page I was trying to edit is refreshed no problem. Only VE originating requests to api.php somehow didn't go through.

P. S. I just checked, I still can't edit Somatic evolution in cancer. KPu3uC B Poccuu (talk) 03:29, 5 September 2017 (UTC)

Any help? I still can't edit via VE, even after reboot and trying in a different browser logged out. KPu3uC B Poccuu (talk) 01:55, 6 September 2017 (UTC)

Can you take a look at phab:T173858 and tell me if anything about that sounds familiar to you? It's based upon the report at mw:Topic:Twpg9elwi18x98m6. Whatamidoing (WMF) (talk) 01:47, 7 September 2017 (UTC)

WP keeps throwing away my edits

Since yesterday, I have had problems contributing to discussions on project pages like this one and my User Talk.

Sometimes (but not always) when I edit a section, it shows me two edit panels - the lower one looks like the panel I'm used to (I never use Visual Editor) and the upper one has a different font - I think it may be the VE, but I've hardly ever used it. I've discovered that if I add a reply in the lower one, my text just disappears when I hit Preview or Save Changes. I think that if I edit in the upper one it takes my text (but one time I had three attempts to correct something in that window before my correction took). I did not intentionally change any preferences before this stopped happening (though I did accidentally go to my preferences page once yesterday, when my machine was being slow: I don't believe I changed anything then though). Afterwards I went there and selected "Always give me the source editor", but that doesn't seem to have had any effect. --ColinFine (talk) 09:31, 5 September 2017 (UTC)

@ColinFine: Can you upload a screenshot to here. That probably makes it a lot easier to make a guess as to the cause of your problem. —TheDJ (talk • contribs) 10:05, 5 September 2017 (UTC)

Thanks, TheDJ. I picked Edit on this section: a single edit panel appeared, looking like the lower one in this screenshot. Then I picked Preview, and got what you see in the screenshot. At the top is the original page, then there are two different-looking edit panels, neither of them containing my new text (you can't see that in the bottom panel, as I couldn't get it all on the screen, but it's not there).

I'm typing this reply now in the middle panel: I shall copy it before I hit Preview, because I have no confidence that WP isn't going to throw it away again. --ColinFine (talk) 11:19, 5 September 2017 (UTC)

This is due to incompatabilities between wikEd and the new beta feature for SyntaxHighlighting that is in your Beta-preferences. Disabling either one will solve your problem. —TheDJ (talk • contribs) 11:22, 5 September 2017 (UTC)

Thank you. I now remember it offering me Syntax Highlighting out of the blue - I thought it was before yesterday, but maybe I was wrong. So it's true that I hadn't been to my preferences page, but not that I hadn't changed my preferences. However - I have now tried three or four times to turn syntax highlighting off in my preferences page, and it won't go away. So I've turned WikEd off. --ColinFine (talk) 11:32, 5 September 2017 (UTC)

As Cacycle, the developer of wikEd has not been active for a while, I have made some changes to his gadget, to avoid loading when the beta is enabled. That should be a bit safer for the average joe. —TheDJ (talk • contribs) 11:48, 5 September 2017 (UTC)

Also reported a ticket about not being able to disable the beta feature. Thanks for reporting that. —TheDJ (talk • contribs) 11:55, 5 September 2017 (UTC)

WikiProject assessment page not updated after running "Update project data"

For WikiProject Catholicism Assessment page it does not update the "Importance" column labeled with "???" after I ran the "Update project data" (http://tools.wmflabs.org/enwp10/cgi-bin/update.fcgi). Even after doing "Purge", logging off, checking again after several hours. This is not urgent, but it used to work correctly & now not. Regards, — JoeHebda • (talk) 12:33, 5 September 2017 (UTC)

Update - ran "Update project data" today & now it worked okay. Thanks. — JoeHebda • (talk) 21:00, 6 September 2017 (UTC)

Is there a bot that cleans external link problems in refs?

List of Brigham Young University alumni has quite a few "External link in |work=" and "External link in |publisher=" reference problems. Is there any way to automatically or semi-automatically fix them? A bot maybe? --Ronz (talk) 14:59, 5 September 2017 (UTC)

@Ronz: Both WikEd and 2017 wikitext editor have a regex find and replace module for use. Failing that, Notepad++ and I would expect some other text editors also have regex find and replace. --Izno (talk) 15:07, 5 September 2017 (UTC)

I have an AutoEd script at User:Jonesey95/AutoEd/unnamed.js that fixes some of them. It is nowhere near bot-ready, though; it needs to be supervised to watch for false positives and edits that erroneously match a pattern that it should not. – Jonesey95 (talk) 15:56, 5 September 2017 (UTC)

Expand templates for Mobile view

Is there a page like Expand templates that shows the expanded template for mobile view? -DePiep (talk) 21:02, 5 September 2017 (UTC)

What do you mean? Special:ExpandTemplates works in both the desktop and mobile version. Some templates render differently or not at all in mobile but that's because of the code they produce and not because they are templates. PrimeHunter (talk) 21:20, 5 September 2017 (UTC)

Thx. So we know, some templates show different in mobile view (visual changes). You say that is not because for mobile, a different (HTML-)code is produced from m.wikipedia? It's the mobile browser only that renders it differently? (eg, class=navbox does not show, ignoring css-textformatting like lineheights). -DePiep (talk) 06:36, 6 September 2017 (UTC)

If you just want to see how something renders then you can preview it anywhere at desktop or mobile (some things depend on the namespace and a few on the page name). The main purpose of Special:ExpandTemplates is to see the generated wikitext from wiki source using templates. As far as I know, exactly the same wikitext is generated at desktop and mobile. I don't know whether different html is generated from the wikitext. The bottom of all desktop pages have a "Mobile view" link. This includes Special:ExpandTemplates although it doesn't remember content you entered before switching. PrimeHunter (talk) 12:34, 6 September 2017 (UTC)

No. This doesn't exist on wikimedia wikis (https://phabricator.wikimedia.org/T85587). Although wikia does have something of like this (http://community.wikia.com/wiki/Help:Preview) that could perhaps be made into an extension or tool. It can't work like special:expandtemplates because the server also provides a different sitewide CSS. In addition, certain changes also depend on screen width and height. 07:56, 6 September 2017 (UTC) — Preceding unsigned comment added by 197.218.91.7 (talk)

Should we ask for mapframe to be turned on?

Tracked in Phabricator
Task T175102

Mapframe is an extension that is being developed by the WMF to show small OpenStreetMap maps in articles. Background information is at mw:Help:Extension:Kartographer. It is currently enabled on some Wikipedias that have opted in, and I think it would be useful here as well. Personally, I'm interested in using this in Wikidata-driven infoboxes such as the one at Lovell Telescope to replace {{Location map}} with OSM data, but it also has wider applications. I don't think that it interferes with existing coding here, so it just adds functionality that we can use. I can't spot any previous discussions about this, so I'm starting this discussion here to try to determine consensus. Also see phab:T138057 and phab:T175102 Thanks. Mike Peel (talk) 00:29, 6 September 2017 (UTC)

Agree I think it would be a major benefit to have proper interactive maps in all Wikipedias, not just the ones that opted in. <mapframe> functionality has not caused any technical issues on any other wikis. Map code is already deployed to all Wikipedias as <maplink>, so enabling it would be as simple as flipping a switch. --Yurik (talk) 00:41, 6 September 2017 (UTC)

Support This should've been done waaay sooner. Ladsgroup^overleg 10:58, 6 September 2017 (UTC)

Support. Also support T137253 converting Earth coordinates in {{Coord}} to use <maplink> as well. Jc86035 (talk) 11:27, 6 September 2017 (UTC)

Support, would be especially useful to have mapframe maps in the infoboxes of road articles. See commons:User:Evad37/sandbox/maps for some examples - Evad37 [talk] 23:48, 6 September 2017 (UTC)

Note from the Wikimedia Foundation product team: This is a totally reasonable thing to request as better maps on Wikipedia could improve the user experience and would make a lot of people happy. Previously, we had internally decided on a process to enable mapframe for new Wikipedia projects by request on a batch basis every 6 months. However, the future of maps support from the Wikimedia Foundation is uncertain and at this point I think all new communities considering adding maps should be made aware of it.

The Reading product team has been working to try to figure out how to support the existing maps implementation, and our initial analysis is that maps requires significantly more resources than were assigned to the project at inception. We are currently working on establishing if we can prioritize resources to get maps into a stable, healthy state and will update folks on a plan as soon as we have a draft for comment. It has taken longer than we would have liked to get more clarity, due to organizational changes, but I think we are making progress and should have a clearer answer by the end of September, 2017.

The current situation is that over the last several months the maps project has relied on the goodwill of individual engineers at the Wikimedia Foundation to keep it up and running in addition to individual volunteers contributing support. We also have a contractor, working on a cartographic re-skin as well as dealing with some other maps issues like disputed borders.

I am personally very nervous about having maps on English Wikipedia because we don’t know what kind of support we will be able to offer in the future and I want to minimize the amount of editor effort going into a feature that is at risk. We are frankly concerned that the resources required to maintain and make necessary upgrades to the map service are more than we can commit to.

We’d like to propose that we revisit this question in October when we have more clarity over the path forward for maps. Thoughts? Jkatz (WMF) (talk) 00:23, 7 September 2017 (UTC)

@Jkatz (WMF): Thank you for the background information on the development work. I think that there are two different issues here that can be handled in two separate stages. First, do we want to have this functionality available on enwp? That is what this discussion will hopefully decide. Second, is WMF ready to support the deployment? That is something that the WMF has to decide, and if the answer to the first question is 'yes' then the timing of the deployment is up to the WMF; if it is 'no' then the WMF is off the hook. ;-) I think that delaying this until next month doesn't help with either question, so it's still worth asking & answering the first question now. Thanks. Mike Peel (talk) 01:06, 7 September 2017 (UTC)

@Mike Peel: I think that is a totally reasonable approach. Am I correctly interpreting your intent when you say "if it is 'no' then the WMF is off the hook." to mean that if the Wikimedia Foundation is not ready to support the deployment, we will have a discussion and that you wouldn't deploy until we were? This interpretation seems like a great way to break down and approach this problem (thank you!). If, instead you mean you would deploy without our support, it makes me very uncomfortable, as it would mean deploying map infrastructure we are responsible for supporting and maintaining at a time when we are suggesting we might not be able to support and maintain it. Can you confirm that I am reading your intent correctly? Thanks. Jkatz (WMF) (talk) 03:18, 7 September 2017 (UTC)

@Jkatz (WMF): My understanding was that someone at the WMF would have to flip the switch to deploy this. Even if that's not the case, I don't think it makes sense to deploy it until the WMF is ready to support and maintain it. So let's answer the first question here (do we want it here), and then we can move over to phabricator and the WMF/devs can determine when to deploy it. Thanks. Mike Peel (talk) 12:15, 7 September 2017 (UTC)

@Mike Peel: Makes perfect sense. Thanks for clarifying! I'll probably add my note with our concerns to the phab ticket too, just so it's in the relevant places. Jkatz (WMF) (talk) 18:12, 7 September 2017 (UTC)

Issue with recent changes

I posted this at the Teahouse initially, but was referred here. In the "recent changes" section of my preferences is set to show only potentially problematic edits. Before today this has always worked. Today I logged on and went to recent changes, and it displayed as if I had not logged in, with one difference: in the options pane of recent changes, instead of saying "hide probably good edits" as would normally go with that, it said "show probably good edits" as it normally does when the feature is working. Clicking it has no effect. I checked my preferences and the feature is enabled. I am using Google Chrome version 60.0.3112.113. -A lad insane (Channel 2) 02:47, 6 September 2017 (UTC)

Hi A lad insane

On Special:RecentChanges, what happens when you click on "Show/Hide probably good edits"?

Thanks, Trizek (WMF) (talk) 12:16, 6 September 2017 (UTC)

It reloads the page but other than that has no effect on anything. -A lad insane (Channel 2) 00:52, 7 September 2017 (UTC)

Okay, this is still A lad insane, but logged out. (don't freak out, it's a dynamic IP address.) The recent changes "hide probably good edits" seems to work as an IP editor. 174.22.16.226 (talk) 15:05, 7 September 2017 (UTC)

Censorship of past edits

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.

---

Is there any special reason why certain areas of certain Edit Histories are censored? If so, it is not well explained. A clearer explanation should be posted somewhere, in the various technical and policy pages. Here is a screenshot that shows what I'm talking about:

I appreciate any and all clarifications. The Mysterious El Willstro (talk) 04:53, 6 September 2017 (UTC)

The contents of the revisions where hidden under WP:RD1 because they contained a copyright violation. See Jytdog's edit summary and the deletion log. — JJMC89 (T·C) 05:18, 6 September 2017 (UTC)

Censoring certain revisions is done under strict conditions which can be seen at WP:Revision deletion. As to any specific case, the best advice is to clock on the "View logs for this page" at the top left; and look for any entries which say "changed visibility of # revisions on page" (with some number in stead of the number sign). In cases of RD1 (copyright violation), you can frequently see the URL of the source if you look at the last revision before the time of the revision deletion log entry; in this case, it's http://www.bbc.co.uk/news/health-40752061. עוד מישהו Od Mishehu 06:35, 6 September 2017 (UTC)

The screenshot you posted is probably also a copyright violation, see WP:SCREENSHOT. (((The Quixotic Potato))) (talk) 07:42, 6 September 2017 (UTC)

I have removed the top and bottom; what's left is just our website's own content. עוד מישהו Od Mishehu 08:38, 6 September 2017 (UTC)

The top of page histories say: "For more help, see Help:Page history". The end of Help:Page history#Overview says:

"In rare cases, all or part of a page history entry may be shown in grey, struck out by a horizontal line. This indicates that information has been hidden from public view by an administrator or bureaucrat. See Revision deletion and Oversight for more on this."

It's also mentioned in other places like Help:User contributions. Is there a help page where you looked for it and think it should have been mentioned? PrimeHunter (talk) 12:17, 6 September 2017 (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.

Redirect wikilinks

In my to-do list of future articles some entries are redirects and thus are blue rather than red, so I have to regularly click on them to check whether some of them became articles. Is there some tool or template that facilitates distinction between redirects and articles among blue wikilinks in real time without redundant clicks (e.g. by labels, different color or hovering popups)? Brandmeister^talk 10:57, 6 September 2017 (UTC)

It ought to be possible - Special:EditWatchlist shows redirects in italics. Mitch Ames (talk) 11:43, 6 September 2017 (UTC)

User:Anomie/linkclassifier. PrimeHunter (talk) 12:02, 6 September 2017 (UTC)

The simplest change is to add something to your common.css file of the .mw-redirect {css here} sort. I happen to have .navbox .mw-redirect, .vertical-navbox .mw-redirect { font-style: italic; color: red; } so that I know when there is a redirect in a navbox, but not elsewhere in a page. --Izno (talk) 15:50, 6 September 2017 (UTC)

Temporary unavailability

There was a short unavailability, a few minutes ago, at least from some places.

http://downdetector.com/status/wikipedia

(See also https://status.wikimedia.org/ )

All the best: Rich Farmbrough, 16:03, 6 September 2017 (UTC).

@Rich Farmbrough: Is this a note for readers' and editors' interest, or what is the intention behind posting this? --Malyacko (talk) 18:08, 6 September 2017 (UTC)

It is of interest, and I would hope someone would be long shortly to tell us what happened. Why do you ask? All the best: Rich Farmbrough, 18:10, 6 September 2017 (UTC).

Why not all templates are equal for mobile users?

I did some quick search, and it seems to be something about how HTML works? I'm not sure though. I just know that some infoboxes works just fine in mobile view, but some will just "break" the page in mobile view. Also, sometimes the information on an infobox (say, First World War) will work just fine, but the "Theaters" field will not show on the mobile site. User:Tetizeraz. Send me a ✉️ ! 23:53, 6 September 2017 (UTC)

Which infoboxes on which articles break what, on which phone and which browser? (((The Quixotic Potato))) (talk) 00:25, 7 September 2017 (UTC)

The Quixotic Potato None in this is breaking this article. I'm just checking in the mobile view on my desktop (Firefox v55, Fedora Linux 26). However, as I mentioned in my original question, some templates don't show up, and I would argue they are great links for curious people about a subject. Yes, they are linked somewhere in the article, but it appears earlier than those mentions. Anyhow, Template:Campaignbox World War I and Template:Events leading to World War I don't show up in mobile view, just as an example. User:Tetizeraz. Send me a ✉️ ! 01:04, 7 September 2017 (UTC)

The templates you mention appear to be based on Template:Navbox and Template:Sidebar, which do not display in mobile view, according to their documentation. – Jonesey95 (talk) 01:18, 7 September 2017 (UTC)

Good to know. THanks for the info Jonesey95. User:Tetizeraz. Send me a ✉️ ! 01:21, 7 September 2017 (UTC)

Specifically, these types of template (navbox and sidebar) are set up to belong to the navbox and vertical-navbox classes, which in mobile view are set up with the CSS declaration display:none;.

This has been mentioned several times in the archives of this page, maybe we should make it an FAQ. --Redrose64 🌹 (talk) 10:43, 7 September 2017 (UTC)

Page shows wrong image with similar name

Here in Virginia, we're stuck with both a Richmond, Virginia and a Richmond County, Virginia that are completely unrelated and nowhere near each other; it produces a bit of confusion among humans, and now apparently our image servers have gotten into the act. User:Nyttend/Virginia NRHP/City of Richmond has always included the city map, File:Map of Virginia highlighting Richmond City.svg, but for some bizarre reason it's now displaying the county map instead, File:Map of Virginia highlighting Richmond County.svg. What's more, if you mouse over the map, you're told that it's actually the city map, and clicking on the county map takes you to the city map. I discovered this upon going to the userspace page, but since I had to edit the page I didn't worry, thinking it some bizarre caching issue that would be cleared up. To my surprise, it persists despite my edit. At the same time, this isn't universal; the city map appears in the top right corner of National Register of Historic Places listings in Richmond, Virginia and in the city's infobox, for example, and the county map appears everywhere that it should. The last edit to either file was more than ten years ago, and this category tweak by me, six months ago, was the last time anyone modified either description page.

Any suggestions? I'm using IE 11 and Monobook, but the same situation appears in Firefox 55.0.3 when I'm logged out. Nyttend (talk) 11:37, 7 September 2017 (UTC)

I don't think User:Nyttend/Virginia NRHP/City of Richmond is displaying File:Map of Virginia highlighting Richmond County.svg although it looks so. I think it's displaying File:Map of Virginia highlighting Richmond City.svg but that file apparently has invalid or problematic svg code which gives different results at different resolutions when MediaWiki converts to png. You also posted about it at Wikipedia:Village pump (technical)/Archive 154#Map won't render at a specific resolution. I don't know much about the svg format but there is a text command to fill out a certain area with red. It's apparently ambiguous which area, at least to MediaWiki. With the current version of the file, the only solution may be to pick a size where it displays as intended. At Wikipedia:Village pump (technical)/Archive 154#Map won't render at a specific resolution I see the city location at 250px and 270px. But things may change if something is changed in MediaWikis svg to png conversion. The uploader is inactive since 2006 but you could try asking for a new version at Wikipedia:Graphics Lab/Map workshop or commons:Commons:Graphic Lab/Map workshop. PrimeHunter (talk) 12:23, 7 September 2017 (UTC)

Template help: Infobox family

Sorry, I realise I do need some help with merging Template:Infobox noble house into Template:Infobox family. I tried to merge the code parametres but not sure if I did it right. The rest - the docs - also need to be merged. Thanks! Chicbyaccident (talk) 20:07, 7 September 2017 (UTC)

Cannot move page that has template-protection for its move protection

Something strange is going on here. The protection levels on move protection for Template:MathSciNet and Template:MR were recently downgraded from "full" (requires an administrator) to "template protection" (must be a template editor). However, when I attempt to move either page, I receive he message "(Green lock) This page is currently protected so that only administrators can move it." with alternatives about how to move these pages. I'm not sure why this is happening: I should be able to move these pages since I am a template editor, and the protection levels for move protection on these pages have been downgraded to template protection. What is going on? Steel1943 (talk) 20:04, 7 September 2017 (UTC)

Interesting, you are indeed a template editor, so should be able to move these templates, which as you say have move protection to TE level (and edit protection to semi level). Maybe a recent software change? --Redrose64 🌹 (talk) 20:28, 7 September 2017 (UTC)

Now I can move both pages. And a template editor has since moved the pages. I suppose there is some lag someplace regarding the protection level change... Steel1943 (talk) 21:18, 7 September 2017 (UTC)

I saw (and still see)

WARNING: This page has been protected so that only users with administrative rights can move it.

• <log entry>

View full log

I moved it anyway. — JJMC89 (T·C) 22:01, 7 September 2017 (UTC)

I removed all protection, made an edit, and restored the TE protection. I don't see the admin-only warning that JJMC89 saw. Could someone with TE rights look at the template now? Nyttend (talk) 22:49, 7 September 2017 (UTC)

@Nyttend: I still see the same warning. — JJMC89 (T·C) 22:55, 7 September 2017 (UTC)

@JJMC89 and Nyttend: Though I am now able to move the page, I also see the warning message JJMC89 referenced above. Steel1943 (talk) 01:17, 8 September 2017 (UTC)

I suppose then the next question is ... what page in the "MediaWiki:" namespace is being called to display the warning message JJMC89 and I see when moving a page with template-protection-level move-protection? Steel1943 (talk) 01:26, 8 September 2017 (UTC)

@Steel1943: It is MediaWiki:protectedpagemovewarning. I think the switch there needs to be on {{PROTECTIONLEVEL:move|{{#titleparts:{{FULLPAGENAME}}||2}}}} instead of {{PROTECTIONLEVEL:move}}. — JJMC89 (T·C) 02:19, 8 September 2017 (UTC)

@Nyttend: In removing all the protection and then re-adding the protection, somehow the edit-level protection was upgraded from confirmed to template editor (without any discussion that I can currently find). I see this request to downgrade the move-level protection from admin/sysop to template editor but I see no discussion of upgrading the edit-protection from confirmed to template editor. Is there a reason for the change and can it be returned to confirmed so confirmed editors can continue editing the template? Thank you. 50.53.1.33 (talk) 09:13, 9 September 2017 (UTC)

Ah, I'm sorry — I see what you mean. When unprotecting and reprotecting, I meant to put things back just as they were; I must have misread the logs, because I thought that the thing had required TE both to edit and to move. [I don't remember ever before seeing TE required to move but autoconfirmed required to edit.] Therefore, when you asked, I thought you were objecting to the very idea of unprotecting and reprotecting, not questioning the reason for the "net upgrade" from semiprotection to TE. Nyttend (talk) 10:47, 9 September 2017 (UTC)

I appreciate you fixing that as I can now appeal to a larger set of editors to get changes made (more editors can respond to {{edit semi-protected}} than {{edit template-protected}}) and I am sure confirmed editors will appreciate being able to directly edit the template again. Thank you. 50.53.1.33 (talk) 12:09, 9 September 2017 (UTC)

Mysterious random popup

I was at MOS:NBSP and switched to another tab, then switched back; and this popup appeared. I know what a half adder is (have done for 40 years) - my question is, how is it relevant, and where has this come from? --Redrose64 🌹 (talk) 20:24, 7 September 2017 (UTC)

Oho, it's Thursday! Wacky new features time! --Redrose64 🌹 (talk) 20:29, 7 September 2017 (UTC)

I just opened Copenhagen and got 'Would this be useful to someone searching for "List of hospitals in Andorra"'. I'd love to know just who sold the WMF whatever algorithm they're using. ‑ Iridescent 20:33, 7 September 2017 (UTC)

Interestingly, we don't even have a list of hospitals in Andorra :-) Nyttend (talk) 22:29, 7 September 2017 (UTC)

But we do have a red link to it in {{List of hospitals in Europe}}. Clicking the link gives an option to search for it. I guess that's how a search got registered and placed in the test, but I have no idea why Copenhagen is suggested. PrimeHunter (talk) 23:42, 7 September 2017 (UTC)

You know what they say about incorrect proclamations. This has nothing to do with Thursday. This wiki is currently still running the prior version of mediawiki. This is likely an A/b test / survey probably to help improve the cirruSearch search engine. 20:38, 7 September 2017 (UTC) — Preceding unsigned comment added by 197.218.89.254 (talk)

You say "A/b test / survey probably to help improve the cirruSearch search engine", I say "yet more fucking about with the interface without consultation or notification". It's probably one of those tricky irregular verbs. ‑ Iridescent 20:45, 7 September 2017 (UTC)

The screenshot includes the string "would they want to read this article". I searched it at Phabricator and got three results: phab:T171740, phab:T171741, phab:T174106. It's an A/B test for Search Relevance. PrimeHunter (talk) 21:15, 7 September 2017 (UTC)

Yes, we're currently running a test for Search Relevance (graded by humans); more information can be found in this ticket: phab:T171740 and the most recent test is detailed here: phab:T174106. DTankersley (WMF) (talk) 22:48, 7 September 2017 (UTC)

I was reading the Adder (electronics) page when one of these appeared. My thoughts were " — there's a pop-up — how did that get here — it seems to be from Wikiepdia itself — it's asking me a question, I'll try to be helpful — it says 'Would you click on this page ...' — would I ever click on a page? — why might I click on a page? —" and before I could come up with a sensible answer, it vanished again. If this is intended as a way of getting useful feedback from users, it's doomed to failure. Maproom (talk) 17:35, 8 September 2017 (UTC)

This reminds me of the Article Feedback Tool. Yuck. (((The Quixotic Potato))) (talk) 19:49, 8 September 2017 (UTC)

The pop-up box is missing an important element - the checkbox or button that says "do not show me this again (ever, on an any article)". Mitch Ames (talk) 00:21, 10 September 2017 (UTC)

Linking to a result in an on-line database

The GlobIZ website allows me to search for various moth taxa; for instance pasting "Agastophanes" into the search field and clicking on the link gives good information that could be used as a reference. However, that page has the same web address as the search page. Is there a way to link directly to the search result? Is there a way to archive a search result? Thanks,  SchreiberBike | ⌨  22:07, 7 September 2017 (UTC)

Normally I'd say to use their permalink feature, but they don't have a permalink feature. Probably the only option is to cite the page and add a little note saying something like "search for agastophanes to obtain specific data". Nyttend (talk) 22:40, 7 September 2017 (UTC)

You can use the at parameter at Template:Cite web#In-source locations, e.g.:

"GlobIZ search". Global Information System on Pyraloidea. Search on Agastophanes. Retrieved 7 September 2017.

PrimeHunter (talk) 23:29, 7 September 2017 (UTC)

Replacing a template with another one when rendering a page using user JS?

Hi there. Okay, basically, what I want to do is to replace the {{Find sources AFD}} template with a customized template (like {{User:SoWhy/find more sources}}) on AFDs I view without touching the AFD's template itself (so I can add resources available to me for a quick check). Is this actually possible or does Javascript only allow manipulation of the HTML generated (which is a bit tricky afaict since the template has no id to get)? If the latter is true, is there a way to get the whole code block and replace it? I have a function in PHP that allows selection between two strings but I have no JS skills whatsoever, so my next question would probably be if someone could create such a script for me Regards SoWhy 07:06, 8 September 2017 (UTC)

I believe you can get the raw wikitext with a call to the API (I don't know if you can display another template's wikitext), but it might be easier for you simply to change the DOM. It doesn't look like the find sources template emits any sort of class to identify its use, which would be the first improvement; once that is changed, you can probably replace the generated HTML pretty trivially by selecting on the element class and then adding some generated HTML of interest. --Izno (talk) 12:49, 8 September 2017 (UTC)

Assistance requested to fix a few hundred dead links

CEEOL have identified that the majority of their approximately 450 links on Wikipedia are now dead links because of a website restructure. They're in the process of compiling a list of replacement links to send to me, but I need some community assistance in replacing all these links with their new URL. If you have the expertise/desire to fix these links in a (semi-) automated way please let me know! Samwalton9 (WMF) (talk) 10:45, 8 September 2017 (UTC)

@Samwalton9 (WMF): Can InternetArchiveBot take care of that? I don't know if it runs automatically, but it's operated by @Cyberpower678: and @Kaldari:. — Maile (talk) 11:48, 8 September 2017 (UTC)

Perhaps, though IABot does a lot more than simple replace one link with another. I have a list of pages, the old link, and the new link, it just needs something to run through the list and simply replace the text. It might want to be semi-automated so that any dead link templates can be removed too though. Samwalton9 (WMF) (talk) 12:11, 8 September 2017 (UTC)

For simple text replacement, WP:AWB is your friend.

—Trappist the monk (talk) 12:19, 8 September 2017 (UTC)

Make a WP:Bot request; a number of AWB users watch there for AWB-able cases (which this is one). --Izno (talk) 12:57, 8 September 2017 (UTC)

Thanks Izno, will do once I've got the full data! Samwalton9 (WMF) (talk) 13:08, 8 September 2017 (UTC)

Large revdel error?

Hi all, I was trying to revdel (for copyright reasons) a mass of edits at Jamai Raja (TV series), from 16:21, September 16, 2016‎ (UTC) to 16:09, September 8, 2017‎ (UTC). This took a few minutes of clicking. When I clicked the Change visibility of selected items button, Chrome returned "This site can’t be reached - en.wikipedia.org unexpectedly closed the connection. ERR_CONNECTION_CLOSED". Any thoughts on this? Thanks, Cyphoidbomb (talk) 16:21, 8 September 2017 (UTC)

Sounds like a temporary failure - try again. Try a single revision first, to make sure there isn't something else going on as well. — xaosflux ^Talk 16:31, 8 September 2017 (UTC)

I have had a problem when trying to do large chunks of articles. If I break it into smaller around 200 edits, it works. ~ GB fan 16:41, 8 September 2017 (UTC)

API:Imageinfo returns null for &iiprop=comment

Tracked in Phabricator
Task T175443

Lately, I have been getting back null for the comment value when making this (action=query&format=json&prop=imageinfo&titles=File%3AExample.jpg&iiprop=timestamp%7Cuser%7Ccomment) Imageinfo API query on File:Example.jpg. I'm expecting to see "Minor tweak to text placement; diminish image height by 1 pixel.". Could someone help confirm if this is a MediaWiki bug, or if I am doing something wrong? Thanks, FASTILY 23:34, 8 September 2017 (UTC)

That should work...I can replicate the lack of a comment every image I give it. I'm not finding anything in Phabricator about it either, you may well have stumbled onto something here. FACE WITH TEARS OF JOY ^[u+1F602] 02:23, 9 September 2017 (UTC)

Hi 😂. Thanks for the input; I just opened phab:T175443. Regards, FASTILY 06:00, 9 September 2017 (UTC)

Edit conflict options spoiling my edit

I just met an edit conflict. I now have to manage two columns, seven colors, twelve options, and still cannot get it. Right now, a straight F*K YOU is appropriate. -DePiep (talk) 00:38, 9 September 2017 (UTC)

What are you going on about? Edit conflict management is a lot better now. On the right is the current version of the page. On the left in yellow are your changes. I haven't had an edit conflict in a while, but I believe the changes made by the editor who caused the conflict will be highlighted blue. Amaury (talk | contribs) 00:41, 9 September 2017 (UTC)

I said: it is NOT better. I see lots of colors, dozens of options, and loads of textual 'helps'. Two columns, five text squares. Fussed texts. Texts talking about "your text" — which is invisible. -DePiep (talk) 00:46, 9 September 2017 (UTC)

It's not even a process (wizard, step-through). -DePiep (talk) 01:05, 9 September 2017 (UTC)

Wait, isn't the new edit-conflict interface opt-in-only, under beta features? I agree that the old one was plain awful, and I generally had to resort to going back in my browser to retrieve my edit manually. —Cryptic 02:52, 9 September 2017 (UTC)

Yes, it's normally opt-in (at Preferences → Beta features); but if DePiep has "Automatically enable all new beta features" set at the top of that page, it becomes opt-out - but they can't turn off individual beta features without turning off "Automatically enable all new beta features" as well. --Redrose64 🌹 (talk) 07:16, 9 September 2017 (UTC)

{{Archive box collapsible}} seems to be broken when using Google Chrome

Transcluding issue here for help, please.

UPDATE: I just looked at {{Collapse}} and have the same issue. What should be expandable sections don't display the [show] button. So it's apparently something to do with the way Chrome handles that function. Thanks for any help that can be offered!—D'Ranged 1 | VT^alk :  10:09, 9 September 2017 (UTC)

Works for me in Google Chrome 61.0.3163.79 on Windows 10. Try updating Chrome and restarting the computer. PrimeHunter (talk) 10:20, 9 September 2017 (UTC)

Most of the time, it means one of your userscripts/gadgets/browser extensions broke. I didn't fully look into your scripts, but at least this from User:D'Ranged_1/vector.js was causing you fatal errors on every page load. Please regularly evaluate what you use, and if it creates errors in your browser's console. See also: Help:Locating broken scripts. —TheDJ (talk • contribs) 10:37, 9 September 2017 (UTC)

Template vandalism somewhere

Hey detectives, I know that there's some template vandalism somewhere, but I'm having trouble tracking it down. I was searching for spam links to songsportalhd.tk. There are three articles that contain the links,

• List of castra in Romania
• History of Kenya
• Serbian traditional clothing

The links appear numerous times in various sidebar templates, however I don't see the links in any of those template, so I surmise they're being transcluded from somewhere else. Your help is appreciated. And if you figure it out, I'd appreciate a quick note on how you solved it. Thanks, Cyphoidbomb (talk) 23:43, 9 September 2017 (UTC)

I think I figured it out. A page purge seems to have cleared them. The offending party edited Template:Linkexist... Cyphoidbomb (talk) 23:51, 9 September 2017 (UTC)

Page with wrong latest revision

The revision as of 00:34, 24 July 2010 appears to be the latest revision in the history of User talk:Brendanmccabe/You Lucky Dog (2010 Television Film). However, if you look into the bot's 50 oldest contributions, the revision does not have "(current)" next to it. Also, if you view the 3 user talk pages created by Brendanmccabe, the creation at 18:28, 23 July 2010 has "(current)" next to it. The page's page_latest field in the database was not updated when a new revision was inserted. Finally, the edit summary says "moved", but in fact the page was not actually moved at all. Are there any other pages where the latest revision is wrong? GeoffreyT2000 ^{(talk, contribs)} 01:37, 10 September 2017 (UTC)

The bot tried to move the talk page [17] and associated non-talk page [18] to the same Wikipedia talk page. Only the non-talk page was actually moved. Articles for creation was placed in the Wikipedia talk namespace at the time because IP's could create talk pages but not other pages (the draft namespace is newer). I guess the bot was trying to move the talk page along with the draft in the non-talk page. I don't know what happens today if you select "Move associated talk page" while moving a non-talk page to a talk page. In July 2010 it apparently caused a misleading page history entry in the talk page, at last when a bot did it via the API. I don't know whether there are other cases. PrimeHunter (talk) 02:40, 10 September 2017 (UTC)

Image in the Zoey Deutsch article

I recently removed a probably copyvio image from the local Zoey Deutch (edit | talk | history | protect | delete | links | watch | logs | views) article. Checking the links of that image on Commons, I noticed that the Ukrainian version of the article has the same image, but the image is newer than the article. The image was uploaded on 3 September 2017, yet the article version on 14 March 2017 also displays the image. I also checked the infobox of the Ukranian article in edit mode and there is no image link in it. Please see uk:Зої Дойч. How can that happen? The Russian article has similar image-display characteristics. Please see ru:Дойч, Зои. Dr. K. 16:48, 10 September 2017 (UTC)

Infoboxes can be configured to automatically display an image based on a Wikidata parameter. My first guess is that is what is happening here. -- Ed (Edgar181) 18:54, 10 September 2017 (UTC)

Thank you Edgar. In that case, if the image is a copyvio it still gets to be displayed. That's a problem. Dr. K. 18:55, 10 September 2017 (UTC)

The image can be nominated for deletion at Commons and in the meantime, this edit at Wikidata could be reverted. -- Ed (Edgar181) 19:05, 10 September 2017 (UTC)

Can this 🤔🤔🤔 be prevented?

Technically, is there a simple way of preventing Emojis (or whatever these things are called) being added to articles, leaving articles looking like this ?
If so, where would I ask for such prevention to be implemented? - Arjayay (talk) 17:46, 10 September 2017 (UTC)

This could be done through the use of a rather simple edit filter. Pop over to the requests page -- There'sNoTime ^{(to explain)} 17:51, 10 September 2017 (UTC)

As mentioned above, an edit filter would work but I don't see the point, as this wouldn't stop vandalism but would stop instances of the legitimate usage of emoji in articles (which is rare but definitely happens). It would be worth adding a tag for repeating emoji, tho. ―Justin (koavf)❤T☮C☺M☯ 18:03, 10 September 2017 (UTC)

Unwanted emojis in articles seems like a minor issue and not worth stopping with an edit filter, but I think emojis in edit summaries are annoying when they display as color images in watchlists, page histories, user contributions and so on. PrimeHunter (talk) 18:27, 10 September 2017 (UTC)

Since this subject came up. Emojis on signatures probably looks cute to the user ... but everytime I see it, I have a knee-jerk reaction that I'm looking at malware popping up with a devilish smile. Maybe Wikipedia should have a policy on displaying emojis, period. I know a lot of online users like these emojis, but I can't help but think Wikipedia has been infested with malware when I see it attached to signatures. — Maile (talk) 18:44, 10 September 2017 (UTC)

There are actually usernames that are emojis. Dr. K. 18:57, 10 September 2017 (UTC)

Watchlist fails to report new edits

My watchlist contains roughly 100 items. It's set to show the last thirty days, with nothing hidden, but for a couple of weeks it has only shown "the last 0 changes in the last 720 hours," ie nothing. The pages I watch are hardly Wikipedia's busiest, so I checked to see if, indeed, there might have been no new edits. It turns out there 'have' been new edits all along. Is there something broken, or am I doing something wrong? ARK (talk) 18:04, 10 September 2017 (UTC)

Wikipedia:Village pump (technical)/Archive 158#Watchlist changes, or if you don't want to search quite so diligently, just above at #Watchlist cuts off at 250 entries. —Cryptic 18:14, 10 September 2017 (UTC)