Wikipedia:Village pump (technical)

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.

view · edit

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@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 So Why 12:29, 20 July 2017 (UTC)[reply]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Put

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

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

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

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

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). —Paleo Neonate - 17:21, 19 July 2017 (UTC)[reply]

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

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

#wpSummaryWidget > .oo-ui-labelElement-label

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

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

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

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... —Paleo Neonate - 22:50, 19 July 2017 (UTC)[reply]

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

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

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

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

Process

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. E Eng 13:43, 27 July 2017 (UTC)[reply]

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

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

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

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

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. E Eng 17:26, 18 August 2017 (UTC)[reply]

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

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. E Eng 13:17, 21 August 2017 (UTC)[reply]

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

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

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

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

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

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

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

Delete page

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

Pagecounts-ez dataset hasn't generated since JUL-23

The daily page-view files at [6] stopped generating/aggregating on JUL-23. Any ideas on who to ping to get this restarted? Documentation suggests they should still be chugging along. West.andrew.g (talk) 19:17, 28 July 2017 (UTC)[reply]

Thanks for reporting. We migrated to new stats server (faster than originally scheduled). I'll look into this Monday. Erik Zachte (talk) 15:56, 29 July 2017 (UTC)[reply]

@Erik Zachte: Ping! Not a huge deal, but this does delay the WP:5000 and WP:Top25Report. Thanks, West.andrew.g (talk) 13:00, 1 August 2017 (UTC)[reply]

@West.andrew.g: The server switch was an emergency, so not time for preparation. Thing were placed in different setup folder structure. I'm looking into it. Erik Zachte (talk) 14:23, 2 August 2017 (UTC)[reply]

Thanks Erik Zachte, a resolution would help immensely. Kindly keep us posted. — JFG ^talk 19:59, 4 August 2017 (UTC)[reply]

Thank you Erik Zachte. Please do resolve this. We don't need to manually count the top 25 for next week. FunksBrother (talk) 04:28, 6 August 2017 (UTC)[reply]

Job is running, processing backlog. Data should appear within 24 hours. Erik Zachte (talk) 10:41, 6 August 2017 (UTC)[reply]

All data have been generated. Now I'm waiting for rsync to be fixed on new server. Request has been sent to operations. Erik Zachte (talk) 13:10, 7 August 2017 (UTC)[reply]

Files are online till August 6. Sorry for long outage. Reorganization of Wikistats environment after emergency move to new server is ongoing. Erik Zachte (talk) 09:26, 8 August 2017 (UTC)[reply]

Thanks so much! West.andrew.g (talk) 13:52, 8 August 2017 (UTC)[reply]

@Erik Zachte: Errrr... Things came to a stop again. Last date generated is 2017-08-08. Thanks, West.andrew.g (talk) 03:18, 14 August 2017 (UTC)[reply]

Yeah, the script worked manually, but failed as a cron job with different settings. Fixed. Erik Zachte (talk) 08:17, 16 August 2017 (UTC)[reply]

New pages -- patrolled?

Resolved

– Fixed by developers. — xaosflux ^Talk 20:41, 24 August 2017 (UTC)[reply]

Tracked in Phabricator
Task T173556

On the New pages page, which lists recently created articles, it says, "Yellow highlights indicate pages that have not yet been patrolled." Lately when I look there I don't see any articles highlighted, though I used to see highlighted ones pretty often. Is the highlighting function broken? Or is there some other explanation? — Mudwater^(Talk) 19:59, 5 February 2017 (UTC)[reply]

I am getting yellow-highlighted entries. Of the first 10 pages listed, 3 are yellow, 1 was marked as patrolled by Twinkle while PRODing it, and the other 6 were created by users with the Autopatrolled right. עוד מישהו Od Mishehu 21:48, 5 February 2017 (UTC)[reply]

@Mudwater: As of November 16, 2016, you need to be a new page reviewer to be able to patrol new pages. Before then, all autoconfirmed users could patrol new pages. GeoffreyT2000 (talk, contribs) 04:59, 6 February 2017 (UTC)[reply]

A lack of yellow-highlighted pages normally means that people have been patrolling from the front (newest) and not the back (oldest), contrary to the advice at the top; and this in turn means that unpatrolled pages at the back eventually get old enough (31 days?) to drop right off the list without ever being patrolled. Apart from that issue, patrolling from the front can be WP:BITEy, since pages get CSD-tagged within seconds of creation. --Redrose64 🌹 (talk) 10:28, 6 February 2017 (UTC)[reply]

Although not in contradiction, it's worth recalling that it says here that While it is a good idea to reduce the backlog of unreviewed pages by working from the back of the list, it is nevertheless important that serious breaches of policy such as spam and attack pages are deleted very quickly. O Fortuna!^{...Imperatrix mundi.} 10:48, 6 February 2017 (UTC)[reply]

Yep, those two (possibly also copyvios) are the sort of thing where CSD should be applied ASAP; but that does not extend to every CSD criterion. I have seen pages tagged {{db-nocontext}} or {{db-person}} within a couple of minutes - in cases like these, the page creator must be given the chance to flesh it out. --Redrose64 🌹 (talk) 20:06, 6 February 2017 (UTC)[reply]

Hello. I'm reviving this archived thread because, in case anyone is interested, I just figured out the answer. Some months ago -- October 2016, maybe? -- the rules for patrolling new pages were changed. Now non-admin editors, such as myself, can only patrol new pages if they have new page reviewer rights. I didn't know that until quite recently. I just got new page reviewer rights, and now, on the New pages page, I can see the yellow highlights again, indicating which pages have not been patrolled. To say the same thing in a different way, the yellow highlights are only visible to editors who have new page reviewer rights, and as of some months ago that's a much smaller group. — Mudwater^(Talk) 02:28, 7 August 2017 (UTC)[reply]

This discussion just made me realize that this is a total accessibility issue, where information is communicated solely by color highlighting.. —TheDJ (talk • contribs) 00:09, 8 August 2017 (UTC)[reply]

@TheDJ: not "solely" there is a separate li class name in use not-patrolled - it could be hooked by someone interested. — xaosflux ^Talk 03:14, 11 August 2017 (UTC)[reply]

@TheDJ and Xaosflux: Just now I noticed that no pages are highlighted, and none of the li's have the not-patrolled class associated with them. As far as I know, I still have my NPP bit. Are either of you aware of any recent CSS changes that may have caused this? – Train2104 (t • c) 02:08, 18 August 2017 (UTC)[reply]

These do appear to all be broken now as well, similar to a long ignored phab ticket, phab:T144132 on arwiki. — xaosflux ^Talk 02:39, 18 August 2017 (UTC)[reply]

Phab ticket phab:T173556 opened for now. — xaosflux ^Talk 02:46, 18 August 2017 (UTC)[reply]

Having the same problem. Makes it difficult to patrol pages right now. At first I thought I might have accidentally been logged out, but that didn't happen. Can this be fixed easily? Narutolovehinata5 ^tccsdnew 04:17, 18 August 2017 (UTC)[reply]

Recent changes is actually a kitchen sink that many other pages related to new changes steal content from. So, as a side-effect of the new filters, everyone can actually see the patrolled status of a "new" page using it. Even if that weren't the case, this has probably always worked using the API. As a workaround (until this is fixed) simple way to see all new pages that haven't been patrolled is to use a link like so:

https://en.wikipedia.org/wiki/Special:RecentChanges?hidenewpages=0&hidepageedits=1&hidepatrolled=1&hidelog=1&limit=1000&&days=30

Or simply use the Special:newpagesfeed which has its own filters. 08:38, 18 August 2017 (UTC) — Preceding unsigned comment added by 197.218.83.162 (talk)

This issue should now be resolved, see phab:T173556. — xaosflux ^Talk 20:40, 24 August 2017 (UTC)[reply]

Watchlist changes

It's Thursday. The watchlist has changed. Previously, at Preferences → Watchlist → Maximum number of changes to show in watchlist, if you had set a value of zero this would be treated as "infinite". Now it's treated as zero, so I now need to set a positive non-zero integer - with an enforced maximum at 1000. This means that when somebody with AWB and editcountitis has decided to make changes to 1001 pages on my watchlist (and it has happened, several times), there are going to be changes that I will simply never see. At present, my watchlist won't show me anything earlier than 14:06, 8 August 2017 - 55 hours ago. --Redrose64 🌹 (talk) 21:02, 10 August 2017 (UTC)[reply]

Please change this setting back. Who discussed this. Why was this change made? Ridiculous. GenQuest ^{"Talk to Me"} 21:21, 10 August 2017 (UTC)[reply]
I'm not experienced with the issue you're facing, but from a technical standpoint "zero really means zero" somewhat makes sense. If there was no enforced maximum, maybe -1 should be made to mimic the old behavior? I can only guess this change was done for performance reasons, but until someone who knows tells more I don't know. 2001:2003:54FA:D2:0:0:0:1 (talk) 22:02, 10 August 2017 (UTC)[reply]
I suspect this is a side effect of the improvements to deal with watchlist queries crashing. Ticket phab:T171027. In that case it's possibly an intentional limit to guarantee performance for of the system. —TheDJ (talk • contribs) 02:28, 11 August 2017 (UTC)[reply]
Please change it back (or atleast revert these "watchlist fixes" as instead of fixing the watchlist another problem has been created instead, Mistakes happen so not going off on one but going from 3 days worth of pages to 250 isn't ideal for me at all..... –Davey2010^Talk 11:47, 11 August 2017 (UTC)[reply]

As usual, TheDJ is correct. I asked around, and learned that this is a WP:PERFORMANCE issue. Disallowing infinite page length on Special:Watchlist was the least-bad of several bad options.

I understand that a partial workaround is in the works, to let you filter out changes you've already looked at. (So you read the most recent 1000, then hide the ones that you've already read, and see the next-most-recent 1000, and repeat – you'll never miss any, but you won't see 1,0001+ on the screen at the same time.) However, this probably won't be available for approximately one month. In the meantime, please reset your watchlist numbers to something greater than 0.

If you'd like, I believe that 0 could be re-defined as whatever the maximum is. However, even if that change were written today, it wouldn't reach this wiki until next Thursday. Because of the delay, I'm not sure that it's worth it: most of the few editors affected by this will want to reset their watchlist lengths immediately, rather than waiting a week for an automatic fix. Whatamidoing (WMF) (talk) 21:04, 11 August 2017 (UTC)[reply]

Comment - Is there a way to make the default number of watchlist items 50 items? Can the system require the user to specify a date range? --Jax 0677 (talk) 15:28, 15 August 2017 (UTC)[reply]

My watchlist is suddenly blank?

My watchlist has recently stopped listing any articles. I've tried this on several browsers and OSes. I have also logged out and back in. I have also removed all the filters. I have over 2,400 watched pages, so I know I have stuff on there. Any help? (EDIT: I won't really be able to tell if anyone has replied to this since... well, my watchlist isn't working. I'll be sure to check back frequently.) PureRED (talk) 01:39, 11 August 2017 (UTC)[reply]

from above: "at Preferences → Watchlist → Maximum number of changes to show in watchlist, if you had set a value of zero this would be treated as "infinite". Now it's treated as zero". Try setting it to 500 or 1000. Power~enwiki (talk) 01:43, 11 August 2017 (UTC)[reply]

Thank you so much! PureRED (talk) 01:51, 11 August 2017 (UTC)[reply]

Ah, I had the same issue, that's quite a change, I would expect a great many editors to wonder what's wrong. Damotclese (talk) 15:12, 22 August 2017 (UTC)[reply]

Bot edits?

If I recall correctly, if the "filter bot edits" checkbox was selected, you would see the most recent non-bot edit to a page, even if a bot had edited it in the meantime. Now, it pages where the most recent edit was by a bot are filtered from the watchlist entirely. is it just me, or is this a regression? Power~enwiki (talk) 03:25, 12 August 2017 (UTC)[reply]

Help:Watchlist#Options says:

If the most recent edit to a page is hidden and "Expand watchlist to show all changes, not just the most recent" is not enabled in preferences then the page will not appear on the watchlist. An earlier edit is not shown instead.^[1]

References

^ Bug 9790: Watchlist doesn't show earlier normal edits when hiding bot edits or minor edits.

I added it in 2014 [7] and it has always been like this as far as I know. PrimeHunter (talk) 11:35, 12 August 2017 (UTC)[reply]

OK. I must have mis-interpreted how it was working before. Power~enwiki (talk) 01:59, 14 August 2017 (UTC)[reply]

Is my watchlist limited to 250 changes?

When I look at 30 days of my watchlist, it only shows a few days. Is it limited to 250 changes? Please {{ping}} me when you respond. --Jax 0677 (talk) 14:54, 15 August 2017 (UTC)[reply]

Jax 0677 - See this above - You need to change the number to 1000, Thanks, –Davey2010^Talk 15:16, 15 August 2017 (UTC)[reply]

My Watchlist Is Always Blank Even After an Update

For the past month my watchlist notification list has been empty, so I update the Talk:: page of one of the articles in my list and the next day I checked to see if it would appear in my watchlist and it did not. For some reason I'm no longer getting entries in my watchlist.

Is anyone else noticing this problem? Damotclese (talk) 14:51, 22 August 2017 (UTC)[reply]

@Damotclese: See above Wikipedia:Village_pump_(technical)#My_watchlist_is_suddenly_blank.3F —TheDJ (talk • contribs) 15:00, 22 August 2017 (UTC)[reply]

Thanks! I'll go see... Damotclese (talk) 15:09, 22 August 2017 (UTC)[reply]

What do you all think about adding a note about this to MediaWiki:Watchlist-details? Whatamidoing (WMF) (talk) 17:19, 22 August 2017 (UTC)[reply]

I think we should unbreak it. I'm just over two days behind on my mainspace watchlist checking (all because of a bunch of edits like this where one editor did only part of the job, or even made mistakes, leaving others to fix: so hundreds of pages now have 2, 3 or 4 edits since 00:01, 20 August 2017), and it's on the point of maxing out at 1000. --Redrose64 🌹 (talk) 20:28, 22 August 2017 (UTC)[reply]

Page history of WP:BN doesn't show in Popups

Resolved

– This is so odd. I've changed nothing at all, but suddenly it's working fine again. --Dweller (talk) Become old fashioned! 10:28, 11 August 2017 (UTC)[reply]

Any Popups guru out there? As a Crat, WP:BN is a really important page for me, but weirdly I can't see its page history using Popups when I hover over the appropriate place on my Watchlist.

Just to deepen the mystery, other Projectspace pages seem to work fine.

Advice welcomed. Just go easy on me, I'm not very technical. --Dweller (talk) Become old fashioned! 09:28, 11 August 2017 (UTC)[reply]

It works for me in Firefox on Windows 10 when I hover over the "hist" link. PrimeHunter (talk) 10:09, 11 August 2017 (UTC)[reply]

All other pages seem to work fine. Using Windows 8.1 Pro and Chrome 60.0.3112.90. Irritating. --Dweller (talk) Become old fashioned! 10:26, 11 August 2017 (UTC)[reply]

There is some issue that effects a number of scripts that work only intermittently. Possibly a resource that for some reason could not be loaded, which stops further loading on that particular page. I have turned to bookmarking those pages and reopening from the bookmark list, which has a high success rate. Agathoclea (talk) 08:46, 18 August 2017 (UTC)[reply]

Why does autoblock disclose the name of the blocked account associated with the autoblocked IP address

Tracked in Phabricator
Task T55008

As mentioned here [8], apparently when autoblock does its thing (blocking not-logged-in access via an IP recently used by a blocked account) it declares the name of the blocked account which is causing the IP to be blocked, thereby doing something we go to great lengths elsewhere not to do i.e. associate IPs with accounts. This obviously isn't a problem if only the blocked editor is using that IP, but where an IP is shared (e.g. at work) it does something we go to great lengths elsewhere not to do i.e. tell people the IP from which a named account has been editing. It is really necessary for the autoblock message to give the name of the blocked account? E Eng 11:35, 11 August 2017 (UTC)[reply]

I believe this is phab:T55008. Jo-Jo Eumerus (talk, contributions) 15:07, 11 August 2017 (UTC)[reply]

Phabulous, thanks. E Eng 15:12, 11 August 2017 (UTC)[reply]

Unfortunately, we need some reasonable mechnism to allow normal admins to see who the original blocked user is. The only alternative is that only CheckUser users be allowed to deal with autoblocks - and I think that would be worse. עוד מישהו Od Mishehu 02:42, 14 August 2017 (UTC)[reply]

How does showing a not-logged-in IP editor the name of the blocked user help admins see the name of the blocked user? E Eng 23:41, 14 August 2017 (UTC)[reply]

As the software is right now, the only way anyone, including admins, can see this information is in the publicly-visible autoblock reason. עוד מישהו Od Mishehu 07:57, 15 August 2017 (UTC)[reply]

I guess I'm confused. I thought this was a message displayed to the IP when it makes an attempt to edit. When/where is this message displayed such that an interested admin (or, perhaps, any editor) can see it? E Eng 15:36, 16 August 2017 (UTC)[reply]

At Special:BlockList. You can see an individual autoblock by entering its number (everything from the number sign onwards) in the "IP address or username" textbox. עוד מישהו Od Mishehu 13:37, 17 August 2017 (UTC)[reply]

I think we're talking past each other, but anyway I've lost interest. Thanks, though. E Eng 14:04, 17 August 2017 (UTC)[reply]

Broken edit syntax highlighting on (expected) unclosed tags

When editing, bare tags such as , <hr>, or will highlight subsequent text in pink (as long as there is a "<" somewhere below). In the case of the first two, one can manually close them, however (which fixes the incorrect highlighting) is invalid per Category:Pages using invalid self-closed HTML tags. Has this issue already been reported? Thanks, ^~Hydronium^~Hydroxide^~(Talk)~ 12:31, 12 August 2017 (UTC)[reply]

I'm guessing that you are using the Syntax Highlighter gadget. See mw:User:Remember_the_dot/Syntax_highlighter#Parsing for an explanation. – Jonesey95 (talk) 15:05, 12 August 2017 (UTC)[reply]

Thanks Jonesey95. That's it. ^~Hydronium^~Hydroxide^~(Talk)~ 08:13, 17 August 2017 (UTC)[reply]

"Place the category box above all other content" and section anchors

This is an oldie but goodie. When "Place the category box above all other content" is checked under Preferences > Gadgets, the category box is moved to the top of the screen, which makes categories more accessible, etc. However, if this is checked when the editor arrives via an anchor/section link, the category box often moves after the browser view has navigated to the section, offsetting the the link or visual anchor by the height of the category box such that the link/visual anchor is no longer at the top of the editor's window. Would there be any way to change the loading order such that the category box moves to the top of the page in advance of the window navigation, so I can navigate as intended? (Please {{ping}} me if you respond with a question.) czar 20:03, 12 August 2017 (UTC)[reply]

The movement is done with javascript, so it is probably impossible. Ruslik_Zero 20:45, 12 August 2017 (UTC)[reply]

It's a browser problem. As noted above, the cat box is moved by javascript; but some browsers (like Firefox and Opera) navigate to the anchor as soon as the page is loaded, they don't wait for javascript to finish first. This is probably because on some web pages, the Javascript is non-terminating - it executes continuously (rolling banner adverts are an example, as are news feeds), and so on these pages, the browser would be waiting for an event that will never happen, and so will never jump to the anchor. --Redrose64 🌹 (talk) 21:04, 12 August 2017 (UTC)[reply]

As a stopgap, would it be possible/practical to have the browser re-navigate to the anchor after the category box moves, as part of the gadget? czar 22:26, 12 August 2017 (UTC)[reply]

Bump. Also any leads on whom to contact—does the gadget have a maintainer? czar 01:53, 23 August 2017 (UTC)[reply]

template:Archive-top on mobile

When viewed using the internet browser on my Android phone, the {{archive-top}} templates, at least as used at WP:ITN/C, are showing several screens worth of blank space between the horizontal line under the header and closure summary box and the start of the included text. I haven't time atm to investigate whether it is just this template or other similar ones and/or if it is idiosyncratic to that page. Awkward42 (talk) [the alternate account of Thryduulf (talk)] 11:44, 13 August 2017 (UTC)[reply]

It looks like what's happening there is that the skin sets overflow:auto on all <dd> and sets class quotebox to auto-width (and also sets word-wrap:break-word at a high level). So when the browser (at least desktop Firefox 52.2.0) tries to lay out the <dd> containing the "The following discussion is closed" and so on next to the floated quotebox with the close reason, it winds up making it 0 width and breaks the line between every letter. Anomie ⚔ 12:28, 13 August 2017 (UTC)[reply]

Is that fixable? Thryduulf (talk) 19:33, 13 August 2017 (UTC)[reply]

Many things are possible, but they often have side effects. Here, it would likely break phab:T160946 again.. Hard calls. —TheDJ (talk • contribs) 03:10, 19 August 2017 (UTC)[reply]

Moving to commons

Can someone please help in moving these files to commons? -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 08:00, 14 August 2017 (UTC)[reply]

@Capankajsmilyo: You can do it yourself using one of these. Jc86035 (talk) 14:37, 14 August 2017 (UTC)[reply]

That is a complex process. I don't want to break anything. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 15:07, 14 August 2017 (UTC)[reply]

This is a Wiki that anyone can edit. If you 'break' something, then I'm sure someone else will see it and fix it :) -FASTILY 06:06, 16 August 2017 (UTC)[reply]

Category:Renault vehicles

There are two problems at Category:Renault vehicles. The first is simple: the page (last edited in May 2014) is broken—click edit then preview to see what it should look like. Please don't purge the page until others have had a chance to see a new kind of problem, namely that templates can be broken by some underlying system glitch, probably related to T170039. The second problem concerns unraveling the history. Why does a category have a navbox, and why does the page have a history showing edits over a ten-year period? Is the page the inadvertent result of a move to the wrong namespace? Johnuniq (talk) 11:00, 15 August 2017 (UTC)[reply]

The edit history looks OK to me - most of it is the gradual addition (and then final removal) of interwiki links, plus various tweaks to the categories. DH85868993 (talk) 12:01, 15 August 2017 (UTC)[reply]

There's no reason a category can't have a navbox. It is not typical--I've been thinking it should be, but that's a discussion for another forum. Either the template needs to be fixed (this is simply due to someone missing some brackets somewhere in the template) and then the category page purged, or the category page simply purged if the template has already been fixed. --Izno (talk) 12:40, 15 August 2017 (UTC)[reply]

Yes, this edit from a few days ago broke the template. It has since been fixed; we are just waiting for the job queue to catch up. --Izno (talk) 12:41, 15 August 2017 (UTC)[reply]

The template now appears correctly in the category. DH85868993 (talk) 22:49, 15 August 2017 (UTC)[reply]

Thanks, I missed seeing that diff, and I have got a bit paranoid after seeing a handful of weird issues while checking articles with script errors. Johnuniq (talk) 22:50, 15 August 2017 (UTC)[reply]

Automated creation of thematic world maps

Some time ago, I found GunnMap, a pretty interesting tool that allows the creation of thematic world maps directly from an excel file (e. g. File:World Map of Price Levels 2015.svg). But the tool is somewhat inflexible, as the colors cannot be chosen manually. Now I had the idea that such a tool could be developed for WP porposes, as editable basic maps like File:World location map (W3).svg do already exist. Since I do not having any programming skills: Is that an idea that could be possible realized?--Antemister (talk) 12:55, 15 August 2017 (UTC)[reply]

Yes, it is possible. But there are many places where one can create maps like those, and creating one for Wikipedia specifically is not necessary as long as there is a tool that uses a worldmap that has a license that is compatible to our licenses.

https://developers.google.com/chart/interactive/docs/gallery/geochart

https://developers.google.com/chart/interactive/docs/gallery/intensitymap

(((The Quixotic Potato))) (talk) 20:55, 15 August 2017 (UTC)[reply]

You might also be interested in what can be done with the Graphs extension. Ckoerner (talk) 00:09, 16 August 2017 (UTC)[reply]

I did not know that something like this already exists here, I'll ask the guys from the Graphs extension!--Antemister (talk) 17:57, 16 August 2017 (UTC)[reply]

Discrepancy between count of pages in a category and actual number of pages

Apologies if this has been covered before. I did a half-hearted search but didn't find anything.

On some maintenance categories, there is an inconsistency in the page count message when compared with the actual number of pages in the category, even when taking into account the delayed update. For example, a category might tell me "The following 200 pages are in this category, out of 209 total." (looking at you, Category:Wikipedia articles incorporating text from the Schaff-Herzog), yet when you page through after the first 200 entries, it says "The following 14 pages are in this category, out of 209 total." and indeed there are 214 total pages listed in the category. One page is in non-main space, which isn't enough to account for the discrepancy.

At this time, I can see the same effect in Category:Wikipedia articles incorporating a citation from the 1911 Encyclopaedia Britannica without Wikisource reference (641 in the message, but 97 displayed on the 4th page); Category:Wikipedia articles incorporating text from Easton's Bible Dictionary (322 in the message, 326 displayed).

I suspect, and in one case I know, that the affected categories have had articles added to them recently. But even accounting for a possible delayed update, resulting maybe in the total count coming from a different database table than the list itself, shouldn't the "page count" message reflect the count of pages being actually displayed? If not, it damages credibility. Or change the message to say "out of 209 or more total." David Brooks (talk) 00:25, 16 August 2017 (UTC)[reply]

I have removed the none main name-space entry for the Schaff-Herzog category as it was accidental added by me some years ago -- PBS (talk) 08:05, 16 August 2017 (UTC)[reply]

This is behavior that has existed for a long time. My understanding is that it is related to the job queue, and also in a larger way to T132467, T157670, or both. The short version of those bugs is that it takes way too long for categories to catch up when something changes that affects them.

My rudimentary understanding is that MediaWiki maintains a category member count, which may not be correct, and it increments or decrements that count by the correct number as pages are added or removed, but the number will remain incorrect. My personal experience has been that the category count on the category page becomes trustworthy only after the category membership drops below 200.

I could be wrong about any or all of this, but that has been my experience over the last few years of editing. (Edited to add: T18036 appears to be the canonical ticket for this problem.) – Jonesey95 (talk) 01:13, 16 August 2017 (UTC)[reply]

The message is made by MediaWiki:Category-article-count. If a discrepancy is common and it can go both ways then we could change "out of $2 total" to "out of around $2 total". If it's only an issue for more than 200 pages then we could add "around" in that case: out of {{#ifexpr:{{formatnum:$2|R}}>200|around}} $2 total. PrimeHunter (talk) 10:30, 16 August 2017 (UTC)[reply]

I think it would be great to be honest about this eight-year old bug. I would love to see "out of approximately NNN" ("approximately" seems less jargon-y to me than "around") in category lists. Whoever edits that MediaWiki page could add a hidden comment or a note on the corresponding talk page pointing to T18036. Thanks. – Jonesey95 (talk) 15:10, 16 August 2017 (UTC)[reply]

Can anyone confirm whether the proposed trigger of 200 articles is coincidentally the same as the display chunk size, or if it is directly related in some way? For example, I would find it believable that a one-page display would count its contents directly while the first of a multi-page display would have to use the (sometimes incorrect) category count. David Brooks (talk) 18:18, 16 August 2017 (UTC)[reply]

It's directly related. When viewing the category without using the 'from' or 'until' parameters, if there are fewer than the display chunk size pages shown in the view then MediaWiki can easily check that the stored count is correct or not (and if not, it can trigger an update in the expectation that it'll be cheap to do so). Anomie ⚔ 19:01, 17 August 2017 (UTC)[reply]

ETA: I realize that's exactly what happens. "The following n pages are in this category" is correct; it's "out of n total" that's often wrong. Perhaps the solution, until and unless the database error is fixed, is to do something like the History display, with a set of next/prev/first links. Or is the database bug rare enough that this would be overkill? David Brooks (talk) 18:53, 16 August 2017 (UTC)[reply]

What do you mean by next/prev/first links? There are already "next page" when you are not on the last page, "previous page" when you are not on the first page, and clicking the "Category" tab jumps to the first page. Do you mean not displaying a count at all, like history pages? We could omit the count in MediaWiki:Category-article-count but I oppose that as long as the count is not wildly off most of the time. PrimeHunter (talk) 20:20, 16 August 2017 (UTC)[reply]

Well, yes, that's what I meant, and I guess I was mistaking form for function. "Next 200" might be an alternative label, but that's confusing on the penultimate page (also true of History). And, as you imply, the effort may not be justified if (a) I'm the only one making a fuss or (b) as you imply, the count is right most of the time. Can the fraction of seriously-wrong counts be measured?. David Brooks (talk) 22:38, 16 August 2017 (UTC)[reply]

In my experience, the count is almost always wrong (although usually approximately close, within a few percent) unless the count is below 200. I think that adding the word "approximately" would be far better than omitting the total altogether. As for the "next 200" discussion above, I don't understand how that would be better than the existing "next page" link that exists at the bottom of each populated page in the category. And as for a "first" link (or any other place within the category), that is what the TOC templates are for. What am I missing? – Jonesey95 (talk) 00:57, 17 August 2017 (UTC)[reply]

You're not missing anything; I was being overly precise in my comparison with the History listing. David Brooks (talk) 01:16, 17 August 2017 (UTC)[reply]

I have added "approximately" to MediaWiki:Category-article-count for totals above 200. PrimeHunter (talk) 09:50, 17 August 2017 (UTC)[reply]

Wikipedia:WikiProject Women in Red/The World Contest

I need somebody to code a bot to run this contest. Wikipedia:ContestBot would be an ideal name. It will need to read article prose length when submitted and check there are no unsourced paragraphs. I will pay for the work if you want it.♦ Dr. Blofeld 09:15, 16 August 2017 (UTC)[reply]

Just to note that User:Shubinator/DYKcheck does most of this already (it checks for no inline citations at all rather than paragraphs, but it's close). Black Kite (talk) 10:37, 16 August 2017 (UTC)[reply]

Thanks. I'll need something which can tick or cross entries as they're submitted on the contest pages though, prose count for the contest is important.♦ Dr. Blofeld 18:52, 16 August 2017 (UTC)[reply]

Who here has wmflabs access

User:Citation Bot has had major code updates in the pipeline for a long while, but they've never been deployed because the updates (github link) never get deployed to wmflabs.

How can we make them happen? Headbomb {t · c · p · b} 11:07, 16 August 2017 (UTC)[reply]

Smith609, Kaldari, Fhocutt, and Maximilianklein are the listed maintainers. — JJMC89 (T·C) 14:14, 16 August 2017 (UTC)[reply]

Gonna ping the noping'd ones. @Kaldari:, @Fhocutt:, and @Maximilianklein:. Smith609 hasn't been active, if he were, the updates would have gone live years ago. Headbomb {t · c · p · b} 15:50, 16 August 2017 (UTC)[reply]

@Headbomb: The actual live code lives in the "citations" tool, which I don't have access too. None of the maintainers of that tool are still active on Wikipedia, though :( Kaldari (talk) 17:48, 16 August 2017 (UTC)[reply]

@Kaldari: - As a "solution", could the current citations tools be taken down/disabled, and new ones be uploaded instead. I don't mean uploading over the existing ones, but rather something like creating a User:Citation Bot 2, blocking User:Citation Bot, and pointing all scripts/gadgets/whatever towards the new code rather than the old one? Headbomb {t · c · p · b} 01:16, 17 August 2017 (UTC)[reply]

If you can let me know how to pull the necessary code updates, I'm happy to do it. Afraid I haven't the time to remind myself of the process. Drop me an e-mail. Martin (Smith609 – Talk) 09:23, 17 August 2017 (UTC)[reply]

AWB subrules

I am having trouble figuring out how the advanced find/replace rules in AutoWikiBrowser work. I have nested some regex rules (if rule 1 then (if rule 2 then (rules 3–5))), but the subrules are run regardless of whether or not their parent rules are actioned upon. Is this a bug, or am I doing this wrong? Are the rules for the entire tree ignored if there is a match in the "Not contains" panel, or does it do something else? Jc86035 (talk) 14:40, 16 August 2017 (UTC)[reply]

@Jc86035: You should ask @Magioladitis: (I have pinged him). (((The Quixotic Potato))) (talk) 23:49, 17 August 2017 (UTC)[reply]

Jc86035 It is highly possible that the Advanced F&R is broken. Reedy what do you thing? -- Magioladitis (talk) 17:02, 18 August 2017 (UTC)[reply]

Gadgets

What MediaWiki/Module is resposinble for showing the gadgets section from the preferences? I would like to see the source codes. ◂ ‎épine _talk♬ 17:49, 16 August 2017 (UTC)[reply]

I'm not sure what you want. https://en.wikipedia.org/wiki/Special:Preferences?uselang=qqx#mw-prefsection-gadgets shows the names of the displayed MediaWiki messages. For example, "(gadgets-prefstext)" at the top means that MediaWiki:Gadgets-prefstext is displayed there. The message for the English Wikipedia can be edited there. MediaWiki:Gadgets-definition defines the gadgets used by the English Wikipedia. Special:Gadgets has links to the JavaScript and CSS pages. PrimeHunter (talk) 18:30, 16 August 2017 (UTC)[reply]

I think he's asking about mediawikiwiki:Extension:Gadgets. --Izno (talk) 19:22, 16 August 2017 (UTC)[reply]

@PrimeHunter: thanks, that's exactly what I wanted. ◂ ‎épine _talk♬ 15:59, 17 August 2017 (UTC)[reply]

Is it just me?

Hi,

I'm having a problem with editing pages. Sometimes, things such as the editor buttons and Twinkle simply do not load. When they do not, I have to keep refreshing until they do. I could not find any other mention of this problem in recent threads. I'm using Firefox 55.0.2 64-bit (Windows 10), but this was also happening with older versions. Is this a problem with Wikipedia, or is there an issue with my connexion? It's worth noting that I had a look at Firefox's Web Console, and in the cases when they do not load, I get a "TypeError: mw.util is undefined" message for index.php:329:3 that I do not get when it does load. The problem happened to me when I went to type this thread, and I got the same message (that said, it happened again when I tried to preview, and I did not get that message, so who knows?). I have tried cleaning my browser's cache. Does anyone else have this problem, because it is getting rather annoying. It sometimes hinders anti-vandalism work, as I sometimes cannot warn vandals and report them to AIV because I have to fight with the system just to be able to do so. Thanks. Adam9007 (talk) 23:10, 16 August 2017 (UTC)[reply]

@Adam9007: It's not you. It's Firefox, and it's been going on at least since the previous release a month or so ago. Straight across the board on Wikimedia. Firefox is not compatible with everything in the editing window. I do the same thing you do. — Maile (talk) 23:20, 16 August 2017 (UTC)[reply]

@Maile66: Is there no workaround? I'd hate to have to switch browser because of this. Adam9007 (talk) 23:28, 16 August 2017 (UTC)[reply]

I haven't read about a workaround. I use Firefox. You should try it on WikiSource, repeated refreshing of the page combined with repeated clicking on "Preview", to get all the tools to load. I like Firefox and don't want to switch at this time. But Firefox and Wikimedia are not currently compatible. — Maile (talk) 23:33, 16 August 2017 (UTC)[reply]

@Maile66: Has this problem been reported somewhere? Adam9007 (talk) 23:49, 16 August 2017 (UTC)[reply]

I don't know if the problem I came to report is exactly the same, but it's similar enough. Along with Twinkle, many of the helper scripts that I regularly use (including WP:POPUPS for example) are not loading, and it's becoming more often than not. But I'm on Chrome in Win10. Any ideas? Ivanvector (^Talk/_Edits) 23:53, 16 August 2017 (UTC)[reply]

@Adam9007: 1, 2 a couple of times this has been reported. — Maile (talk) 23:59, 16 August 2017 (UTC)[reply]

Actually, this problem sounds like one that can be fixed--it sounds like one of your user scripts/gadgets is not declaring its dependency on mw.util. Which gadgets are you using? (Cc TheDJ, the prognosticator of scripts.) --Izno (talk) 23:54, 16 August 2017 (UTC)[reply]

@Izno: I'm using (under "Editing"): "Add two new dropdown boxes below the edit summary box with some useful default summaries", Citation Expander, Syntax highlighter, HotCat, "Form for filing disputes at the dispute resolution noticeboard" (what's this anyway? I never use it), CharInsert (which also doesn't load when the buttons and Twinkle don't), refToolbar, and "Add extra buttons to the old (non-enhanced) editing toolbar". Adam9007 (talk) 00:02, 17 August 2017 (UTC)[reply]

You could try blanking User:Adam9007/common.js. PrimeHunter (talk) 00:15, 17 August 2017 (UTC)[reply]

@PrimeHunter: Nope, didn't work

. I also still get the "TypeError: mw.util is undefined" message. What is of interest is that I also get messages like "This page is using the deprecated ResourceLoader module "jquery.ui.core". Please use "mediawiki.ui.button" or "oojs-ui" instead." Maybe this has something to do with the problem? Adam9007 (talk) 00:34, 17 August 2017 (UTC)[reply]

per my userpage, im on the road atm, so i cannot debug a persons scripts right now. Blanking everything, and then waiting for the cache to expire is the guaranteed way out. —TheDJ (talk • contribs) 14:52, 17 August 2017 (UTC)[reply]

I want to note that I usually encounter this issue with Safari as well. I mostly have this issue with the summary sections.◂ ‎épine _talk♬ 16:04, 17 August 2017 (UTC)[reply]

Adam9007: User:Adam9007/common.js is importing User:Ohconfucius/script/EngvarB.js, which in turn imports m:User:Pathoschild/Scripts/Regex menu framework.js, and that script uses mw.util.addCSS, but nowhere in this chain of script importing is the ResourceLoader module mediawiki.util loaded. If you wrap your entire common.js like this:

mw.loader.using( 'mediawiki.util', function() {
	//Just put your entire common.js inside here
} );

it should work, or at least give you another error. Nirmos (talk) 16:08, 17 August 2017 (UTC)[reply]

@Nirmos: I'll try that, but I'm not sure that'll help: I just had two instances of the editor of that page open. One loaded correctly, the other did not. There was no difference in errors between them except the one that loaded correctly had an additional message: "Automatically scrolling cursor into view after selection change this will be disabled in the next version set editor.$blockScrolling = Infinity to disable this message". Also, by "editor buttons", I meant the toolbars, not the save, preview, and show changes buttons. Adam9007 (talk) 22:09, 17 August 2017 (UTC)[reply]

Latest version of Chrome, Win 10, sometimes Twinkle loads, sometimes it doesn't. Doug Weller talk 10:16, 20 August 2017 (UTC)[reply]

Doug Weller: I've looked at your JavaScript pages and in User:Doug Weller/vector.js you are importing MediaWiki:Gadget-markblocked.js. When you do that, you are bypassing that gadget's dependencies that are declared on MediaWiki:Gadgets-definition. That's why you should never ever import gadgets this way unless you know what you're doing. Gadgets are meant to be enabled and disabled at Special:Preferences#mw-prefsection-gadgets. markblocked in particular can be found at Special:Preferences#mw-input-wpgadgets-markblocked. Nirmos (talk) 01:41, 21 August 2017 (UTC)[reply]

@Nirmos: thanks very much. I obviously missed the fact it was in preferences. Everything seems ok now. Doug Weller talk 18:55, 21 August 2017 (UTC)[reply]

Spoke too soon. Twinkle doesn't always load. Doug Weller talk 16:05, 22 August 2017 (UTC)[reply]

@Doug Weller: I've been using Wikipedia with your scripts installed for a day, and couldn't find anything significant. But I can't really look over your shoulder and be sure that our setups are actually similar of course. mw:Help:Locating_broken_scripts has information on how to retrieve more information if problems do occur, and I have also added a gadget that you can enable in your preferences, called "Show an alert when you encounter Javascript errors", that might help you track down potential problems. If you can discover more information around the error you encounter, then maybe I can help you further at that time. —TheDJ (talk • contribs) 12:38, 23 August 2017 (UTC)[reply]

@TheDJ: Thanks, that's really very kind of you. I'll look at the help page. I can't find the gadget though. Doug Weller talk 18:31, 24 August 2017 (UTC)[reply]

Requesting OCR help at mr.wikisource

Hi,

At Marathi language mr.wikisource we have planned a student workshop tomorrow. We are looking for unicodification support from people using linux operating system. Since our usual voluntters to are not around.

Book that need OCR support is अनुक्रमणिका:Arth shastrachi multatve cropped.pdf (word अनुक्रमणिका stands for Index namespace.)

Book link on Wikimedia commons commons:File:Arth shastrachi multatve cropped.pdf

As per info on Marathi Wikisource help page one needs to use Linux operating sytem.

OCR4Wikisoource programme -is written using python- needs to be downloaded from (https://github.com/tshrinivasan/OCR4wikisource)

Steps
- Step 1: Download & install OCR4Wikisoource
- Step 2: Google API
- Step 3: API Enable
- step 4: Change file config.ini fill URL link of the book to be OCRed then wikisource log in and pass word.
- Step 5: use OCR4wikisource

Thanks & Regards

Mahitgar (talk) 07:57, 17 August 2017 (UTC)[reply]

Problems with my user rights.

Hi, I have auto confirmed status then even I am not able to edit most semi-protected pages. I have had a discussion over this with MusikAnimal and he only suggested me to seek help here. Bingobro (Chat) 11:01, 17 August 2017 (UTC)[reply]

Are you sure that they are semi-protected and not extended-confirmed protected articles? The latter require the extended-confirmed group, which is automatically added after 500 edits and a minimum of 30 days. Maybe that specifying the name of the semi-protected article you cannot edit would be a good idea. It's also possible that an edit filter issue prevents your edits, but the only event that I can see is Special:AbuseLog/18906070 which was an article creation attempt without references. Thanks, —Paleo Neonate – 12:46, 17 August 2017 (UTC)[reply]

@Bingobro: I saw some of your posts on the other pages, and it is unusual. A few questions: have you tried editing from a different computer? Have you made any edits from tor? — xaosflux ^Talk 12:49, 17 August 2017 (UTC)[reply]

Possibly related to phab:T136044. Would you be able to share the operating system and browser you are using? — xaosflux ^Talk 12:50, 17 August 2017 (UTC)[reply]

Yup, Cars is a semi-protected page and as for the article I created I did provide references although they may not have been considered valuable.And for tor , the only browsers I have installed are Chrome and Internet Explore and my OS is Windows 8.1.And I doubt my pc's specs could be a problem? Bingobro (Chat) 13:50, 17 August 2017 (UTC)[reply]

Permalink to the discussion on my talk page (and at WP:PERM/C), for reference. I agree with Xaosflux – let's try editing from a different computer. If it still doesn't work, while you are logged in, please create a new account at Special:CreateAccount. This will show up as an account created by Bingobro, which we can then manually confirm. If with the new account you find you are able to edit these semi-protected pages, we can isolate the issue to some weirdness with the Bingobro account, and rule out your browser and operating system — MusikAnimal ^talk 16:13, 17 August 2017 (UTC)[reply]

Wait, wait.. Wont creating a new account loose all my contributions i.e. around 200+ and my media from commons.I thought I soon would have an extended confirmed account but creating a new account I'll have to start all over again! And if you guys wont to try out the confirmed flag again, I'd suugest to do it with this account. Bingobro (Chat) 10:47, 18 August 2017 (UTC)[reply]

Hello, anyone here? My problems aren't yet fixed so, somebody can perhaps still help. Thank you! Bingobro (Chat) 15:22, 19 August 2017 (UTC)[reply]

@Bingobro: have you tried using a different computer yet to rule that out? — xaosflux ^Talk 16:36, 19 August 2017 (UTC)[reply]

@Xaosflux: Sorry, forgot to metion that. Yup, I have tried it out and no help. Bingobro (Chat) 16:52, 19 August 2017 (UTC)[reply]

@Bingobro: When MusikAnimal (talk · contribs) suggested that you create a new account, this wasn't with the intention that you use it in future and abandon your present account - the idea is to see if an account which is uncustomised, and so still has the default settings, is having the same trouble. If it is not having such trouble, we consider the customisation that has been applied to your main account; for example, you might have enabled two gadgets that are not happy together. For this reason, I created Redrose64a (talk · contribs) some years ago, where I have not altered any of the configuration settings; and to make sure that I have all of the current defaults, I periodically use the "Restore all default settings" feature at Preferences (n.b., if you have any Custom CSS / Custom JavaScript pages (see Preferences → Appearance), this will not alter or disable anything set up in those). If I have trouble with my main account, I try out Redrose64a and if the trouble is gone, I know that it's a settings issue. Such additional accounts are permitted under WP:VALIDALT. --Redrose64 🌹 (talk) 09:23, 20 August 2017 (UTC)[reply]

@Redrose64: Well, I have created the account User:BingobroA but its still 4 days till I know whether it worked or not.Bingobro (Chat) 13:30, 20 August 2017 (UTC)[reply]

I added the manual confirmation on it for now, try to make 10 edits and we can remove when it is auto confirmed. At that point if there are still issues we can get a phabricator ticket open for a developer. — xaosflux ^Talk 14:39, 20 August 2017 (UTC)[reply]

@Xaosflux: Well, 10 edits are done no problems whatsoever the pages now say edit source. And, its the same computer and browser I'm using. BingobroA (Chat) 14:48, 20 August 2017 (UTC) I think, trying out the confirmed flag (temporarily) on this account could help although previously it only partially worked. Bingobro (Chat) 15:09, 20 August 2017 (UTC)[reply]

@Bingobro: if you would check back in in 4 days, that account should become autoconfirmed and you can test at that point. I've added the confirmed flag temorarily back to this account until then. — xaosflux ^Talk 15:17, 20 August 2017 (UTC)[reply]

This is great! I am finally able to edit all semi-protected pages.No, problems at all. Bingobro (Chat) 10:29, 21 August 2017 (UTC)[reply]

Dropping support for Internet Explorer 8 on Windows XP

Tracked in Phabricator
Task T163251

"Sons of Wikipedia! I see in your eyes the same Manual of Style that would take the heart of me. **A day may come** when a comma is used as the decimal separator, when we forsake the decimal *point*, and break all bonds of fellowship; **but it is not this day!** An hour of ENGVAR edit wars, and shattered serial commas, when the Age of Harvard References comes crashing down; but it is not this day! This day we fight! By all that you hold dear on this good earth, I bid you stand, Men of the Wikipedia!" –**E Eng**

As announced several times, Ops is dropping all support for Internet Explorer 8 on Windows XP (and a few other, even rarer, combinations), for privacy and security reasons. "All support" means that if you are using an affected web browser, you will not be able to either read or edit pages.

Sometime today, affected browsers will start getting an error message on 5% of page views. Reloading the page will (95% of the time) get you to the article. But support is going away, and the number of errors will increase steadily until it reaches 100% in approximately two months or so, so please change browsers as soon as you can. Whatamidoing (WMF) (talk) 17:50, 17 August 2017 (UTC)[reply]

Sort of the iron fist in the velvet glove. E Eng 17:54, 17 August 2017 (UTC)[reply]

Google.com works for me with IE6 (with a better dense interface). Anyway, can we link to www.getfirefox.com or use call-to-action buttons (Buy Windows 10 for US$ 99)? — Dispenser 18:06, 17 August 2017 (UTC)[reply]

IE8? I have thought that only IE10+ are officially supported as of now? Ruslik_Zero 18:48, 17 August 2017 (UTC)[reply]

IE under 10 doesn't receive JavaScript. Here, we're talking about removing the ability to connect to Wikipedia for even older stuff. Max Semenik (talk) 18:51, 17 August 2017 (UTC)[reply]

There will be a link to download Firefox 52 ESR. /Johan (WMF) (talk) 19:45, 17 August 2017 (UTC)[reply]

This will affect roughly 0,1% of our traffic, by the way. /Johan (WMF) (talk) 19:48, 17 August 2017 (UTC)[reply]

You're violating our Manual of Style by using comma as the decimal separator. You WMF guys think rules don't apply to you.^[FBDB] E Eng 19:56, 17 August 2017 (UTC)[reply]

Nah, he's just showing off his non-English language skills. Someday, I'm going to fill his userpage with Babel boxes. ;-) Whatamidoing (WMF) (talk) 20:16, 17 August 2017 (UTC)[reply]

A day may come when I learn to pause and think about which language I'm writing in when I come to the decimal separators. But it is, apparently, not this day.

(1,000.67 is written 1.000,67 in my native language. This is seriously one of the most confusing aspects of switching back and forth between languages.) /Johan (WMF) (talk) 21:51, 17 August 2017 (UTC)[reply]

@Johan (WMF): You work for the WMF and in the weekends you make extra money as a Kane impersonator? (((The Quixotic Potato))) (talk) 23:45, 17 August 2017 (UTC)[reply]

Template namespace shortcut

Why is it that t: works as a shortcut in English Wiktionary but not Wikipedia? This small change could save a whole lot of time. Pariah24 (talk) 19:31, 17 August 2017 (UTC)[reply]

Because editors disagree about whether T: should be Template: or Talk:. There's no technical impediment. Whatamidoing (WMF) (talk) 20:17, 17 August 2017 (UTC)[reply]

It works in English Wiktionary because mw:Manual:$wgNamespaceAliases is used to add it in https://noc.wikimedia.org/conf/highlight.php?file=InitialiseSettings.php:

# wgNamespaceAliases @{
'wgNamespaceAliases' => [
...
	'+enwiktionary' => [
		'WS' => 110, // Wikisaurus
		'WT' => NS_PROJECT,
		'CAT' => NS_CATEGORY, // T123187
		'T' => NS_TEMPLATE, // T123187
		'MOD' => 828, // T123187
		'AP' => 100, // T123187
		'RC' => 118, // T123187
	],

// T123187 is a comment indicating it was requested in phab:T123187 which links to wikt:Wiktionary:Votes/2015-11/Namespace abbreviations. PrimeHunter (talk) 17:34, 18 August 2017 (UTC)[reply]

Cite magazine

Dear editors: I edit a lot of music articles, so I often reference Billboard Magazine. There are four Cite templates on the drop down list in the edit window: web, news, book and journal. Since "Cite journal" is the closest, I have been using that. While attending a session at Wikimania, I learned that there is also a "Cite magazine", and that using the journal template for magazines can cause categorization problems. Is it possible to add "Cite magazine" to the drop-down menu?—Anne Delong (talk) 19:47, 17 August 2017 (UTC)[reply]

Categorization problems? How so? {{cite journal}} and {{cite magazine}} are essentially the same except in how they render volume, issue and pagination:

{{cite journal |title=Article title |journal =Journal |volume=1 |issue=2 |page=3}}

"Article title". Journal. 1 (2): 3.

{{cite magazine |title=Article title |magazine=Magazine |volume=1 |issue=2 |page=3}}

"Article title". Magazine. Vol. 1, no. 2. p. 3.

The rendering engine Module:Citation/CS1 does not categorize according to the type of cs1 template used. Perhaps you can explain what it is that you mean by categorization problems.

—Trappist the monk (talk) 19:58, 17 August 2017 (UTC)[reply]

There's a gadget somewhere (found it Wikipedia:RefToolbar!) that has a default list of templates to use: Cite web, cite news, cite book, cite journal. The request is to add cite magazine to that list. Headbomb {t · c · p · b} 20:12, 17 August 2017 (UTC)[reply]

There's possibly MW:Citoid as well, which has a json mapping (MW:Citoid/MediaWiki:Citoid-template-type-map.json). I tried leaving a message over there to update "magazineArticle": "Cite news"," to "magazineArticle": "Cite magazine",", but the talk page is weird, and I'm not dealing with figuring out how to use that interface. Looking at the json map, some other entries could be updated as well. We have {{cite thesis}}, {{cite patent}}, {{cite dictionary}} that could be used, and {{cite arxiv}}/{{cite biorxiv}} that should be added to cite arxiv/biorxiv preprintsHeadbomb {t · c · p · b} 20:16, 17 August 2017 (UTC)[reply]

MediaWiki_talk:Citoid? E Eng 20:20, 17 August 2017 (UTC)[reply]

Just click in the white box at the top, where it says "Start a new topic". It will likely all make sense after that. However, Anne doesn't seem to be using VisualEditor, so the citoid service isn't immediately related to her request.

(I am also curious about the claim that problems are created by using the "wrong" template.) Whatamidoing (WMF) (talk) 20:22, 17 August 2017 (UTC)[reply]

It is possible that by that she means such citations get picked up by WP:JCW/POP, or just makes people think Billboard is a journal, rather than a magazine. I'll let Anne Delong (talk · contribs) speak for themselves, however. Headbomb {t · c · p · b} 20:38, 17 August 2017 (UTC)[reply]

Sorry, I was away from my computer. The presenter whose talk I attended ([9]) was using an algorithm to harvest and analyze journal citations from Wikipedia articles, creating statistical information about which academic journals were being cited with what frequency by articles in which categories, etc. He was using this information to find and fill gaps in Wikipedia's coverage of notable journals. Billboard kept coming up on his list of journal citations, much to his annoyance (I sat quietly embarrassed in the audience and said nothing....) He was categorizing references, rather than articles, so the categorization problem was indirect, but still, I was cluttering his dataset by using the wrong template. It appears I can just change the word "journal" to "magazine" after the citation is rendered, but I thought if it wasn't too much work for the tech people to add one more item to the citation template list, it would be helpful to others who add magazine references as well as to me. There are a LOT of citations to magazines. I could also just cite the magazine directly without using the Cite template, but several talks at Wikimania have convinced me of the value of structured data.—Anne Delong (talk) 21:57, 17 August 2017 (UTC)[reply]

We could rename it {{cite periodical}}, to reduce the belief that "journal" means "academic publication", but then we'll have people using that template for newspapers (which are also periodicals). WhatamIdoing (talk) 23:36, 17 August 2017 (UTC)[reply]

Glad you attended my talk Anne! A few things, most of the issue comes from way back, when {{cite magazine}} redirected to {{cite journal}} and were rendered the same. That changed a few years ago, but as far as the project is concerned, misuse of the templates concerning magazines vs journals really isn't that big of a deal. Sure it might be a cleaner dataset when excluding the magazines, and it might be nice to have a "Magazines Cited by Wikipedia" compilation (I think I'll ask J-LaTondre to build one in fact, because why not?), but it doesn't really affect our work as far as categorization/article creation goes.

It causes issues when you try to do what I did and try to find some patterns in the data, or do original research like I did, but short of that, it's not a critical difference. There are actually some benefits, as magazines that make their way on the list get more attention.

Best practice would be to use the correct {{cite magazine}}, but it's not horrifyingly horrible to use {{cite journal}}. Cheers! Headbomb {t · c · p · b} 01:06, 18 August 2017 (UTC)[reply]

Okay, thanks for listening.... I will use the magazine template by adding it manually.—Anne Delong (talk) 03:33, 18 August 2017 (UTC)[reply]

When closing a picture (in Media Viewer), it doesn't return to original scroll position (regression, Chrome only)

Tracked in Phabricator
Task T173618

Repro:

Open https://en.wikipedia.org/wiki/Battle_of_Long_Tan#Battle
Click on the image on the right
Close Media Viewer by "X" or Esc

What happened: it scrolls all the way to top instead of staying at your original position. Chrome only, tested with Version 61.0.3163.49 (Official Build) beta (64-bit) and 62.0.3188.0（Official Build）canary.--fireattack (talk) 07:11, 18 August 2017 (UTC)[reply]

Don't worry you can disable that horrible thing by going into your user preferences, clicking on the "Appearance" tab and unchecking "Enable Media Viewer". Then click Save. (((The Quixotic Potato))) (talk) 09:08, 18 August 2017 (UTC)[reply]

I cannot reproduce the problem using Chromium 59. Scroll position remains correct. Have you reported a bug to the Chrome developers? --Malyacko (talk) 11:57, 18 August 2017 (UTC)[reply]

Just did: https://bugs.chromium.org/p/chromium/issues/detail?id=756868 seems like a regression caused by a change in ver. 61 -fireattack (talk) 17:30, 18 August 2017 (UTC)[reply]

JPG missing content when thumbnailed

Something is up with File:Stonehenge Q&R.jpg - at full size (and some thumbnail sizes) it has overlaid key text and stone locations marked (eg. [10]), but at other thumbnail sizes, including the one used in the Q and R Holes article, it just shows the grey background blocks (eg. [11]). What's happening here? --Gapfall (talk) 10:51, 18 August 2017 (UTC)[reply]

That image, as well as the others uploaded by that user, have the hallmarks of not actually being free images. New user, claims they are his images, clearly zoomed-in on some page or another. The question might be somewhat moot. --Izno (talk) 13:12, 18 August 2017 (UTC)[reply]

Template:la and wikisyntax

That appears to be the very old bug T14974. Anomie ⚔ 15:01, 18 August 2017 (UTC)[reply]

Per Help:Template#Problems and workarounds, you can replace * with * in the call:

PrimeHunter (talk) 17:20, 18 August 2017 (UTC)[reply]

I have made {{Encodefirst}} as a general workaround which can also be used in templates without the caller having to do anything. {{la|{{Encodefirst|*}}}} produces:

If {{Encodefirst}} were used in two places in {{la}} then {{la|*}} would also work. Should we start thinking about complicating some templates by using {{Encodefirst}} or something similar to work around this issue? PrimeHunter (talk) 20:48, 19 August 2017 (UTC)[reply]

Please don't add more internal complexity to {{la}}, it was a series of "enhancements" (by Technical 13) to that and related templates that caused a large number of XFD listings to fall over with WP:TLIMIT problems back in 2013-14. --Redrose64 🌹 (talk) 10:24, 20 August 2017 (UTC)[reply]

The price of adding {{la|*}} to my userpage was 34/1000000 Preprocessor visited node count, 13/2097152 Post‐expand include size, 5/2097152 Template argument size, 0.01/10 seconds Lua time usage and 0.09/50 MB Lua memory usage. If adding 1 instance of this template increases the results by 1% of the maximum, then adding 2 to {{la}} would put a limit of 50 page listings on any AFD page - and yesterday we reached 104. עוד מישהו Od Mishehu 06:52, 21 August 2017 (UTC)[reply]

You mean you added {{Encodefirst|*}} to your user page. Where do you get 1% of the maximum from? 0.01/10 seconds is 0.1%, and 0.09/50 MB is 0.18%. And {{Encodefirst}} is cheaper when the parameter doesn't start with one of : ; * #. Nearly all uses would be the cheap case where it only tests the first character and then returns the whole parameter unchanged. That gives zero Lua usage and allows tens of thousands of calls of {{Encodefirst}}. The expensive case with the special characters could be optimized with a dedicated Lua function. I only used template code which calls a general Lua function via {{str right}}. PrimeHunter (talk) 11:01, 21 August 2017 (UTC)[reply]

One possible Lua function might be this: Module:Sandbox/trappist_the_monk/bob. Invoke it from a template like this:

{{#invoke:Sandbox/trappist_the_monk/bob|encode_first|:some text}} – in real life replace ':some text' with {{{parameter}}}

which, for this example would give this output:

<strong class="error"><span class="scribunto-error mw-scribunto-error-7c52fa29">Script error: The function &quot;encode_first&quot; does not exist.</span></strong>

I'm skeptical that such a function is needed but there it is.

—Trappist the monk (talk) 12:23, 21 August 2017 (UTC)[reply]

New feature: LoginNotify

Hi everyone,

The Community Tech team has released a new security feature this week: LoginNotify, which gives you a notification when someone tries and fails to log in to your account. This project was wish #7 on the 2016 Community Wishlist Survey.

Here’s how it works:

If someone tries and fails to log in to your account from a device or an IP address that hasn’t logged into your account recently, then you’ll get an on-wiki notification at the first attempt. For a familiar device or IP address, you’ll get an on-wiki notification after 5 failed logins. This is on by default, but you can turn it off in your preferences; you can also turn on email notifications.

It’s also possible to turn on email notifications when there’s a successful login from a new device or IP address. This is turned off by default, but it might be useful for admins or other functionaries who are concerned that their user rights could be misused. This means that you’ll get a notification every time you log in from a new device or IP address.

We want to take this opportunity to thank Brian Wolff for all of his work in writing the underlying extension for this feature.

There’s more information on the feature on the Community Tech project page on Meta, and please feel free to post questions on the talk page: Community Tech/LoginNotify

If you're also active on another wiki, please feel free to copy and share this information with your community.

PS: If you’re wondering what happened to the Syntax Highlighting beta feature that we deployed a couple weeks ago and then had to roll back: it’ll be back soon! -- DannyH (WMF) (talk) 23:19, 18 August 2017 (UTC)[reply]

Thanks, I will test it on my own MediaWiki install. (((The Quixotic Potato))) (talk) 23:36, 18 August 2017 (UTC)[reply]

Edit position lost on "Show preview"

When I am editing a page, click the "Show preview" button, than go back to the edit window my position is lost – the text now starts at the top again. I have to scroll back down to find the text I was changing. With "edit this page" on a large article it introduces a fair amount of scrolling. This is a new feature. Will it be fixed? Aymatth2 (talk) 22:23, 19 August 2017 (UTC)[reply]

Not broken in Firefox... Try fixing it with Preferences → Editing → Show previews without reloading the page, live preview.— Cpiral§Cpiral 04:59, 20 August 2017 (UTC)[reply]

@Cpiral: The editing preferences change fixes it with Chrome. For some reason the display momentarily fades before showing the preview, but edit position is not lost. Solved. Thanks, Aymatth2 (talk) 10:53, 20 August 2017 (UTC)[reply]

It does this in Opera, don't know if it's always been the case. --Redrose64 🌹 (talk) 09:24, 20 August 2017 (UTC)[reply]

@Redrose64: This just started a few days ago in Chrome. Cpiral's solution works - probably for Opera too. Aymatth2 (talk) 10:53, 20 August 2017 (UTC)[reply]

Not fixed. I use User:Ucucha/HarvErrors to check that the {{sfn}} citation links are good, and User:Anomie/linkclassifier to color links to disambiguation and redirect pages. When I choose "Preferences → Editing → Show previews without reloading the page", those scripts do not kick in. Problems are not visible until I save the page. I would rather lose edit position than lose the script functionality.

Something must have been changed to introduce this problem? I am sure the edit position used to be retained after "show preview". Aymatth2 (talk) 16:17, 20 August 2017 (UTC)[reply]

Wikimedia Commons watchlist problem

Hi, I've recently had a problem with my watchlist on Commons (elsewhere, everything is fine). It doesn't open, instead I get the following message:

"[WZlJ3gpAMFoAADyMDKwAAAAE] 2017-08-20 08:36:42: Fatal exception of type »Wikimedia\Rdbms\DBQueryError«"

Can anyone help here? Where should I report this?

Thanks in advance. --Eleassar ^{my talk} 08:39, 20 August 2017 (UTC)[reply]

@Eleassar: This may be related to #Watchlist changes above. How many pages are there on your watchlist (approximately)? At c:Special:Preferences#mw-prefsection-watchlist, what value do you have for "Maximum number of changes to show in watchlist"? --Redrose64 🌹 (talk) 09:29, 20 August 2017 (UTC)[reply]

There are about 90,000 pages on my watchlist. I don't exactly remember the maximum number of changes, but I would say it is 1,000. --Eleassar ^{my talk} 10:48, 20 August 2017 (UTC)[reply]

Yes, I've checked this up. Correct: there are 1,000 changes shown. --Eleassar ^{my talk} 10:53, 20 August 2017 (UTC)[reply]

It could be related to these changes. Anyway, at this moment, my watchlist does not work at all... Re work here, I find this rather urgent. In addition, I'm most probably not the only one with a non-functioning WL. --Eleassar ^{my talk} 11:32, 20 August 2017 (UTC)[reply]

There are others with huge watchlists at commons:Commons:Village pump#Filtered whatchlist causing Database error. PrimeHunter (talk) 12:21, 20 August 2017 (UTC)[reply]

Thanks. I'll report there. --Eleassar ^{my talk} 13:03, 20 August 2017 (UTC)[reply]

I also think that this is the same set of problems that is discussed in #Watchlist changes. Whatamidoing (WMF) (talk) 06:23, 21 August 2017 (UTC)[reply]

This could be phab:T164059, phab:T142329, phab:T171898, phab:T171027, or something else. Potential workarounds you can try are in phab:T171898#3481750 and phab:T171366#3462659. --AKlapper (WMF) (talk) 10:09, 21 August 2017 (UTC)[reply]

extract infobox

is there any way to extract infobox from en wiki and save it in txt?I want to write aricle by bot. is there any tools in wmflabs to help me? --Monorodo (talk) 17:08, 20 August 2017 (UTC)[reply]

Automatic article creation is not permitted on English Wikipedia. Though on other projects it is possible. See User:Lsjbot. Ruslik_Zero 20:28, 20 August 2017 (UTC)[reply]

You could use WP:AWB for this. There should be some documentation about infobox (params) extracting. --Edgars2007 (talk/contribs) 13:23, 22 August 2017 (UTC)[reply]

Markup broken on Wikipedia:Articles for deletion/Stanley Aronowitz bibliography

I closed Wikipedia:Articles for deletion/Stanley Aronowitz bibliography a while ago. Today, I just noticed the automated tools got the markup wrong; the pastel blue box indicating a closed AfD only extends about halfway down the page. Could somebody, who's better at wiki-markup and templates than me, take a look at it and fix whatever's wrong? Thanks. -- RoySmith (talk) 13:45, 21 August 2017 (UTC)[reply]

Fixed by Izno.[12]. A starting div was removed in [13] without removing the ending div which later matched a new starting div. PrimeHunter (talk) 14:33, 21 August 2017 (UTC)[reply]

Likely a thousand external links broken by comma-space errors.

I have recently done a test run searching about 150,000 articles for comma-space errors. One recurring error that I have seen a few dozen times is the kind typified by this correction. The external link contains a comma between the URL and the intended external link text; the external link is broken while the comma is there; removing the comma fixes it. From the sample of repairs done, I would estimate that there are probably a thousand additional instances of this error. What is needed is a way to search for broken external links containing commas that would work if the last comma in the link was changed to a space. bd2412 T 14:40, 21 August 2017 (UTC)[reply]

How common are false positives, i.e. a URL that ends in a comma? The regex for this would I presume be single(not double) left bracket followed by http: then a string with no spaces, commas or right brackets, followed by a comma, then a space.Naraht (talk) 14:59, 21 August 2017 (UTC)[reply]

The given example does not have a space after the comma, which makes the problem quite difficult. There are many valid URLs that do contain embedded commas (see quarry:query/21030 for examples). DMacks (talk) 12:55, 22 August 2017 (UTC)[reply]

That is the problem in a nutshell. The way to find these is to find broken links that happen to have a comma before the last string of text, and see if changing that comma to a space would turn the link into a working link. The ones I have found have primarily been because the link just looks wrong even in AWB. bd2412 T 13:20, 22 August 2017 (UTC)[reply]

Then the question becomes how many valid URLs have a string at the end consisting of comma, capital letter, string of lower case letters.Naraht (talk) 14:07, 22 August 2017 (UTC)[reply]

That, I have no idea. However, if there's a way to test URLs and skip the valid ones, we should be able to generate a list of non-working URLs with this characteristic. bd2412 T 19:08, 23 August 2017 (UTC)[reply]

Tech News: 2017-34

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

Recent changes

You can now test the new Timeless skin on the test wiki and mediawiki.org. You can turn it on in your preferences. You can report bugs in Phabricator. It will come to more wikis soon. [14][15]
Your watchlist can now have the option to unwatch pages. You have to turn this on in your preferences. [16]
If a table has several columns you can often choose which column you want to use to sort the table. This has not worked for some columns for readers who have used Firefox or Safari. This has now been fixed. [17]
The RelatedArticles extension has shown related pages on Wikivoyages. You will now see the related pages at the end of the article together with an image. Previously the links were in the sidebar. Wikis that want this extension can request it on Phabricator.

Changes later this week

Videos will now be played in the WebM format in all browsers. Previously some browsers used Ogg Theora (.ogv). If you use Safari, Internet Explorer or Edge you may see slower playback speed at high resolutions. Instead we will get better quality and smaller file size. You can still upload video as Ogg files. They are automatically converted to WebM. This doesn't affect Ogg audio files. [18]
The default font in the edit window will change for some users this week. Instead of using the browser default, it will be monospace. Users can change this in their preferences. This should only change this for some users on Macs and iOS devices. [19]
The new version of MediaWiki will be on test wikis and MediaWiki.org from 22 August. It will be on non-Wikipedia wikis and some Wikipedias from 23 August. It will be on all wikis from 24 August (calendar).

Meetings

You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 23 August at 15:00 (UTC). See how to join.
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 22 August at 19:00 (UTC). See how to join.

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

18:00, 21 August 2017 (UTC)

Quick highlight: The default font for the editing window in the older wikitext editors (e.g., in the 2010 wikitext editor) will change here on Thursday. If you don't like the result, you can change it at Special:Preferences#mw-prefsection-editing to whatever you prefer. Whatamidoing (WMF) (talk) 18:06, 22 August 2017 (UTC)[reply]

MediaWiki:Licenses/en-placeholder

Are MediaWiki:Licenses/en-placeholder and its related -buildings and -people variants still used anywhere in the interface? I just came across File:Ellie portrait.jpg, uploaded by Georgewarre (talk · contribs), which used a {{Multilicense replacing placeholder new}}, a deprecated and since deleted license tag that is apparently still listed on these subpages. Georgewarre, if you see this - please let us know the process (links, pages) by which you uploaded this file. – Train2104 (t • c) 18:57, 21 August 2017 (UTC)[reply]

External link checker

Having trouble with the external link checker. eg

[20]

Any ideas? Hawkeye7 (talk) 23:07, 21 August 2017 (UTC)[reply]

Per [21] you can replace dispenser.homenet.org with 69.142.160.183: [22]. Maybe you have enabled MoreMenu at Special:Preferences#mw-prefsection-gadgets. Its code at MediaWiki:Gadget-dropdown-menus-vector.js has several currently broken links to dispenser.homenet.org. The domain hasn't worked for at least 24 days. Should we update the script to link to the IP address? In [23] I updated MediaWiki:Linkshere which is shown at WhatLinksHere. Redrose64 expressed concern about linking an IP address in the MediaWiki namespace at Wikipedia:Village pump (technical)/Archive 158#What Links Here. An opt-in gadget may be less controversial than a non-optional interface message. PrimeHunter (talk) 23:31, 21 August 2017 (UTC)[reply]

It is included in {{Featured article tools}}. Hawkeye7 (talk) 00:42, 22 August 2017 (UTC)[reply]

I'm not sure why linking to an IP address from the interface would be any more or less problematic than linking to someone's personal web domain from the interface, as we are currently doing. — This, that and the other (talk) 04:51, 22 August 2017 (UTC)[reply]

It would be problematic if the IP address is not static. Hawkeye7 (talk) 14:12, 23 August 2017 (UTC)[reply]

Images in infobox header

The symbols in the title of the infobox of Dalian North Railway Station are not showing in mobile (Minerva) because of the CSS rule .content a > img { max-width: 100% !important }. Is this fixable? (pinging Super Wang) Jc86035 (talk) 11:08, 22 August 2017 (UTC)[reply]

PLEASE help mobile users ;-) Super Wang 11:13, 22 August 2017 (UTC)[reply]

You can set a min-width on the element that wraps the images. This is a known problem with images inside tables on mobile. —TheDJ (talk • contribs) 11:35, 22 August 2017 (UTC)[reply]

@TheDJ: The images (basically anything from {{rail-interchange}}) tend to have varying widths so a fixed one cannot be set in this instance. Jc86035 (talk) 11:37, 22 August 2017 (UTC)[reply]

Why is the rule used? Could it be changed to be more specific and filter out images inside tables? Jc86035 (talk) 11:39, 22 August 2017 (UTC)[reply]

To make sure that larger images don't overflow the viewport of the device. Unfortunately there are no selectors for 'small images', so i don't see how it can be made more specific. And it's not just tables, it's table layout (for which again, there is no selector). It's a difficult problem. —TheDJ (talk • contribs) 12:06, 22 August 2017 (UTC)[reply]

@TheDJ: Wasn't there this bug whose fix used JavaScript to disable lazy loading for small images (defined there as less than 50px in either height or width)? (Or is this not fixable or too computationally expensice to fix with JS?) Jc86035 (talk) 14:44, 23 August 2017 (UTC)[reply]

New notification when a page is connected to Wikidata

Hello all,

The Wikidata development team is about to deploy a new feature on English Wikipedia. It is a new type of notification (via Echo, the notification system you see at the top right of your wiki when you are logged in), that will inform the creator of a page, when this page is connected to a Wikidata item.

You may know that Wikidata provides a centralized system for all the interwikilinks. When a new page is created, it should be connected to the corresponding Wikidata item, by modifying this Wikidata item. With this new notification, editors creating pages will be informed when another editor connects this page to Wikidata.

This feature will be deployed on September 5th on English, French and German Wikipedia. It has already been deployed in May on all the other Wikipedias and other Wikimedia projects. This feature will be disabled by default for existing editors, and enabled by default for new editors.

If you have any question, suggestion, please let me know by pinging me. You can also follow and leave a comment on the Phabricator ticket.

Thanks go to Matěj Suchánek who developed this feature! Cheers, Lea Lacroix (WMDE) (talk) 14:23, 22 August 2017 (UTC)[reply]

What an excellent idea! Very nice to hear from you after Wikimania, I've attended your Wikidata talks and they were just great!Headbomb {t · c · p · b} 14:34, 22 August 2017 (UTC)[reply]

"This feature will be disabled by default for existing editors" - Great news. This should be the standard for all updates. Lugnuts ^{Fire Walk with Me} 18:53, 22 August 2017 (UTC)[reply]

Greenville, North Carolina

Tracked in Phabricator
Task T170039

Hi there. At Greenville, North Carolina, on the main page (not in edit mode), there is a script error in the infobox where the coordinates are. Not all the time, but a few times. All the coding looks fine though. Thanks. Magnolia677 (talk) 19:43, 22 August 2017 (UTC)[reply]

This is phab:T170039. The developers are working on this problem. --Izno (talk) 20:30, 22 August 2017 (UTC)[reply]

Watchlist category changes

I made the changes as suggested in Help:Watchlist#Limitations, but in the watchlist I can't see if a page is added or removed from a category. Just to be clear, my expectation is that if I am watching a category and if any of the pages in that category removes this category from the page, I get to see in the watchlist, but that doesn't happen. Coderzombie (talk) 06:43, 23 August 2017 (UTC)[reply]

It works for me. Is "Hide categorization of pages" disabled at Special:Preferences#mw-prefsection-watchlist? Have you enabled any of the hide options there? Which category are you watching and which page did you expect to see? Does your watchlist display edits which are older than the edit which removed the page from the category? PrimeHunter (talk) 20:58, 23 August 2017 (UTC)[reply]

@PrimeHunter: I had done everything, except "Have you enabled any of the hide options there?". I made a change in category, but I had hidden "my edits", so that's the reason it was not showing. It works now. Thanks! Coderzombie (talk) 00:53, 24 August 2017 (UTC)[reply]

Tracking category

I requested for a tracking category at Template talk:Coord#Tracking category. Can anyone please help in that? -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 07:49, 23 August 2017 (UTC)[reply]

I suggested that you ask here if there were a demonstrable need for such a category. What would be done with it? Johnuniq (talk) 08:15, 23 August 2017 (UTC)[reply]

Need is simple. There are articles having infoboxes using this template outside infoboxes. I guess that is not how it should be used. With such a tracking category, we will be able to move the template to infoboxes used in those articles. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 08:21, 23 August 2017 (UTC)[reply]

@Capankajsmilyo: Not every article has an infobox. I think it would be better to add tracking to the infobox templates instead. Jc86035 (talk) 08:57, 23 August 2017 (UTC)[reply]

There is nothing in the documentation saying {{Coord}} is only for infoboxes. It has 1.1 million uses and tens of thousands are probably without infoboxes, e.g. Londinium, Tribeca, Noachian. The only way this might be a little useful is if it only lists articles which do have an infobox and the used infobox does have a coordinates parameter, but {{coord}} is used outside it. It cannot be done with a tracking category but would require a database scan. It doesn't seem worth the effort to me. PrimeHunter (talk) 17:56, 23 August 2017 (UTC)[reply]

Adding the new Timeless skin as a non-default option

Tracked in Phabricator
Task T154371

(This is not—yet—an RFC.) A new MediaWiki skin called Timeless is being developed, mostly by Isarra. I was wondering if there would be any community interest in adding it to the English Wikipedia as a non-default preference.

For further context, this is Isarra's post on Wikimedia Commons about testing Timeless. Jc86035 (talk) 08:49, 23 August 2017 (UTC)[reply]

This is what developer time is being spent on? E Eng 11:57, 23 August 2017 (UTC)[reply]

@EEng: yes, volunteer developers get to work on whatever they want. —TheDJ (talk • contribs) 12:21, 23 August 2017 (UTC)[reply]

Sorry, didn't realize these were the volunteers. E Eng 12:23, 23 August 2017 (UTC)[reply]

There are no downsides to adding it, and it may be used by people who like it, so why not? It may be a good idea to wait until Isarra thinks it is ready to be used. (((The Quixotic Potato))) (talk) 12:37, 23 August 2017 (UTC)[reply]

@The Quixotic Potato: Timeless is already enabled on three wikis with content, so even if it's not finished yet it's probably ready for being a non-default preference here (although Commons has been waiting for it for about five months now). Jc86035 (talk) 13:04, 23 August 2017 (UTC)[reply]

Good point. I am in favor of adding it as a non-default optional skin. (((The Quixotic Potato))) (talk) 13:08, 23 August 2017 (UTC)[reply]

This is the first line in #Tech News: 2017-34. I expect "it will come to more wikis soon" to mean "we're rolling it out as a proper skin". --Izno (talk) 13:24, 23 August 2017 (UTC)[reply]

This seems to have been a bit unclear. My fault, and my apologies. What I referred to was the wikis mentioned in phab:T154371 and other wikis that decide they want it (like English Wikipedia could do here). /Johan (WMF) (talk) 13:32, 23 August 2017 (UTC)[reply]

@Johan (WMF): There was this comment at the Phabricator task that (now-later) leads me to believe that it's coming down the train. :) --Izno (talk) 13:38, 23 August 2017 (UTC)[reply]

I'm not involved in the development or deployment of Timeless, so I'm not intimately familiar with the plans – I'm just trying to discourage people from reading too much into the Tech News announcement. If the information is coming from other sources, then my objections are irrelevant. (: /Johan (WMF) (talk) 13:53, 23 August 2017 (UTC)[reply]

Ogg Theora video sunsetting

As mentioned in tech news, we are sunsetting Ogg Theora (.ogv) video derivatives in favor of playing back WebM on all browsers, including Safari/IE/Edge which use a JavaScript decoder shim.

Starting today, playback in Safari/IE/Edge will start using WebM derivatives in favor of Ogg most of the time; if nothing seems explodey we'll turn off the generation of Ogg derivatives tomorrow.

Playback may be slower on very slow machines, especially running Internet Explorer, but this improves quality and file size and makes server-side maintenance a lot easier.

Note that Ogg videos may still be uploaded -- they are converted to WebM for playback. Non-ogg audio files also still produce Ogg Vorbis (.ogg or .oga) derivatives. -- Brion VIBBER (talk • contribs) 19:53, 23 August 2017 (UTC)[reply]

The .ogv video derivatives are now switched off; only .webm video derivatives will now be generated and used. If anyone is specifically using .ogv derivative files (not the original uploads), beware that in the future you'll need to use the .webm versions. --brion (talk) 23:41, 24 August 2017 (UTC)[reply]

It would make more sense to take the opportunity to kill 3 birds with one stone, and fully kill off all ogg transcoding. Audio is better transcoded into mp3 rather than ogg, as that can be used by more devices, and users who want full quality can always download the original file. It seems that task (or related https://phabricator.wikimedia.org/T45149) is stuck on needless bureaucracy... 21:51, 23 August 2017 (UTC)~ — Preceding unsigned comment added by 197.218.80.227 (talk)

I think only fairly old devices can't play Ogg Vorbis nowadays. Is mp3 completely unencumbered by now? If it is, then I suppose even the few devices that can't play Ogg Vorbis are some sort of argument, but if there are any intellectual-property restrictions on it whatsoever, then I don't think it's worth it. --Trovatore (talk) 22:33, 23 August 2017 (UTC)[reply]

Based on c:Commons:Village pump#A discussion about support for MP3 on Commons, MP3s can't be uploaded right now. I understand that this could be changed, if there were a consensus at Commons to permit it. Whatamidoing (WMF) (talk) 22:49, 23 August 2017 (UTC)[reply]

Indeed, mp3 is now free (https://www.theregister.co.uk/2017/05/16/mp3_dies_nobody_noticed/), phab:T120288#3316046. Newer devices do not necessarily support ogg anyway, see http://caniuse.com/#feat=ogg-vorbis . Edge, and safari are used by newer devices (including mobile) and don't seem to have builtin ogg support. If they had, there would be no need to worry about javascript fallback because most older browsers don't even get javascript anyway.

Also, somewhat offtopic here, this is about transcoding not uploading, but anyway, Mp3 can be uploaded, commons isn't the only wikimedia project that allows direct upload. Other projects can also easily ignore whatever decision commons makes, and request mp3 uploading separately (mw:Manual:$wgFileExtensions). 197.218.80.227 (talk) 23:04, 23 August 2017 (UTC)[reply]

Oh, MP3 is coming. I was at Wikimania pushing this. WMFer are scared of another community revolt and the hecklers spewing FUD isn't helping. Also, MPEG-2 (DVD-Video) become patent free February. — Dispenser 00:13, 24 August 2017 (UTC)[reply]

We do intend to add .mp3 audio derivatives soon, which will provide mobile playback for iOS, and native (non-shim) playback in desktop Safari, IE, and Edge. There's not a pressing need to turn off the .ogg audio derivatives (they don't require ffmpeg2theora or libtheora on the server, which were becoming maintenance problems), but that will be something we have an option to consider in the future once the .mp3 derivatives are available. --brion (talk) 23:41, 24 August 2017 (UTC)[reply]

Listeria bot

Hello. I am using Template:Wikidata list. I have created two list. Both are showing the managers of a both teams. The first one take the values for the team item and the second one takes the in formations from managers items. But, no one shows the references.

Anyone knows if I can solve that? Xaris333 (talk) 01:40, 24 August 2017 (UTC)[reply]

Listeria bot and non-free images

This was previously discussed at Wikipedia:Village pump (technical)/Archive 154#Listeria bot again, but Listeria bot is back adding non-free files to page outside the article namespace: this time Wikipedia:GLAM/Amnesty International: Human Rights Defenders. File:Liu Xiaobo.jpg is non-free content, and it is shadowing a freely licensed image on Comomns of the same name. FWIW, the Commons' file is likely a copyvio claimed as "own work" and should be deleted shortly, so there's no point in changing the local file's name and this file should no longer be an issue when that happens. Is there, generally speasking, a way to tweak the bot's settings so that it can differentiate between (non-free) files uploaded locally to Wikipedia and files uploaded to Commons even when they have the same name? I've tried posting about this at User talk:ListeriaBot, but there's been no response. -- Marchjuly (talk) 01:57, 24 August 2017 (UTC)[reply]

Have you tried its operator, Magnus Manske? עוד מישהו Od Mishehu 03:00, 24 August 2017 (UTC)[reply]

This isn't a problem with the bot I believe, it is a problem with us having a different file from Commons under the same name. I'd fix that instead of changing the bot. Jo-Jo Eumerus (talk, contributions) 14:41, 24 August 2017 (UTC)[reply]

I am aware, as posted above, of the shadowing. I also posted above that the Commons files seems likely to be deleted for lacking permission, so changing the non-free's name at this point seems unnecessary; moreover, if the Commons' file is kept, the non-free will no longer be needed and can be deleted per WP:F7. The "problem" is more of a general one in that the bot will keep re-adding a non-free file which has been removed per WP:NFCC#9 because it believes it is adding a file from Commons. So, I am curious as to whether the bot can tell if the file it is actually adding is from Commons or Wikpedia because if it can do that then maybe there's a way for it to tell whether the file is non-free. -- Marchjuly (talk) 21:43, 24 August 2017 (UTC)[reply]

Need template help

I've nominated both Draft:Cleeng and Draft:Cleeng (2) for deletion, at WP:Miscellany for deletion/Draft:Cleeng (2nd nomination). I have failed to find the correct magic template incantation to place on Draft:Cleeng (2) to get it to point to the correct MfD page. Could somebody fix that up for me? Thanks. -- RoySmith (talk) 13:35, 24 August 2017 (UTC)[reply]

The documentation for {{mfdx}} is wrong. I had to view the source to work it out: [24]. PrimeHunter (talk) 15:09, 24 August 2017 (UTC)[reply]

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

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

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

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

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

Closing break tags

Hi, I find it annoying when there are unclosed break tags ( ) in a page as they mess up the syntax highlighting. I then have to look for them and close them ( ) before proceeding with my actual edit. Is there some way this can be automated? Or could a bot (perhaps AnomieBot) include this as a clean-up practice?—Cpt.a.haddock (talk) (please ping when replying) 15:13, 24 August 2017 (UTC)[reply]

Ideally there shouldn't be any html break tags in an article at all since wiki markup should be able to handle all sorts of line breaks. From my experience they keep getting used though in infoboxes and other large templates where {{plainlist}} and the like should be used instead. So as a first measure I wouldn't mind a bot closing open breaks. De728631 (talk) 15:20, 24 August 2017 (UTC)[reply]

Indeed, that's where most of these tags end up being clustered.—Cpt.a.haddock (talk) (please ping when replying) 15:46, 24 August 2017 (UTC)[reply]

Don't use a broken syntaxhighlighter then. —TheDJ (talk • contribs) 15:23, 24 August 2017 (UTC)[reply]

@TheDJ: Which one is the unbroken syntaxhighlighter?—Cpt.a.haddock (talk) (please ping when replying) 15:47, 24 August 2017 (UTC)[reply]

The one in beta since yesterday (See Beta top of the page), or wikEd. (though wikEd has some other problems). —TheDJ (talk • contribs) 16:02, 24 August 2017 (UTC)[reply]

Agreed, this is a case of a broken highlighter, not the wikitext's fault. --Izno (talk) 17:44, 24 August 2017 (UTC)[reply]

The   tag is valid HTML5 (as is the   tag) and is also whitelisted for MediaWiki. We should not be using automation (whether by sending in a bot or somebody using WP:AWB) to alter one form of perfectly valid markup to another form, with nil effect on the rendered page. This is what WP:COSMETICBOT and WP:AWBRULES item 4 are all about. --Redrose64 🌹 (talk) 22:16, 24 August 2017 (UTC)[reply]

Beta feature: advanced filters and more options for Watchlists, starting September 5

Hello!

As you may already know, the Global Collaboration team has created a Beta feature. This feature is on your wiki since few months: "⧼eri-rcfilters-beta-label⧽". You can activate it in your Beta preferences.

What is this feature again?

This feature improves Special:RecentChanges and Special:RecentChangesLinked. It adds new features that ease vandalism tracking and support of newcomers:

Filtering - filter recent changes with easy-to-use and powerful filters combinations, including filtering by namespace or tagged edits.
Highlighting - add a colored background to the different changes you are monitoring. It helps quick identification of changes that matter to you.
Bookmarking to keep your favorite configurations of filters ready to be used.
Quality and Intent Filters - those filters use ORES predictions. They identify real vandalism or good faith intent contributions that need help.

You can know more about this project by visiting the quick tour help page.

What's new?

On September 5, the Beta feature will have a new option. Watchlists will have all new features available on Recent Changes Beta now.

If you have already activated the Beta feature "⧼eri-rcfilters-beta-label⧽", you have no action to take. If you haven't activated the Beta feature "⧼eri-rcfilters-beta-label⧽" and you want to try the filters on Watchlists, please go to your Beta preferences on September 6. It will not be possible to try the filters only on Recent Changes or only on Watchlist.

Please also note that later in September, some changes will happen on Recent Changes. We will release some features at the moment available in Beta as default features. This will impact all users, but we will provide an option to opt-out. I'll recontact you with a more precise schedule and all the details very soon.

You can ping me if you have questions.

All the best, Trizek (WMF) (talk) 15:46, 24 August 2017 (UTC)[reply]

Fixed-width font on edit boxes

This is amazing and exactly what I wanted! It also looks terrible by default.

Is there any way I could have found out about this before it was applied, or can modify the font? Power~enwiki (talk) 19:37, 24 August 2017 (UTC)[reply]

@Power~enwiki: see Special:Preferences#mw-prefsection-editing "Edit area font style" to change this. — xaosflux ^Talk 20:12, 24 August 2017 (UTC)[reply]

And announced right here —TheDJ (talk • contribs) 20:24, 24 August 2017 (UTC)[reply]

I've subscribed, thanks! Power~enwiki (talk) 20:30, 24 August 2017 (UTC)[reply]

Happy this worked for you. Jdforrester (WMF) (talk) 20:36, 24 August 2017 (UTC)[reply]

CSS related change

In case others also have breaking custom CSS after this change, what I had to do to fix mine was update the .mw-editfont-default class to the .mw-editfont-monospace one ([25]). This might be different if not using the monospace font setting (but it always was monospace for me and I like it this way). —Paleo Neonate – 20:29, 24 August 2017 (UTC)[reply]

I'd strongly counsel not using the font as the selector. textarea#wpTextbox1 will work for a long time without risk of disruption when the user changes their font. Jdforrester (WMF) (talk) 20:36, 24 August 2017 (UTC)[reply]

Thanks for the suggestion, I updated it. —Paleo Neonate – 20:47, 24 August 2017 (UTC)[reply]

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

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

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

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

[1] Bug 9790: Watchlist doesn't show earlier normal edits when hiding bot edits or minor edits.

[1]