This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown.
No, we will not use JavaScript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an accesskey property on it (default to accesskey="f" in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences.
No, we will not add a spell-checker, or spell-checking bot.
You can use a web browser such as Firefox, which has a spell checker.
If you changed to another skin and cannot change back, use this link.
Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem.
If an image thumbnail is not showing, try purging its image description page.
If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear.
For quite a while now, ever since the last big update, when I try to bring up my Watchlist it takes ages - much MUCH longer than bringing up Contributions or getting to the Main Page. But this afternoon I have been unable to even get to my Watchlist. Sorry if I missed the memo (lol) but does anyone know what is going on? Thanks, Shearonink (talk) 21:11, 28 April 2016 (UTC)[reply]
I'm having this problem too, Safari 6.1.6 (yes, I know, haven't updated). I managed to log on using Chrome, deleted my watchlist, then tried logging in with Safari and had no problem. I started reloading the watchlist a bit at a time, and after adding all the As, which was okay, then the Bs and then I got a message telling me there are too many pages to load (the entire watchlist - all of it – is barely over 2000, so As and Bs is a small number). Have we stopped supporting old versions of Safari? Victoria (tk) 01:21, 29 April 2016 (UTC)[reply]
Adding: I tried to go to my contribs to comment out the scripts I have on my .js and other pages and hung when I clicked "contribs" so I think it's more than the watchlist. Victoria (tk) 01:28, 29 April 2016 (UTC)[reply]
Nice to know I'm not the only one. Haven't tried Chrome, am running on Safari atm, but haven't been able to access my Watchlist at all today. Is anyone else having this issue? Shearonink (talk) 03:09, 29 April 2016 (UTC)[reply]
Yes, I can't see my contributions page either. Richard75 (talk) 08:59, 29 April 2016 (UTC)[reply]
"Have we stopped supporting old versions of Safari?". Officially not yet, but that is probably because no one thought about taking that action yet. It is really hard to support older versions of Safari, because it is a tiny group of the userbase, and because it is very difficult for developers to run older versions of Mac OS Safari (basically you need a 2nd mac that you don't upgrade). I would say that Safari 8 and up is what is effectively supported. —TheDJ (talk • contribs) 09:08, 29 April 2016 (UTC)[reply]
Thanks for the answer. But upgrading sounds like a hassle, especially since I don't have any trouble on any other website; I think I'll just stop editing. Richard75 (talk) 09:12, 29 April 2016 (UTC)[reply]
You can consider using a different browser. Also, reports like this, will probably cause older Safari versions to be degraded from our list of 'Modern' to 'Basic' support, where all Javascript enhancements (the most likely cause of any problems) are no longer enabled for you. —TheDJ (talk • contribs) 09:17, 29 April 2016 (UTC)[reply]
Ok, thanks. The problem might not be with the browser, though, and I'm not sure how to respond to the "the reports like this … " part of this. I managed to load 500 pages back to the my watchlist and it worked, then it hung again when I loaded the next 100. So basically, just reporting that when I try to log in, when I try to view my watchlist, (and last night trying to view diffs, page history, and contribs) it hung. So there's an issue somewhere. Victoria (tk) 12:16, 29 April 2016 (UTC) Struck old - these conditions no longer apply. Victoria (tk) 21:37, 29 April 2016 (UTC)[reply]
Since yesterday I've gone from being unable to view the watchlist, contribs, page histories, spent many hours trying to troubleshoot, and now get a complete freeze trying to log in. I think that it would nice if the three people posting to this thread who are experiencing similar difficulties could have a little more troubleshooting help other than being told that the browser isn't supported, please update. I get update messages from other websites and usually I have months to do the updating. Here it has to be done after the fact. And in the meantime you're locked out. Victoria (tk) 21:37, 29 April 2016 (UTC)[reply]
Here's what I found out: My guess is you are using Lion or Mountain Lion as your operating system, and this means you are unable to upgrade to a more recent version of Safari. Safari 6.1.6 came out in August 13, 2014. It's not realistic for us to have to maintain compatibility with outdated browsers indefinitely. It looks like you have two options at this point: Switch to Chrome, or upgrade your browser to El Capitan so that you can upgrade to the most recent version of Safari. I use Chrome almost exclusively, as I find it is the best browser for the type of work I do here on Wikipedia (operating system is Mavericks). I suggest you give it a try, as this is a simple fix. — Diannaa (talk) 14:09, 30 April 2016 (UTC)[reply]
Hi Diannaa, thanks for replying. You're right, I need to update to El Capitan, but don't have the time to do it immediately (and it wasn't on my list of things to do during the winter), and I think that's my frustration that this came out of nowhere. The issues are to do with loading any page and it doesn't matter if I'm logged out or not, i.e. if I'm reading an article while logged out and click a wikilink it freezes (and it's a really terrible freeze). Surely I'm not the only person who is lazy about updating. I understand that we can't support all browsers or older browsers; I do get that. But it seems a disservice, is the point I'm trying to make, and I don't have trouble reading or accessing any other websites. When that begins to happen, I know that it's time to update, but I'm surprised that it's Wikipedia that's forcing it, is all. In the meantime, I dumped my entire watchlist, which allowed me to log in and I was able got here using the search function. Victoria (tk) 16:38, 30 April 2016 (UTC)[reply]
The problem is very simple. We need to find someone with enough technical skill who can 'figure' out why this is occurring. Now those people generally tend not to run Safari 6 on Lion, can't easily downgrade to that, and can't easily install it from scratch. Simple problem, hard solution. It's not a disservice, it's a practicality. In the mean time, I've filed a bugreport (which anyone could have done), but Victoria, could you please check if you have the same problems on other language versions of Wikipedia or sister sites ? Just to make sure that it is not a problem specific to this site ? —TheDJ (talk • contribs) 17:37, 30 April 2016 (UTC)[reply]
Hi TheDJ, that's a good point. While logged out I went the main page and clicked today's featured article, clicked through the first link, tried to click that page's history and froze. Also, while logged out, I went from the TFA to the German version, was able to click through a few links, and was able to open the page history without freezing. I can log into Commons and load my watchlist there. I was also able to click history on a file without freezing. So it seems to be an issue with en.wp. Basically if I click anything that's blue here, whether or not I'm logged in, it freezes and I have a very hard time getting out of the freeze. My concern is not so much whether I can edit, because I haven't been much recently, but whether it's feasible to add some sort of notification to anyone using Lion/Safari 6.xx that Wikipedia doesn't support the browser, instead of causing an ugly freeze. P.s trying to preview causes in edit conflict, so apologies for mistakes. Also, thanks for filing the bug report. Victoria (tk) 18:20, 30 April 2016 (UTC)[reply]
Hm, that is strange. Do you have any Gadgets enabled in your preferences per chance ? —TheDJ (talk • contribs) 19:53, 30 April 2016 (UTC)[reply]
TheDJ, yes, I have gadgets and I can turn them all off and then work through to test each one, but until I'm able to put back my watchlist I won't be working under normal conditions. Before posting here, while still logged out, I tried to get click the history tab of the TFA on the main page and froze again, so it seems the issue is more to do with the OS/browser rather than whether logged in user or not. My sense is that during the server updates something got changed with the way pages are called and it's now not compatible with Lion/Safari 6.xx Victoria (tk) 21:15, 30 April 2016 (UTC)[reply]
Victoriaearle Right, after the earlier reply, I realized i myself had an old mac in storage somewhere, so I spent some 4,5 hours to revive it and I can confirm that I see the same problem. It has nothing to do with Javascript, since it still crashes if I disable Javascript. It very much looks like the Safari rendering engine just dies on something that we feed it (probably a CSS statement of some sort). I see the same problem on the german Wikipedia, but not on the Dutch wikipedia, which is .... most peculiar to say the least. The cause is most definitely a bug in Safari, but which one it is and what the exact trigger is will take a bit more time to figure out. —TheDJ (talk • contribs) 23:04, 30 April 2016 (UTC)[reply]
TheDJ, yeah I've hacked at it a bit too since Friday and it does show very odd and inconsistent results, but I've been doing a lot of cache-clearing and restarting, which might have something to do with it. The thing is, my machine isn't ancient - 2012 model Macbook pro – and I chose to skip the Mavericks update because it had problems when released. If we're finding these issues on the other wikipedias then I have to wonder how many people in the world run four-year-old machines who haven't updated in two years and are experiencing these freezes/crashes and if that's what we want? I don't have any issue with other major websites at all yet – only here. If I want to edit here I'll use Chrome as Diannaa suggests above until I get around to doing the necessary backing up (I have tons of files ). Thanks for spending time with this. Victoria (tk) 01:15, 1 May 2016 (UTC)[reply]
Root cause found. I knew this started to sound somewhat familiar. Together with valhallasw, I reported this issue to both Safari and Chrome before (but neither ticket was ever closed it seems). It's apparently fixed in newer versions of Safari and Chrome, but not in old versions of course. We saw something similar happened in august 2015. —TheDJ (talk • contribs) 09:24, 1 May 2016 (UTC)[reply]
I have the same problem. I'm using Safari 6. Everything is working good in my Wikipedia account (Talk, Sandbox, Preferences, Beta, Read Edit, View History) except when I go to my "Contributions" and Watchlist", my wiki page hangs/freezes and unable to proceed.--Richie Campbell (talk) 02:48, 2 May 2016 (UTC)[reply]
I was having this problem yesterday on iOS7. Updating the iPad to 9.31 cleared it up, though this option won't be available to everyone.LeadSongDogcome howl! 13:28, 2 May 2016 (UTC)[reply]
Update: TheDJ - I'm now on Mavericks and using Safari 7.0.6. Bad news is that it still freezes - i.e. if I try to load the history of a page it freezes (with the swirling colored circle). Good news is that it's a softer freeze - I can back out of it, I can close Safari, all things I couldn't do with Safari 6. To digress slightly, the update to Mavericks was done after a lot of backing up, researching El Capitan and a trip to the Apple store where I was advised that these machines designed for Lion don't do great when updating all the way to Yosemite or El Capitan, so we compromised. Mavericks will allow me to go all the way to Safari 9 (a big jump), which I'll do in a few days, but I'd like to hack around with this first and see what else I find. I've not yet tried to replace my watchlist. Victoria (tk) 15:33, 2 May 2016 (UTC)[reply]
We have decided to rollout a patch that will bypass the problem, since so many people are affected (also quite a few iOS devices) and because it's a page freeze that is not related to Javascript but to CSS. This change will mean that Safari users will not get the improvement for text with bidirectional content that the developer originally intended to make, instead only chrome and firefox users will get the improvement. —TheDJ (talk • contribs) 17:39, 2 May 2016 (UTC)[reply]
TheDJ thanks for putting in the patch. I'm not sure what's happened, but I had all of two pages on my watchlist, was able to log in this morning, and now can't get past the log in screen without the hard freeze again. I deleted the two pages from my watchlist (using Chrome) and was able to get back in, but I don't think it's quite there yet for Safari users. Victoria (tk) 20:26, 2 May 2016 (UTC)[reply]
PS - Even though I have switched to Chrome for this issue, I have noticed over the past several days that my Watchlist seems to be slowing down on Chrome. Not hanging up or getting stuck but slower... Shearonink (talk) 00:36, 6 May 2016 (UTC)[reply]
JFTR I haven’t experienced any of the described problems with Safari v5 on OS X v10.6 “Snow Leopard”. There are quite a few sites that don’t work properly any more (I use Firefox for those) but so far this isn’t one of them. (Although I had to switch my math preference to use PNG, because formulæ were getting rendered much too small to read.)—Odysseus1479 21:53, 8 May 2016 (UTC)[reply]
It's still happening for me. I'm using Mac OS X 10.9.4, Safari 7.0.5. More info: it appears to be related to the amount of data to display. It hangs on my "Contributions", or the "History" of most pages. But it doesn't hang for my Watchlist (which is very short), or (it seems) when the article History is very short. Adpete (talk) 03:52, 9 May 2016 (UTC)[reply]
I assume the fix got extended to Safari 7, because it's fixed today for me. Adpete (talk) 06:46, 10 May 2016 (UTC)[reply]
Yes, MediaWiki 1.27wmf23, containing the fix was redeployed today, after another regression occuring when it was first (very shortly) deployed last thursday was explained. —TheDJ (talk • contribs) 17:54, 10 May 2016 (UTC)[reply]
THANK YOU to everyone who spotted replies/issues and everyone who came up with the fixes. My Safari now plays nicely with my Watchlist. Shearonink (talk) 19:24, 13 May 2016 (UTC)[reply]
The Firefox and Opera browsers are viable alternatives. --VanBuren (talk) 06:08, 17 May 2016 (UTC)[reply]
It works fine for me on Safari now; thank you to all concerned. Richard75 (talk) 17:09, 22 May 2016 (UTC)[reply]
Watchlist & contribs corruption
I imagine this is relevant to a discussion above: Watchlist getting stuck. I've got Mac OS X Lion 10.7.5 [with Safari 6.1.6 (7537.78.2)] and keep getting a "some webpages are not responding" message whenever (and only when) I try to check my WP watchlist and contributions. Any other activity on Wikipedia, e.g. accessing mainspace or pages such as this, or online generally is fine. The same error message was identified on apple.com back in January 2014; for me it's only been an issue in the last two days. Has something changed on Wikipedia in that time? I also use an ancient iPad, btw, but I can access Watchlist, etc. no problem on that. Frustrating – but my question is, why is this suddenly an issue? Cheers, JG66 (talk) 14:13, 30 April 2016 (UTC)[reply]
Because the code of website has a couple hundred changes per week, and because old browser are not as capable as new browsers. Oh and because browsers have hundreds and hundreds of bugs in them. And apparently those conditions came together to create a problem :) —TheDJ (talk • contribs) 18:01, 30 April 2016 (UTC)[reply]
Btw, I have Mac OS X Lion 10.x.x & have been running a higher version of Safari than yours. At this point I've given up using Safari to access my Watchlist - Chrome works but it's annoying to have to switch between the two. Would be nice to know why the Watchlist has been misbehaving - but apparently only for Safari users. Shearonink (talk) 03:28, 1 May 2016 (UTC)[reply]
Statistics for page counts and breakdown of the source of the page counts
Page count statistics are stored and available for all Wikipedia articles for the cumulative number of page hits per day on one of the tabs readily accessible on the edit history page. Does anyone know if these page count statistics are broken down anywhere as to the source of where the page request is coming from? What part of the the cumulative page count at Wikipedia comes from searching and linking from the Yahoo engine, as opposed to the Google engine, as opposed to the Wikipedia search box engine, how many are from desktop, how many are from mobile, etc? Which percentage of page counts for individual Wikipedia articles come from which sources whether from inside Wikipedia or from outside Wikipedia? Can these statistics be readily retrieved? Fountains-of-Paris (talk) 19:07, 10 May 2016 (UTC)[reply]
@Fountains-of-Paris:PageViews has a "Platform" and an "Agent" box. The former for all/PC/mobile/app and the latter for all/user/spider/bot. The other information you're looking for is not provided by the API of interest, but I believe you can report the desire for that information at Phabricator; the generic bug for PageViews things is phab:T120497--you can submit another task if you think this is desirable by a wide set of persons. @MusikAnimal: FYI. --Izno (talk) 11:49, 11 May 2016 (UTC)[reply]
@Izno: That sounds like the correct tool, though I cannot locate the tabs for Platform or for Agent which you are referring to. Are they above the graph or below the graph which is posted to illustrate the page counts? Do I need to navigate through other tabs first to find them? Knowing the difference between the sources of how readers are getting to Wikipedia articles is a very important design paramater. How do I get to Platform or to Agent? Fountains-of-Paris (talk) 14:25, 11 May 2016 (UTC)[reply]
They should be dropdowns located above the graph, placed to the right of the Dates and Project forms. What browser are you using? The Github repo docs have this line: "IE10 and Safari 8 and below are not supported." Are you using one of the unsupported variants? --Izno (talk) 14:28, 11 May 2016 (UTC)[reply]
It wouldn't work at all in IE10 and Safari 8 and below, so I'm guessing you're just missing that dropdown: it's at the top-right next to the date range and platform input. Anyway, what you are after is the HTTP referer, and the API does not offer this information. The old squid reports, has some referer information, but that hasn't been updated since August 2015. If you want to file a feature request on phab, I guess add the "RESTBase-API" tag at that seems to be the place where this information would be made available [1]— MusikAnimaltalk 14:50, 11 May 2016 (UTC)[reply]
Wikipedia does have software for identifying whether or not an article is an orphan article with no links made to it and no links made from it. This seems like an all or nothing option. Is there a way to get information regarding how many times, by tally or count, that one article refers to another article throughout Wikipedia? Fountains-of-Paris (talk) 14:37, 13 May 2016 (UTC)[reply]
How do you set up the SQL syntax for the querry to work for a random article, for example, "Dostoevsky" to get a summary of the usage counts of its links? Fountains-of-Paris (talk) 15:55, 13 May 2016 (UTC)[reply]
Regarding internal referrers, there is a public dataset which is very occasionally updated: m:Research:Wikipedia_clickstream (used to generate the chart for London on the right)
The Pageview_hourly table, which is the source for https://tools.wmflabs.org/pageviews/ contains a "referer_class" field (values: internal, external or unknown) which could potentially be exposed in the tool too. (The full table can't be made public for privacy reasons.) You may want to file a Phabricator task for that if you are interested in this; it might need some wider discussion but right now I don't see reasons why this would be impossible.
Lastly, if one has access to these internal tables (only a few people who have signed an NDA, mostly WMF staff like myself who need it for their work - I myself use it as a data analyst in the Reading department, mostly to support the department's software development) can also query recent referrer URLs for a specific article, however this data might still be sensitive depending on the situation. Also, these queries are computationally intensive. Still, if you have a research question that can't be answered via the above options, I might be able to occasionally set some time aside to run some specific queries of that nature for you. It would be easiest if you study the documentation here and generate the queries yourself, and then file a Phabricator task, assigning it to me.
@Tbayer (WMF): That's actually directly on target, and my intention was to try to extend the current Wikipedia concern that so-called "orphan" articles should be avoided and fixed when possible. Wikipedia currently does allow us to find out if an article is not used at all system-wide within Wikipedia (in other words a two-state "non-zero-or-zero" inter-article request rate) in hoping to remedy such under-used and under-accessed articles. Rather than causing privacy concerns, my interest in raising this issue was to extend the current two-state "non-zero-or-zero" count notification towards trying to keep the actual number of times one article uses another article, and to do this as a natural extension of the "non-zero-or-zero" indication currently being used for identifying orphan articles. If this can be done without causing privacy issues, then the statistics for the quantity of inter-article referrals within Wikipedia would be useful to editors in the future. (Also, its notable of you to offer running these stats as a one-off when needed, though it would be nice if the stats where more readily available to all editors in the future.) Fountains-of-Paris (talk) 15:56, 25 May 2016 (UTC)[reply]
Can Wikipedia measure how many times one article uses another article within Wikipedia
Is there any way to see how many times one Wikipedia page links to another Wikipedia page for any particular day. This would be comparable to the page counts app but tailored to seeing how useful one article is to another article at Wikipedia. For example, how many times per day (per week, per month) do readers of the Physics article link to the Einstein article? How many times do they link from the Physics article to the Isaac Newton article, etc? Fountains-of-Paris (talk) 14:46, 18 May 2016 (UTC)[reply]
Cross-wiki notifications - how to clear?
Following the introduction of cross-wiki notifications, I now have a few messages from other projects. Clicking on "view messages" shows the list, but doesn't display the message text or any links - clicking on the hamburger icon and selecting "Mark as read" doesn't seem to do anything (the message count doesn't change and the message list is still populated). Do I have to visit each project individually to clear the messages, or is this a bug? I'm using Monobook on IE11, and en-wiki messages seem to be working correctly. Tevildo (talk) 07:38, 13 May 2016 (UTC)[reply]
There's a link in the notifications list, towards the bottom of the section. Can't remember what it's called, they disappear once you've used that link. --Redrose64 (talk) 07:51, 13 May 2016 (UTC)[reply]
I had to visit 8 separate wikis to clear the messages...Jokulhlaup (talk) 11:30, 13 May 2016 (UTC)[reply]
I used the "X" delete button on the supernotification that says "You have 5 notifications on other wikis", and that mostly worked. Except that it seems like it only actually loaded 2 of the 5 non-local notifications the first time and so only cleared those 2, leaving the other 3. Then I reloaded and it loaded 2 of the remaining 3, then I reloaded again and the "X" finally got rid of the last one. Anomie⚔ 12:44, 13 May 2016 (UTC)[reply]
Thank you for you feedback!
@Tevildo, where do you have a hamburger icon? You are supposed to havesomething like that. Can you provide me a screenshot next time you will have some cross-wiki notifications?
@Redrose64, cross-wiki notifications disappear when you mark them as read on your wiki. Is it what you observed?
Sorry, yes, I meant the three dots which brings up the pop-up menu. Selecting "Mark as read" (the only menu option) closes the popup, but the indicator value doesn't change. It seems to be working in Firefox, so I've used that browser to clear out my list. Tevildo (talk) 14:54, 13 May 2016 (UTC)[reply]
@Trizek (WMF): - I clicked 'mark as read' and the big X to clear - no luck. In the end had to go to Wikidata and clear from there, then refresh the browser at en.wikipedia, only way it worked. Will this be fixed? GiantSnowman 14:55, 13 May 2016 (UTC)[reply]
Yes, Giant. I'll ask it to be our #1 priority as soon as the developer in charge wakes-up (you know, timezones! :)) Trizek (WMF) (talk) 14:58, 13 May 2016 (UTC)[reply]
Thanks for reporting this! There was a bug where the global notification counts (the numbers that tell you how many notifications you have) weren't updating correctly. That bug should now be fixed. As for dismissing cross-wiki notifications, that's working for me. If it's not working for you, please let us know, and also tell us if you're using a browser plugin like Privacy Badger or AdBlock. Those plugins have been known to interfere with cross-wiki requests (we worked around them for showing notifications cross-wiki, but not for dismissing them). --Roan Kattouw (WMF) (talk) 22:09, 13 May 2016 (UTC)[reply]
I have an alert saying I have 99+ cross-wiki messages that suddenly appeared a few days ago that I cannot get rid of. They are of no interest to me as I do 95%+ of my work on en.wp. Even though the bug may be fixed, the message alerts refuse to go away and I have 99+ perpetually on my messages icon. Do I have to click on each one individually, as was suggested by a user above? I bloody well hope not -- Ohc ¡digame! 17:13, 16 May 2016 (UTC)[reply]
Ohconfucius, if many of the notifications were from the same wiki, then try going to zh:Special:Notifications or wherever you were notified (or go to your talk page on that project if you have talk page messages). The notifications from that wiki should then be marked as read, and the total notification count will drop. If you don't want cross-wiki notifications at all, then you could try disabling them at Special:Preferences#mw-prefsection-echo, but maybe you will get a useful notification at some point in the future which you want to see. I find this feature very useful as I can see both Commons and Wikipedia notifications on both projects, but I had to visit Special:Notifications on a lot of different projects in order to mark everything as read. --Stefan2 (talk) 21:18, 18 May 2016 (UTC)[reply]
Stefan2, The very strange thing is that I have apparently over 99+ interwiki messages, many of them from MediaWiki, where I don't seem to even have an account, and the messages there don't have anything to do with me. :-( - Ohc ¡digame! 21:35, 18 May 2016 (UTC)[reply]
Ohconfucius You should have a standard global account. It might take a few seconds (and require a page-reload) to auto-login, or if you have strict cookie-permission settings or other privacy extensions, you might need to login manually using the same account details). Re: too many notifications, it's probably because you're watchlisting a busy page there, e.g. I see you have a 4 year old edit at mw:Project:Support desk - I suggest unwatching that. To fix the existing profusion, the easiest way is to open the flyout/popup, and click "Mark all as read" at the top-right corner (screenshot). Note: This will only mark 25 at-a-time (the limit that are visible in the flyout), so you'll need to click a few times. Let me know if that doesn't work, or you encounter any other (specific) problems. Quiddity (WMF) (talk) 18:41, 20 May 2016 (UTC)[reply]
I don't know where this stands, but I've had a phantom message (bell 0 boxes 1) for the past few days... if I go to a project like Wiktionary, it says I have no notifications when I click on the boxes, and here, there's nothing obvious coming up. I mean, it's good to have notifications cross-wiki, but I sure wish I knew *where* .. I've run through the likely suspects. At least it ought to link to the list of what wikis you're on so you have something to go through, because right now I have to think how to look up even how to get that list. Wnt (talk) 12:01, 19 May 2016 (UTC)[reply]
@Wnt: Please could you try marking a single "message" notification as unread, using the "..." menu (screenshot), at another wiki, and then clear all cross-wiki notifications (using the "X" at the top of the bundle)?
Actually, I'll send you 2 test messages elsewhere, to make it easier. Let me know if it doesn't work, in which case I'll ask the devs to look deeper. Quiddity (WMF) (talk) 19:00, 20 May 2016 (UTC)[reply]
@Quiddity: Initially I had no luck - didn't see the three dots or the X you were talking about, had no way but trial and error to find your messages. I tried enabling javascript, which I'd done before, with no luck (in fact, all the edits I've made in Module: space recently were with javascript enabled, but possibly not mediawiki or something). However, once I went back and forth, enabled Wiktionary javascript, then went to meta, then came back here, *after that* when I was preparing to post here that nothing worked, then I got the "welcome to wikipedia" message everyone was talking about, and saw the other format of notifications like in your screen shot. Apparently the notification was on mediawiki.org, which I'd forgot to check. After that I have them cleared out. As I believe I was ranting on below lately, I tend to have a low opinion of javascript for various purposes... among other things, it seems like if the WMF server makes up its mind to show you something, you shouldn't need to run a script to see it. Wnt (talk) 19:25, 20 May 2016 (UTC)[reply]
@Wnt: Nod. Thanks for the details. There are some planned improvements for the Special:Notifications page, including making it possible to see cross-wiki notifications there. I've filed a task (phab:T135877) specifically about the no-JavaScript version, just as a reminder. Cheers, Quiddity (WMF) (talk) 21:03, 20 May 2016 (UTC)[reply]
Not able to edit
@Bishonen reported on IRC that she can't edit anything in the past hours (seems like T134869, but more severe: appears not periodically but continuously). I don't know much about it, just she asked me to report it. --Tacsipacsi (talk) 12:45, 15 May 2016 (UTC)[reply]
Thanks, Tacsipacsi. I've realized I can in fact edit after a fashion using Chrome. But I really really don't want to. In Firefox it's impossible. I have the latest version of Firefox for OSX, and it can neither preview nor save since at least seven hours. All I get when I try is the "Secure Connection Failed" message. Does the phabricator report mean I can look forward to the problem being fixed? Anybody got any idea of the timescale for that? How long a wikibreak should I take? :-( User:RexxS, you got anything? Bishonen | talk 14:15, 15 May 2016 (UTC).[reply]
This is a shot in the dark and probably not related, but are you using Avast Antivirus? I had an issue with HTTPS content not loading properly on Wikipedia that was fixed by disabling HTTPS scanning in Avast. clpo13(talk) 16:05, 15 May 2016 (UTC)[reply]
Not using it, no. But thanks. Bishonen | talk 16:31, 15 May 2016 (UTC).[reply]
@Bishonen: All of the other reports I've been able to track down associate the problem with Firefox version 46 (which was originally released on 3 May 2016 and my version is currently at 46.0.1). I'm currently using Chrome this month as part of my usual anti-checkuser strategy, but I'll get Famously Sharp to attempt a post on your user talk. Hmmz - it works. Ok - only suggestion I can make is for you to try Firefox version 47 which is in Beta - download from https://www.mozilla.org/en-US/firefox/beta/all/ (the OSX version is in blue in the middle column). --RexxS (talk) 19:42, 15 May 2016 (UTC)[reply]
Bishonen, have you tried reloading the page? These past few days, I have randomly got a Firefox error message about the connection being insecure, but reloading the page always solves the problem. --Stefan2 (talk) 20:41, 15 May 2016 (UTC)[reply]
Many times, but it didn't help. But actually it has just started working quite smoothly! Long may it last. I don't see myself as a Beta user, much. Bishonen | talk 20:48, 15 May 2016 (UTC).[reply]
I've been getting the "Your connection is not secure" warning for a week or so. SarahSV(talk) 06:28, 18 May 2016 (UTC)[reply]
Whatamidoing (WMF), thanks for the reply. When it happens a notice appears saying "try again," so I have to click on that, then a second notice appears, which I think says "resend," and I have to click on that too. Then the edit is saved or the preview viewable, whichever it was. SarahSV(talk) 06:14, 19 May 2016 (UTC)[reply]
I've been having this problem off and on as well; unlike Bishonen it's not consistent, but rather happens randomly about every tenth time I try to save an edit. I am running Avast, but I've already turned off https scanning as directed when I first Googled to solve the problem — but even with that turned off, the problem still recurs. It appears to interfere more actively with using Twinkle than with conventional editing — for the XFD module in particular I almost always have to undertake a second attempt because the first one fails under an unspecified error message, which I'm presuming is related to this "secure connection issue" because if everybody were having as many Twinkle failures as I've been having, Twinkle's talk page would be flooded with requests. But it's not, which means this is pretty clearly a "just happening to me" problem. Bearcat (talk) 19:56, 23 May 2016 (UTC)[reply]
Strange things
OK, I'll try to explain what happened. For some time, "[[Category:Grand Lodges|England]]" appeared on the top of the article United Grand Lodge of Englandwhether or not the category was present or removed. After checking the edit history, I found that it all started after this (seemingly unrelated) edit (if you check the previous versions of the article, it is not there). After seeing this, I decided to (manually, of course) undo what was done in this edit and this thing disappeared. My question is, what was the relation of this edit to the appearance of this thing? 94.65.133.34 (talk) 16:19, 17 May 2016 (UTC)[reply]
I just figured that it happened because he had linked to England at the "jurisdiction" area. I will re-add the others, but this means that Infobox Grand Lodge might be a little broken if it leads to the appearance of such things. 94.65.133.34 (talk) 16:26, 17 May 2016 (UTC)[reply]
{{Infobox Grand Lodge}} doesn't expect |jurisdiction= to be linked, since it uses that value as the sortkey for a category. Effectively, by using |jurisdiction=[[England]] what you have is [[Category:Grand Lodges|[[England]]]], and you can't put links inside links. --Redrose64 (talk) 17:25, 17 May 2016 (UTC)[reply]
The past couple of days, every time I've tried to use reFill it hasn't worked. I can bring up the main ReFill page, and enter the title of the page I want to fix, but when I click on the "Fix page" tag it merely goes to a completely white screen and then nothing happens. The tool was fine last week because I used it then. White Arabian FillyNeigh 20:23, 18 May 2016 (UTC)[reply]
Same issue here. Very frustrating when trying to clean up drafts. Happy Squirrel (talk) 21:35, 20 May 2016 (UTC)[reply]
You might consider using the visual editor while this is down (click the [[ ]] button in the wikitext editor's toolbar to get there). It's running the mw:citoid service, which has a 'convert' option for refs that contain bare URLs. Whatamidoing (WMF) (talk) 22:47, 20 May 2016 (UTC)[reply]
nitpick: the [[ ]] button is for switching from VE to wikitext editor. in the other direction it's the small pencil in the right-hand side of the toolbar. peace - קיפודנחש (aka kipod) (talk) 00:52, 21 May 2016 (UTC)[reply]
This can be Exhibit A for my ongoing quest to get the same icon in both places. ;-) Whatamidoing (WMF) (talk) 21:54, 21 May 2016 (UTC)[reply]
It worked for me again this afternoon. Yeah! Happy Squirrel (talk) 19:20, 21 May 2016 (UTC)[reply]
Whatever WMF is doing with banners or other bullshit STOP IT. I am so fucking sick of the page jumping after I click edit and try to start doing something, leading me to click on the wrong thing. Just fucking stop adding whatever crap is making pages jump when we try to edit. Yes I am frustrated. Jytdog (talk) 03:18, 19 May 2016 (UTC)[reply]
Can you give a bit more details? I'm seeing some unwanted page movement on edit, namely the "Template, Named references, Error check" bar unfolds in to the edit window and pushes it all down a couple of lines. — xaosfluxTalk 03:22, 19 May 2016 (UTC)[reply]
The adverts that appear on pages, in particular watchlists but more and more on other pages, move the page after it has finished rendering. This leads to me misclicking on things as they jump a few lines just as I click. It’s especially annoying as it’s not caching anything: use 'back' to go back to the page and it runs the same slow code to redraw the adverts and again jumps the page after it’s loaded. I don’t notice it so much on my PC but it is tediously annoying on an Android tablet I sometimes use for browsing.--JohnBlackburnewordsdeeds 03:34, 19 May 2016 (UTC)[reply]
That's part of it. I'm also getting edit windows reset to the top after the page completes loading, after I've found my text that I want to correct while the page is loading, which is very often much farther down. Dhtwiki (talk) 03:40, 19 May 2016 (UTC)[reply]
Enable "Suppress display of fundraiser banners" and "Suppress display of CentralNotices" and disable "Geonotice: display notices on your watchlist about events in your region" in Special:Preferences#mw-prefsection-gadgets - NQ(talk) 03:43, 19 May 2016 (UTC)[reply]
I experience this constantly, not just one jump but two. A page seems to stop loading. I now know not to click "edit" because if I do, it will jump and open "view history" instead. Nearly a year ago, a second jump appeared, so I have to wait until that has completed too. It has happened with different computers and browsers. SarahSV(talk) 06:10, 19 May 2016 (UTC)[reply]
This is because of javascripts changing the page after it has been delivered to you. navboxes, twinkle being inserterd,, notifications etc. —TheDJ (talk • contribs) 06:39, 19 May 2016 (UTC)[reply]
This is also a sign of bad web page design (related issue: there is no way to suggest improvements that will actually reach the ears of those on the WMF staff who actually do the page design work). A proper design puts greyed-out tabs in the page that loads first, then has the Javascript replace the greyed-out tab with a working tab. Result: no jump, no misclick. --Guy Macon (talk) 10:08, 19 May 2016 (UTC)[reply]
Not really. It's a sign of old Javascripts that are hard to fix. Besides we cannot know upfront if someone has hidden a notice. If you use a vanilla MediaWiki you have none of these problems, it's all the ancient stuff we have on en.wikipedia that is the problem mostly. —TheDJ (talk • contribs) 10:18, 19 May 2016 (UTC)[reply]
It is actually very easy to not display the banner when editing, just need to add this to Common.css:
Well, yes, but I was thinking about Mediawiki:Common.css since it impacts everyone, including anonymous and new users. Darkdadaah (talk) 14:31, 19 May 2016 (UTC)[reply]
Changing Common.css can be a problematic action - last time, as I recall, the admin involved was forcibly desysoped by WMF which then created some kind of "superprotect" power to stop it, all over a less significant format issue. But, who knows? The communication system would seem to be a bit like the red phone in Cabin in the Woods, working one way and rather late in the game. Nonetheless, for purposes of historical accuracy only, I should note that MediaWiki:Sitenotice is a mechanism by which, AFAIK, any fundraising banners could be placed on this site as part of the wiki itself, without any jumping around, and fixed present and past versions on the record. It would make instant sense to make the reform suggested above and switch any fundraising banners to be part of the wiki. However, it would frustrate mad scientists who want to do "A/B testing" giving different users different versions of the message at the same time to see how it affects them. I view that as a feature, not a bug, but WMF mad scientists likely disagree. I wonder if they did A/B testing of the page jumping around. Wnt (talk) 16:13, 19 May 2016 (UTC)[reply]
"AFAIK, any fundraising banners could be placed on this site as part of the wiki itself" Yes, and then they would be cached for a month, without the option to change them
"last time, as I recall, the admin involved was forcibly desysoped by WMF", that was Common.js and yes, only people who really understand what they are doing should mess with those pages. And the average admin is distinctly unqualified. Atm, I only trust Edokter with that actually.
"MediaWiki:Sitenotice is a mechanism by ...without any jumping around". Also incorrect.. site notice has the same problems. —TheDJ (talk • contribs) 16:32, 19 May 2016 (UTC)[reply]
I'm not opposed to this as an intermediate solution. It would mean hiding all notices from those types of pages, but that isn't a bad, since it is still a minority amount of pages. —TheDJ (talk • contribs) 16:40, 19 May 2016 (UTC)[reply]
@TheDJ: I don't understand why the ads would have to be "cached for a month" when the Main Page changes every six hours. Also, I had been under the impression the sitenotice is transcluded onto the page, i.e. part of the wiki source (example - note use of Wiki double bracket links), which ought to make it immune to the Javascript-related display problems. Once a non-Javascript page is finished loading, it's finished loading. Wnt (talk) 18:17, 19 May 2016 (UTC)[reply]
offtopic
The following discussion has been closed. Please do not modify it.
I haven't noticed this because I almost always keep Javascript off. The sole [no wait, it's also good for wikitable sortable] exception, which is a justifiable one I think, is to edit Lua scripts. The editor there is actually fast and has a lot of powerful features like debugging the whole script pretty much as you type, which should emphasize how pathetic it is that an image loading script fails to do so rapidly. Still... my overall feeling is more and more that Javascript has little legitimate purpose on the web, that it makes no sense to use it even for advertising - in the sense of pushing products rather than in the sense of violating user privacy, that is - and that sites that require it are fundamentally illegitimate sites that deliberately intend to "accidentally" push spyware onto their readers at some point within the next few years. I think Wikipedia would do well to break with the mafia-industrial complex on this point and start killing javascripts whenever doing so does not immediately and irretrievably break something. I can't say I especially relish the notion of seeing ad banners pop up on my Javascript-free view of the site when they finally just make them part of the normal served pages, but I'll grudgingly admit that would be fairer, and certainly it should be faster and more stable. Wnt (talk) 15:57, 19 May 2016 (UTC)[reply]
Wnt, if you use words like "mafia-industrial complex" no one is taking you seriously anymore, and you have just wasted your 218 words and 1282 characters and 2 minutes of every readers attention span instead of dealing with the problem. Our problem is collapsible content, especially the fact that the state of said collapsibility is conditional. It's part of why the collapsible sidebar got removed btw. But collapsible content is highly integrated with the expectations of the community, so this is a hard problem to solve one-sided. —TheDJ (talk • contribs) 16:32, 19 May 2016 (UTC)[reply]
@TheDJ: I may have displayed a certain irateness, but I don't feel like computer professionals really understand how disreputable their science has come to appear. People like us have been saying for years that stuff like having webcams built into laptops and now even "smart" (i.e. really stupid) TVs without a physical cover or even so much as a physical on-off switch is really dumb. Yet it goes on and then people report on it as if it were a law of nature. Well it's not: there's something rotten in the computer industry, and it can't be trusted, and there is no distinction for us, say, between the online publisher that uses Outbrain, or Outbrain, or the hacker who distributes malware code via that route. We're tired of drive-by downloads and billion-dollar computer bank heists and privacy policies that are fluffy ways of saying "we'll do whatever we damn well please". And so when Wikipedia has Javascript becoming prominent and making a nuisance out of itself, what do we expect computer professionals to do? Make it worse, naturally. But Wikipedia is supposed to be a nonprofit with a better mission than that (even if it does feature Square Enix ads on its front page every six months or less) with a chance for its people to fight back and be something different. Wnt (talk) 18:12, 19 May 2016 (UTC)[reply]
Wnt, if you have something to say specifically about this issue, say it. Otherwise do not derail this thread with offtopic ranting. Yes, I am telling you to shut the fuck up. This page jumping thing is a concrete problem that needs to be fixed. Jytdog (talk) 05:18, 20 May 2016 (UTC)[reply]
I have nothing fancy loaded in my settings, just the default stuff. No javascript crap or gadgets, not even twinkle. Telling me to turn default shit off so that I can edit in a sane way is fucking bullshit. Things weren't always this way. WMF has fucked something up. Jytdog (talk) 17:07, 19 May 2016 (UTC)[reply]
Yes something changed. JS now load asynchronous and 'late'. This is intentional. It makes everything else significantly faster. It's just highly problematic for stuff that has JS state. We will need to reassess how we show things like central notices I think. —TheDJ (talk • contribs) 18:55, 19 May 2016 (UTC)[reply]
Also, I like to reiterate, that in the case of notices, as soon as you dismiss a notice it should not show up and also NOT cause a flash. As long as you keep using the same browser at least. It is only the new/changed notices that cause this effect.. —TheDJ (talk • contribs) 19:49, 19 May 2016 (UTC)[reply]
BTW. For Centralnotice, the overal tracking task for this is phab:T109634. For dismissable sitenotices, the task is phab:T125323 and for collapsed content it is phab:T42792 (though on en.wp we still use the even older collapsible div's and tables code that is kept in MediaWiki:Common.js). And for Twinkle, it is this Github issues —TheDJ (talk • contribs) 19:22, 19 May 2016 (UTC)[reply]
We really should get rid of that dinosaur code and move to mw-collapsible. -- [[User:Edokter]] {{talk}} 22:50, 19 May 2016 (UTC)[reply]
Please whatever you do to fix this without screwing up other stuff would be great. Please. Jytdog (talk) 05:19, 20 May 2016 (UTC)[reply]
Last week I asked Edokter to deploy a change that should help with some jumps caused by (by default) collapsed content elements. This should help with jumps etc due to collapsed content in infoboxes for instance. I've also just submitted two patches to reduce the amount of jumping by the WikiEditor. I hope those will land somewhere next week. Baby steps —TheDJ (talk • contribs) 20:38, 22 May 2016 (UTC)[reply]
Thank you very much. Very. Jytdog (talk) 01:15, 23 May 2016 (UTC)[reply]
I just got this stupid popup, I've been editing for seven years and am at no. 185 in the most edits list. I turned off VE as soon as an option to do so was available. I've been an admin since 2011 ferchrissakes. Get real. --Redrose64 (talk) 19:33, 19 May 2016 (UTC)[reply]
Joining Redrose64 in not welcoming this in the least. In the best of circumstances I hate these not-really-there phenomena that social media uses nowadays; my screen freezes with the darned thing hovering there and it's never clear what I should click on to be able to use the window again. In this case it almost gave me a heart attack - I was previewing and thought I'd lose the edit. I took the risk of clicking on "Edit" or whatever and thank all the gods, neither lost the edit nor crashed my browser. WMF: I volunteer here, doing the work that makes this wiki popular enough that you get to be handsomely paid for whatever it is you do. Stay out of my workflow. Take your abysmal Visual Editor and shove it, don't thrust it in front of me, I and the vast majority of the people who actually work around here told you it sucks, it sucks, that's it, stop demanding we choose between it and what works! Yngvadottir (talk) 19:49, 19 May 2016 (UTC)[reply]
Please relax a bit, it makes everyone's participation a whole lot more pleasant. —TheDJ (talk • contribs) 19:57, 19 May 2016 (UTC)[reply]
Don't tell me to relax. It came up again. Do you work for that awful outfit? If so, please report that the experience of having this pop-up freeze one's screen is not pleasant. Yngvadottir (talk) 20:08, 19 May 2016 (UTC)[reply]
"Do you work for that awful outfit" No, not that that should have anything to do with how we communicate with eachother. —TheDJ (talk • contribs) 21:08, 19 May 2016 (UTC)[reply]
It really is disruptive - I get a box with no "dismiss" option - only "start editing" that is quite jarring - when I clicked on it, it just went away. Completely useless in the workflow for me as an editor, and unexpected. I think we should put up the site notice to warn about this - any objections? — xaosfluxTalk 20:20, 19 May 2016 (UTC)[reply]
I know that this is a case of hindsight, and given that all I know of this is what I learned from mucking about with scripts in...the other thread, I probably don't have all the information I would need to speak intelligently about this. But just for curiosity's sake, shouldn't it have been possible to prevent the message from popping up for current users by adjusting the starting value of visualeditor-hidebetawelcome in everyone's preferences? New accounts could have the welcome enabled, of course, since it's targeted to them, but would it not have been straightforward enough to just set that pref to "true" for all current users? Maybe this version of the welcome is different though or something, so I might not understand correctly. Writ Keeper⚇♔ 20:21, 19 May 2016 (UTC)[reply]
@Writ Keeper: I made the decision not to do that intentionally, I'm afraid. Doing the fetch of the users' edit count and registration date would have added another few ms to every edit page load for every editor for the rest of time. Pre-setting tens of millions of rows in the databases to fake 'visualeditor-hidebetawelcome' as true would be a pretty major step which we go out of our way to avoid. Note that any account that's seen the dialog before (e.g. in the visual editor) won't get the prompt (unless they've reset their preferences), it's just a one-time thing regardless of which editor you use. Jdforrester (WMF) (talk) 21:38, 19 May 2016 (UTC)[reply]
Hmm, I guess I can understand that. I know my ops people always get mad at me when I write update queries for them to execute that hit millions of rows. I wouldn't have said it's a dealbreaker--there are generally speaking ways to do it gradually without totally destroying the database--but I can respect it, as long as it was at least thought about. Writ Keeper⚇♔ 21:42, 19 May 2016 (UTC)[reply]
When I just now brought up a deleted page to check its logs, I got the "Welcome to Wikipedia" popup smack in the middle of my screen, that told me to click on it to begin editing. I've been on Wikipedia for about 7-8 hours today, and this just popped up the first time. If it's an oversight, please give us an opt out. This shouldn't be coming up for anyone but people who have never edited at Wikipedia before. And considering how hard internet users work to keep popups off their screens, maybe this was not the best of ideas. And by the way, in my Preferences, "Temporarily disable the visual editor while it is in beta" has been checked off as long as the option has been there. — Maile (talk) 20:30, 19 May 2016 (UTC)[reply]
I just got it straight across the board, testing all the wikis. — Maile (talk) 23:38, 19 May 2016 (UTC)[reply]
You should see it once per wiki while logged in. This means once at the English Wikipedia, once at the German Wikipedia, once at the French Wikipedia, etc. – all the languages times all the projects (times all the accounts, if you have more than one, as I do). Most editors don't spend much time doing cross-wiki work, so most editors won't see it more than once or twice. Personally, I've already clicked past it at least six times in the last hour. (Also, it's faster to click "Start editing" on that dialog than to go to Preferences, find an item, and opt-out.) Whatamidoing (WMF) (talk) 00:16, 20 May 2016 (UTC)[reply]
Why not link to this angry public flogging thread, since it is going to contain all the answers as time goes on - seriously? Fred Gandt · talk · contribs 21:30, 19 May 2016 (UTC)[reply]
Will mock something up and post back soon. — xaosfluxTalk 21:38, 19 May 2016 (UTC)[reply]
Ironically I got the welcome message on Commons but not here .... I feel even more blessed lol, –Davey2010Talk 21:52, 19 May 2016 (UTC)[reply]
Any suggested changes? — xaosfluxTalk 23:46, 19 May 2016 (UTC)[reply]
What action do you expect typical users to take in response to that proposed message? Whatamidoing (WMF) (talk) 00:07, 20 May 2016 (UTC)[reply]
I trust the typical users will band together and demand another site notice to explain the first site notice which explains the trivial pop-up, using There Was an Old Lady Who Swallowed a Fly as a general guide to strategy. --Tagishsimon(talk) 00:12, 20 May 2016 (UTC)[reply]
Become aware of what is going on. I'm not about to slam it up there unless there is some agreement here that it will be useful. — xaosfluxTalk 00:15, 20 May 2016 (UTC)[reply]
Good call. You do not have 'some agreement', or, at least, you do have some dissent. --Tagishsimon(talk) 00:17, 20 May 2016 (UTC)[reply]
Xaosflux, there's no clear "call to action", if you don't mind the designers' jargon. It first tells editors something that they'll find out on their own (so it's redundant), and then it offers a place to discuss something or another about "this", but at the time that they're offered this option to discuss something, they don't know what you want them to discuss, because they haven't seen the dialog yet. If I didn't already know what this message was about, I'd be confused by it. The discussion is also unlikely to provide actual value to the participating editors: by the time you know enough to discuss it, you've already dismissed it.
For the record, I don't think it's an unreasonable thing to consider; in fact, I very briefly considered a CentralNotice myself. It's a tool I often consider, but rarely use, for user interface changes. However, I decided that the net result of any such message would be thousands of editors at 800+ WMF wikis spending collectively hundreds of hours trying to figure out what I was talking about. That time would be far more than they would spend in dismissing the one-time dialog when it reached them – and they'd still have to dismiss the dialong anyway. So based on that analysis, it didn't seem like a valuable use of volunteer time and attention, and I abandoned the idea. Whatamidoing (WMF) (talk) 00:45, 20 May 2016 (UTC)[reply]
To be clear, unless there is actual support I'm not touching the sitenotice. My goal was to get information in front of people to avoid drama, certainly not make more. — xaosfluxTalk 01:00, 20 May 2016 (UTC)[reply]
I'm not going to pretend to know exactly why this welcome popup is popping up, but get the jist. Please bare that in mind as I suggest that if there's to be a site notice to act as a heads up, it should be simple, honest and self contained advice.
Something like "Because of a discussion that lead to a decision to implement a thing, the WMF did a thing which lead to a discussion which reversed the decision, and resulted in a technical glitch. This glitch will manifest as a welcome message that pops up as editors begin editing. This popup will only show once on each Wiki thing, and other than getting in the way a little, changes nothing. Welcome to Wikipedia! ;-)" - with obvious editing.
It's not a call to action, or an obscure and confusing riddle; it just says what's happening to alleviate potential surprise and maybe save some freaking out. Fred Gandt · talk · contribs 01:06, 20 May 2016 (UTC)[reply]
It may be simpler to just make the popup itself do the talking since I'm sure a lot of editors have not yet been harassed by it. For some reason, it popped up at least twice for me, and the option buttons were, as stated, not very clear on what to expect when selecting the edit option. I, for one, did not know whether to expect the familiar editing format of some newfangled thing to waste my time. -- André Kritzinger (talk) 01:20, 20 May 2016 (UTC)[reply]
I'd be in a favor a single [X] in the top right corner, clicking it: dismisses the box forever and keeps all your settings exactly how they were prior to the popup. — xaosfluxTalk 01:45, 20 May 2016 (UTC)[reply]
An [X] would do it. It was the first thing I was looking for when the popup popped up... André Kritzinger (talk) 02:11, 20 May 2016 (UTC)[reply]
A forever X would be a step forward, click it once and it stays gone for all eternity. Even better, if our Preferences had an option to suppress any and all popups that Wikimedia could come up with, forever and ever and ever. — Maile (talk) 14:15, 20 May 2016 (UTC)[reply]
I've asked. I don't know whether I'll get a definitive answer today, but I'll let you know. One of the devs also suggested making it possible to dismiss things like this by clicking anywhere outside the box, so there may be more than one 'leave me alone' approach implemented. Whatamidoing (WMF) (talk) 16:31, 20 May 2016 (UTC)[reply]
If there's a need for the Welcome message, making it accidentally dismissable is not a good idea. --Pipetricker (talk) 09:02, 21 May 2016 (UTC)[reply]
I was gone for a few days, and when I returned a pop-up greeted me when I wanted to edit. I agree with Maile above, quit spamming us with the VE already. I already have just one edit tab, I suppressed the VE one. Manxruler (talk) 15:26, 25 May 2016 (UTC)[reply]
I think this is terrible advise for people. Anyone going this direction should consider if it is not wiser to disable all Javascript instead. We have two modes of operation, without JS and with. That's what can be supported, not some freak of nature in between state that this would create.
For instance. I'm in the process of removing the jquery UI dialog popup that we have on thumbnail videos, with oojs ui dialogs. By doing this you would have autoplaying but invisible videos after you click them at some point in the future. And though I am now warned, there is no way in hell that I will take this into account when creating my patches. —TheDJ (talk • contribs) 13:49, 22 May 2016 (UTC)[reply]
This is really bad advice. It will hide every OOjs UI dialog, on every page, in every tool. And then developers will have to field bug reports from people who thoughtlessly copy and paste this. Matma Rextalk 14:18, 22 May 2016 (UTC)[reply]
I wrote the following in my global .js and it seems to be working:
I have a couple of problems with this message, some of which I admit are repeats:
I don't see a use for it
If WMF wants to communicate with me, shouldn't they do it whether I have Javascript enabled or not? Even if there is a Visual Editor that requires Javascript and I have it disabled, shouldn't they tell me about it anyway?
If the WMF wants to communicate with me, why don't they leave me a talk page message like everybody else? Why have multiple methods of communication to maintain and debug?
If the WMF is going to put up a message box that looks like any standard alert anywhere else on OSes or the web, shouldn't it have a standard X in the upper right corner?
The only thing I can think of more useless than the welcome message would be having a sitenotice warning people about the welcome message. Wnt (talk) 12:16, 23 May 2016 (UTC)[reply]
Adding this to meta User/Global.js works, does anyone know if a meta gadget would be able to provide that (in lieu of having each person have to edit their .js file)? — xaosfluxTalk 15:44, 25 May 2016 (UTC)[reply]
Gone, but like the cat in the hat, keeps coming back
To all of the above, I was about to say I haven't experienced the popup since I initially encountered them on each wiki. However....I just opened Commons to an image, and the minute I clicked on "Edit", the popup blocked my screen. Nothing really got rid of it until I accidentally clicked on switching to Visual editing. Then I had another popup telling me to click on an icon to get out of Visual editing. Except...there was no icon there. And I don't have noscript on that page. So, I finally shut down the window and came back in, and no popups. If I'm in Visual edit, I don't know what it's supposed to look like.
Get rid of this for everybody. It serves no useful purpose for potential editors. Anyone clicking on the Edit tab already knows they're editing, and they don't need a popup to input a separate step. So the question is...exactly what purpose does it serve? If one encounters popups on the internet, they're most likely tracking something. Is that the underlying purpose with this? Editing on Wikipedia should not require the user to keep clicking away popups just to edit. Clicking on the "Edit" tab should work. — Maile (talk) 13:18, 23 May 2016 (UTC)[reply]
The developers also broke Special:MovePage like this some time ago. Is there some way to get the old version back? A lot of unnecessary scrolling is required, and it also takes more time to load the page, and if I change anything in any of the lists or text boxes before the page has finished loading, then those changes are discarded once the page has finished loading. --Stefan2 (talk) 22:35, 19 May 2016 (UTC)[reply]
One hour on from TheDJ's post, and the dialog box at Special:WhatLinksHere still takes up more than half the screen, with big gaps between selection items. This is MonoBook, and it's trying to be like Vector - why? --Redrose64 (talk) 22:46, 19 May 2016 (UTC)[reply]
My mistake in UTC timezone translation. it should have been 1,5 hours when I posted that. 10 mins left, and then the deploy slot will start. —TheDJ (talk • contribs) 22:50, 19 May 2016 (UTC)[reply]
The old layout is back. The filters had unlinked "Hide transclusions | Hide links | Hide redirects" for a few minutes but also work now. The default MediaWiki:Whatlinkshere-hidetrans and friends apparently reverted a little later than the layout. PrimeHunter (talk) 00:11, 20 May 2016 (UTC)[reply]
@Stefan2: "if I change anything in any of the lists or text boxes before the page has finished loading, then those changes are discarded once the page has finished loading" – are you sure this is still occurring? I fixed that bug months ago. I just tried and this doesn't happen for me. (Loading time should not be noticeably affected and no scrolling should be required unless you have a tiny screen.) Matma Rextalk 15:23, 20 May 2016 (UTC)[reply]
The filter links are still missing on Swedish and Finnish language versions. Can we do anything to fix that or should we just wait a little longer? --Pipetricker (talk) 09:47, 20 May 2016 (UTC)[reply]
You can just wait. If you want a quick local fix then a local admin can create MediaWiki:Whatlinkshere-hidetrans, MediaWiki:Whatlinkshere-hidelinks, MediaWiki:Whatlinkshere-hideredirs. If they contain $1 it should already work. If not then the local word for "hide" should be replaced by $1 (no promise this works in all languages). When the planned global fix goes through (or if my suggested fix doesn't work), the three messages can be deleted. PrimeHunter (talk) 10:01, 20 May 2016 (UTC)[reply]
It's also still broken for users here with a foreign langauge selected at Special:Preferences, for example Swedish. I don't recommend creating these messages in other languages here at the English Wikipedia. The foreign language users must live briefly without it. User:PrimeHunter/English interface.js gives a one-click option to see the working English interface on a given page. PrimeHunter (talk) 10:12, 20 May 2016 (UTC)[reply]
It now works in all tested languages. PrimeHunter (talk) 18:38, 20 May 2016 (UTC)[reply]
PC1 seems to be broken
Does anyone have any idea why my edit to Freetown Christiania had to be accepted by a reviewer? The article is configured to PC1 so autoconfirmed people should be automatically accepted provided there are no other pending changes to be reviewed. There weren't any other changes. I am certainly autoconfirmed. But my edit was not auto-accepted. Has anyone else experienced anything like this before? --Majora (talk) 02:26, 20 May 2016 (UTC)[reply]
My regular edit to that page with my testing account didn't require any acceptance - will check a revert. — xaosfluxTalk 02:31, 20 May 2016 (UTC)[reply]
I was able to duplicate your symptom - not sure if this is "new" behavior - the version you reverted to was prior to the PC being enable and itself was not reviewed, there are beany ways around that situation but this may be "by design" because of the "if no previous pending changes remain to be accepted" part of PC1. — xaosfluxTalk 02:35, 20 May 2016 (UTC)[reply]
Ah ok. Just seemed like an odd bug but that makes sense and if it is by design so be it. I really don't need to know more details if it is a BEANS matter. Expect perhaps to confirm if this is in fact by design. --Majora (talk) 02:49, 20 May 2016 (UTC)[reply]
UserStatus template
Just curious as to why the {{UserStatus}} template has stopped working? When I type in a code at User:Paine Ellsworth/Status}} for another status besides the default, it is still the default status that is seen on my user page. Have there been any recent software changes that would cause this? Stick to sources!Paine 12:22, 20 May 2016 (UTC)[reply]
Thank you, John of Reading! – yes, that did the job. I was concerned that it might be widespread, since it has worked so well for a long time and only recently stopped working, but that concern is improbable under the circumstances. Thank you again for your help! Stick to sources!Paine 08:18, 21 May 2016 (UTC)[reply]
Using WP:AWB. Find: #REDIRECT \[\[User:(.*)\1 Replace with: #REDIRECT [[User:$1\n{{R to user namespace}}
Why did AWB append the backreferece $1 to the end (DIFF), rather than insert it where it was supposed to? wbm1058 (talk) 18:45, 20 May 2016 (UTC)[reply]
@Wbm1058: Try #REDIRECT \[\[User:$1\n\{\{R to user namespace}} ? I think the unescaped characters might be causing problems. EvergreenFir(talk) Please {{re}} 18:57, 20 May 2016 (UTC)[reply]
Actually... scratch that... let me tinker. EvergreenFir(talk) Please {{re}} 18:57, 20 May 2016 (UTC)[reply]
Get rid of the \1 in your find and it will work (tested on regex101 dot com). EvergreenFir(talk) Please {{re}} 19:01, 20 May 2016 (UTC)[reply]
Got it, thanks! Now I see, I don't need to name or number the capture group, and even if I did, the syntax for that is different. wbm1058 (talk) 19:09, 20 May 2016 (UTC)[reply]
(edit conflict) Yep! Adding that \1 makes the regex look for the first defined capture group (.*) again. So it was looking for a repeat. Something like #REDIRECT [[User:FOOBARFOOBAR would hit since it would pick up FOOBAR twice (once for the initial capture and once for the \1). EvergreenFir(talk) Please {{re}} 19:14, 20 May 2016 (UTC)[reply]
\1 doesn't do what you think it does. (.*)\1 basically matches the same string twice in a row, e.g. "aa", "abab", etc. In the diff, $1 is "" (the empty string), since no longer repeated string is found; the remainder of the line (Dl2000/Band names - plural or singular?]]) isn't matched at all and is left alone. To be sure the entire line is matched, try #REDIRECT \[\[User:(.*)$ ($ matches the end of a line). SiBr4 (talk) 19:12, 20 May 2016 (UTC)[reply]
MediaWiki::API and SSL
Resolved
Apparently my various "Null bot" operations (see User:Joe's Null Bot, will break on June 12th if I don't update the somewhat ancient code to https. Thanks, WMF. :)
I've been using MediaWiki:API, and when I update the URL from http to https I get "500 Can't verify SSL peers without knowing which Certificate Authorities to trust". I've checked what would appear to be the appropriate documentation at [2], and while I get what the error message is saying in the abstract, am fairly lost about what it actually wants me to do, given the lack of CA-related apis in the documentation. Any assistance appreciated, and apologies that I'm fairly out of date on all this. --joe deckertalk 21:51, 20 May 2016 (UTC)[reply]
The first thing to do when you receive an error message is to search for it. How about this? Max Semenik (talk) 22:01, 20 May 2016 (UTC)[reply]
That latter works great Mx. 37.x.x.x, thank you! --joe deckertalk 22:23, 20 May 2016 (UTC)[reply]
And people wonder why so many creditcard numbers get stolen all the time.. —TheDJ (talk • contribs) 00:29, 21 May 2016 (UTC)[reply]
LOL, but yes as this is the TECHNICAL pump - that setting will leave you open to a man in the middle attack for stealing your credential. — xaosfluxTalk 00:44, 21 May 2016 (UTC)[reply]
Depending on other settings you may not be "wide open" just "more open". — xaosfluxTalk 00:47, 21 May 2016 (UTC)[reply]
The setting is 'perl'; it is a question of how wide. John Vandenberg(chat) 01:46, 21 May 2016 (UTC)[reply]
joe decker, if you are not wedded to your Perl, pywikibot has mw:Manual:Pywikibot/touch.py which means each of those tasks is a one liner shell command, which can be scheduled using cron. If there are any features missing, I will add them. John Vandenberg(chat) 01:46, 21 May 2016 (UTC)[reply]
When I have a bit more time I'll probably look into it--it'll be a bit more than a one-liner (I doubt your one-liner includes the rate-limiting requested by BAG), but I'm sure it'd be a heckuva lot simpler, and that will certainly be what I do if there's ever need for more than a trivial upgrade.
It is a poor formatting style to put a heading of a section at the bottom of a page and put the following paragraph in the next page. Yet in wiki categories, e.g. Category:1974 in Gaelic games, when "pages in category" were split into 2 columns, the heading "L" is at the bottom of the first column, while the page link 1974 All-Ireland Senior Ladies' Football Championship (its sort key is "Ladies' Football" due to the infobox so it belongs to "L") is at the top of the second column. I would like to suggest that the heading should always keep with at least the first page link. I know this issue may seem minor, but it is really awkward and not so reader-friendly. --Quest for Truth (talk) 11:18, 21 May 2016 (UTC)[reply]
The "L" is an <h3>...</h3> and the page links are <li>...</li> items in a <ul>...</ul>. Sounds like CSS "break-after: avoid" on the header or "break-before: avoid" on the list would fix it. Is it supported widely?DMacks (talk) 11:45, 21 May 2016 (UTC)[reply]
Support is in its infancy. I had code ready that might work in the near future, but the devs refused the CSS code that targeted modern browsers using vendor prefixes because they were not implemented (yet!). -- [[User:Edokter]] {{talk}} 13:37, 21 May 2016 (UTC)[reply]
For the record: this is probably dublicate and should be merged at phab. --Edgars2007 (talk/contribs) 16:31, 21 May 2016 (UTC)[reply]
@Edokter: That is a lie. It was I who proposed a patch for it, and you who blocked it. See phab:T104541 and gerrit:261723. That patch could still be merged if anyone wants to "discuss" it with Edokter. Last time I checked, this would work only in Opera 12, Internet Explorer 10 (and later) and Edge. Matma Rextalk 10:37, 22 May 2016 (UTC)[reply]
Both Firefox and Chrome were in the process of implementing these properties as well. Your pach was incomplete and inconsistent with other break-related mixins that were using the vendor prefixes; that was my only complaint. -- [[User:Edokter]] {{talk}} 11:49, 22 May 2016 (UTC)[reply]
Thank you all of you! It is a shame that the CSS "break-after" is not universally supported yet.--Quest for Truth (talk) 02:46, 23 May 2016 (UTC)[reply]
Interactive chess game viewer at VPR
Hi VPT,
There's an ongoing discussion about the development/implementation of an interactive chess board over in this thread at VPR. Basically, there's one being tested and another intended to be lighter-weight that just began development. I think the discussion(s) would benefit from some having some additional technically competent eyes, though it's kind of unwieldy to move to this venue (and it's a concept that has been brought up and momentum lost multiple times before, so I'm hoping to keep the inertia going by using the same thread). Thanks. — Rhododendritestalk \\ 12:56, 21 May 2016 (UTC)[reply]
Newly created articles needs to be double patrolled
I came across an ANI post, where one user is accused of patrolling pages without checking them properly. There are are many users with auto-confirmed rights who can patrol pages. Unpatrolled pages appear Yellow. Patrolled pages appear white in new pages list.
I suggest unpatrolled pages should appear Orange. If it's patrolled by one user it will appear Yellow, and then if second user patrols it, then only it will appear white. --182.66.9.122 (talk) 16:59, 21 May 2016 (UTC)[reply]
redirects have stopped appearing under "what links here"
As of today, when one clicks on "what links here", one no longer sees redirects. It is important to see those every time one wants to fixed links to "monestary", which redirects to the correct spelling "monastery" (when of course one doesn't know which redirects from unprintable links exist), and when one moves an article and wants to fix double or unprintable redirects. Can this be fixed? (The toggle button that says "show redirects" and "hide redirects" no longer has any effect.) Michael Hardy (talk) 20:08, 21 May 2016 (UTC)[reply]
PS: I see that one does see the redirect from "monestary" to "monastery", but one doesn't see redirects from former titles of pages that have just been moved. Michael Hardy (talk) 20:12, 21 May 2016 (UTC)[reply]
I think you need to give us the name of a redirect page which you think should be turning up, but is not. (Or explain what you mean by "one doesn't see redirects from former titles of pages that have just been moved.") I see a number of redirects - Monasteries, Nunnery, Monastery, all present and correct. --Tagishsimon(talk) 20:16, 21 May 2016 (UTC)[reply]
Possibly related to the OP's report, the number of redirects and number of 'Links to this page' don't seem to be shown. For the article Sky Tower (Auckland), see the page here. "Links to this page" and "Redirects" both show 0, but when the 0's are clicked, it's obvious that there are many links and redirects. Why are 0's showing? Akld guy (talk) 21:51, 21 May 2016 (UTC)[reply]
In short: if you move a page, you need to wait for the job queue to update the "what links here" tables before all redirs are listed. --Redrose64 (talk) 23:30, 21 May 2016 (UTC)[reply]
@Redrose64: But I created those Sky Tower (Auckland) redirects on 21 February. Are you saying it takes at least three months for the job queue to get around to updating? Akld guy (talk) 05:40, 22 May 2016 (UTC)[reply]
I've known the job queue take longer, I think six months. But in the specific case of this URL, it's not a job queue issue - that tool doesn't read the link table directly, it works from a database replication on tool labs, so what we're talking about here is more likely to be a replication lag (replag). Replags usually catch up, but occasionally periods of a few hours are lost entirely. The only fix for lost periods is to copy the whole database over again, and that takes weeks.
OK on the delay, :( thank you. That other tool worked on the Sky Tower article and a couple of others, so I've bookmarked it; it's going to be really useful, thanks much. Akld guy (talk) 09:07, 22 May 2016 (UTC)[reply]
I've known null edits help jolly things along on the what links here front. DuncanHill (talk) 18:34, 23 May 2016 (UTC)[reply]
They do on this site, but not sure if they propagate through to toollabs. --Redrose64 (talk) 20:17, 23 May 2016 (UTC)[reply]
Allow additional Preference options for watchlist pages that have changed? (Hard to distinguish little green dot from little blue dot)
In watchlist I find it difficult to tell the difference between the little green dot indicating a change in a watched page since last visit and the same size blue dots for watched pages that haven't changes after last visit, at least on my system, and I'm not sure bold is working or working well for me, so I'd suggest that Preferences allow some additional choices for marking pages with changes in watchlist:
use a much BIGGER GREEN DOT to indicate changes
use a GREEN SQUARE marker (bigger than the current green dot)
use a BIG RED dot
use a BIG RED SQUARE marker
General idea would be to use small marker for unchanged, big marker for changed. UnderEducatedGeezer (talk) 11:30, 22 May 2016 (UTC)[reply]
I think changing it to a square would be simple and easy to do. Also good for accessibility reasons.
But I'm against adding more choices.. Choice for something as minute a detail like this is why people have a personal stylesheet. You can change everything to your hearts delight. When people are talking about their watchlists these days, it's already a guessing game regarding which of the dozens of gadgets they have enabled that has caused 'something' to break. Don't think we need more. —TheDJ (talk • contribs) 13:55, 22 May 2016 (UTC)[reply]
Why not try these universally recognised symbols? ♠ ♥♣♦ The blue ♣ is to contrast better with the black ♠ but the ♦ may as well be red too, since it's more readily discermable from the ♥ than with ♠ and ♣. -- André Kritzinger (talk) 14:07, 22 May 2016 (UTC)[reply]
@TheDJ: I suppose most who have a watchlist use stylesheets, but I don't have or use one, so I don't know how to make that work. [Is there a way to make text here 'struck-out', with the text remaining but with a line through it? Strike-out following text, as Redrose64 told me how to address a response to a responder.](Also not sure how to indicate responses to specific individuals here. Should I interrupt the timestamped flow by putting responses directly under post I'm responding to after others have more quickly responded, or do it this way by trying to indicate who I'm responding to and maintaining the timestampedness? )UnderEducatedGeezer (talk) 22:54, 22 May 2016 (UTC)[reply]
/* [[Wikipedia:Village pump (technical)/Archive 113#Green bullets in watchlists]] */li.mw-changeslist-line-watched,li.mw-history-line-updated{list-style-image:url("//upload.wikimedia.org/wikipedia/commons/c/ce/ChangedBulletMono2.png");}
and save. If you use Vector skin, it would be pasted into Special:MyPage/vector.css but some of the code needs changing to suit the different skin. --Redrose64 (talk) 23:16, 22 May 2016 (UTC)[reply]
Ok, thank you Redrose64, I looked at the archived Wikipedia:Village pump (technical)/Archive 113#Green bullets in watchlists that you provided, & see that there was quite a discussion about it, but while I'm aware of the general concept of a 'skin' for a display, to apparently achieve a result of easier to perceive personal display of changed watchlist items, I don't use one as far as I'm aware, & don't have (or don't have one that I am aware of) a stylesheet, and just thought it would be easier for a user such as myself to select an option from Preferences than to go through setting up a stylesheet to get that result. UnderEducatedGeezer (talk) 02:02, 23 May 2016 (UTC)[reply]
@UnderEducatedGeezer: There are several ways of striking out text, these include the use of HTML tags, for example <s>like this</s> → like this or <del>like this</del> → like this; or a template such as {{strikethrough|like this}} → like this.
Everybody has a skin, it's set at Preferences → Appearance, first box; there are four options. If you've never altered that, and your account was created after about 2010 or so, it's almost certainly set to Vector (accounts created before about 2010 used MonoBook). On the same row are three links "Preview", "Custom CSS" and "Custom JavaScript" - the middle one of those is your stylesheet, which will be a redlink if you've not created one.
To get a preference set up, we can petition the developers (via phab:), and to get that through that takes anything ranging from months through years to never. We can set up a local gadget, which is much quicker (I've known one to be written, tested, installed and available to everybody inside a couple of hours), but we still need community consensus; there are quite a lot already, see Preferences → Gadgets, but most of them add features that are a lot more complicated than changing the style of a list bullet. But we do have one that might help to some extent here: under the second heading ("Watchlist") you may find something like "(D) Display green collapsible arrows and green bullets for changed pages in your watchlist, page history and recent changes (unavailable with the improved Watchlist user interface)" - enable that, and click Save. --Redrose64 (talk) 08:39, 23 May 2016 (UTC)[reply]
@Redrose64: Oh! Ok, I think I get it, better to try stylesheet if I want it any time soon, thanks for explaining it. So, using a vector stylesheet, is there some way to make just the bullets for items-changed bullets BIGGER? Preferences → Gadgets → Watchlist → '...green collapsible arrows and green bullets' just gives me the same tiny green-near-blue dots I've wanted to change to something I could see better.
Need developers
Ladies/Gents - I know you're sitting at home right now, probing Wikipedia, and looking for something to soften that boredom. You could work on an article about the 1968 Philadelphia Eagles season, but the tediousness of finishing the whole 1960s collection is just dragging on and on. Let me offer you a new opportunity! The Unblock Ticket Request System is looking to get some additional developers on board. Developers do not have to be administrators, but administrator tools will be required for SSH access and access to the live instance of the tool. Non-administrators can still develop with Github and will have access to UTRS-Alpha and UTRS-Beta. Specifically, we're looking for two associate core developers, a senior user experience developer, and a user interface developer. Specific requirements are listed on the link above, but we're looking for experience with HTML5, PHP, jQuery, CSS3, and bootstrap. Additional cross-platform experience, team management, object oriented design, and secure systems development experience is a huge bonus. Please send an application to utrs dash developers AT googlegroups dot com. We have big ideas and big plans for a v2.0 of the system and we're looking for some folks looking to do exciting work.--v/r - TP 03:15, 23 May 2016 (UTC)[reply]
User Contribution Search for I Hate Everything (YouTube channel)
The diff says no difference. The old revision is from March 2002. The first MediaWiki version is from 2003. Some things in older revisions can appear inconsistent. The source has 38 lines so there are 37 newlines if the last line doesn't end with a stored newline. The size difference is exactly 37 bytes so I guess the issue is one- or two-byte representation of newline. Just ignore it if it doesn't cause problems. PrimeHunter (talk) 18:53, 23 May 2016 (UTC)[reply]
Graham87 (talk·contribs) did a history merge at 04:33, 1 December 2011. These always give strange byte counts. --Redrose64 (talk) 19:53, 23 May 2016 (UTC)[reply]
Special:PermanentLink/721701133 (2261 bytes) has UNIX line breaks (one byte per line break) while Special:PermanentLink/171816 (2298 bytes) has DOS line breaks (two bytes per line break). You can check this by downloading the source (action=raw) using wget or a similar tool. --Stefan2 (talk) 22:27, 23 May 2016 (UTC)[reply]
Behaviour when undoing edits
I've just noticed a couple slight oddities when clicking "undo". Previously this would generate an automatic edit summary on the lines of "undid revision 1234 by Gubbins". The last couple of times I have used "undo" this has not happened - here. The second oddity is that it undid two edits at once (the two immediately preceding IP edits in the article history). I did want to undo them both, but wasn't expecting it to do both at once. I use Edge on Win10. DuncanHill (talk) 18:32, 23 May 2016 (UTC) (edited by me for some bizarre error on my part DuncanHill (talk) 18:42, 23 May 2016 (UTC))[reply]
The automatic edit summary works for me in Firefox. It works by prefilling the edit summary box. It's possible for the user to delete the prefilled text before saving but that has always been the case. Is the edit summary box empty for you right after you click "undo"? PrimeHunter (talk) 19:08, 23 May 2016 (UTC)[reply]
Yes, I didn't delete the auto summary, there wasn't one to delete. DuncanHill (talk) 19:12, 23 May 2016 (UTC)[reply]
Check your privileges. I suspect you're a rollbacker, since it looks like what you did was [rollback] rather than [undo]. -- André Kritzinger (talk) 19:29, 23 May 2016 (UTC)[reply]
I am a rollbacker, but I did not use rollback, I clicked undo. DuncanHill (talk) 19:59, 23 May 2016 (UTC)[reply]
The WP:ROLLBACK edit summary is prefilled (in the form "Reverted edits by User1 (talk) to last version by User2") and cannot be blanked or otherwise amended.
If you are viewing the diff of two or more consecutive edits, and click the "undo" link, the edit summary box always starts off blank, but may be amended. --Redrose64 (talk) 20:15, 23 May 2016 (UTC)[reply]
And as I did add an edit summary it is obvious I didn't use rollback. I didn't know that about using "undo" when viewing multiple diffs - is that a new thing? DuncanHill (talk) 20:21, 23 May 2016 (UTC)[reply]
It's been like that for as long as I've been around - seven years or more. --Redrose64 (talk) 20:40, 23 May 2016 (UTC)[reply]
I never use "undo" to revert more than one edit so didn't know this. That means our customized MediaWiki:Undo-success is problematic. It assumes there is only one edit and that there is a default summary. The interface messages used when undoing one or two edits both say "(undo-success)" so the same message is called with no parameter indicating one or multiple edits. This means I don't know a good fix. The MediaWiki default for MediaWiki:Undo-success says: "The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit." This also assumes there is only one edit but there is no reference to a summary so it's less important. The summary for undoing a single edit is made by MediaWiki:Undo-summary. Based on [3] there are no other relevant interface messages so I don't know whether it's possible to make any default summary for undoing multiple edits. PrimeHunter (talk) 21:16, 23 May 2016 (UTC)[reply]
While not a solution to the problem you bring up, perhaps our help page (WP:UNDO) should also be amended with an instruction to fill in the edit summary when undoing more than one edit.--William ThweattTalkContribs 22:03, 23 May 2016 (UTC)[reply]
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 now see a warning message on pages that try to use {{DISPLAYTITLE}} but it doesn't work because it doesn't match the page's actual title. [4]
Problems
Commons had problems with server lag. This meant that it took longer time for files to turn up in categories. [5]
Changes this week
The new version of MediaWiki will be on test wikis and MediaWiki.org from 24 May. It will be on non-Wikipedia wikis and some Wikipedias from 25 May. It will be on all wikis from 26 May (calendar).
Meetings
You can join the next meeting with the VisualEditor team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on May 24 at 19:00 (UTC). See how to join.
Future changes
All HTTP access to Wikimedia sites and APIs will stop working. Some bots still use HTTP. They will need to use HTTPS instead. This will happen on June 12. [6]
Suppose a non-admin would like to move a file, without leaving a redirect, to a new name listed on the title blacklist. This action requires tboverride, movefile, and suppressredirect, which means that the user needs the trio of page mover (extendedmover), file mover, and template editor, right? Do we know if this scenario is working for non-admin accounts in all 3 groups? Or has the MediaWiki backend been tested for this scenario? Just a curious thought. — Andy W.(talk ·ctb) 00:55, 24 May 2016 (UTC)[reply]
Yes, if you are a member of all three of these groups you can move a file, without a redirect, to a blacklist title. example here. — xaosfluxTalk 01:44, 24 May 2016 (UTC)[reply]
Insert Citation button missing from the editing toolbar
Hello, recently when I go to edit an article or create a new one, I find that the "insert citation" button is missing from the edit toolbar as seen here. I was wondering if this was a known issue or one unique to me. If it helps, I'm running Google Chrome version 50.0.2661.94 on WIndows 10.
Americanfreedom (talk) 04:31, 24 May 2016 (UTC)[reply]
The "Cite" menu (if that's what you're referring to) is to the left of the "Help" menu for me. Is it not to the left of the "Help" menu for you? — Andy W.(talk ·ctb) 04:46, 24 May 2016 (UTC)[reply]
You appear to be using RefToolbar 2.0a at Wikipedia:RefToolbar#Versions. With that I have two more icons in Firefox than your image: Between the book icon and "Advanced" are both a signature icon and the insert citation icon {{ }}. Have you tried to clear your entire cache? Have you tried RefToolbar 2.0b by enabling "Enable wizards for links, formatting, tables, citations, and the search and replace function" at Special:Preferences#mw-prefsection-editing? It gives a "Cite" button to the right of "Help" and another citation interface. PrimeHunter (talk) 10:07, 24 May 2016 (UTC)[reply]
Austrian_presidential_election,_2016 linked from Main Page, infobox broken
Could be something that I'm doing wrong, or intentional, but it looks like *even though* Van der Bellen is filled in as the elected president, the infobox is showing "Elected President" as blank. This seems like a highly visible issue; could someone take a look at it? Thanks :) Goldenshimmer (talk) 06:13, 24 May 2016 (UTC)[reply]
Hi, If you look at Teen_Choice_Awards#External_links there's a space between both templates - I've added both templates to my sandbox and it looks fine so I'm not sure if this is a bug or simply the article layout ?, Thanks, –Davey2010Talk 19:45, 24 May 2016 (UTC)[reply]
I've fixed it, but I have no idea why my edit worked! -- John of Reading (talk) 20:29, 24 May 2016 (UTC)[reply]
Haha neither do I, Thanks John of Reading - On the laptop it looks like a whitespace ... surely that's not the whole reason for the screw up ?, Thanks tho for fixing it - Much appreciated, –Davey2010Talk 20:53, 24 May 2016 (UTC)[reply]
The space was being taken as a paragraph, so the emitted HTML was
</table><p></p><table...
the two tables being the navboxes. If you see something like this again, use your browser's "View source" or "Inspect element" feature. --Redrose64 (talk) 00:02, 25 May 2016 (UTC)[reply]
The characterafter the first template was a Unicode "thin space". Unlike a trailing regular space which would be ignored by MediaWiki, the thin space is treated like normal text and placed in its own paragraph between the navboxes.
(In wikilinks, thin spaces are on the other hand treated similarly to regular space characters, and the markup [[ ]] doesn't result in a link, so you can't make an R from Unicode redirect for the character.) --Pipetricker (talk) 14:37, 25 May 2016 (UTC)[reply]
OK to switch English Wikipedia's category collation to uca-default?
Is anyone seeing this article as a redirect to an identically-named article? What exactly is going on here? Very confused. — Andy W.(talk ·ctb) 05:37, 25 May 2016 (UTC)[reply]
Can anyone verify that, for one of these articles, the first letter is a Greek "beta", but due to technical issues, renders as "B"? I really feel like this needs to be mitigated. — Andy W.(talk ·ctb) 05:39, 25 May 2016 (UTC)[reply]
Yes - the article, not the redirect, begins with a Greek capital beta, U+0392. The redirect is a normal capital B. —Cryptic 05:45, 25 May 2016 (UTC)[reply]
(edit conflict) The redirect target's title has "Β" (U+0392 GREEK CAPITAL LETTER BETA) as its first character. This character is homoglyphic to (looks basically the same as) B (U+0042 LATIN CAPITAL LETTER B) in many typefaces. Goldenshimmer (talk) 05:47, 25 May 2016 (UTC)[reply]
But that's ridiculous. Surely it ought to be either (all Latin) beta-lactamase or β-lactamase. βeta-lactamase is not a style corroborated by any source I can see. Propose move to beta-lactamase Intelligentsium 05:51, 25 May 2016 (UTC)[reply]
It seems to have been moved recently from the correct title β-lactamase to βeta-lactamase. Intelligentsium 05:54, 25 May 2016 (UTC)[reply]
I proposed the move. I also think that the one with the Greek letter beta should be deleted. (including a number of redirects that seem iffy as well. — Andy W.(talk ·ctb) 05:55, 25 May 2016 (UTC)[reply]
@Intelligentsium: Yes, I made the move you mentioned, but couldn't figure out how to resolve some of the double redirects (about half an hr ago). — Andy W.(talk ·ctb) 05:57, 25 May 2016 (UTC)[reply]
Ah yes. I do agree beta-lactamase is a better title per Wikipedia:Naming conventions (use English) but I think the redirect at β-lactamase should remain as it is a style frequently used in the literature and thus would be a common search-term. Intelligentsium 06:00, 25 May 2016 (UTC)[reply]
I don't think there's any particularly compelling need to change the styles from how they are currently used to conform to one or the other, as both are widely used in the literature. In fact, from a Google Scholar search it appears there are more hits for the Greek β-lactamase than the Latinized beta-lactamase. In that case the old title might be more appropriate after all. Intelligentsium 06:25, 25 May 2016 (UTC)[reply]
It has been undone, and redirects are fixed. I think it's more in-line with things like Beta-carotene and beta-Carboline in generally the same topic (although we still have β-Lactamase inhibitor)... <-- I'm gonna think about this one. Definitely didn't intend to get this deep into the issue when I just wanted to fix some DISPLAYTITLES. — Andy W.(talk ·ctb) 06:54, 25 May 2016 (UTC)[reply]
What links here and a talk page redirect
I've run into an interesting situation that probably has been mentioned before, but my admittedly quick search didn't find.
SummerPhDv2.0's old talk page at User talk:SummerPhD is a redirect to the current talk page. This redirect causes (I think) unintended behavior in the "What links here" area for all articles links on the redirected talk page. For example, spin-off should have only about 295 incoming links from all namespaces. Instead, it has over 13,000 incoming links because of the 12,845 pages that have a link to User talk:SummerPhD (all of the various pages where a signature owas left). The issue is that for those of us that use semi-automated tools, all of those extra incoming links cause the page to load much slower than it normally would.
Does anyone have an idea how to leave the redirect alone (so that anyone clicking on an old signature still goes immediately to the correct talk page) and to get rid of all of the entries in the various "What links here" areas? -NiceguyedcGo Huskies! 06:33, 25 May 2016 (UTC)[reply]
Where are you getting 13,000 links? Special:WhatLinksHere/Spin-off has 306 entries for me. When I click "500" the list is complete. If some tools get confused by User talk:SummerPhD being a redirect and also linking to pages it doesn't redirect to then the obvious quick solution is to archive the talk page somewhere so the redirect has no other text. Ideally, the tools should be coded to avoid such confusion. PrimeHunter (talk) 10:38, 25 May 2016 (UTC)[reply]
Comment - I don't quite understand what the technical issue is, but I have no objection whatever might need to be done to correct this. I'd like to keep my archives and, of course, clean navigation from old links to my new pages. Thanks. - SummerPhDv2.0 13:29, 25 May 2016 (UTC)[reply]
Numeric ID
I'm sure every username is assigned a unique numeric ID in wikimedia projects. I searched previous archives of the technical village pump and found this relevant disscussion. My question is how to find that numeric id? I want to make a random selection between two candidates who ended up in a tie in a Persian Wikipedia election. Thank you 4nn1l2 (talk) 07:56, 25 May 2016 (UTC)[reply]
Yes, my ID is also different here and at my home Wikipedia. This ID doesn't have to do anything with SUL. --Edgars2007 (talk/contribs) 08:39, 25 May 2016 (UTC)[reply]
Alternatively, go to Special:Export and export a page that the user has edited. The account numbers of all users who have edited the page appear in the XML code. Doesn't work for users without live contributions. --Stefan2 (talk) 12:28, 25 May 2016 (UTC)[reply]
@Redrose64: Thank you, that is a clean and nice way, but it only gives my user ID. How can I obtain another user's ID? I don't see any parameter to specify the username in your code, whereas PrimeHunter's code has such a parameter, namely &aufrom=Edgars2007. User:PrimeHunter's code has a downside. It lists all similar usernames including sockpuppets which are sometimes derogatory, for example: https://fa.wikipedia.org/w/api.php?action=query&list=allusers&aulimit=1&aufrom=Mardetanha4nn1l2 (talk) 15:49, 25 May 2016 (UTC)[reply]
My API call only shows the next user in alphabetical order. PrimeHunter (talk) 16:14, 25 May 2016 (UTC)[reply]
This is a screenshot of a notification for the Archive.is RFC, showing I was pinged in a discussion. The blue link does not go to the RFC in question. Rather, it goes to RFC 4, the real one on the internet. Clicking anywhere else gives me the right page. This is bizarre and unexpected behavior for the end user. Everywhere else on Wikipedia we are told to click on the blue links to get to the page we want, and here it throws you for a loop. Another example of this auto linking behavior may be found on this very page at #Wikipedia:Archive.is RFC 4. I do not remember adding any scripts or checking any preferences that would cause this. Pinguinn🐧 17:01, 25 May 2016 (UTC)[reply]
GiantSnowman 15:03, 13 May 2016 (UTC)
-- Ohc ¡digame! 17:13, 16 May 2016 (UTC)
Resolved
The new version of MediaWiki will be on test wikis and MediaWiki.org from 24 May. It will be on non-Wikipedia wikis and some Wikipedias from 25 May. It will be on all wikis from 26 May (calendar).
All HTTP access to Wikimedia sites and APIs will stop working. Some bots still use HTTP. They will need to use HTTPS instead. This will happen on June 12. [6]
Fixed. --Edgars2007 (talk/contribs) 06:44, 24 May 2016 (UTC)
![[7]](https://archive.org/download/ScreenShot20160524At02.10.25.09000.0400/Screen%20Shot%202016-05-24%20at%2002.10.25.09000.-0400.png){kind=link}
![[8]](https://archive.org/download/ScreenShot20160524At02.10.25.09000.0400/Screen%20Shot%202016-05-24%20at%2002.12.37.39800.-0400.png){kind=link}