Wikipedia:Village pump (technical)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

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

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

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

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

Save changes buttons - accessibility

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Show changes clicks Editing help on Android

Tracked in Phabricator
Task T171495

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

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

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

New Edit summary window

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Edit summary field hidden

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

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

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

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

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

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

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

What is this number?

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

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

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

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

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

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

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

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

Last characters in summary are hidden

Tracked in Phabricator
Task T169982

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

Put

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

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

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

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

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

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

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

#wpSummaryWidget > .oo-ui-labelElement-label

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

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

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

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

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

Character counts on subject/edit summaries?

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

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

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

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

Process

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Make it stop

Tracked in Phabricator
Task T169982

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

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

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

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

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

Cancel button no longer a button

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

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

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

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

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

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

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

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

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

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

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

Shortened edit summary

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

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

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

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

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

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

No preview of edit summary with live preview

Tracked in Phabricator
Task T171156

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

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

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

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

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

Tracked in Phabricator
Task T172844

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

Show Preview and Show Changes on a single button

Tracked in Phabricator
Task T41666

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

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

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

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

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

Citation expander

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

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

Delete page

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

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)

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)

@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)

@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)

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

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)

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

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)

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)

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

@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)

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

Hlist bullets not shown in mobile

Is this intentional behaviour or not? It looks bad when items are separated only with bigger spaces. I see no bullets in infobox data hlist on latest Chrome. --Obsuser (talk) 13:40, 29 July 2017 (UTC)

@Obsuser: This is some weird "feature" of the mobile CSS wherein a different class is supposed to be used instead, but obviously no one was informed of this as the class is completely unused. I have filed bugs but no action has yet been taken. A temporary solution would be to request the addition of proper hlist formatting to MediaWiki:Mobile.css. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 12:51, 1 August 2017 (UTC)

@Jc86035: Thank you. Until bug or something gets fixed, on sr.wiki I added class hlist-separated in sr:Module:List (sr:Special:Diff/10654538/14772002) because I saw you attempted same fix here but reverted it for some reason (probably precaution). If it really makes some problems, it should be reverted there too.

Now there are bullets on sr.wiki mobile (they are a bit weird, and dark blue and overspaced relative to desktop normal ones I think, but better to have something than nothing; text is otherwise separated with bigger space what is very confusing, and {{hlist}} is very widely used template). --Obsuser (talk) 17:45, 1 August 2017 (UTC)

@Jdlrobson: as I've not entirely followed discussion around hlist —TheDJ (talk • contribs) 18:20, 1 August 2017 (UTC)

hello. Jon here who works on the Minerva skin (mobile site). The hlist-separated class you talk about is a class used by the Minerva skin. Since the name "hlist" is very common in software development when we introduced horizontal lists to the mobile UI we happened to choose the same name that editors came up with. This is good as it means we can avoid introducing additional CSS that's not necessary and make hlist rules more general. That was the intention of keeping the same name once we realised there was a clash.

You are welcome to use the hlist-separated class as it is native to the skin and not an editor created class so it's likely to make UIs consistent with the rest of the user experience. We have some lists in the mobile skin which look bad with separators between them - so that's why it exists, although hlists inside the article should behave differently (whether they are working as they should is another matter).

MediaWiki:Mobile.css is JavaScript only so I advise you not to make any changes there - that would result in a flash of unstyled content in the mobile site (this is for performance reasons - rendering our mobile site as early as possible is very important in mobile development).

I'm not quite sure I understand the issue here. The Minerva skin uses the core hlist styling rules. There are some new styles relating to hlist currently riding the train (and will be deployed on Thursday) which may help, but I'm struggling to understand what the bug is here to tell you whether that will happen. What pages are you seeing the problem on? What are you expecting to see? What are you actually seeing? Yes, these styles are likely to look different from the Vector skin but I can't tell you whether that's intentional without that information. It's best to follow this conversation on the Phabricator ticket - I was aware of that issue, but not this discussion. Thanks TheDj for the ping! Jdlrobson (talk) 23:50, 1 August 2017 (UTC)

Oh and with regards to "but obviously no one was informed of this as the class is completely unused". This is quite new, and an advisory note about this has been in MediaWiki:Mobile.css since November 2016, but it's hard to know to circulate this to all the wikis we support - there are so many and commenting on every single village pump wouldn't scale. Is there a central place we can make these sort of notifications so they get seen? Jdlrobson (talk) 00:07, 2 August 2017 (UTC)

@Jdlrobson: Not sure, but a note could have been put in the weekly Tech News (or a separate mass message could have been sent, if the change is important enough) asking for comments on Meta. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 14:04, 8 August 2017 (UTC)

The issue is this: screenshot – no bullets in mobile, so items in 'Occupation' are unseparated and can cause very dangerous confusion if certain words find themselves next to each other separated only with bigger space. After adding hlist-separated in sr:Module:List, we get overspaced blue bullets with space before each next item: screenshot (note spaces before each next item, that's why I selected text). My question is can hlist-separated be added in Module:List too and if not why (it was added but removed shortly after)? --Obsuser (talk) 01:44, 2 August 2017 (UTC)

Yes! Please do add hlist-separated to Module:List. The blue color is definitely a bug our end and I can get that fixed. I've applied a temporary fix to MediaWiki:Mobile.css and will get this looked at. Does that work?

Jdlrobson (talk) 19:55, 3 August 2017 (UTC)

It appears that the problem still exists. Take a look here, please. Artoasis (talk) 03:20, 7 August 2017 (UTC)

yes and it will continue to work like that unless " hlist-separated" class is added to the underlying template alongside 'hlist'. The class will be harmless on desktop but will make mobile render as you are suggesting. FWIW I find that example perfectly readable even without separators, but if they are needed that's how to fix it - by an edit to Module:List Jdlrobson (talk) 14:30, 7 August 2017 (UTC)

@Jdlrobson: Since it's template-protected, I can't really edit the Module:List. Could you please fix it? Thank you. Artoasis (talk) 02:57, 8 August 2017 (UTC)

@Jdlrobson: Wouldn't it be better to edit the CSS page so that only one CSS class is needed, or change the class name in the Minerva skin? This doesn't solve the problem for uses of the hlist class which don't use the module (although I'm not sure if there are actually that many, aside from Module:Navbar). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 13:58, 8 August 2017 (UTC)

Minor edit checkbox hidden

Sometime between 8 July and 26 July, the minor edit checkbox is no longer visible.  Unscintillating (talk) 18:33, 29 July 2017 (UTC)

Still shows up for me, both in Monobook and Vector. Anomie⚔ 12:45, 30 July 2017 (UTC)

This problem also affects the "Watch this page" checkbox.  A fix for displaying either checkbox is Ctrl- or Ctrl+.

The focus has also been affected by the changes.  The focus is not visible when a checkbox is checked.  The focus is also not visible on the "Save changes" button.  Thanks, Unscintillating (talk) 18:48, 30 July 2017 (UTC)

What kind of browser (and version of it) do you have. —TheDJ (talk • contribs) 05:36, 31 July 2017 (UTC)

I am running Mozilla Firefox 2.0.0.20, which has a date of 2008-12-17.  Unscintillating (talk) 20:57, 5 August 2017 (UTC)

Does it work as expected if you go to https://en.wikipedia.org/wiki/User:Unscintillating?action=submit&ooui=0 and/or https://en.wikipedia.org/wiki/User:Unscintillating?action=submit&safemode=1 ? Whatamidoing (WMF) (talk) 06:01, 31 July 2017 (UTC)

With https://en.wikipedia.org/wiki/User:Unscintillating?action=submit&ooui=0, the checkboxes are visible and the focus is visible.  The safemode=1 has the previously stated problems that the checkbox requires Ctrl- or Ctrl+ to be visible, and the visibility of the focus depends on the background used in the box or checkbox.  Unscintillating (talk) 20:57, 5 August 2017 (UTC)

It seems you are using a 9 year old browser. Something from when the iphone was first released is unfortunately no longer supported. —TheDJ (talk • contribs) 01:17, 6 August 2017 (UTC)

Why break things that have been working for nine years?  That is Microsoft's policy so that they can sell new operating systems.  What is Wikipedia's policy?  Unscintillating (talk) 02:46, 6 August 2017 (UTC)

Unfortunately, the policy is to not (fully) support such old browsers. Your browser is not actually blacklisted (for performance reasons), but most bugs caused by your choice of web browser will not get the resources needed to fix them (although patches from volunteer devs are always welcome).

If possible, please consider upgrading. wikitech:HTTPS/Browser Recommendations has some information about browsers that are supported and which are more secure (for you) than the one that you're currently using. You didn't mention your OS, but if you're running Windows XP, Vista, or Server 2003, then you should consider Mozilla Firefox 52 ESR (free). Whatamidoing (WMF) (talk) 18:43, 7 August 2017 (UTC)

Under XP, Firefox has been ridiculously slow since about version 50.0.1. When going through a watchlist, it should not take several minutes to load and display a diff, and twice as long to return to the watchlist - sometimes ten minutes for the pair. Occasionally it just stuck completely, and I needed to use the three-finger salute to start the Windows Task Manager, and use that to end the task. This of course causes Firefox to detect an abnormal termination, and so attempts to send a crash report back to Mozilla... but even that usually times out and fails. I've switched to Opera 36 - which has a few annoying features, and a severe lack of customisation options. --Redrose64 🌹 (talk) 19:04, 7 August 2017 (UTC)

• As for the minor edit checkbox not displaying, I have a one- or two-keystroke fix with Ctrl- and Ctrl+ that will work reasonably well going forward.  Thanks, Unscintillating (talk) 02:41, 8 August 2017 (UTC)

New filters for edit review Beta feature: how to show new edits on watchlists?

Hello!

Since April 2017, you can activate in your Beta features a new filtering system for RecentChanges. You are more than 10,000 users trying it. Thank you!

We are regularly updating those filters, and since the last message, we have added filtering for Namespaces and Tagged edits. For instance, you can highlight in green all edits made on Talk namespace using mobile, or try the new "live" mode (both examples need the Beta feature to be activated).

Based on the feedback the Collaboration team have received so far (we still welcome your feedback), we plan to move on by providing those filters on Watchlists as a Beta feature. I'm contacting you about a custom feature you have enabled on Watchlists on English Wikipedia.

First, a quick reminder: the New Filters for Edit Review provide a feature to highlight particular edits. When a given edit is highlighted by more than one color (because it possesses more than one highlighted property), the system highlights that edit with a blend of the relevant highlight colors. For example, yellow and blue highlights will blend to make green. On the left, the bulleted list is also used to emphase the highlight: if a particular edit is highlighted by one color, the bullet is colored; if the line matches two colors, two bullets are shown, each of them with one of the colors used (example). Testing shows users find these dots very helpful, especially when multiple colors have been applied to a particular edit.

At the moment, on Watchilists on other wikis, the titles of pages with unseen changes are in bold. However, English Wikipedia Watchlists uses a green dot for unseen changes instead of bolded page title. The green dot approach is not compatible with the use of multiple bullets to mark the multiple colors applied to one particular edit.

So we are asking for your input for this case, the different solutions we have so far are:

1. Have titles in bold, like on other wikis.
2. Have a distinctive mark for unseen changes; our proposal is to use the bulleted list and have a filled bullet for unseen changes and an empty bullet for seen change (see the mockup).
3. Both boldfaced titles and filled/unfilled bullets.

Your input will help us to take a decision about Watchlists styling. Please leave your comments about this specific feature by replying to this post, or directly on Phabricator.

Thanks! Trizek (WMF) (talk) 11:27, 3 August 2017 (UTC)

IMO, it's well past time to revert the mistake. For those coming in late, here's the timeline:

• In December 2011, a discussion at Village pump (proposals) asked to turn on the MediaWiki feature that bolds titles on the watchlist of pages that haven't been visited since the last change.
• The necessary configuration change was made in May 2012.
• A bunch of existing editors freaked out.
• People jumped the gun in trying to restyle it in a less obvious manner, rather than just providing a gadget for people to disable it, and it just inflamed the situation.
• Eventually we wound up with the current situation: green bullets that are barely distinguishable from the normal bullets plus several of gadgets to re-enable the standard behavior or provide additional different styling.

IMO the better solution would have been to keep the standard behavior as the standard and let people who dislike it enable a gadget to give them green bullets or whatever, rather than making nearly-unnoticeable bullets the default. Even though it's five years later now, it's not too late to fix the situation. Anomie⚔ 12:22, 3 August 2017 (UTC)

I agree that it needs to be sorted and that we should return to the default. We should also ensure we have The Gadget To Make The Unhappy People More Happy ready prior to reverting to the default (whatever form The Gadget takes). --Izno (talk) 14:04, 3 August 2017 (UTC)

Let me add my voice in agreement with Anomie and Izno. It may be necessary to make a watchlist notice (perhaps more prominent than the usual ones, or placed in a different location) to explain the change to users, and inform people of how to turn on the relevant gadget. — This, that and the other (talk) 09:55, 4 August 2017 (UTC)

Thank you all for your comments! The discussion is still open, at least for a few days.

This, that, the change will first impact people who use the Beta, not all users. We will communicate about the green dot when the Beta will be available. Trizek (WMF) (talk) 10:06, 4 August 2017 (UTC)

"Make The Unhappy People More Happy" lol, I propose we rename the entire gadget feature to this :) —TheDJ (talk • contribs)

All of the "make the thing vanish" gadgets, at the least. --Izno (talk) 17:12, 4 August 2017 (UTC)

If you really have to enable the in-your-face ugly bolding, then at the same time provide an easy, working, and fast way to turn this off for everyone who doesn't want it (which, judging from the last time this happened, are quite a lot of people). Better still, if you know from last time that this will get protest from many people here, start an RfC to get approval for this. Oh, and Anomie, if you check that RfC which was for enabling this, the RfC was for enabling highlighting unvisited changes (which I support), but was not for bolding them; how exactly the highlighting should be done was going to be decided afterwards.

We then had Wikipedia:Requests for comment/Watchlist survey, which decided that the feature was opt-in only (and with most people clearly opposing the "bold"). That RfC had a fairly wide participation (more than 100 participants), so I don't think changing this with a short discussion among a few people here is wise. (If there have been more recent RfCs about this, please list them here). Fram (talk) 12:52, 4 August 2017 (UTC)

@Fram: Your reading of that initial RFC seems to be faulty. I see a few people mentioning that it would be possible to change the styling, including the initial statement, but there appears to have been no specific wording there that actually supports your assertion. As for the followup RFC that was dominated by the bad feelings from various people fooling around with the styling instead of just making a disable gadget, that was five years ago and consensus can change (and I hope it did).

As for "start an RFC", WP:VPT is the usual place for technical RFCs, isn't it? Here we are. Feel free to advertise the discussion if you'd like. Anomie⚔ 21:57, 6 August 2017 (UTC)

@Anomie: VPT is not the place for RfCs, technical or otherwise. Please find one from the last five years (or so) which wasn't moved elsewhere (or otherwise terminated) within 48 hours. --Redrose64 🌹 (talk) 23:07, 6 August 2017 (UTC)

Oh, did someone change the unwritten rules around again? Anomie⚔ 01:05, 7 August 2017 (UTC)

How about Wikipedia:Village pump (technical)/Archive 99#RFC, which was the RFC here to overturn the original CENT-listed RFC at VPPR that requested the bolding in the first place? WhatamIdoing (talk) 18:52, 7 August 2017 (UTC)

That one was more than five years ago... just. Have there been any that are more recent? --Redrose64 🌹 (talk) 19:19, 7 August 2017 (UTC)

@Redrose64: Now that I find time to search, I see a few:

• Wikipedia:Village pump (technical)/Archive 119#Proposal to Reduce the API limits to 1 edit/30 sec. for logged out users, opened October 2013.
• Wikipedia:Village pump (technical)/Archive 125#Font size and style, opened April 2014.

And looking at the ones that were moved, it seems to be because people have generally gone along with your personal crusade against having RFCs on this page. Several were begun here, then moved after you personally complained about it. Anomie⚔ 21:29, 7 August 2017 (UTC)

RfCs are proposals - "should we do this or not?"; VPT is about discussing technical matters - "can this be done; if so, how?". The two can follow on from one another, either with the RfC first as in "having decided that we want to do this, how should it be done?" or with the RfC second, as in "having determined that this procedure is possible, should it be done?". It's about keeping the how and why distinct, in order not to sidetrack. For examples of discussions where the two have become mixed, leading to stalled discussion, see the last few archives of Help talk:Citation Style 1 and look for the discussions about access lock icons (small coloured padlocks). Others have shared my opinion. --Redrose64 🌹 (talk) 09:59, 8 August 2017 (UTC)

Thank you all for your comments, they have been very useful. I'll recontact you when the Watchlist Beta feature will be available. You will then be able to try the new design we have chosen from the 3 ideas, and of course provide feedback.

Best, Trizek (WMF) (talk) 14:57, 9 August 2017 (UTC)

Odd looking block message

Well, having tried and failed to replicate the problem (and locked myself out for an hour in the process), I figure I should at least make good on the promise I made at User talk:Worm That Turned... WTT was caught by an IP block and saw this → rather odd looking block message; I said I'd bring it up here for the more technically skilled elements of our community (i.e. those that don't block themselves by accident) to take a look. Yunshui ^雲_水 12:16, 4 August 2017 (UTC)

I see that MediaWiki:Blockedtext/en-gb and MediaWiki:Blockedtext/en-ca are transcluding MediaWiki:Blockedtext in a way that will probably lose the message substitution parameters (the "$2" and so on). If Worm That Turned is using one of those languages, that could potentially cause the problem. Anomie⚔ 12:25, 4 August 2017 (UTC)

I use en-gb, good catch :) Worm^TT(talk) 13:20, 4 August 2017 (UTC)

How can we keep these synchronized without loosing the parameter content? עוד מישהו Od Mishehu 09:42, 6 August 2017 (UTC)

I don't know anything which can be placed in MediaWiki:Blockedtext/en-gb and MediaWiki:Blockedtext/en-ca to always display the same as MediaWiki:Blockedtext if it uses $ parameters and isn't adapted for the purpose of displaying the same as the other messages. int: from mw:Help:Magic words#Localization doesn't allow a language parameter and {{int:Blockedtext|$1|$2|...}} for en-gb users will just try to use MediaWiki:Blockedtext/en-gb istself instead of MediaWiki:Blockedtext. {{MediaWiki:Blockedtext}} in MediaWiki:Blockedtext/en-gb will not pass the $ parameters as we see above. {{MediaWiki:Blockedtext|$1=$1|$2=$2|...}} will pass them but then they have to be referenced as {{{$1}}} instead of $1 in MediaWiki:Blockedtext. {{MediaWiki:Blockedtext|$1|$2|...}} or {{MediaWiki:Blockedtext|1=$1|2=$2|...}} will pass them but then they have to be referenced as {{{1}}} instead of $1. Maybe MediaWiki:Blockedtext could say {{{1|$1}}} instead of $1 to check for {{{1}}} in case it's transcluded. Another option is for both MediaWiki:Blockedtext and MediaWiki:Blockedtext/en-gb to do nothing on their own except calling a template with all their $ parameters. Then the template can reference them as {{{1}}} without caring where they came from. Both options rely on adapting MediaWiki:Blockedtext to allow synchronization. We could also make a database report for en-gb and en-ca pages which differ from the en page, so an admin can periodically fix unwanted differences by copy-pasting. If the report includes a diff link between the two pages (diffs can be between revisions of different pages) then it should be easy to spot unwanted differences. I wish the software allowed a fallback setting for all MediaWiki messages saying "If the default en is customized but en-gb is not then display the customized en version to en-gb users." That would solve a lot of problems. PrimeHunter (talk) 10:24, 6 August 2017 (UTC)

Thanls. I did it -- and saw (using a self-block) that it works. עוד מישהו Od Mishehu 05:15, 7 August 2017 (UTC)

Let's remove "en-gb" as a language option (and "en-ca", while we're at it) and force everybody over to the vanilla "en". After all, what would they really lose? --Redrose64 🌹 (talk) 17:37, 6 August 2017 (UTC)

Should Template Editors be able to edit the MediaWiki namespace?

I know I am not a template editor, but I am asking this question anyway. Should template editors be able to edit the MediaWiki namespace? I am asking because template editors still have the ability to edit pages transcluded in an interface page. Ups and Downs (↕) 01:39, 6 August 2017 (UTC)

If there were a technical way to allow them tro edit the interface texts, without allowing them to edit the interface scripts, I wouls say yes; editing the templates transcluded in these pages is certainly on the same level as the texts. עוד מישהו Od Mishehu 03:34, 6 August 2017 (UTC)

No. It is best to not pose hypothetical issues that many people will stop to consider unless there is reason for thinking a change would be desirable. I have seen template editors make bold changes to templates that should never have occurred without prior discussion and sandbox testing. Admins seem to be accustomed to the fact that great care should be used when fiddling with interface messages, and there is no backlog of requests for messages to be updated. Johnuniq (talk) 04:21, 6 August 2017 (UTC)

I am fairly sceptical that developers will let that happen. There are so many ways one can break the wiki in MediaWiki space (especially by messing with the JS pages) that I would expect them to say "nobody who hasn't received community review akin to a RfA has any business editing the MediaWiki namespace" with an office hat on. Jo-Jo Eumerus (talk, contributions) 10:17, 6 August 2017 (UTC)

@Jo-Jo Eumerus: This is a community decision not a developer issue. We can pick who may edit what. Globally, and on some other language projects, there are user groups that may edit anything (often called "technicians" - including mediawiki, protected pages, userjs, usercss pages. The "rules" for what they may or may not edit are up to the communities, along with enforcement. This isn't so much of a "can this happen" question as to a "is this appropriate for us" question. — xaosflux ^Talk 15:11, 6 August 2017 (UTC)

It is a developer issue because developers must implement this but have no obligation to. As noted on phab:T162845 and phab:T85713editinterface is a sensitive permission and the right to assign rights entailing that permission is not freely dispended. Jo-Jo Eumerus (talk, contributions) 16:21, 6 August 2017 (UTC)

Absolutely not. You can break things even without touching JavaScript (or indeed CSS) pages. --Redrose64 🌹 (talk) 13:06, 6 August 2017 (UTC)

Not necessary (and I'm a TE). However, a good mechanism to suggest changes and test them in various contexts would be welcome. — JFG ^talk 13:50, 6 August 2017 (UTC)

I would welcome the ability to edit the Green on black skin without waiting 2-4 weeks for an admin to do the edit request. — Dispenser 14:58, 6 August 2017 (UTC)

That speaks of not too many admins being familiar with CSS. Jo-Jo Eumerus (talk, contributions) 16:21, 6 August 2017 (UTC)

Admins understand policy, template editors understand code; each requires orthogonal skills. I would contribute far more if it weren't a multiday affair. — Dispenser 02:26, 7 August 2017 (UTC)

Nope, absolutely not. editinterface is actually the most sensitive permission we can grant (yes I'm including deletion, checkuser, oversight). If we were redoing the implementation today, it probably wouldn't be coupled with admins by default. I'm pretty sure WMF Legal would veto such a move (cf: non-admin access to deleted materials), as would most of the developers. FACE WITH TEARS OF JOY ^[u+1F602] 23:02, 6 August 2017 (UTC)

Long urls

Part of the standard page payload for me is the following:

https://en.wikipedia.org/w/load.php?debug=false&lang=en&modules=ext.centralNotice.geoIP%7Cext.centralauth.ForeignApi%7Cext.centralauth.centralautologin.clearcookie%7Cext.charinsert,eventLogging,guidedTour,navigationTiming,wikimediaEvents%7Cext.cx.campaigns.contributionsmenu%7Cext.cx.eventlogging,model%7Cext.cx.widgets.callout%7Cext.echo.api,init%7Cext.eventLogging.subscriber%7Cext.guidedTour.lib,styles%7Cext.guidedTour.lib.internal%7Cext.uls.common,compactlinks,eventlogger,init,interface,preferences,webfonts%7Cext.visualEditor.desktopArticleTarget.init%7Cext.visualEditor.supportCheck,targetLoader,track,ve%7Cext.wikimediaEvents.loggedin%7Cjquery.accessKeyLabel,byteLength,byteLimit,checkboxShiftClick,chosen,client,cookie,form,getAttrs,highlightText,makeCollapsible,mw-jump,spinner,suggestions,textSelection,tipsy%7Cjquery.uls.data%7Cmediawiki.ForeignApi,RegExp,Title,Uri,api,cldr,confirmCloseWindow,cookie,experiments,icon,jqueryMsg,language,notification,notify,searchSuggest,storage,template,toolbar,user,util%7Cmediawiki.ForeignApi.core%7Cmediawiki.action.edit%7Cmediawiki.action.edit.collapsibleFooter,editWarning,preview%7Cmediawiki.action.view.postEdit,rightClickEdit%7Cmediawiki.api.options,parse,user,watch%7Cmediawiki.diff.styles%7Cmediawiki.language.data,init%7Cmediawiki.libs.guiders,pluralruleparser%7Cmediawiki.page.ready,startup%7Cmediawiki.page.watch.ajax%7Cmediawiki.template.regexp%7Cmediawiki.ui.button%7Cmediawiki.widgets.visibleByteLimit%7Cmoment,oojs,oojs-ui-core,site%7Cschema.GuidedTourButtonClick,GuidedTourExited,GuidedTourExternalLinkActivation,GuidedTourGuiderHidden,GuidedTourGuiderImpression,GuidedTourInternalLinkActivation,UniversalLanguageSelector%7Cuser.defaults%7Cwikibase.client.action.edit.collapsibleFooter&skin=monobook&version=0wezebo

1712 characters that get sent to me and I send back - is it possible that this could be done more efficiently?

(This part took 6 seconds to load, but that may be a local issue.)

All the best: Rich Farmbrough, 14:04, 6 August 2017 (UTC).

What makes you think that the number of characters in the URL has something to do with the speed of your machine and internet connection? --Malyacko (talk) 10:30, 9 August 2017 (UTC)

The url is sent to my machine. This is a de-facto use of about 1.7k. My machine then sends it back, another waste of the same amount. Obviously 3.4k is very minor by today's standards, but if this is symptomatic of the the whole, the implications could be very large. Consider that overheads will probably add another 10-20%. While many of the individual parts of loading a WP web page are there for good reason, the overall impact is that to view a 55 byte piece of source I need to transfer about 1M of data. If something is already going wrong, this is, to say the least, unhelpful.

All the best: Rich Farmbrough, 20:40, 9 August 2017 (UTC).

@Rich Farmbrough: This has already been identified before (we then changed the way this link was built slightly). It's on the radar of the performance team, but significantly changing this atm, probably doesn't have a good cost/benefit ratio (aka the time of the performance team is better spent on other tasks with larger gains, than on fixing this) —TheDJ (talk • contribs) 22:16, 9 August 2017 (UTC)

Searching for visible pipe

Using the standard search, what's the expression for a visible pipe? I want to find and fix the bad edits made by Ruttnpark (talk · contribs) such as those to Midland and Great Northern Joint Railway and Dunstable Branch Lines. I've tried this this and this, none worked. It seems to be treating the pipe as a logical OR, I want it literal. --Redrose64 🌹 (talk) 15:12, 6 August 2017 (UTC)

@Redrose64: Searching for insource:/Class 31\|/ should work, if you're only looking for Class 31|. I think symbols are ignored without both regex and insource. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 15:31, 6 August 2017 (UTC)

I'm not looking for piped links (although that editor has been violating WP:NOTBROKEN too). I'm looking for double piped links, those where the second pipe is visible in the rendered text, as with the content of this section. --Redrose64 🌹 (talk) 17:17, 6 August 2017 (UTC)

I would start with this. There may be more, but I am bad at regex so the search times out. A database scan may be the best way. (WT:AWB has some pretty good regex types that you might inquire with.) --Izno (talk) 17:58, 6 August 2017 (UTC)

I think this is a subset of CheckWiki error 32, so the scan is already done for you. -- John of Reading (talk) 18:25, 6 August 2017 (UTC)

How often is that updated? The relevant report seems to be mostly from July. --Redrose64 🌹 (talk) 20:57, 6 August 2017 (UTC)

Short answer : No, it is not possible to search for certain visible tokens or symbols such as a pipe on a page. Proof (https://en.wikipedia.org/w/index.php?search=%7C). There's no way only a single article has it visible ...

Longer answer: The search engine deliberately removes this to improve general search.

The best way to use insource is to make the regex efficient and to use a very good filter to prevent it from timing out.

One sneaky and a bit crazy way of searching all those pages edited by that user, is to temporarily add a hidden category to each of them. Then this would be as simple as writing "insource:/\[\[.*\|.*\|.*\]\]/ hascategory:temporary_search_cat123". Considering that at the time of this writing the user has only edited ~ 204 pages, it is probably a non-issue. Though others may disagree. Other possibilities include finding a common category / template or term in all those pages and using or alternating between all of them, for example, a lot of those page titles contain the word "rail"(intitle:rail), "line", or "class".

This won't help if the general goal is to find all these.In such cases the dumps are better. Fine tuning a query like : "insource:/\[\[[A-Za-z0-9 \_]*?\|[A-Za-z0-9 \_]*?\|[A-Za-z0-9 \_]*?\]\]/ hastemplate:reflist" will make it possible to find all such occurrences. As a sidenote, even google chokes with a similar search : '"|" site:en.wikipedia.org'. 22:06, 6 August 2017 (UTC) — Preceding unsigned comment added by 197.218.90.95 (talk)

• The user has "only" edited 198 articles so I cheated by downloading the current wikitext of them all, and searching that. There are no occurrences of problematic links like [[...|...|...]]. Johnuniq (talk) 23:03, 6 August 2017 (UTC)

Nice workaround, it might be suitable for a basic userscript for users with few contributions. Anyway, it seems that at least a few search engines can find such characters, e.g. http://symbolhound.com/?q=%7C&l=&e=&n=&u=en.wikipedia.org . According to that site there currently seem to be ~ 570 indexed pages with visible pipe symbols. Scrapping that site for such occurrences could be used as a short term workaround for this problem. 10:24, 7 August 2017 (UTC) — Preceding unsigned comment added by 197.218.88.42 (talk)

Sample data for viewing:

[[British Rail Class 31|Class 31|Brush Type 2]]

while formulating:

insource:/"[["[^\]]*\|[^\]]*\|[^\]]*"]]"/ prefix: a

and refining:

insource:/"[["[^\]]*\|[^\]]*\|[^\]]*"]]"/ -insource: image -insource: file prefix: a

Note how the regexp pattern only works on pages whose titles begin with A, (otherwise it will timeout), without images, but captures unwanted "double pipes" caused by instances of valid template pipes informing the wikilink label. From the highlighted matchings, note the impossibility of the existing or other further refinements.

Please find and contribute time towards the improvement of the search documentation. It's on WP, MW, {{search link}}, {{regex}}, etc. Prod their talk page. Then bring it up on phabricator. But, I know, here at WP:VPT it is so big city, and there their talk pages are small country. — Cpiral§Cpiral 09:43, 14 August 2017 (UTC)

New pages -- patrolled?

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)

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)

@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)

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)

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)

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)

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)

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)

@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)

A strange system error or malfunction problem on wikipedia

Hello! I want to bring a system error issue here, sometime back I moved the page Abdul malik Afegbua for capitalization purpose, The page was created by another editor. But when it was tagged for Proposed deletion I got a notice on my talk page. This system error is faced by many other editors, This error also affects page creation credits. Can anyone solve it ? Anoptimistix Let's Talk 07:34, 7 August 2017 (UTC)

It's working as intended. A move automatically creates a redirect at the old name. The mover is registered as creator of the redirect while the original creator of the old name is registered as the creator of the new name which takes over the old page history including the original page creation. Somebody turned the redirect page into an article but you remain registered as creator of the page. Trying to do it otherwise would cause other confusion. A redirect is just a page with certain content. A given page can change between redirect and article multiple times. PrimeHunter (talk) 08:41, 9 August 2017 (UTC)

File usage incomplete

Resolved

 – PEBKAC

File:Tiobeindex.png#filelinks lists only one usage, but there are more, such as in C (programming language)#Uses, where the link has been for over a year. Why is the list incomplete? A similar question was asked in 2014, but did not yield a conclusive answer. — Sebastian 09:15, 7 August 2017 (UTC)

Because they are different files?

File:Tiobeindex.png vs File:Tiobe index.png 197.218.88.42 (talk) 09:41, 7 August 2017 (UTC)

That would explain it - thanks! — Sebastian 15:15, 7 August 2017 (UTC)

Wikipedia:Bots/Dictionary

This has just been created. Feel free to be WP:BOLD and add missing terms which you feel would be useful. Headbomb {t · c · p · b} 14:09, 7 August 2017 (UTC)

Can I get a list of articles which use Wikipedia as a reference?

Every once in a while I run into an article where Wikipedia is used as a reference. Since we don't allow Wikipedia articles to be used as references for other Wikipedia articles, it would be useful to have a list of articles with such a reference - specifically, any instance of an external link to a Wikipedia article between a set of ref tags, or as the url= field in a citation template having that field. Please let me know if this is doable. Cheers! bd2412 T 20:50, 7 August 2017 (UTC)

This is a start, though it times out. --Izno (talk) 23:45, 7 August 2017 (UTC)

Thanks. I get a manageable number with the search string, insource:wikipedia insource:/\<ref.*https://en.wikipedia.org/wiki/*\<\/ref>/. bd2412 T 01:58, 8 August 2017 (UTC)

Tech News: 2017-32

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 see which Wikipedia language versions are read in a specific country. This tool is called Wikipedia Views Visualized. [7]
• The Architecture Committee is now the Wikimedia Technical Committee. You can read the charter. [8]

Problems

• You can get an email when a page on your watchlist was edited. You can choose not to get emails for minor edits. There is a bug that means that you then don't get an email when someone does a normal edit after a minor edit. The developers are working on fixing this. Until it has been fixed you can activate "Email me also for minor edits of pages and files" at the bottom of "User profile" in your preferences if you want to. [9]
• The thanks button sometimes didn't work for mobile users. This was because of a new bug and has now been fixed. [10]

Changes later this week

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

Future changes

• Editors and readers who still use Internet Explorer 8 on Windows XP will not be able to use Wikipedia. Internet Explorer 8 on Windows XP can't connect securely to the wikis. When we allow them to do so it means that we get less security for everyone else. If you use Internet Explorer 8 on Windows XP you can install Firefox 52 ESR instead. Around 0.1% of the traffic to the Wikimedia wikis comes from Internet Explorer 8 on Windows XP. [11]
• Links to sections on Wikipedia don't work well in languages that don't use the Latin script. The URL in the address bar in your browser shows Latin characters like .D0.A1.D1.81.D1.8B.D0.BB.D0.BA.D0.B8 instead of the section heading in the wiki's language. Links to sections in non-Latin scripts will be in the script of that wiki in the future. This will happen in the next few months. [12][13]
• Wiki pages printed by the web browser "Print" function will have an updated style. This new style will be similar to the when you download a page as PDF. It will be better at showing tables, infoboxes and headings. [14][15]

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

21:45, 7 August 2017 (UTC)

Problem suddenly found when printing out RDT line templates

Resolved

 – Edit request has been answered. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 12:31, 9 August 2017 (UTC)

Each of the three RDT line temeplates that I have printed out this week have suddenly shown a blank line completely across the printing between each of the stations shown. Can this be investigated and corrected, as this has never happened to me before on Wikipedia.

Xenophon Philosopher (talk) 00:32, 8 August 2017 (UTC)

Please give an example. Is it a page like Template:GZM RDT? PrimeHunter (talk) 09:21, 8 August 2017 (UTC)

It sounds like a margin or padding issue; if so, I strongly suspect that MediaWiki talk:Common.css#Protected edit request on 8 August 2017 is related to this problem. --Redrose64 🌹 (talk) 09:40, 8 August 2017 (UTC)

Yes, the CSS change would solve the issue. The print CSS currently has a lot of other !important declarations which might not really need !important, although those don't seem to be causing problems yet. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 09:49, 8 August 2017 (UTC)

Bug in dating of photographs

Perhaps someone familiar with the procedure could log this bug for me? When a photo description has only a month and a year, and no day, the display in the Media Viewer incorrectly assumes the first of the month. For example, see https://commons.wikimedia.org/wiki/File:Ryde_Pier,_IW,_UK.jpg. The date is March 2017. Now see https://en.wikipedia.org/wiki/Ryde_Pier#/media/File:Ryde_Pier,_IW,_UK.jpg. It says "Created: 1 March 2017". The "1" should not be assumed. It should just say "March 2017". Mypix (talk) 01:02, 8 August 2017 (UTC)

It's phab:T58794 from 2013. See also Wikipedia talk:Media Viewer#Fix for year display? [16] says 1 January 1926 when only 1926 is given. PrimeHunter (talk) 09:11, 8 August 2017 (UTC)

Thanks. Some people in that thread seem to think this is a very minor problem not worth bothering about. I disagree. While obviously it is not show-stopping, it is highly misleading, and even worse than I realised actually, if a date of 1926 is shown as 1 January 1926. Clearly it needs fixing. Mypix (talk) 20:52, 8 August 2017 (UTC)

@Mypix: If you are interested in the procedure, see mw:How to report a bug. :) --Malyacko (talk) 10:32, 9 August 2017 (UTC)

• I just noticed that in another example, https://en.wikipedia.org/wiki/Isle_of_Wight/Sandown_Airport#/media/File:Sandown_Airport,_IW,_UK.jpg, the date is correctly shown as "month + year", in this case "Created: August 2017". That's odd, isn't it? I wonder why it would do it correctly in one place and not another? Mypix (talk) 11:12, 9 August 2017 (UTC)

Maybe it depends on the date format. The source at commons:File:Ryde Pier, IW, UK.jpg#Summary says Date=2017-03 which becomes "1 March 2017" in Media Viewer. The source at commons:File:Sandown Airport, IW, UK.jpg#Summary says date=August 2017 which remains as "August 2017". This could both hint that August 2017 is preferred by Media Viewer, or that it cannot read the format at all and just copies it as written. commons:Template:Information#Template parameters says YYYY-MM is preferred by the template. It doesn't mention Media Viewer. PrimeHunter (talk) 11:35, 9 August 2017 (UTC)

Thanks, you're right. A bot changed it from "March 2017" to "2017-03". When I changed it back, it fixed it in Media Viewer. I have left a message here suggesting that such automated changes should not be made until the bug in Media Viewer is fixed. Mypix (talk) 17:57, 9 August 2017 (UTC)

CirrusSearch

Is there any documentation for how the regular expressions in Special:Search work? Its behaviour is peculiar and tends to have weird quirks; searches containing \s or \n don't work, for instance. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 10:29, 8 August 2017 (UTC)

@Jc86035: There is some documentation at Help:Searching/Draft#Regular_expressions - not the most obvious place for it... -- John of Reading (talk) 10:38, 8 August 2017 (UTC)

Wikimedia uses Cirrusearch, which uses elasticsearch, and that in turn uses lucene regex as the backend, and its custom regex :

• https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-regexp-query.html#regexp-syntax
• https://lucene.apache.org/core/4_7_0/core/org/apache/lucene/util/automaton/RegExp.html 10:44, 8 August 2017 (UTC) — Preceding unsigned comment added by 197.218.89.59 (talk)

Thanks, 197.218.89.59 and John of Reading. Is there another way to search the source of every article/page in the wiki, other than manually downloading every page? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 12:37, 8 August 2017 (UTC)

@Jc86035: You can download every page, see Wikipedia:Database download, and then search it with the Wikipedia:AutoWikiBrowser/Database Scanner using "traditional" regular expressions. I have a copy of the 20 July dump; if that's recent enough I could search it for you. I have the "pages articles" dump, with no talk pages or user pages. -- John of Reading (talk) 12:45, 8 August 2017 (UTC)

@John of Reading: Thanks. I'm not looking to search anything right now, though, and I could download the dump myself if I needed to. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 12:49, 8 August 2017 (UTC)

Nested tables

Is it technically possible to allow collapsing only part of a table, such as in {{Collapsed infobox section begin}}, {{Infobox station}} and {{3 (New York City Subway service)}}, without nesting tables within each other? The Norwegian Wikipedias have a sort-of-solution, but this only allows for one collapse button per table. (In addition, is it possible to prevent a table cell containing only images from wrapping, so that the images stay left to right? This would solve the other nested table problem in the third template.) Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 12:32, 8 August 2017 (UTC)

In principle, yes but someone needs to do the work: to write the code, introduce necessary classes etc. Ruslik_Zero 20:47, 8 August 2017 (UTC)

Also, collapsing of content, however popular is also ill advised: Wikipedia:Manual_of_Style#Scrolling_lists_and_collapsible_content. If you need to collapse content to hide it on Desktop, then you likely should have already changed the form of the content for editorial reasons anyway. My opinion on this is "Collapsed content is a signal of a lazy editor". —TheDJ (talk • contribs) 14:49, 9 August 2017 (UTC)

@TheDJ: Some infoboxes (e.g. station, Chinese, soap character) have the collapse built in, probably for the sake of not filling up people's screens. I suppose it's bad to do this in the middle of the prose, but for sidebars, etc., it's not really problematic to collapse content. FWIW the Wikipedia app automatically collapses all infoboxes. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 14:19, 10 August 2017 (UTC)

"In addition, is it possible to prevent a table cell containing only images from wrapping" yes, you set a fixed width using CSS on the table cell that contains the images. —TheDJ (talk • contribs) 14:49, 9 August 2017 (UTC)

The problem with this is that {{Routemap}} does not have a parameter for the width of the centre icon column, and some icons have the wrong width prefixes/suffixes so it's not yet possible to calculate width automatically. If it's not possible with HTML then it's not really a big deal (a regular screen reader couldn't read the diagrams anyway) and the problematic icons will probably be renamed eventually. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 14:19, 10 August 2017 (UTC)

New contributions

I was trying to use a translation tool and all of a sudden Wikipedia thinks I want to translate articles. I just want to see what something on German Wikipedia looks like in English, but I didn't succeed in doing that. Instead, I am supposedly now able to get a list of my translations. Can I just remove that from my list of contributions when they are displayed?— Vchimpanzee • talk • contributions • 17:50, 9 August 2017 (UTC)

Disable "Content Translation" at Special:Preferences#mw-prefsection-betafeatures. PrimeHunter (talk) 17:56, 9 August 2017 (UTC)

Done. Thanks.— Vchimpanzee • talk • contributions • 18:27, 9 August 2017 (UTC)

Lua error - searching

On doing the search:

incategory:"All orphaned articles" incategory:"Genes on human chromosome 6"

One of the results is showing:

UNC5CL
Lua error in mw.wikibase.entity.lua at line 37: data.schemaVersion must be a number, got nil instead. Unc-5 homolog C (C. elegans)-like is a protein in
539 bytes (51 words) - 13:53, 1 August 2017

Eno Lirpa (talk) 13:31, 10 August 2017 (UTC)

It's temporary. The error was recently displayed on many articles. Individual pages can be fixed by a purge. The search function happened to cache (computing) the article UNC5CL when it displayed the error. A search on part of the error message "data.schemaVersion must be a number, got nil instead" currently gives me 326 pages. None of the examined pages display the error now. The search cache could be updated faster by editing the articles (a null edit might be insufficient), but I wouldn't worry about it. PrimeHunter (talk) 13:48, 10 August 2017 (UTC)

Thanks Eno Lirpa (talk) 13:54, 10 August 2017 (UTC)

Windows 10 and spellchecker

I recently started using Windows 10 and am having trouble with spellchecker in the Wikipedia edit window. Apparently, Windows 10 tries to spellcheck every box that can be typed in whether it is a Windows application or not. The result is that every piece of wikicode on the page gets a squiggly red line under it. I have turned off autocorrect and spelling highlighting in the settings page. I have also run the registry changes downloaded from this forum page but nothing seems to work. Anybody here got any ideas how to deal with this? SpinningSpark 19:28, 10 August 2017 (UTC)

@Spinningspark: Which browser are you using? (((The Quixotic Potato))) (talk) 19:52, 10 August 2017 (UTC)

Various browsers have the wiggly red line. I ignore it. --Redrose64 🌹 (talk) 21:12, 10 August 2017 (UTC)

I'm using Firefox, but I don't think it's especially browser related. Word has the same problem for instance. I never had any of this while I was using Windows 7 (still don't on my old PC). Definitely seems to be an issue with Windows 10. SpinningSpark 21:51, 10 August 2017 (UTC)

Not new. XP does this. --Redrose64 🌹 (talk) 22:40, 10 August 2017 (UTC)

See https://support.mozilla.org/en-US/kb/how-do-i-use-firefox-spell-checker#w_disabling-automatic-spell-checking. PrimeHunter (talk) 00:00, 11 August 2017 (UTC)

Solved, thanks. @Redrose64: I have an XP Notebook (now only used in the kitchen for recipes) and I have never seen this before on Wikipedia. SpinningSpark 17:27, 12 August 2017 (UTC)

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)

• Please change this setting back. Who discussed this. Why was this change made? Ridiculous. GenQuest ^{"Talk to Me"} 21:21, 10 August 2017 (UTC)
• 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)
• 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)
• 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)

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)

• 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)

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)

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)

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

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)

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.

References

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

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

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)

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

MediaWiki revision navigation is not excluded from printing

Tracked in Phabricator
Task T173057

MediaWiki:Print.css does not exclude #mw-revision-nav from printing.

Consider an old revision such as Special:Permalink/794918659 and print the page (or use print preview). The navigation for previous/latest/next revision is printed, despite not being interactive or useful on paper, unlike the #mw-revision-info above it.

Can the useless-on-paper #mw-revision-nav element be hidden in print? 2001:2003:54FA:D2:0:0:0:1 (talk) 21:26, 10 August 2017 (UTC)

• I've hidden it on en.wp for now, but we will need to add this to core soon. —TheDJ (talk • contribs) 22:03, 10 August 2017 (UTC)
  • Thanks. Could you also update the code comment above it to include a fifth item, the revision navigation? 2001:2003:54FA:D2:0:0:0:1 (talk) 22:10, 10 August 2017 (UTC)
  • The issue ticket title could also use improvement: Hide mw-revision-nav on old revisions → Hide mw-revision-nav on old revisions in print mode. 2001:2003:54FA:D2:0:0:0:1 (talk) 22:13, 10 August 2017 (UTC)

HotCat disappeared

I opened a tab and HotCat was gone. Cat-a-Lot as well. Can anyone tell me why and how to re-enable them? ―Justin (koavf)❤T☮C☺M☯ 04:47, 11 August 2017 (UTC)

Will return soon. A sockpuppet investigation concluded that an account was a sockpuppet, was then blocked on en.wp and consequently went on a deletion spray on with his sysop rights on Commons. quite sad. Over 1600 pages/files deleted, including the Commons mainpage, several gadgets etc.. restoration is being worked on. —TheDJ (talk • contribs) 05:29, 11 August 2017 (UTC)

@TheDJ: Thanks. All's well now. ―Justin (koavf)❤T☮C☺M☯ 15:44, 11 August 2017 (UTC)

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)

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)

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

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)

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

Tracked in Phabricator
Task T55008

As mentioned here [18], 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? EEng 11:35, 11 August 2017 (UTC)

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

Phabulous, thanks. EEng 15:12, 11 August 2017 (UTC)

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)

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

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)

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? EEng 15:36, 16 August 2017 (UTC)

Navbox formatting

Is it possible in {{Challenge Cup}} to remove the first six entries in list1 and maintain the right alignment of the remaining entries? I can see that previous editors want the columns lined up in decades and the first entries are dummies solely to achieve this as the competition didn't start until 1896–97. I did wonder about using template:0 but I couldn't work out a way to make the bullets invisible. Nthep (talk) 15:45, 11 August 2017 (UTC)

I do not think that you can do this with in the standard navbox. Ruslik_Zero 20:27, 11 August 2017 (UTC)

@Nthep: Will this do? – Srdjan m (talk) 20:59, 11 August 2017 (UTC)

Brilliant, thx. Nthep (talk) 21:15, 11 August 2017 (UTC)

Template help

Hey guys. I was wondering how you can make one parameter replace the whole texts on a template if a value is given? For example: this is an example template. {{#if: {{{example2}}} | yes | this should replace the previous texts entirely.}} can you do that? ◂ ‎épine _talk♬ 01:04, 12 August 2017 (UTC)

@Épine: I'm not sure what you're trying to do. If you want to ignore the rest of the template if |example2= has text, then your template should look like {{#if: {{{example2|}}} | «text to display if example2» | «if not, then rest of template here» }}. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 07:14, 12 August 2017 (UTC)

@Jc86035: that's exactly what I wanted. Thank you! ◂ ‎épine _talk♬ 07:25, 12 August 2017 (UTC)

If you want to understand how it works so you can make other code in other situations: If the parameter example2 is not set then {{{example2}}} produces itself, i.e. that exact 14-character string. But {{{example2|string}}} will produce string if example2 is not set. So {{{example2|}}} with nothing after the pipe will produce empty. {{#if:string|yes|no}} produces yes if string is non-empty and no if it's empty. Therefore {{#if: {{{example2|}}} |yes|no}} produces yes if example2 is set to something non-empty , and no if it's not set or is set to empty, i.e. |example2= with no value. PrimeHunter (talk) 11:24, 12 August 2017 (UTC)

Edit section not appearing on mobile view

[19]

The problem appears to be TOC not appearing, but I am not sure what exactly is causing the issue. Any thoughts? Alex Shih^Talk 03:23, 12 August 2017 (UTC)

The problem is solved if I close the table properly, but is there another way? Alex Shih^Talk 03:31, 12 August 2017 (UTC)

I tried rewriting the page in plain script, but still cannot figure out what is preventing the TOC and the page content from appearing in mobile view. Alex Shih^Talk 03:54, 12 August 2017 (UTC)

@Alex Shih: Try using <div> tags instead of tables (the width attribute might need to be changed to CSS). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 07:29, 12 August 2017 (UTC)

@Jc86035: Thank you for your response. I tried doing both but the edit section/the content still wouldn't appear. So frustrating :( Alex Shih^Talk 07:43, 12 August 2017 (UTC)

@Alex Shih: You've left in the td and tr tags. Remove the tr tags, replace td with div, remove the width: 70%;, and change platinum to silver (platinum is apparently not a real colour). Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 07:52, 12 August 2017 (UTC)

@Jc86035: Thanks again, I followed these instructions, and it's looking better but the edit section still wouldn't appear (sad face). Alex Shih^Talk 07:59, 12 August 2017 (UTC)

@Alex Shih: It doesn't seem to work inside tags. I've filed a bug, but I don't think it'll be fixed unless a developer really wants to have their talk page decorated nicely. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me 08:09, 12 August 2017 (UTC)

@Jc86035: I see! I feel less silly now, thank you so much. I'll make adjustments accordingly in the meanwhile... Best regards! Alex Shih^Talk 08:11, 12 August 2017 (UTC)

the search box on my watchlist isn't working

Most common search strings work, and I can type in words I see on the screen and see them light up. But my most common search string, "scout" automatically turns red, although I have myself made 3 edits on my watchlist to Scouting topics in the last 72 hours. What's afoot?--Kintetsubuffalo (talk) 07:34, 12 August 2017 (UTC)

Wikipedia has no feature to search the watchlist so I guess you are using a browser feature to search a string on the current page. Check whether it has enabled options which limit search results, e.g. by being case sensitive or only searching whole words. Are you sure the watchlist actually displays the exact string you search for? PrimeHunter (talk) 11:01, 12 August 2017 (UTC)

I'm certain because it's worked for 9 years until yesterday, on two unconnected computers.--Kintetsubuffalo (talk) 12:54, 12 August 2017 (UTC)

Maybe this could be related to the change in the maximum number of watchlist entries? Jc86035 (talk) 13:01, 12 August 2017 (UTC)

Jc86035I betcha that's it, the timing matches! Thank you! What thing do I need to reset from zero?--Kintetsubuffalo (talk) 13:24, 12 August 2017 (UTC)

@Kintetsubuffalo: Go to Special:Preferences#mw-prefsection-watchlist and set the maximum number of changes to a bigger number. Jc86035 (talk) 13:26, 12 August 2017 (UTC)

Thanks, got it working, kinda! The new maximum means I can't ever take a break or I'm lost...--Kintetsubuffalo (talk) 13:56, 12 August 2017 (UTC)

Help's on the way, in the form of filters that will show the most recent n changes that you haven't seen yet. (So just no breaks for the next month or so.  ;-) Whatamidoing (WMF) (talk) 21:23, 12 August 2017 (UTC)

@Whatamidoing (WMF): By "changes that you haven't seen yet", does that mean that I would need to view the most recent edits before any earlier edits become available to view? Seems backwards. What about introducing offset= and dir= parameters into the query string, as presently permitted by page history or a user contributions? Then, if I knew that my last watchlist check was at, say, 22:15 yesterday, I could use the query string parameters dir=prev&offset=20170811221500 to view watched edits going forward from that moment. --Redrose64 🌹 (talk) 22:54, 12 August 2017 (UTC)

That's my impression, although it's not my project, so I could be wrong.

I like the &offset= idea, but it feels like the sort of thing that's really only useful if you show each change individually (rather than the default). I know one editor who never checked diffs until the page hadn't been edited for a week, so s/he would probably appreciate an offset that hid the most recent 6 days. (Apparently, it's a good strategy for avoiding disputes.)

I believe that you could also filter by namespace to 'extend' the list: the 1000 most recent changes that I haven't read in this namespace, followed by the 1000 most recent changes in that namespace, etc. If your watchlist is reasonably diverse, then this may work around the problem now. Whatamidoing (WMF) (talk) 00:09, 14 August 2017 (UTC)

Might have been practical when we had 16 namespaces, two of which (MediaWiki and MediaWiki talk) I never touched; but now we have 32. --Redrose64 🌹 (talk) 08:41, 14 August 2017 (UTC)

Broken edit syntax highlighting on (expected) unclosed tags

When editing, bare tags such as <br>, <hr>, or <p> 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<p /> (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)

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)

References are now unordered lists

I just edited Begin the Begin and see that the references are no longer numbered--this is a very useful feature. Does anyone know why this is happening? ―Justin (koavf)❤T☮C☺M☯ 16:56, 12 August 2017 (UTC)

If I had to guess, probably something to do with the reference wedged into the reflist template. Ian.thomson (talk) 16:59, 12 August 2017 (UTC)

Fixed by Nthep.[20] PrimeHunter (talk) 18:48, 12 August 2017 (UTC)

"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)

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

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)

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)

"national youth handball team" or "youth national handball team"

Resolved

 – This section is neither the correct forum (there are no technical issues here, only naming policy issues), nor still relevant (as the OP has moved the "youth national" titles to "national youth"). עוד מישהו Od Mishehu 12:28, 13 August 2017 (UTC)

Which word order is correct? Men's national teams use "national youth", women's – "youth national". For example:

• Denmark national youth handball team
• Denmark women's youth national handball team

Maiō T. (talk) 23:43, 12 August 2017 (UTC)

@Maiō T.: This is not a VPT matter. A good place to have such a discussion would be the talk page of an interested WikiProject, such as Wikipedia talk:WikiProject Handball. --Redrose64 🌹 (talk) 07:34, 13 August 2017 (UTC)

Help with category renaming

I'm trying to figure out how to cause the code {{Expert-subject|New York|reason=Foo}} to populate Category:New York (state) articles needing expert attention in stead of Category:New York articles needing expert attention. Can some one please help me on this? עוד מישהו Od Mishehu 06:32, 13 August 2017 (UTC)

@Od Mishehu: Not a good idea. New York is ambiguous; the problem should be fixed at source, by altering each individual template use to be either {{Expert-subject|New York (state)|reason=Foo}} or {{Expert-subject|New York City|reason=Foo}} as appropriate. --Redrose64 🌹 (talk) 07:43, 13 August 2017 (UTC)

KISS principle supports Redrose64's answer. The template will soon become unwieldy if it has to cater for every disambiguation. If you're sure that every NY means NYS, not NYC then AWB or a bot could churn through the job of altering the template call. Cabayi (talk) 07:55, 13 August 2017 (UTC)

How would we do that so the WikiProject link will point to Wikipedia:WikiProject New York, not to Wikipedia:WikiProject New York (state)? עוד מישהו Od Mishehu 10:12, 13 August 2017 (UTC)

Is that necessary if you just redirect Wikipedia:WikiProject New York (state)? PrimeHunter (talk) 10:19, 13 August 2017 (UTC)

Until/unless the WikiProject is renamed, we shouldn't be displaying the name "WikiProject New York (state)". עוד מישהו Od Mishehu 10:40, 13 August 2017 (UTC)

The documentation for the template states "These subcategories are named after WikiProjects." Until the project changes name there's no need to include this change (nor to move the category) in the workflow from the RM - is there? Cabayi (talk) 12:28, 13 August 2017 (UTC)

MinervaNeue skin

Hi, like this new skin, big improvement but there is an issue with editing. When you click "edit" it tends to ignore the lede and go to sections lower down. I would rather just a simple "Edit" button and you can access the whole article at the top. Can this be fixed?♦ Dr. Blofeld 08:02, 13 August 2017 (UTC)

@Dr. Blofeld: Feel free to create a ticket in Wikimedia Phabricator by following the instructions How to report a bug. This is to make developers of the software aware of your request. Thanks. --AKlapper (WMF) (talk) 14:53, 13 August 2017 (UTC)

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)

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)

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

Wanted pages almost broken

Special:WantedPages is somehow not matching up with my expectations of the 'New Page' box at the top of my contributions page, it is never updated and should link to the help pages on how to create an article. A Guy into Books (talk) 14:20, 13 August 2017 (UTC)

The button saying New page at top of your own contributions is made by enabling "Content Translation" at Special:Preferences#mw-prefsection-betafeatures. Linking to Special:WantedPages seems a bit odd. There are other ways to get there and users following those ways may not have the same expectation as you but you have a point. The top of Special:WantedPages displays MediaWiki:Wantedpages-summary which is currently just a MediaWiki default. We could customize it to include links to help and process pages at the English Wikipedia. By the way, Special:WantedPages is pretty useless at the English Wikipedia because the highly redlinked mainspace pages are mainly pages which happen to be in WikiProject to-do lists with many transclusions, e.g. HaRav Moshe Nehemia Cohenov in Wikipedia:WikiProject Israel/to do2. It has 0 links from mainspace but around 19,600 from talk pages transcluding {{WikiProject Israel}}. PrimeHunter (talk) 15:24, 13 August 2017 (UTC)

We have Wikipedia:Most-wanted articles, but that list hasn't been updated since May 2016. Thryduulf (talk) 19:36, 13 August 2017 (UTC)

I have added the below to MediaWiki:Wantedpages-summary. PrimeHunter (talk) 11:15, 14 August 2017 (UTC)

See also: Wikipedia:Requested articles, Wikipedia:Most-wanted articles, Wikipedia:How to create a page, and Wikipedia:Your first article

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)

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

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

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)

You can't "page back" from a random article

Tracked in Phabricator
Task T39224

Perhaps this is a Safari thing, but while poking about the Wiki using Random article (which demonstrates the Wiki to consist largely of gazetteer entries and obscure one-season sports players) I found that hitting the "back" button did not, in fact, return me to the last article, but the first one it served up, a disambig page for Petts. This seems wrong. Maury Markowitz (talk) 10:37, 14 August 2017 (UTC)

It works for me in Firefox, Microsoft Edge, Internet Explorer and Google Chrome. PrimeHunter (talk) 11:03, 14 August 2017 (UTC)

If you have a setting which causes a new window or tab to open when clicking links, this could be the reason. It also works for me, although I don't have Safari to test. —PaleoNeonate – 11:16, 14 August 2017 (UTC)

Known problem with some browsers. —TheDJ (talk • contribs) 13:20, 14 August 2017 (UTC)

Advanced search parameters

I want to search for articles that come within the scope of WikiProject Medicine in the hidden category Category:All articles to be merged. There are several thousand articles in that category, so is there a search parameter or tool that will allow me to filter those out more easily? Regards CV9933 (talk) 15:16, 14 August 2017 (UTC)

To get a cross section including categorization from talk pages, you need to use WP:Petscan. --Izno (talk) 15:46, 14 August 2017 (UTC)

This link is to the correct query, if I'm not mistaken. עוד מישהו Od Mishehu 17:36, 14 August 2017 (UTC)

Thank you both for providing the above information, running the query was a very useful way of letting me know which box I wasn't ticking. Cheers. CV9933 (talk) 19:38, 14 August 2017 (UTC)

Tech News: 2017-33

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

• Bureaucrats can now set users as confirmed. Previously only stewards could do this on most wikis. Nothing will change for wikis that have previously decided to let administrators set users as confirmed. [21]

Problems

• The symbols in the language list that show that an article is good or featured in that language doesn't work. Links to the Commons category in the sidebar doesn't work either. The developers are working on fixing it. [22][23]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 15 August. It will be on non-Wikipedia wikis and some Wikipedias from 16 August. It will be on all wikis from 17 August (calendar).

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

23:28, 14 August 2017 (UTC)

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)

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)

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)

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)

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

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)

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)

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)

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

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

• 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)

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)

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)

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

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)

@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)

@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)

AWB subrules

Reposted from WT:AWB due to lack of response.

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)

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)

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)

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

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)

@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)

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

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)

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

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)

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

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)

@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)

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

@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)

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)