Wikipedia:Village pump (technical)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

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

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

Newcomers to the technical village pump are encouraged to read these guidelines prior to posting here. Questions about MediaWiki in general should be posted at the MediaWiki support desk.

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

August 4 Echo changes

Echo icons still backwards

I see echo has been updated with the new icons as mentioned by Whatamidoing (WMF) (talk · contribs), but the icons are still wrong in my perspective, and it's irritating because it always misleads, and the new ones even more so. I get alerts in what appears to be an inbox, and new messages in the alerts section. When I'm on another wiki, I always need to think about it when my bell lights up. Can these please be switched, or provide an option to switch them in echo?—^cyberpower_{Chat:Limited Access} 19:20, 4 August 2016 (UTC)

What are you seeing in each section, and what do you think should be in each section? Whatamidoing (WMF) (talk) 21:05, 4 August 2016 (UTC)

Well the right one, the resembling an inbox, should be for messages and mentions, while the left, the bell, for alerts like thanks, page links, etc... In other words exactly flipped around.—^cyberpower_{Chat:Limited Access} 21:11, 4 August 2016 (UTC)

@Cyberpower678: The sorting was reorganized a while ago using the criteria of "urgency" - bucketed into Alerts and Notices - because editors want a clearer insight into whether they need to distract themselves from their current task. I.e. Notification types that we are more likely to want to see immediately, are in the Alerts section now. The background and research is at phab:T123018 and m:Research:Notifications user survey. The clearest overview is mw:Help:Notifications/Notifications types. The new tray icon isn't perfect for making this intuitive, but no better alternatives could be found (phab:T135114). Hopefully this explanation and a little bit of time, brings familiarity and clarity. :-) Quiddity (WMF) (talk) 22:25, 4 August 2016 (UTC)

Unfortunetly, for me, seeing the inbox light up flags as more urgent to me as the bell on occasion forgetting that it actually had a message. Missed a few mentions that way.—^cyberpower_Chat:Offline 04:16, 5 August 2016 (UTC)

@Whatamidoing (WMF) and Quiddity (WMF): I agree that the icons are pretty obviously backwards. One of the icons is an in-box, but this is where you get non-message notifications. The other icon is a notifications/alert icon (a bell), but it functions as a message in-box. The paradigms for these are pretty much universal. Every site has an alerts/notifications icon and a messages icon. We also have these but are using them the opposite of how every other site does. Look at Twitter, Facebook, LinkedIn, or pretty much any website with an account system. Kaldari (talk) 04:29, 5 August 2016 (UTC)

+1 - It's extremely confusing to have talkpage notices & pings in the bell and thanks in the "box", Ideally it would make sense to switch them around, –Davey2010^Talk 09:48, 5 August 2016 (UTC)

• So with a unanimous discussion so far, can these be flipped?—^cyberpower_{Chat:Limited Access} 20:52, 5 August 2016 (UTC)

Some good points are raised; thanks everyone. Although just flipping the icons may seem like a solution, I don't think it gets us where we need to be. A number of factors are involved in this discussion, including the interplay of the icon design and the sorting scheme overall. The new sorting scheme was designed to answer users' complaints, and we did our best to get user input to the various ideas put forward for solutions, but the issue is complex. We will look back at the research that was done, discuss the issue and get back to you. The team is occupied with other pressing business right now, so please don't expect an instant response. Plus, as Quiddity suggests, the new system might grow on you. Thanks for your feedback and patience. JMatazzoni (WMF) (talk) 21:33, 5 August 2016 (UTC)

Not sure if we'd want to stick with the bell & brassiere icons long term, but their functions seem to be understandable. Dl2000 (talk) 21:58, 5 August 2016 (UTC)

Actually flipping them around is the simple solution. One doesn't use an inbox icon for non-message related notifications, you use a bell and call them alerts. Conversely, the bell is only for messages, right now. A thank you is an alert. A page link is an alert. A mention is a message. A talk page message is a message. Messages go in an inbox. Or at least give us an option in preferences that allows us to switch them globally. But I've been irritated about this since the initial change was made. What research, btw? I'm not aware of any. Where was the user input?—^cyberpower_Chat:Online 08:12, 6 August 2016 (UTC)

Personally I disagree with flipping them around, it never confused me, though I suppose if you focus on the icon rather than the color, it can be confusing to some. nyuszika7h (talk) 10:35, 8 August 2016 (UTC)

My focus is on the icon and not the color. Maybe providing an option to flip them around is the best, or categorizing yourself which icon they should appear under is the best solution. I see that the best solution is to let the user decide which icon they should appear under. That way everyone is happy.—^cyberpower_Chat:Online 11:25, 8 August 2016 (UTC)

Thread bump. Any update on this?—^cyberpower_{Chat:Limited Access} 18:28, 12 August 2016 (UTC)

@Whatamidoing (WMF), Quiddity (WMF), and JMatazzoni (WMF): Can you show me the research that JMatazzoni mentions? When I was on the Echo team, we did extensive research on notification best practices (which we shared with the community here). According to our research, the most common practice is to have a "notifications" feed and a "messages" feed. This was true of every platform we looked at except for Twitter, and now Twitter also follows this practice. On Wikipedia, mentions and talk page posts would logically fall under "messages", while everything else would fall under "notifications". Our plan was to implement just that, but as soon as we finished the first version of Echo the team was transitioned to Flow and we never got to build the messages feed. Kaldari (talk) 19:28, 12 August 2016 (UTC)

@Kaldari and Cyberpower678: The research links were given further up (phab:T123018 ("Revise Sorting of Notifications on the Fly-Out Menus") and m:Research:Notifications user survey) and feedback was requested in a few issues of Tech/News, plus a message to the wikitech-ambassadors mailing list which resulted in announcements at metawiki and elsewhere, and the survey was linked from the bottom of the notifications panel at all English wikis for a couple of weeks (for editors who had >2 unread notifications) (phab:T128937)

For moving forward, Pau has been thinking about the scenario of potentially merging the two panels back together; see notes and mockup in phab:T142981. Feedback welcome.

Overall, it is a complicated problem because we all have different usage scenarios and preferences; Ideally we could each pick-and-choose what happened to each notification - but that would vastly increase the complexity of the technical aspects (code and database) particularly due to cross-wiki notifications, as well as the usual problems with adding more preferences (I wrote an essay about it..). So, more pragmatically, we (all) have to consider how much effort and complexity needs to be invested in this feature, and whether we can come to any sort of consensus as to a [good/sensible/default/single/global] method of sorting notifications, instead of going to the extreme complexity of personalization. I recommend reading the editor comments in phab:T123018, at minimum, to understand why "urgent vs non-urgent" was used as the current sorting method. Feedback welcome there, too (ideally on phabricator, so that it's a global discussion). HTH. Quiddity (WMF) (talk) 00:15, 16 August 2016 (UTC)

I have no issues with the current sorting, just that the icons are backwards. The letter tray in this case for me is urgent, while the bell is not. That's my primary problem. The simple solution is to simply flip them around so they make more sense.—^cyberpower_Chat:Online 11:26, 16 August 2016 (UTC)

Echo bell icon glitch

My echo icon, or one of them, has an odd glitch. On all pages apart from prefs it has a light grey (#b0b0b0) rectangle over its upper half. Just the left most bell icon. It’s half the icon’s height, wider so I presume as wide as its clickable area. It disappears as I mouse over the icon. It also disappears on my Preferences and Beta pages, but is visible everywhere else (and I tried a wide variety of pages). I have no outstanding notifications, have had since the new icons appeared.--JohnBlackburne^words_deeds 20:14, 4 August 2016 (UTC)

Can you see if it is in the same location regardless of your window size? — xaosflux ^Talk 20:16, 4 August 2016 (UTC)

If I narrow the window enough that line (user icon ... Log out) smoothly wraps onto two lines, but the grey rectangle stays attached to the icon throughout.--JohnBlackburne^words_deeds 20:19, 4 August 2016 (UTC)

Ah, my own darn fault. fixed.--JohnBlackburne^words_deeds 20:28, 4 August 2016 (UTC)

Notification icons

My notification icons

Nyttend's notification icons

Are the new notification icons supposed to look like this? If not, is there anything I can do about it? Tevildo (talk) 20:21, 4 August 2016 (UTC)

@Tevildo: This alignment is a bug with some versions of IE, when using monobook. See phab:T142053 for details. It should be fixed by next Thursday (following the standard deployment schedule). Quiddity (WMF) (talk) 21:47, 4 August 2016 (UTC)

Thanks for the information - it's not a serious problem. Looking forward to the fix, though. Tevildo (talk) 22:14, 4 August 2016 (UTC)

@Quiddity (WMF): Here's what I have. This is with Firefox browser, MonoBook skin. The figures are so tiny they're unreadable, and the contrast (black on colour) is poor too - I can only just make out that there's a character there, which I'm guessing is a figure. When we first got the icons, the contrast was good, as it used white figures on a dark-coloured background, and the figures were large compared to the links at either side - I think they were boldfaced too. I could fix this by working out the CSS rules (yet again) that would make it readable for me, but I shouldn't need to. This is an accessibility issue. --Redrose64 (talk) 22:33, 4 August 2016 (UTC)

Filed as phab:T142149. Thank you for the screenshot and report :) Quiddity (WMF) (talk) 22:49, 4 August 2016 (UTC)

Thanks very much! Since I use IE with Monobook, I came here to ask about the situation, not because of what's mentioned here, but because the icons are overlapping the "watch" tab; it's still possible to click it, but it takes a good deal more concentration (annoying), and things shouldn't generally overlap each other (bad design). Nyttend (talk) 01:00, 5 August 2016 (UTC)

@Nyttend: That one is filed as phab:T141942. Skins! I love 'em, regardless of the complexities they cause. (Which pale in comparison with browser quirks...) Quiddity (WMF) (talk) 01:04, 5 August 2016 (UTC)

Quiddity, see the screenshot I just added; I'm really not familiar with the Bugzilla process (so much that I can't remember the new name), so I'll leave it to you to decide what (if anything) to do with my screenshot. Something has changed, both here and at Commons, because the "watch" button isn't being obscured on mainspace or filespace pages. Nyttend (talk) 01:39, 5 August 2016 (UTC)

The fix is: Stop using Internet Explorer and use a superior browser. Lugnuts ^{Dick Laurent is dead} 07:03, 5 August 2016 (UTC)

^ This. Who uses IE these days. :p—^cyberpower_Chat:Online 08:17, 5 August 2016 (UTC)

Does IE still exist ? .... Thought it had died years ago! }. –Davey2010^Talk 09:51, 5 August 2016 (UTC)

I've written a patch that fixes the IE+Monobook issue, and I'll try to get it reviewed today and deployed on Monday. I'll post an update here when it's been rolled out. --Roan Kattouw (WMF) (talk) 18:10, 5 August 2016 (UTC)

@Roan Kattouw (WMF): The icons moved to the correct position on Tuesday (August 9), but today (August 11) they've now moved up off the top of the screen. I can provide another screenshot if it would help. I suspect that two patches have been applied to fix the same problem, with an additive affect. I would suggest that one (BUT NOT BOTH) of them should be reverted. Thanks in advance. Tevildo (talk) 20:28, 11 August 2016 (UTC)

@Tevildo: I see it, looks like this affects IE 11 and below (but not Edge) in Monobook only. Looking into it now. --Roan Kattouw (WMF) (talk) 22:52, 11 August 2016 (UTC)

I've found the cause and submitted a patch, it should be deployed shortly (probably 5-15 mins). I'll update here once it's deployed. --Roan Kattouw (WMF) (talk) 23:31, 11 August 2016 (UTC)

@Tevildo: The patch is deployed, and it looks fixed to me (using IE11 in Monobook). --Roan Kattouw (WMF) (talk) 00:47, 12 August 2016 (UTC)

Yes, looks good here as well. Thanks! Tevildo (talk) 06:56, 12 August 2016 (UTC)

@Quiddity (WMF) and Roan Kattouw (WMF): OK, I gave up waiting for the accessibility fix, so I put together some CSS rules which may benefit other people. They go in m:Special:MyPage/global.css and affect all Wikimedia sites. In this context, alert is the bell one on the left, which is normally black on pink, and notice is the car door one on the right, normally black on light blue.

/* Make the notifications counters a bit more noticeable. White on red for alerts where at least one is unseen */
#pt-notifications-alert .mw-echo-notifications-badge.mw-echo-unseen-notifications::after,
#pt-notifications-alert .mw-echo-notifications-badge.oo-ui-flaggedElement-unseen::after {
  background-color: #D11813; /* Vector's colour instead of MonoBook's #DEA4A2 */
  color: white;
}
/* White on blue for notices where at least one is unseen */
#pt-notifications-notice .mw-echo-notifications-badge.mw-echo-unseen-notifications::after,
#pt-notifications-notice .mw-echo-notifications-badge.oo-ui-flaggedElement-unseen::after {
  background-color: #0D5EF2; /* MonoBook's #B7CFFB reduced to 50% lightness */
  color: white;
}
/* Red on white for alerts which have all been seen (not necessarily marked as read) */
#pt-notifications-alert .mw-echo-notifications-badge::after {
  font-size: 1em;
  background-color: white;
  color: #D11813;
}
/* Blue on white for notices which have all been seen */
#pt-notifications-notice .mw-echo-notifications-badge::after {
  font-size: 1em;
  background-color: white;
  color: #0D5EF2;
}

There are four rules, one for each principal combination. The idea is that if you've seen them all, the figure is dark on white, coloured appropriately (red or blue), see first screenshot; but when the alert or notice counter is increased, indicating a new notification, the colours flip to white on dark, attracting your attention, see second screenshot. This is the converse of the present arrangement where an unreadable black figure on pale background is supposed to be the attention-getter, but is less noticeable than the white-on-grey "you've seen all of these" figure. The font-size: 1em; declaration makes one heckuva difference to readability, and although it is in only two of the four rules, it's specific enough to affect all four combinations. --Redrose64 (talk) 19:40, 14 August 2016 (UTC)

@Redrose64: Apologies for the delay. I have some tweaks to the badge styles sitting in code review, including a change to font-size: 0.9em;. If all goes well they'll roll out next week; they missed the boat for this week's deployment, unfortunately.

As for the color tweaks, I think white text on a darker background is a good idea, we already use that in Vector anyway. I can write a patch that applies those changes; the only thing I'm confused about is where you say that #D11813 is the Vector color; it's #CC3333 AFAICT. Also, #0D5EF2 looks very similar to what Vector uses for unseen notices (#3366CC), so perhaps we could just have Monobook use the same colors as Vector? (i.e. #C33 for alerts and #36C for notices)

I think the colored text when things are seen is a neat idea, but I'm not that enamored with the white background. You may also be interested in this idea which would merge the two badges and present the alerts/notices distinction differently. --Roan Kattouw (WMF) (talk) 00:17, 17 August 2016 (UTC)

I've boldly gone ahead and submitted a patch for code review that changes the Monobook color scheme to the Vector color scheme. --Roan Kattouw (WMF) (talk) 00:45, 17 August 2016 (UTC)

@Roan Kattouw (WMF): I've added two screenshots above to illustrate what my CSS blob does for me. The only remaining issue is that the figure uses a blurred font, rather than the sharp-edged font used in the rest of MonoBook (as seen with the Redrose64 and talk links on either side of the notifications in my screenshots). --Redrose64 (talk) 09:28, 17 August 2016 (UTC)

Excessive whitespace

Icon spacing before and after this CSS is used

Is there meant to be so much whitespace around the icons? I used the following code to reduce it:

/* ADJUST NOTIFICATION SYMBOL SPACING */
#pt-notifications-notice { margin-left:1px !important; padding-right:4px !important;}
#pt-mytalk {margin-left:0 !important;}

(add to Special:MyPage/common.css; you can play around with the numbers to suit your personal preference) - Evad37 [talk] 02:01, 5 August 2016 (UTC)

Thank you. Your changes make it look better, but I would recommend putting it in the global CSS. :p—^cyberpower_Chat:Online 08:11, 5 August 2016 (UTC)

Good idea! (btw, that's m:Special:MyPage/global.css for anyone else reading this) - Evad37 [talk] 09:03, 5 August 2016 (UTC)

Icon spacing with User:Evad37's CSS, with the notification counts set to 99+.

I'd be happy to put styles that put the badges closer together in the Echo software, but do take into account that there can be a number on the badges, and that number can be long (double digits, or "99+" in extreme cases). Because we couldn't figure out a way to make the badges take up more space automatically when the number is longer (without ruining the rest of the layout), there needs to be some buffer for the number to grow into. With your CSS and the number "99+", the badges don't look good. (To fake this yourself in the web inspector, remove the mw-echo-notifications-badge-all-read class and then modify the data-counter-text attribute.) --Roan Kattouw (WMF) (talk) 17:27, 5 August 2016 (UTC)

I think they look fine that way. It gives it a more natural look.—^cyberpower_{Chat:Limited Access} 20:51, 5 August 2016 (UTC)

66 alerts and 99 notices with my CSS

I think the reducded spacing is still fine for two digits, its really when the numbers get above 99 that the extra space is needed. @Roan Kattouw (WMF): could the software adjust the spacing based on the number of notifications? just reread your comment - Evad37 [talk] 23:58, 5 August 2016 (UTC)

What the badges look like with Roan's patch

We actually just made a change (which will be deployed on Thursday) that would make it easier for the width to be dynamic, but another problem with that (as a coworker reminded me) is that the popup with the list of notifications is anchored from the badge, so then when you mark a notification as read and the counter goes from 10 to 9, everything in the personal toolbar moves over and the popup moves too (because its anchor point moves). You can try this by going to beta labs and putting .mw-echo-notifications-badge { padding-right: 24px; width: auto !important; } in your user CSS.

That said, we can still reduce the spacing a bit, so that "99+" just barely fits (it's uncommon anyway). I've submitted a patch that does the equivalent of .mw-echo-notifications-badge { width: 24px !important; } .mw-echo-notification-badge:after { left: 50% !important; }. I've put some screenshots of that on the right. I'll try to get that patch reviewed on Monday so it can included in Thursday's deployment. --Roan Kattouw (WMF) (talk) 01:13, 6 August 2016 (UTC)

New alert pictures

Is it possible to replace the ghastly new alert pictures at the top of the screen (an alarm bell and whatever the other thing is) with the old ones, by adding a line to my .css page? (Please note, I am totally technically illiterate - someone did my .css for me.) zzz (talk) 04:19, 6 August 2016 (UTC)

I believe that's supposed to be a letter tray like seen in these images. EvergreenFir (talk) 04:26, 6 August 2016 (UTC)

Looks like a car door to me. --Redrose64 (talk) 09:21, 6 August 2016 (UTC)

I see the front of a bus or tram. And they are much too dark. My eye is aware of them all the time when it shouldn't be. If these are to be kept, the inactive state should be a paler shade of gray.

—Trappist the monk (talk) 10:45, 6 August 2016 (UTC)

Given the context it's clearly a letter tray, or a message inbox. :p—^cyberpower_Chat:Online 17:00, 6 August 2016 (UTC)

I think it looks like a bikini top... Tevildo (talk) 17:46, 6 August 2016 (UTC)

After having moused over it, it looks like the "Your notices" icon to me. (In other words, I don't care much what it looks like, as long as I know what it's for.) ―Mandruss ☎ 19:22, 6 August 2016 (UTC)

Resembling as a letter tray for messages, it alerts you to thank yous, page links, and all other non-message stuff. While the bell only alerts you to messages. :p—^cyberpower_{Chat:Limited Access} 20:28, 6 August 2016 (UTC)

The new icons are a regression. It's hard to tell when you have new messages/alerts now (why are the icons always dark rather than being translucent when there is nothing there?). The old design was easier to read. ViperSnake151  Talk  16:52, 12 August 2016 (UTC)

See I'll ping these WMF members - @Quiddity (WMF):, @Roan Kattouw (WMF): and @Whatamidoing (WMF): who have been involved in the echo discussions. As per what I read above most users oppose the new echo system. When I joined Wikipedia (around 19th may 2016) there used to be 2 icons - one bell and one notifications. The bell used to house all mentions and page reviews. While the notifications housed talk page messages. That system was the best and liked by everyone. Then errors started in it they kept reversing and it was first reported by User:Cyberpower678 over here. Now as per above consensus we can have a panel very similar to Twinkle's to set our Echo preferences. VarunFEB2003 ^{I am Offline} 14:19, 13 August 2016 (UTC)

Consolidation and convergence

The icons being discussed here are called alerts and notifications. Conceptually, these seem to be similar to other entries in the line at the top of the screen – Talk and Watchlist. To me, the equivalence is

Alert — Watchlist

Notification — Talk

Perhaps these could be brought together by putting them together in the top line? There are also other similar features like the Geonotices and discussion links which serve a common purpose in letting me know that something is going on. Some convergence and consolidation of these features might help too. Andrew D. (talk) 10:09, 8 August 2016 (UTC)

Spacing in monobook

In vector the spacing looks OK, however monobook the new icons appear to be "top aligned" and rise higher than the rest of the line. Any site-wide hints to fix? — xaosflux ^Talk 13:36, 14 August 2016 (UTC)

In vector they are not so high. — xaosflux ^Talk 00:51, 17 August 2016 (UTC)

I believe this was done in reaction to feedback that monobook, with its very slim height for the personal-bar, needed to extend down into as little additional space as possible. The icons and numbers do extend above and below the same amount in Vector, but the entire personal bar in Vector has more height, hence it looks less noticeable. There were also some Internet Explorer related issues with alignment, which might be involved? A quick test, shows you can tweak the top of the icons lower like so. I'll pass it along to the devs, in case this is an easy cross-browser-compatible solution. Quiddity (WMF) (talk) 18:54, 18 August 2016 (UTC)

Fixed in next update. Quiddity (WMF) (talk) 21:37, 19 August 2016 (UTC)

New bolding in watchlist (resurrected)

Restored from 2 August premature archive. Problem remains unresolved. At least one editor has stated that they like the change. To prevent more premature archiving, I am adding a DNAU template to prevent another archive for one year, and that can be removed when this issue is resolved. ―Mandruss ☎ 20:35, 5 August 2016 (UTC)

Firefox 47.0.1. Less than an hour ago, my watchlist started bolding unvisited page title links, where previously there was just a subtle color difference and no bolding. I have cleared history and cache and restarted Firefox, don't know what else I could do on my end. Anyone else seeing this? ―Mandruss ☎ 21:19, 21 July 2016 (UTC)

@Mandruss: Did you recently change any of your gadget settings? Under Gadgets -> Watchlist there is a setting that will "Display pages on your watchlist that have changed since your last visit in bold". Is that checked? If not, check it, save, uncheck, and resave, and see if it fixes it. --Majora (talk) 21:24, 21 July 2016 (UTC)

Did you recently change any of your gadget settings? No, not in many moons. The option was unchecked, so I did what you suggested. No change. ―Mandruss ☎ 21:26, 21 July 2016 (UTC)

I'm having the same phenomenon, the same version of Firefox. Nothing changed on my end. But in the last hour or two, the bolding got so bold on the unvisited ones that it's blurry. It's big and thick and very dark and blurry. Only the link title is that way, not the rest of the info on the item. My gadget on Preferences is also not checked. What happened? — Maile (talk) 21:37, 21 July 2016 (UTC)

It's beginning to look like it might be a Firefox problem. I saw the change around the time that Firefox said it had automatically downloaded 47.0.1, albeit before I restarted Firefox to install it. I don't understand how the download could have introduced the problem, but then I know nothing of the internals. If it's Firefox, I'd expect a 47.0.2 very soon. ―Mandruss ☎ 21:42, 21 July 2016 (UTC)

I've had Firefox 47.0.1 for a couple of weeks now. By default of any other postings here, it's probably Firefox. But who knows. It's really distracting. And just confirming that I do not have this same problem in I.E. — Maile (talk) 21:48, 21 July 2016 (UTC)

I assume that the bolding has something to do with the was Firefox handles CSS scripts. I'm not seeing the issue on Chrome so it is probably a problem on their side. I believe you can override it. WP:CUSTOMWATCH has instructions on how to make it bold. I'm guessing you would just replace, "font-weight: bold;" with "font-weight: normal;" --Majora (talk) 21:47, 21 July 2016 (UTC)

Am seeing the same myself in Chrome, Firefox, IE and Edge. Do not have the option selected in prefs. Have tried selecting it and deselecting it. No difference. Nanonic (talk) 21:49, 21 July 2016 (UTC)

Not seeing it in Edge or IE, no other browsers to test. ―Mandruss ☎ 21:55, 21 July 2016 (UTC)

Has now stopped in both my Edge and Chrome but still in IE and FF. Odd! However when I refresh the page in Chrome, I can see it bold the 'unread' entries during page load before putting them back to normal when rendered. Nanonic (talk) 22:00, 21 July 2016 (UTC)

I've always experienced that in Chrome. I just assumed there was some Javascript at work that took a little longer to load. clpo13_(talk) 22:04, 21 July 2016 (UTC)

I think I've always seen that in Firefox, but the bolding was turned off so quickly that I barely noticed it. So the hypothesis would be that whatever was turning it off is no longer working. No idea what that is, or why it would suddenly stop working. ―Mandruss ☎ 22:19, 21 July 2016 (UTC)

It's CSS. The MediaWiki software comes with bolding and no builtin option to remove the bold. The English Wikipedia removes bolding in MediaWiki:Gadget-WatchlistBase.css, a gadget enabled by default and saying "(This loads the base style for the watchlist. Please do not disable this option.)" Another gadget MediaWiki:Gadget-WatchlistChangesBold.css can then override the first gadget and make bolding again with "Display pages on your watchlist that have changed since your last visit in bold (see customizing watchlists for more options)". For some reason the first gadget is failing. I tried a dummy edit of MediaWiki:Gadget-WatchlistBase.css with no effect. It works in Firefox 47.0.1 if I load it using withCSS: https://en.wikipedia.org/wiki/Special:Watchlist?withCSS=MediaWiki:Gadget-WatchlistBase.css. But it fails if I just have it enabled in gadgets and disable the bolding gadget. The English Wikipedia got mw:MediaWiki 1.28/wmf.11 three hours ago so something there may have triggered the issue. PrimeHunter (talk) 22:31, 21 July 2016 (UTC)

(edit conflict) I'm experiencing this problem as well, Firefox 47.0.1 and briefly on Chrome 52. Interestingly enough, I tried Majora's suggestion above regarding the watchlist gadget and the bolding went away, but only in Chrome. Firefox still has it. clpo13_(talk) 22:04, 21 July 2016 (UTC)

I also am seeing the same bolding effect, started in the last hour or two. I am using Iceweasel 24.4.0, and have not recently tweaked any of my settings there or on WP. (Just got a new pair of glasses, but surely that is not a factor.) ~ J. Johnson (JJ) (talk) 23:12, 21 July 2016 (UTC)

Me too. Started up this afternoon. I thought perhaps I had just loaded the page funny (sometimes clearly caches and what not fixes things like this) but apparently its still happening. I haven't tweaked any of my watchlist settings, and I am not happy about the bolding, although if it helps I have noticed that only pages I haven't directly edited are being bolded on the watchlist, those pages that I have edited and still have the current for are not bolded. Not sure what that means, but I am willing to take it. For the record, I am contributing using Firefox and I am fairly certain its the most recently available one. TomStar81 (Talk) 01:26, 22 July 2016 (UTC)

Incidentally, I just noticed that its also on the recent changes page for those items I have on my watchlist. Not sure how that happened, but its happened. TomStar81 (Talk) 02:56, 22 July 2016 (UTC)

The bolding is of watched pages that have been changed since you last visited them. I don't know why MediaWiki:Gadget-WatchlistBase.css fails as a gadget but the bolding can be removed by importing it in your common JavaScript:

importStylesheet('MediaWiki:Gadget-WatchlistBase.css'); // Linkback: [[MediaWiki:Gadget-WatchlistBase.css]]

With this, bolding will be determined by the gadget "Display pages on your watchlist that have changed since your last visit in bold". PrimeHunter (talk) 10:33, 22 July 2016 (UTC)

@PrimeHunter: Thanks for helping with this, as always. Before deciding whether to fix this locally, I would like to know the prospects for a site fix that would make that unnecessary. Is anyone looking at this? If not, is there a way to get them to, such as phab? ―Mandruss ☎ 10:51, 22 July 2016 (UTC)

My guess is it will soon be fixed but I don't know where or by whom. I only know what is written here. Many people with CSS and MediaWiki knowledge watch this page, it has only been 14 hours where many users are not active, and so far a problem is only known to exist with a locally made gadget so I wouldn't take it to phab now. PrimeHunter (talk) 11:10, 22 July 2016 (UTC)

Ok. I'll wait. ―Mandruss ☎ 11:21, 22 July 2016 (UTC)

It appears that gerrit:288026 has somehow changed the loading order of modules, so the module that applies the default bolding is now loaded after gadgets rather than before. Anomie⚔ 13:14, 23 July 2016 (UTC)

A short-term workaround would be to increase the specificity of the selectors in the gadget (e.g. make it "html .mw-changeslist-line-watched .mw-title") so it's not relying on ordering to break the tie. Anomie⚔ 13:25, 23 July 2016 (UTC)

I have limited CSS knowledge but I suggest you do that if you ensure MediaWiki:Gadget-WatchlistChangesBold.css still works for those who do want bolding and have selected it in preferences. PrimeHunter (talk) 19:11, 23 July 2016 (UTC)

This is still occuring, seems to have stalled in getting a "fix", think we need to this this enwiki local still? — xaosflux ^Talk 11:18, 26 July 2016 (UTC)

@Xaosflux: If the suggested fix looks good to you or another admin with CSS knowledge then I suggest trying it. Anomie only has one edit since the suggestion. I'm not qualified to evaluate it. PrimeHunter (talk) 10:54, 27 July 2016 (UTC)

That dreadful bolding that everyone hates!!!

I see that unreadable bold text in the watchlist is back. How do I get rid of it this time? Checking/unchecking the "Display pages on your watchlist that have changed since your last visit in bold (see customizing watchlists for more options)" box, in preferences/gadgets/watchlist, makes no difference.--Ykraps (talk) 18:58, 23 July 2016 (UTC)

I don't see this bold. Where is the customize button? Millbug ^talk 19:09, 23 July 2016 (UTC)

See #New bolding in watchlist. There is a solution for your personal JavaScript and a suggested solution for everybody who is affected. PrimeHunter (talk) 19:14, 23 July 2016 (UTC)

I'm afraid I don't understand much of that conversation. Do I create User:Ykraps/common.js, then copy this script, "importStylesheet('MediaWiki:Gadget-WatchlistBase.css'); // Linkback: [[MediaWiki:Gadget-WatchlistBase.css]]" to it, and save?--Ykraps (talk) 19:32, 23 July 2016 (UTC)

Exactly. (Don't copy the nowiki part in the page source). PrimeHunter (talk) 19:35, 23 July 2016 (UTC)

That seems to have done the trick, thank you.--Ykraps (talk) 21:32, 23 July 2016 (UTC)

As as side note, I don't understand why people consider the bold "unreadable". In fact I've had the bolding enabled for a while, and it's much easier to spot changes than solely based on the color of a small dot. nyuszika7h (talk) 21:13, 23 July 2016 (UTC)

Perhaps it's a failing eyesight, getting old thing but in vector skin the type is so blobby the characters are barely distinguishable. With other skins it's not so bad but then the normal type is too small.--Ykraps (talk) 21:32, 23 July 2016 (UTC)

I use Firefox and MonoBook; I found that with IE (any skin), all characters get smudged. I believe that this smudging is something called anti-aliasing, which some consider a Good Thing. With my eyesight, it's not - I need sharp edges. --Redrose64 (talk) 22:47, 23 July 2016 (UTC)

I use Firefox and the Vector skin, it looks fine to me. nyuszika7h (talk) 11:12, 24 July 2016 (UTC)

I use Firefox and Safari in Vector, and it looks good. Perhaps it's a Windows problem? I use a Mac.

Not a Windows thing. I see it on Linux with Firefox. Jason Quinn (talk) 17:23, 28 July 2016 (UTC)

Despite the assertion that everyone hates the bolding, I happen to like it, and I will go to some trouble to enable it at the few wikis where it's not on by default. WhatamIdoing (talk) 13:50, 27 July 2016 (UTC)

WhatamIdoing I think what everyong "hates" is that we already had a gadget option for this (Display pages on your watchlist that have changed since your last visit in bold) that is broken, removing the ability for users to configure this as a preference. Perhaps the gadget needs to be changed to "DO NOT BOLD ....." ? — xaosflux ^Talk 21:57, 5 August 2016 (UTC)

I like the bolding too, because otherwise the only notice that a page is unvisited is the dim color of the tiny bullet to the left of the page name. (In fact, the bullets are so non-obvious that I never even noticed their color variations until I read about it in nyuszika7h's post above.) I don't care whether bold or non-bold is the default, as long as I have the power to choose bold if I want it. (I'm using Firefox.) — Lawrence King ^(talk) 20:44, 21 August 2016 (UTC)

Google returning outdated text snippet for Gender page

Unresolved

 – The google snippet has been updated and now matches out lead. — xaosflux ^Talk 19:43, 13 August 2016 (UTC)
And it is broken again. — xaosflux ^Talk 17:42, 18 August 2016 (UTC)

When searching for "gender" on Google, a text snippet from a disruptive May 26 revision of the Gender page is being returned. (The page has been semi-protected since June 23 due to excessive vandalism.) The page's current cache in Google is from August 1, so I don't understand why the snippet is still showing the outdated information. As I discussed on the Gender talk page, this problem came up several weeks ago, appeared to be resolved, and has now resurfaced. I reviewed a Google help page on text snippets, and it doesn't appear that Google can or will update them manually. Any suggestions of how or if this can be fixed? Funcrunch (talk) 23:18, 7 August 2016 (UTC)

Click on the send feedback link on the bottom of the Google search page? We have no control over when Google next crawls our articles. Beyond contacting them we can't do anything about it. --Majora (talk) 23:20, 7 August 2016 (UTC)

Again, the cache of the page in Google is up to date, so it's not just a matter of waiting for another crawl. It's the text snippet preview that is outdated. As I explained at the Gender talk page, I already contacted Google several weeks ago to remove the cached page from their database, and some time after that the snippet began correctly displaying text from the updated page. But now the problem has resurfaced, so something else is going on. Funcrunch (talk) 23:28, 7 August 2016 (UTC)

Alright. But I'm not sure what you want people here to do about this. You can try contacting Google again. Beyond that there is nothing more I (or anyone else really) can suggest. I have no idea how Google chooses how to display their results but we certainly have no control over it. I'm sorry that that is not really a good answer but that is really the only answer anyone on Wikipedia can give. --Majora (talk) 23:32, 7 August 2016 (UTC)

@Funcrunch: I would say it's definitely a problem with Google. I tried searching "gender" on Bing, Yahoo, and DuckDuckGo; each of those showed a snippet close to what's in the article now, whereas Google shows me the snippet you're talking about. I would think someone at Google would want to know that they're serving up 2-month-old snippets that don't match the cache, but I haven't a clue as to where to begin to find them. — Gorthian (talk) 00:53, 8 August 2016 (UTC)

The full snippet for me is: There are only 2 genders. Male and Female. Retrieved from "https://en.wikipedia.org/w/index.php?title=Gender&oldid=722247975" ...

https://en.wikipedia.org/w/index.php?title=Gender&oldid=722247975 is the revision saying "There are only 2 genders. Male and Female." I don't know how Google got the "Retrieved from" part into the snippet. PrimeHunter (talk) 01:11, 8 August 2016 (UTC)

@PrimeHunter: I believe Google doesn't take CSS into account when evaluating text snippets, and that text is displayed to non-CSS-enabled browsers. Graham87 04:00, 8 August 2016 (UTC)

On viewing the source for the old page revision, I see this soon after the page content: <div class="printfooter">Retrieved from "<a dir="ltr" href="https://en.wikipedia.org/w/index.php?title=Gender&oldid=722247975">https://en.wikipedia.org/w/index.php?title=Gender&oldid=722247975</a>"</div> So it looks like Google is displaying as its text snippet the print-formatted version of an old revision of the page? Funcrunch (talk) 17:11, 9 August 2016 (UTC)

Nope... You are making the assumption that there is an actual difference between a print and a display version. There is not, there is just CSS dressing both of them up. See note by Graham for actual cause. —TheDJ (talk • contribs) 09:37, 11 August 2016 (UTC)

I just tried Google-searching for various snippets from the Gender article; The url of the returned pages is always Masculinity vs femininity, a redirect to a non-existing section of Gender. The title of the page is correct, however - "Gender - Wikipedia, the free encyclopedia". עוד מישהו Od Mishehu 02:59, 8 August 2016 (UTC)

Could you share examples of some of your searches? That does sound strange... Funcrunch (talk) 15:41, 8 August 2016 (UTC)

Just go to Google and search for "gender". It's the first hit on the list! It seems plausible to me that the same person who made this edit might have known how to get Google to lock on it... Wnt (talk) 16:09, 8 August 2016 (UTC)

I was asking about Od Mishehu's searches for "various snippets from the article", not about searching on the term "gender" itself (which is what I originally posted about). Funcrunch (talk) 16:46, 8 August 2016 (UTC)

Look at this search, this one, and [this one, foe example. עוד מישהו Od Mishehu 17:16, 8 August 2016 (UTC)

I've submitted a request to refresh the snippet cache. Let's see if it works. - NQ (talk) —Preceding undated comment added 16:11, 8 August 2016 (UTC)

I tried that before, and the results were corrected temporarily, but then reverted to the way they are now. Maybe this time it will work... I also tried the "send feedback" link yesterday, highlighting the incorrect text snippet. We'll see... Funcrunch (talk) 16:49, 8 August 2016 (UTC)

I don't have a login set up for using the page, but I wonder if someone is going to that removal page and requesting "outdated content" be removed for https://en.wikipedia.org/w/index.php?title=Gender&oldid=722247975 on a regular basis. What's kind of cool is that if this really works you can use it for any vandal edit in the history of any article. A way to test it would be to pick a different vandal oldid and try the same removal request and see if you can spoil results for that article... Wnt (talk) 12:51, 9 August 2016 (UTC)

Google still returns it I've RevDel-ed the revision in question. Let's see if that, combined with their feedback tool (I sent them a complaint about this), will get them to fix it. עוד מישהו Od Mishehu 14:05, 12 August 2016 (UTC)

According to my hypothesis, this would prevent the refresh from restoring the oldid version, but someone still needs to request a refresh with some other version before the snippet changes. Right now it's still the same snippet. If our vandal is feeling generous he'll start refreshing with some other oldid in the database (or submit a new one) and then that will come up instead. Wnt (talk) 15:07, 12 August 2016 (UTC)

Now this is interesting... I just re-checked the page after Od Mishehu revdeleted the bad revision and Xaosflux purged the current page. Searching Google for "gender" still returns the outdated text snippet, but now the page in Google's cache, which previously showed an up-to-date revision from August 1, is showing the bad revision from May 26. Funcrunch (talk) 18:15, 12 August 2016 (UTC)

For anyone who submitted a google content update request, has your request progressed past "Pending" ? — xaosflux ^Talk 18:30, 12 August 2016 (UTC)

My request from July 3 to remove the bad revision has a status of "Expired". Funcrunch (talk) 18:35, 12 August 2016 (UTC)

I put one in earlier, status is "Denied". — xaosflux ^Talk 23:36, 12 August 2016 (UTC)

I put in an appeal to Jimbo (User_talk:Jimbo_Wales#Assistance_with_Google.3F) to find a better way to route problems to Google. — xaosflux ^Talk 23:42, 12 August 2016 (UTC)

 Done The google snippet now matches the very short replacement of the entire page that I made (just our lead sentence). The "HOW" or "WHY" of Google's change is still a mystery. — xaosflux ^Talk 19:44, 13 August 2016 (UTC)

Thanks for the update. I'll be keeping an eye on this search, as this problem was previously resolved and then reoccurred. Funcrunch (talk) 21:03, 13 August 2016 (UTC)

Just did a check, and as I feared, the problem has resurfaced. Searching Google for "gender" returns There are only 2 genders. Male and Female. Retrieved from "https://en.wikipedia.org/w/index.php?title=Gender&oldid=722247975". That's the vandalized May 26 revision, which was revdeleted on August 12. Google's cache currently shows a page revision from August 13, so that's up to date; just the snippet is wrong. What's going on here?? Pinging Xaosflux as the closer of this issue... Funcrunch (talk) 17:10, 18 August 2016 (UTC)

Marked as "unresolved" - but this really isn't a Wikipedia problem - it is a Google problem. We have identified a problem with how to get WMF to complain to Google.... anyone know where to go from here? — xaosflux ^Talk 17:44, 18 August 2016 (UTC)

Contact one of the google-affiliated WMF board members directly? Only in death does duty end (talk) 12:34, 19 August 2016 (UTC)

[Idea] Wikidata descriptions to help disambiguate article topic on mobile web

Hello everyone, the Reading team would like to help readers learn faster about the topics they are browsing on our mobile site, by displaying Wikidata descriptions underneath article title. This has been the case on apps for a while now, and the team would like to move with the same practice to mobile web, and help our mobile readers, by using content from a Wikipedia sister project. This change has already been enabled on Catalan and Polish Wikipedias. There is a page the describes the idea and the details here . Please check to learn more about the rationale and the details of the suggested change.--Melamrawy (WMF) (talk) 16:10, 12 August 2016 (UTC)

• First mobile screen with and without description
• 
  You can't tell who Maria Callas is from the first screen
• 
  The current beta view where the descriptions show under the title makes it easy to learn about the topic from the first glance

Um, what about the sourcing? Wikipedia article lead sections usually rely on the sources in the article beneath. Wikidata material is usually unsourced or poorly sourced. Also, what about articles without a Wikidata item? Jo-Jo Eumerus (talk, contributions) 16:15, 12 August 2016 (UTC)

Does this proposal include all the other changes from image 1 to 2? (e.g. translation tool, reordered buttons) — xaosflux ^Talk 20:01, 14 August 2016 (UTC)

Hello Xaosflux, the difference is that now the language switcher change has moved to stable. I have just updated the screenshot above. Thanks! --Melamrawy (WMF) (talk) 20:22, 18 August 2016 (UTC)

Unable to make fullpage edits to an article

For some reason, almost every time I edit the entire article List of DTT channels in the United Kingdom using the main edit link, I am unable to publish, preview or show changes. The later two options eventually generate the error:

An error occurred while attempting to preview your changes.

HTTP error: timeout

I am able to edit individual sections of the article fine. This has been happening for the past few weeks, but isn't happening to me on any other article. Eladkse (talk) 15:16, 15 August 2016 (UTC)

Are you editing from a small portable device? I just did a full page edit from my PC, and both the preview and the show changes worked fine. ←Baseball Bugs ^{What's up, Doc?} carrots→ 15:22, 15 August 2016 (UTC)

No, I'm on a PC. Have tried on other PCs too. Eladkse (talk) 15:27, 15 August 2016 (UTC)

I just made a trivial change to it and it saved immediately. I'm using IE 10. ←Baseball Bugs ^{What's up, Doc?} carrots→ 17:45, 15 August 2016 (UTC)

I have just tried editing as an anon and it is working fine. Seems this is very specific to my account. Eladkse (talk) 20:18, 15 August 2016 (UTC)

I see several edits by you on that page - did your edit actually succeed after the timeout or it's just some edits that made through? If it's the latter, can you tell me the precise time of when that happened (try making another edit if you're unsure)? Max Semenik (talk) 00:31, 16 August 2016 (UTC)

I'm not sure which edits you're specifically looking at, but my recent edits are mostly section edits. There is the odd fullpage edit that does make it through, but I can't correlate as to why this happens. Trying just now seems to work fine - but this is exception rather than the norm. I'll update this post when I next find I cannot edit the whole page. Eladkse (talk) 10:33, 16 August 2016 (UTC)

Historically edits that appear to fail sometimes succeed, becsuse the save works but the render times out. Which further muddies the waters if this is still the case. All the best: Rich Farmbrough, 11:55, 18 August 2016 (UTC).

NewPP limit report

It was sometimes useful to view the HTML source of a wiki page, then search for "NewPP" to see the "NewPP limit report" (new page parser). It's still present on cached pages, but purging shows that NewPP has been replaced with some clever stuff (wgPageParseReport) that would presumably need a script to interpret. Is the info going to be displayed somewhere readily available such as at Page Information (?action=info)? I have sometimes pointed people to NewPP while explaining why a problem needs to be fixed. Johnuniq (talk) 04:07, 16 August 2016 (UTC)

I dunno, the new HTML comment still is human readable. But it needs to be documented. Jo-Jo Eumerus (talk, contributions) 06:35, 16 August 2016 (UTC)

If you have a look at the change that introduced it, you can see that all of the same data is there. The only difference is that it's a structured JSON object now instead of hardcoded English strings in an HTML comment. For example, "Cache expiry" is now "cachereport-ttl." It's no less readily available than before, it's still in the page source (as well as on preview and a few other places too if I'm reading the follow-up changes correctly). I don't see any particular reason it couldn't be exposed via action=info as well :) ^demon^{[omg plz]} 06:40, 16 August 2016 (UTC)

It seems to be missing from previews… Jc86035 (talk • contribs) Use {{re|Jc86035}} to reply to me 06:54, 16 August 2016 (UTC)

I have occasionally written module code to fix a template limit problem, and have found it convenient to copy the NewPP report into a text editor so I can easily compare the before/after reports. I can still do that, but there is now quite a lot of syntax surrounding the nuggets of data. It would be nice if action=info showed something similar to the original text, but I suppose that won't happen due to the pain of doing it properly with i18n. Johnuniq (talk) 08:02, 16 August 2016 (UTC)

So I started hacking about adding this to action=info. The biggest problem will be coming up with some decent strings to describe these fields, as well as properly expanding the arrays into a more presentable format. Thoughts? ^demon^{[omg plz]} 01:50, 18 August 2016 (UTC)

Update! I realized we actually have messages on hand for most of this already! :) Only need some better formatting for the timing report I think :) ^demon^{[omg plz]} 02:50, 18 August 2016 (UTC)

@^demon: Thanks, that's great! I hope your code would show the "scribunto" items that occur if a module is invoked. An example which was over 10 seconds two days ago is here—for some reason it is now 6 seconds but nothing seems to have changed to cause the improvement...strange, although not relevant here. It would be nice if the "timingprofile" array could be displayed with line breaks instead of the array indices. Johnuniq (talk) 10:11, 18 August 2016 (UTC)

• Is the info going to be available when previewing a page? That used to be very, very convenient. Uanfala (talk) 19:49, 18 August 2016 (UTC)

• I talked to Aaron earlier, he said it's fixed in the master branch, so hopefully be on the wikis next week? ^demon^{[omg plz]} 20:20, 18 August 2016 (UTC)

Unremovable notification

In my notices, I get the "More notices from another wiki MediaWiki" notice, with the "view 1 notice" below. When I open this, I get a line saying "MediaWiki", nothing else. This used to say why I got this notice (e.g. "topic added at..."), which I could then ignore. Not with this one. Worse, when I click the blue button (the only available option to "mark as read", not really obvious), the message disappears, and the counter as well, only to reappear again a second later with the same message highlighted.

When I go to MediaWiki, I have the same "1" in my intray, but no unread notifications and no way to remove the "1". When I go to the new notifications page on enwiki, I also have no unread notifications. So I'm apparently stuck with that "1" for eternity. Fram (talk) 08:16, 16 August 2016 (UTC)

This is (I think) the third in the list of problems in the latest Tech News above. See phab:T140327 and phab:T140836. Here's a ping to see if it flushes out the issue. BethNaught (talk) 08:33, 16 August 2016 (UTC)

Thanks for the message and the ping, I got it but it didn't change the issue. Reading the phab tickets, the last comments state "Could not find any instances of the issue in production - 1.28.0-wmf.14 (ba1c692)". It seems to be, if no the same problem, then at least related. I don't see the "can mark message as read, get counter to 0, but only for a short while" aspect, but that may be implied. Anyway, they now have at least one instance in a productionwiki to deal with! Fram (talk) 08:38, 16 August 2016 (UTC)

@Fram: This is probably phab:T93673 which a proper fix is in progress for.

In the meantime, you should be able to clear the existing message via 1 of these methods: (a) go to mw:Special:Notifications, mark one notification as "unread" (click the empty circle), then click the cog-icon at the page-top and mark all as read (screenshot). (b) go to mediawiki.org, open the notices panel, mark one of the older notifications as unread, then mark it as read again. (c) go to mediawiki.org, open your browser's javascript console, paste in this line new mw.Api().postWithToken('csrf', {action:'echomarkread', all:1}); and press [enter]. Let me know if any of those do/don't work, and I'll update the phab task accordingly, thanks. Quiddity (WMF) (talk) 17:28, 16 August 2016 (UTC)

Thanks. In the meantime, I got another notification from mediawiki, and when I marked that as read, the counter went back to 0. So I haven't tried your solutions, and the issue is fixed at my side, but thanks for the advice! Fram (talk) 06:34, 17 August 2016 (UTC)

Pages being marked as patrolled despite being autopatrolled

Sorry if this is the wrong place to ask or seems like a newbie question (and maybe I should know better considering I've been on Wikipedia for 10 years), but can anybody answer as to how, if I am an autopatrolled user, my pages are coming up on the new pages feed/script as "unpatrolled"? I just had a notification a while ago saying that High (EP) had been reviewed, but I created that page as an autopatrolled user. I asked the user who did and they said they clicked "patrolled" on the NPP script. How is this an option if whenever I create a page now, it is already patrolled? Is it something to do with a script that allows users to click "patrolled" even on autopatrolled users' pages? Ss112 16:29, 16 August 2016 (UTC)

As you can see here that when you created the page, it was automatically marked as patrolled. The "review" that you was informed of has nothing to do with patrolling. Ruslik_Zero 17:21, 16 August 2016 (UTC)

Right, I was conflating the two. Then what is a review? Is that something one can mark off as having done on a page with a script? Ss112 17:39, 16 August 2016 (UTC)

@Ss112: I think that it's WP:CURATE. --Redrose64 (talk) 23:10, 16 August 2016 (UTC)

Re: The bug - I'll investigate and try to reproduce this bug, tomorrow. I'm not deeply familiar with NPP yet, but AFAIK that is indeed a bug.

Re: Terminology - "Review" is very ambiguous, potentially referring to (a) WP:New Page Patrol (aka PageTriage, aka Page Curation), or (b) to WP:Reviewing (aka Pending changes, aka the Enwiki configuration of Flagged revisions), or (c) to WP:Articles for creation reviews, or (d) to WP:REVIEW (Peer reviews).

Re: The notification message - These are triggered by page-patrol, either via Special:NewPagesFeed or via the link at the bottom of each new article. Historically: Enwiki changed the local notification messages in Oct 2014. Currently: The overhauled Extension:Echo uses a new structure, with new message-strings, hence the new default (MediaWiki:Notification-header-pagetriage-mark-as-reviewed) is being shown instead of those older messages.

However, I'm not sure whether to suggest changing that message locally, or updating the software itself to use "patrol" instead of "review" everywhere, given (1) the perennial confusion about those terms, and (2) the target demographic for these messages is newcomers who will be confused by "patrolled", and given (3) the ongoing discussions about a new user-group for New Page Patrollers (which @Kudpung: has suggested naming "New Page Reviewer").

HTH, and hope that's all accurate. I'm not sure where the terminology-focused discussion should occur, but probably not here, given the huge bikeshed potential ;) Quiddity (WMF) (talk) 02:37, 17 August 2016 (UTC)

Quiddity (WMF) It looks like though the page was already "patrolled" (automatically) someone else later went through and marked it "reviewed" (see page log), and the notification was triggered based on that. I think the question seems to be why was that page able to be marked "reviewed" when it should have already been "autoreviewed". — xaosflux ^Talk 03:18, 17 August 2016 (UTC)

Side note, I'm still lost on what a group for "New Page Patrollers" would actually "do" (are there existing permissions that users don't have that would be bundled to this assignable group? Is it to house brand new extensions to the permissions system? Is it part of removing rights from exiting editors?) — xaosflux ^Talk 03:20, 17 August 2016 (UTC)

Xaosflux, I'm extremely surprised at your comment here, because your very questions were explained to you personally in penetrating detail very recently, explicitly because you had already misunderstood the suggestions in spite of them already being quite clearly discussed in a thread you started. Kudpung กุดผึ้ง (talk) 04:40, 17 August 2016 (UTC)

Kudpung I know we talked - but I'm still missing something! I think that because we have multiple systems with the same or similar terminology is what is tripping me up (between the tools related to "(patrol)", the "review" permissions related to "stable/pending versions", the ability to use the "review" features related to "curate", and the AfC scripts) I read over mw:Topic:T7bfjv9rhjybw333 as well but am still missing something. As seen in the beginning of this thread, we already have a page that is separately being logged "patrolled" and "reviewed". Do you have a proposal page that outlines all of the changes (what needs to be removed and added in concert)? (something akin to The page mover group RfC perhaps?. — xaosflux ^Talk 10:31, 17 August 2016 (UTC)

Xaosflux, In that same thread you told me words to the effect: 'I'm a bureaucrat, I know all about user rights groups' This new development has nothing to do with Rollbackers, Page Movers, Template Editors, or Recent Changes Patrolers. It is to be a new MediaWiki user group that will, on application for the right, allow people to tag new pages that appear in the New Pages Feed. That's it. The source code of how this will be done is of no interest to anyone but the developers who work on the NedaWiki software. The list of actual additions and changes needed to the Page Curation software prior to the creation of the user group were submitted by me in a meeting I had with Foundation staff a few weeks ago. Developmnt is likely to take several months because it includes a proper landing page for new users - something Wikipediahas never had. Our concerns are to better control what gets published without discouraging good faith editors. To learn more, you may wish to tryout the current systems at AfC (of which I had no hand in the 2007 development) and and Page Curation which I co-developed with the Foundation and others in 2011. Kudpung กุดผึ้ง (talk) 11:29, 17 August 2016 (UTC)

OK, so a new access for a new kind of tagging - Is there anything that most editors can already do (such as mark a page as "reviewed") that you want to prevent them from being able to do? — xaosflux ^Talk 13:19, 17 August 2016 (UTC)

Currently, the patrol user-right is given to the autoconfirmed user-group, which is vastly too wide, and leading to problems. The plan is to create a new user-group, for just this user-right. The patrol user-right is used for New Page [patrol/curation/triage/review/checking]. Quiddity (WMF) (talk) 17:41, 17 August 2016 (UTC) -

Quiddity (WMF) Thank you! That is all I was really looking for here! This would be similar to the "Patrollers" group at commons: - but may have the additional settings related to the NewPagesFeed, correct. This would be pretty easy to get an RfC going for (Move the "patrol" permission from confirmed to a new group). — xaosflux ^Talk 20:44, 17 August 2016 (UTC)

Xaosflux, Both those log actions are for patrol (click "Hide review log" to verify) - Curate and Patrol are the same thing - the confusion is again due to the wording in messages. Uselang=qqx leads me to MediaWiki:Logentry-pagetriage-curation-reviewed. (And to repeat, we should probably bikesheddiscuss the terminology elsewhere. But briefly, "review" is the software default term, which is ambiguous/confusing for everyone. The word "patrol" is the local (inconsistent) override, which is a confusing word for newcomers, and also ambiguous. The words "curation" and "triage" are used in the documentation, which is confusing. We should determine a replacement. mw:Naming things is hard.). Quiddity (WMF) (talk) 17:41, 17 August 2016 (UTC)

Quiddity (WMF) Me again - so if this page was already marked "patrolled" why was it able to be marked "patrolled" again - are there still multiple patrol flags that can be set per page - or can it just be patrolled over and over again? I noticed that pages can also be marked "UNREVIEWED" (example log). — xaosflux ^Talk 20:44, 17 August 2016 (UTC)

Yup, that's what I was referring to in my initial "Re: The bug [...]" comment. I'm now looking through the phab tasks to see if it's already reported, and will do some testing once that's done. Quiddity (WMF) (talk) 21:11, 17 August 2016 (UTC)

No existing bugs that I can find.

Some testing on testwiki suggests to me that the 2 log items come from the interplay between the 2 levels of software, the core mw:Help:Patrolled edits feature, and the newer WP:NPP page. If I use the core feature, it marks the revision as patrolled. If I use NPP, it marks the page as [reviewed/patrolled] and the revision as patrolled. -- E.g. a single "mark as reviewed" action at NPP triggered both log actions in this testpage log).

However, If I use the core patrolled-edits feature on a page, and then visit it with NPP (using another account) it is not possible to use the NPP popout to "mark as reviewed" without "unreviewing" it first. I don't know how it is possible to have that log entry appear later in time, without that unreview. I've filed it as phab:T143286. Quiddity (WMF) (talk) 23:26, 17 August 2016 (UTC)

Typing into editor or edit summary on large articles is very sluggish

Tracked in Phabricator
Task T143182

In recent weeks, whenever I type into the editor or the edit summary of a sizable article (not sure what I would use for a cutoff here), the keyboarding is painfully sluggish. For examples, typing in Louisville Clock seems normal while typing in Thomas Jefferson is as slow as molasses. I have been disabling gadgets/scripts to see if any of them are causing the issue, to no avail. Is anyone else seeing this behavior? Any ideas for how to narrow down the issue? Stevie is the man! ^{Talk • Work} 20:54, 16 August 2016 (UTC)

Syntax highlighter does this for me. Occasionally it even times out. – Finnusertop (talk ⋅ contribs) 21:38, 16 August 2016 (UTC)

I thought that might be the issue, so I disabled it. However, this didn't fix the problem. Stevie is the man! ^{Talk • Work} 21:44, 16 August 2016 (UTC)

What is your skin? Does it happen in other skins like Modern? Does it happen when you log out? Does it happen at other wikis like pages at de:Special:LongPages? What is your browser? Have you tried to clear your entire cache? PrimeHunter (talk) 22:54, 16 August 2016 (UTC)

It happens for me at pages like Fenchurch Street railway station, which isn't particularly long. MonoBook skin, no WikEd, Firefox. --Redrose64 (talk) 23:07, 16 August 2016 (UTC)

1) Vector (default); 2) Haven't tested; 3) Haven't tested. 4) Haven't tested; 5) Chrome, but it's a problem in Firefox too; 6) Haven't tried yet. Stevie is the man! ^{Talk • Work} 23:44, 16 August 2016 (UTC)

Also, I'm not using WikEd. Stevie is the man! ^{Talk • Work} 23:45, 16 August 2016 (UTC)

Typing for me is slower though not painfully sluggish in Firefox on semi-protected pages with a large source text. It also happens at other wikis, in different skins, and with simple source text like a line of random letters copied thousands of times. Fenchurch Street railway station is not protected and it doesn't happen for me there. Special:ProtectedPages can be used to find protected pages at other wikis where you may be able to edit semi-protected pages. If I copy the same large source text between semi-protected pages and unprotected pages then it only happens on the semi-protected pages. I can obviously not test it when logged out. PrimeHunter (talk) 23:50, 16 August 2016 (UTC)

2) didn't fix problem; 6) didn't fix problem. Stevie is the man! ^{Talk • Work} 23:55, 16 August 2016 (UTC)

3) I logged out and tried to edit Kentucky. Same problem. Very slow response to my typing. Stevie is the man! ^{Talk • Work} 00:06, 17 August 2016 (UTC)

I can reproduce this issue in Firefox 48 and inconsistently in Chromium 51, at the article Thomas Jefferson, using a preferences-reset account and all (visible) gadgets disabled. By copy&pasting the text from there into other edit windows, I can reproduce at mediawiki.org. There does seem to be some partial consistency with page-protection (per PrimeHunter), but I also sometimes reproduce it on unprotected pages. There have not been any recent (since May) code changes in WikiEditor, so it's probably not a problem with that. I'll keep testing, and also asking some people. Quiddity (WMF) (talk) 00:52, 17 August 2016 (UTC)

Filed as phab:T143182, with more details on browser reproducibility. Quiddity (WMF) (talk) 02:15, 17 August 2016 (UTC)

Firefox 48. I can drive my 2.5 GHz processor to 25% (attributed to the Firefox task only) and hold it there as long as I want, by simply typing garbage rapidly into the editor at Jefferson using two hands and six fingers. That's a lot of processing per character. For comparison, about 6% at Waters Ave S. and about 2% for Wordpad. ―Mandruss ☎ 02:31, 17 August 2016 (UTC)

I too am facing this problem on some pages! VarunFEB2003 ^{I am Online} 17:08, 17 August 2016 (UTC)

This appears to be a browser bug related to the handling of text directionality control characters. It may be possible to work around it in MediaWiki. See T143182#2561436 for details. --Ori Livneh (talk) 18:42, 17 August 2016 (UTC)

Update: The issue has been tracked down to be caused by the left-to-right mark (LRM). See technical notes at phab:T143182#2561436. A bug has been filed upstream with Firefox. It doesn't affect the latest version of Chrome/Chromium, but other people had already reported it for older versions. Devs are discussing how to deal with existing uses of the LRM in the MediaWiki codebase. Quiddity (WMF) (talk) 18:46, 17 August 2016 (UTC)

@Quiddity (WMF): I didn't particularly get you, I use Chrome and I am still facing that issue! VarunFEB2003 ^{I am Online} 06:34, 18 August 2016 (UTC)

What version of Chrome are you using, on what kind of computer? Whatamidoing (WMF) (talk) 08:55, 18 August 2016 (UTC)

It does affect the current public version of Chrome (52) on Windows 10. Stevie is the man! ^{Talk • Work} 12:14, 18 August 2016 (UTC)

@Whatamidoing (WMF): I am using Windows 7(because I like it) on a Lenovo 35cm width by 30cm height PC. Chrome Version 51.0.2704.103 m (that's what the 'About' tab says) VarunFEB2003 ^{I am Online} 12:17, 18 August 2016 (UTC)

I am using 52.0.2743.116 m to be exact. Stevie is the man! ^{Talk • Work} 12:33, 18 August 2016 (UTC)

Retrieving wikidata ID from talk page

How can I retrieve the wikidata item Q-ID from the talk page namespace? With {{#invoke:Wikidata|pageId}} we can do it from article but not from article talk.--ԱշոտՏՆՂ (talk) 11:10, 17 August 2016 (UTC)

@ԱշոտՏՆՂ: talk page is just another Wikipedia page. Currently you can't accesss this info via Lua/parser functions. I think it's now closer than it was year ago, but still not doable. You can get ID with API, if needed. --Edgars2007 (talk/contribs) 02:35, 22 August 2016 (UTC)

Dropdown lists

I recently worked out some html code that creates a dropdown list (like when you click on the arrow a list drops down) The code that does this is:

<div class="margin8 puree-dropdown dropdown usernamereg-gender">
<select id="usernamereg-gender" name="gender"   >
<option value="no_disclosure"  selected >Gender (optional)</option>
<option value="female" >Female</option>
<option value="male" >Male</option>
<option value="other" >Other</option>
</select>
<div class="arrow"></div>
</div>

However this code is not working for Wikipedia! Can someone help me create the code that can create a dropdown list! Please VarunFEB2003 ^{I am Offline} 12:11, 17 August 2016 (UTC)

Not all HTML tags are allowed in Wikipedia. See a list of allowed tags here. In particular, <select> and <option> are not supported. Ruslik_Zero 13:01, 17 August 2016 (UTC)

Then how do I use it here? Are there alternatives can you help please? Redrose64? VarunFEB2003 ^{I am Online} 13:07, 17 August 2016 (UTC)

Generally you can not create drop down lists in Wikipedia. You'd better to say what you want to achieve with a drop down list. Then we may be able to help you. Ruslik_Zero 13:13, 17 August 2016 (UTC)

A template to help others create drop down lists. VarunFEB2003 ^{I am Online} 13:34, 17 August 2016 (UTC)

What would that template be used for, besides helping people make drop down lists? --Izno (talk) 13:42, 17 August 2016 (UTC)

The purpose of a drop-down list is to make a selection. As far as I know we have no feature which would be able to use a selection for anything. If you want to display something different depending on the selection then it would require more than just a drop-down list to make the selection. The closest we have may be sortable tables where you can click the column to sort by, and collapsible tables where you can click show or hide. PrimeHunter (talk) 14:11, 17 August 2016 (UTC)

@PrimeHunter: I know about them but can you help me create what I actually want to. Can you please tell me what can be the alternative coding for it which does the same thing. Please! Thanks VarunFEB2003 ^{I am Online} 17:03, 17 August 2016 (UTC)

VarunFEB2003, what you're suggesting is likely to be a major breach of WP:ACCESS unless you have the technical knowledge to embed appropriate ARIA markup to make it screen-reader readable (which having seen your edit history, I find unlikely), and will also have a significant impact on printability and mirror sites. Unless you can give a very good justification for why you want to use a drop-down list on Wikipedia, any attempt to do so is very likely to be treated as disruption. ‑ Iridescent 17:12, 17 August 2016 (UTC)

Does it breach a policy, I didn't get a word you wrote above. If you just tell me how I have to do I can get it done, my father is a very good coder/programmer. Thanks. VarunFEB2003 ^{I am Online} 17:15, 17 August 2016 (UTC)

You can make personal drop-down lists as described here. However it is unlikely that this will ever be implemented site-wide. Ruslik_Zero 17:18, 17 August 2016 (UTC)

(edit conflict) If you really didn't get a word you wrote above, you should not be working on template coding; no ifs, no buts. Everything I mention are either key Wikipedia guidelines, or basic principles of web design. To put it in simple language: You are asking for help in doing something that is fundamentally disruptive. If you do it and can't either do it in a way that complies with Wikipedia policy and practice, or provide a good reason why the benefits justify the policy breach, you will be treated as any other disruptive editor and blocked. As has already been pointed out to you in the various posts you ignore on your talkpage, you have less than 7% of your edits to mainspace, and are rapidly exhausting WP:AGF and WP:CIR. ‑ Iridescent 17:24, 17 August 2016 (UTC)

Iridescent no problem I just asked if it evades policy then i'll not proceed further. okay okay! VarunFEB2003 ^{I am Online} 17:27, 17 August 2016 (UTC)

(edit conflict) You still haven't clarified what you want to use it for. Assuming you want a way for users to select which content to display, it cannot be done without somebody making the code and then getting consensus to permit the code, maybe by installing an extension (would also require acceptance by the server administrators in the Wikimedia Foundation), or making common JavaScript for all users of the English Wikipedia. Users without JavaScript should also be able to see our content so a fallback system would be needed for a JavaScript solution. We want our content to be reusable, also in print and other media without interaction. PrimeHunter (talk) 17:35, 17 August 2016 (UTC)

@PrimeHunter: I have dropped the project since I learned it breaches some policy and then I don't want to create such a big discussion for a thing that want be of much use. Thank You all for your guidance and help. VarunFEB2003 ^{I am Online} 06:32, 18 August 2016 (UTC)

Flashearth

Hi, this site linked in the geohack maps http://www.flashearth.com/ is currently down. I noticed a few weeks ago that the site had changed and altered. It's possible they no longer have the financing to run. I used it for years for finding coordinates. Perhaps it should be removed from the list if it stays down? Can somebody find an alternative with shows the exact coordinates when you hover over a location? I used to have Google earth but not any longer.♦ Dr. Blofeld 07:34, 18 August 2016 (UTC)

It looks like the website has been hacked, since its page source is now

<!DOCTYPE html>
<html>
  <body style="margin:0;">
    <img src="http://www.reactiongifs.com/wp-content/gallery/no/no_way.gif" width="100%" height="100%">
  </body>
</html>

so I've commented it out from Template:GeoTemplate#Global services. --Redrose64 (talk) 13:19, 18 August 2016 (UTC)

Here's a geolocation website: http://itouchmap.com/latlong.html — Diannaa (talk) 14:27, 18 August 2016 (UTC)

Does it have parameters by which a pair of coordinates may be fed in? --Redrose64 (talk) 16:13, 18 August 2016 (UTC)

Yeah, "Show Point from Latitude and Longitude" — Diannaa (talk) 00:27, 19 August 2016 (UTC)

No, those are input boxes, not parameters - clicking Show Point moves the marker and zooms in, but doesn't alter the URL. In order to incorporate this site into Template:GeoTemplate, we need to be able to pass the coordinates through the URL, without the user needing to enter them manually. Flashearth did this in the form http://www.flashearth.com/?lat=51.64&lon=-1.242&z=15&r=0&src=ggl - here, the URL's query string has five parameters, the first two are lat=51.64 which is the latitude, and lon=-1.242 which is the longitude. What we need are the equivalents for itouchmap.com - better still, a full list of valid parameters, so that we can set things like the zoom level and map type (e.g. topographical, satellite). --Redrose64 (talk) 08:07, 19 August 2016 (UTC)

Dr. Blofeld, itouchmap.com doesn't display a map for me. I have to resort to http://www.openstreetmap.org and http://www.bing.com/maps/ together. I find the place with bing's birdseye and then compare with open street to get the coords. I sorely miss flashearth. Is there any other way I don't know about? Best, Anna Frodesiak (talk) 01:22, 19 August 2016 (UTC)

Here's another one you could try: http://www.gps-coordinates.net/ — Diannaa (talk) 04:46, 19 August 2016 (UTC)

For years I've used http://mapper.acme.com, a site that's included on {{GeoTemplate}}. It's a basic Google map, with all the normal features (plus, with the US, you have a good topo map option, but Dr. Blofeld, I know you do a ton more non-US stuff than I do), and the box at bottom right always displays the coordinates for the center of the screen. Nyttend (talk) 11:36, 21 August 2016 (UTC)

Thanks. The site it seems was hacked and has now been restored.♦ Dr. Blofeld 15:30, 21 August 2016 (UTC)

Hi Dr. Blofeld. What has been restored? Flash Earth? For me, it still bounces to https://zoom.earth/ which doesn't work. :( Anna Frodesiak (talk) 22:11, 21 August 2016 (UTC)

@Dr. Blofeld and Anna Frodesiak:  Works for me, so restored to GeoHack. --Redrose64 (talk) 22:22, 21 August 2016 (UTC)

Template:Infobox wildfire

I just finished (well almost finished) adding map capabilities to {{Infobox wildfire}}. I used {{Location map}} to make it happen but I'm stuck on a couple of things and would love some assistance.

1. Even with {{{pushpin_map_caption}}} is supplied, the default caption of <pagename> (<map name>) is showing up. (See Blue Cut Fire for an example).
2. How can I add pages to Category:Wildfire articles needing coordinates based on them neither using {{{coordinates}}} or any of the individual coordinate parameters?

Thanks in advance! --Zackmann08 (^{Talk to me}/_{What I been doing}) 17:49, 18 August 2016 (UTC)

@Zackmann08: Regarding (1), this is the fix. --Redrose64 (talk) 18:19, 18 August 2016 (UTC)

@Redrose64: thanks but that isn't exactly what I was hoping for. It has a rather unattractive format. What I was trying to do was reproduce what is done in {{Infobox airport}}. See Santa Barbara Municipal Airport for an example. --Zackmann08 (^{Talk to me}/_{What I been doing}) 18:31, 18 August 2016 (UTC)

What's unattractive about it? --Redrose64 (talk) 18:45, 18 August 2016 (UTC)

@Zackmann08: you could use code like this: {{#if:{{{coordinates|}}}{{both|{{{latd|}}}|{{{longd|}}}}}{{both|{{{coordinates_wikidata|{{{wikidata|}}}}}}|{{#property:P625}}}}||{{main other|[[Category:Wildfire articles needing coordinates]]}}}} – but this won't take account of articles using {{Coord}} outside the infobox (e.g. Summerland disaster), so a better category name would probably be "Category:Infobox Wildfire without coordinates" (or similar wording) - Evad37 [talk] 00:23, 19 August 2016 (UTC)

Create file redirect from red link

When you click on a red link to a file, it goes directly to the file upload page. Can we add an option to create a redirect to an existing file? This would br most useful for allowing deleted files to be viewed in page history if they are re-uploaded following concensus etc--Prisencolin (talk) 18:59, 18 August 2016 (UTC)

@Prisencolin: See User:Equazcion/SkipFileWizard. --Redrose64 (talk) 19:10, 18 August 2016 (UTC)

Ah thanks, this is exactly what I'm looking for. I gotta look into more of these scripts, they might come in handy from time to time.--Prisencolin (talk) 18:41, 19 August 2016 (UTC)

Inline math tags on mobile

Currently it seems that <math>...</math> is always rendered as a block element on mobile when the page is saved, but preview shows them correctly displaying them inline. For example König's lemma#Computability aspects. Adding style="display: inline" to the tag does nothing (presumably the math extension doesn't allow styling). This is Firefox 48 for Android. Hairy Dude (talk) 01:00, 20 August 2016 (UTC)

I'm unable to reproduce it in the sandbox :(

foo $\omega ^{<\omega }\,$ bar

foo

$\omega ^{<\omega }\,$

bar

In the sandbox, but not here (!), the first example displays inline and the second block. On the saved page, both are block. In preview, both are inline. Hairy Dude (talk) 01:09, 20 August 2016 (UTC)

User:Physikerwelt knows a lot about math rendering. Perhaps he can help you. Whatamidoing (WMF) (talk) 09:15, 22 August 2016 (UTC)

TOC problems

Not sure if this is the right place to ask, but I've been running into some problems with tables of contents while working on List of Re:Zero -Starting Life in Another World- characters (edit | talk | history | links | watch | logs). {{TOC hidden}} isn't working - the TOC just appears normally. Additionally, when I then hide it, TOCs on other pages appear hidden. I've experimented on 3 different computers, so I don't think that is the problem. White Demon seems to be encountering the same issue. Any ideas about what is causing this? G S Palmer (talk • contribs) 18:36, 20 August 2016 (UTC)

{{TOC hidden}} is disabled in mainspace. See the page history and talk page. I have restored documentation saying this.[1] PrimeHunter (talk) 20:09, 20 August 2016 (UTC)

Recent changes concerning mobiles

Some recent changes have been made to the site that have had a few negative impacts on mobile devices. I noticed it in particular on 2016 Formula One season, as the flag icons do not display properly. Prisonermonkeys (talk) 03:36, 21 August 2016 (UTC)

Hi Prisonermonkeys, can you please share a screenshot of the changes that you noticed? --Melamrawy (WMF) (talk) 09:33, 22 August 2016 (UTC)

@Melamrawy (WMF) — I can try, but it may take a while. I have never actually uploaded images to Wikipedia before. In the meantime, I will try and describe it;

Ordinarily, the flag icon and the driver name would appear on the same line. It took WP:F1 a long time to get this right as we started introducing some complex markup to tables, such as the sortable function.

However, in the past week or so, things have changed. It coincides with some changes to the way images appear—all images now appear as a grey box and fade in as they upload. The flag icon and name appear across two lines, with the name forced under the flag. Curiously enough, they appear properly in the editing review window on mobiles. Prisonermonkeys (talk) 10:58, 22 August 2016 (UTC)

@Melamrawy (WMF) — okay, that was way easier than expected.

What it looks like now.

What it should look like.

Hope that helps. Prisonermonkeys (talk) 11:09, 22 August 2016 (UTC)

@Melamrawy (WMF) I suspect this is due to the lazy loaded images experiment. It messes with the styles and dom position of the images... —TheDJ (talk • contribs) 11:49, 22 August 2016 (UTC)

I also see it in the mobile version on my desktop computer. Mobile looks like the left image. Desktop and mobile preview looks like the right. PrimeHunter (talk) 12:04, 22 August 2016 (UTC)

@PrimeHunter thanks for the screenshots! @TheDJ), that was my initial assumption indeed, let me check with web folks! Thanks --Melamrawy (WMF) (talk) 14:37, 22 August 2016 (UTC)

Chinese characters in mobile

I've recently started to notice a pair of random Chinese characters when accessing articles on my Kyocera flip-phone. When I first saw such characters, I assumed that they were vandalism, but virtually every article features the same two characters, at the very top on the left side. What's the point of including them everywhere? I can't copy/paste them, because the phone doesn't have the ability to edit (or the ability to copy/paste content in any other manner), and I'm not seeing these characters when accessing pages on my computer. Nyttend (talk) 05:15, 21 August 2016 (UTC)

These characters appear to be the mobile equivalent of the languages part of the sidebar. Clicking on them opens up a language selection tab, allowing you to select what language version of the article you wish to read. -- The Voidwalker ^Discuss 21:45, 21 August 2016 (UTC)

display of logs

Does anyone know which MediaWiki-namespace entries control the displays of the logs (Special:Log)? (disclaimer, I want to make the display of the spamblacklistlog more useful). Thanks! --Dirk Beetstra ^{T C} 05:22, 21 August 2016 (UTC)

Per this link, which outputs MediaWiki message names rather than their values, the page you want is MediaWiki:Logentry-spamblacklist-hit. Graham87 07:39, 21 August 2016 (UTC)

@Graham87: thanks, that was what I wanted to know. Unfortunately $1 is there expanded, it is not the plain username (I wanted to tweak it so I could add a link to 'Special:Log/spamblacklist/<username>' (see for this user the contents of that specific log - now I have to click the contribs for the user, click the logs, select the spamblacklistlog)).  :-( .. --Dirk Beetstra ^{T C} 10:30, 21 August 2016 (UTC)

$2 looks like it just expands to the username or IP. —Cryptic 11:19, 21 August 2016 (UTC)

Yes. The source of MediaWiki:Logentry-spamblacklist-hit says: {{GENDER:$2|$1}} caused a spam blacklist hit on $3 by attempting to add $4. translatewiki:MediaWiki:Logentry-spamblacklist-hit/qqq says: "$2 - unused, or user who performed the action (to be used with GENDER)". It's transcluded from translatewiki:Template:Logentry so the "unused, or" part is apparently because the same documentation is used for similar messages. PrimeHunter (talk) 11:32, 21 August 2016 (UTC)

translatewiki:MediaWiki:Logentry-spamblacklist-hit/qqq also says: "Wiki markup is not supported in these messages". It's possible html with url's is supported but I don't know. PrimeHunter (talk) 11:41, 21 August 2016 (UTC)

I tried html and it didn't work. The html for a link was just displayed as plain text. PrimeHunter (talk) 12:03, 21 August 2016 (UTC)

The magic problem is, from translatewiki:Template:Logentry, Wiki markup is not supported in these messages. So I cannot add a custom link here :-(. --Dirk Beetstra ^{T C} 11:40, 21 August 2016 (UTC)

Display of {{Routemap}} in mobile view

{{Routemap}} is still having display problems in mobile view where the viewing area or the template's container object is narrow: see here (resize the browser window to be narrower). This is probably because the mobile view CSS adds width: 100% !important to all tables, which is quite annoying because Routemap uses nested tables for the groups of icons. Is there a workaround? (I tried using div tags instead, but they wrap in the desktop skins.) I've asked on MediaWiki talk:Common.css for assistance, but was ignored because it wasn't in a neatly formatted edit request with perfect instructions. –Jc86035 (talk • contribs) Use {{re|Jc86035}} to reply to me 06:09, 21 August 2016 (UTC)

You could define an 'opt-out' class in MediaWiki:Mobile.css and have the templates use those. —TheDJ (talk • contribs) 11:14, 22 August 2016 (UTC)

HTTP 403 error message

Have we ever used something like this image to reflect an HTTP 403 error? The image is used in that article, and between the quality of the image and the simple wording (allegedly dating from 2010), I'm doubtful. Nyttend (talk) 16:01, 21 August 2016 (UTC)

Some results from a Google search on "Error 403 bad bad, very bad request": Wikipedia:Reference desk/Archives/Computing/2010 May 21#Error 403 bad bad, very bad request, Wikipedia:Help desk/Archives/2010 June 21#Anyone ever gotten 403 errors for all Wikipedia/Wikimedia images?, wikitech:Bits.wikimedia.org/Varnish testing. It looks real. PrimeHunter (talk) 16:57, 21 August 2016 (UTC)

Oh boy, early testing of varnish for bits.wikimedia.org! Yep, that was definitely a thing. If you look at the history for that wikitech page the wording makes even more sense 😂 ^demon^{[omg plz]} 17:08, 21 August 2016 (UTC)

Unnecessarily high precision for watchlist notice

I got this notice on my watchlist earlier today:

Changes newer than 11.067339897156 seconds may not appear in this list.

That should probably be fixed, such a high precision is entirely unnecessary there. nyuszika7h (talk) 20:51, 21 August 2016 (UTC)

Purge links require confirmation step

Tracked in Phabricator
Task T135170

Tracked in Phabricator
Task T143531

Screenshot of error

Screen shot from trwiki

When clicking on a purge link, such as the one in my sandbox, or even adding ?action=purge to the top of any page, forces me to confirm that I wish to purge the page. This notice is the same as if I had logged out of my account and had tried to purge the page. It does not however, require a confirmation when I use the link provided by the "Add a "Purge" option to the top of the page, which purges the page's cache" gadget, even though the url appears to be the same. -- The Voidwalker ^Discuss 21:52, 21 August 2016 (UTC)

The action only looks like it's the same. What MediaWiki:Gadget-purgetab.js actually does is cancel the default action of the click, POST a request for the page with action=purge, then reload the page. I suppose it does this to avoid the confirmation step. The ability to skip the confirmation step is granted by the purge right, which all registered users should have. It appears there's a bug with the right. The js was edited on 22 May 2016. Was the bug anticipated? --Unready (talk) 23:28, 21 August 2016 (UTC)

The bug also affects purge tabs on meta:, and I first noticed this at about 22:41 (UTC). --Redrose64 (talk) 23:46, 21 August 2016 (UTC)

The gadget hasn't been updated on meta. --Unready (talk) 23:53, 21 August 2016 (UTC)

For those who are disinclined to read the Phab tickets, the change isn't a bug. It's intentional. The change to MediaWiki:Gadget-purgetab.js was indeed in anticipation of the change to action=purge. --Unready (talk) 09:55, 22 August 2016 (UTC)

I've also posted on mediawiki.org. --Unready (talk) 00:04, 22 August 2016 (UTC)

This is new behavior on all wiki's must have been bundled with a recent release (see screenshots above). — xaosflux ^Talk 00:45, 22 August 2016 (UTC)

• This looks like phab:T88044 / phab:T136375 all over again. I'll open a phab ticket. — xaosflux ^Talk 00:32, 22 August 2016 (UTC)

  Opened as phab:T143531. — xaosflux ^Talk 00:41, 22 August 2016 (UTC)

  Please comment on T143531 if you have an opinion if the prior behavior should be restored. — xaosflux ^Talk 01:16, 22 August 2016 (UTC)

• meta:User:Glaisher/autoPurge.js has been created to imitate the old behaviour. Is it something that would work as a default gadget? Jo-Jo Eumerus (talk, contributions) 08:20, 22 August 2016 (UTC)

I realize that the new confirmation step is slightly annoying, but this is a security fix. Previously, for purge actions, a GET request was being used to have the same effect of POST, and that's Not A Good Idea. So unless something is actively broken, rather than requiring an extra click, I put the odds of getting this reverted at basically zero. I understand that User:Krinkle updated the UTC clock gadget to skip the confirmation step here at enwiki, so you may want to consider that as an alternative to manually editing the URL. Whatamidoing (WMF) (talk) 09:27, 22 August 2016 (UTC)

That doesn't fix the pages with built-in purge links, such as Category:Pending AfC submissions. BethNaught (talk) 09:37, 22 August 2016 (UTC)

The "security" issue is that action=purge causes a database write for the page_touched column for that page, therefore embedding links with action=purge on foreign sites could somehow cause a problem. I pointed out in Phab that meta:User:Glaisher/autoPurge.js is probably going to be installed everywhere, so I'm unconvinced there's really any benefit to requiring a POST. --Unready (talk) 09:55, 22 August 2016 (UTC)

@Xaosflux: @Whatamidoing (WMF): I came here to report it too and I would like the old version that is auto-purge to be restored and an extra confirmation is very very annoying. If you want the confirmation step atleast a parameter or function should be provided in all purge templates and gadgets. The parameter can say confirm=no if confirmation is not wanted. Please place a oppose (to keeping of this new update) comment by on Phabricator from my side if possible because I am not registered out there. I look forward to this issue being resloved. — Preceding unsigned comment added by VarunFEB2003 (talk • contribs)

From what I've gathered from the Phab tasks, making you click an extra button isn't actually the goal, so scripts that hide that step from a user aren't necessarily a problem. The goal is to stop using GET to achieve a POST result. If that idea doesn't make your skin crawl, then think "when I'm just reading a page, the computer should not be editing the database".

Varun, you have an account at Phab:. Just click the login button in the top right, and look for the button at the bottom of the login screen with the [{yellow sunflower}] logo that says "Login or Register – MediaWiki" (underneath the big LDAP username/password fields – practically "hidden in plain view"). However, please don't post !votes there. Phabricator is a place for technical work, not for determining user consensus. (That happens here on wiki, and if it's relevant, then a link to the on-wiki discussion will get posted in the Phab task). Whatamidoing (WMF) (talk) 14:45, 22 August 2016 (UTC)

IP address update/tracking tool?

Anyone know of a tool I can use to monitor and be notified (like via RSS or something) when there are updates from a given IP range? I know I could set up a Twitter bot and hack the code to email me or dump to a file instead, but chances are good someone's already solved this problem. Ideas? Ivanvector 🍁 (talk) 23:21, 21 August 2016 (UTC)

Sounds useful for noticing the return of sock puppets. Doug Weller talk 13:39, 22 August 2016 (UTC)

action=raw on a JavaScript pretty path

Attempting to get the raw source of a JavaScript page, for example https://en.wikipedia.org/wiki/MediaWiki:Common.js?action=raw&ctype=text/javascript, fails with the message "Forbidden. Invalid file extension found in the path info or query string." Attempting to get raw JavaScript from index.php, for example, https://en.wikipedia.org/w/index.php?title=MediaWiki:Common.js&action=raw&ctype=text/javascript, works fine. Why is action=raw forbidden on a pretty path at Wikipedia? It works fine at other MediaWiki installations elsewhere. --Unready (talk) 23:39, 21 August 2016 (UTC)

AFAIK the /w/ form has always been needed for action=raw --Redrose64 (talk) 23:47, 21 August 2016 (UTC)

action=raw works fine here for non-JavaScript pages with a pretty path, for example, https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)?action=raw&ctype=text/javascript. Something special is happening with JavaScript (and CSS as well) at Wikipedia, presumably for a reason. What's the reason? --Unready (talk) 23:52, 21 August 2016 (UTC)

What's this

What's this

03:38, 19 August 2016: SSUCCK MY PUSSSY AND FUCCK ME ALADDIN PLEASE!! (talk | contribs) triggered filter 733, performing the action "edit" on User:Sro23, hi. Actions taken: none; Filter description: New user creating a page in someone else's userspace (details | examine) 03:37, 19 August 2016: SSUCCK MY PUSSSY AND FUCCK ME ALADDIN PLEASE!! (talk | contribs) triggered filter 733, performing the action "edit" on User:Sro23, hi. Actions taken: none; Filter description: New user creating a page in someone else's userspace (details | examine) 03:37, 19 August 2016: SSUCCK MY PUSSSY AND FUCCK ME ALADDIN PLEASE!! (talk | contribs) triggered filter 733, performing the action "edit" on User:Sro23, hi. Actions taken: none; Filter description: New user creating a page in someone else's userspace (details | examine) 03:37, 19 August 2016: SSUCCK MY PUSSSY AND FUCCK ME ALADDIN PLEASE!! (talk | contribs) triggered filter 733, performing the action "edit" on User:Sro23, hi. Actions taken: none; Filter description: New user creating a page in someone else's userspace (details | examine) 03:37, 19 August 2016: SSUCCK MY PUSSSY AND FUCCK ME ALADDIN PLEASE!! (talk | contribs) triggered filter 733, performing the action "edit" on User:Sro23, hi. Actions taken: none; Filter description: New user creating a page in someone else's userspace (details | examine) 03:36, 19 August 2016: SSUCCK MY PUSSSY AND FUCCK ME ALADDIN PLEASE!! (talk | contribs) triggered filter 733, performing the action "edit" on User:Sro23, hi. Actions taken: none; Filter description: New user creating a page in someone else's userspace (details | examine) 03:35, 19 August 2016: SSUCCK MY PUSSSY AND FUCCK ME ALADDIN PLEASE!! (talk | contribs) triggered filter 733, performing the action "edit" on User:Sro23, hi. Actions taken: none; Filter description: New user creating a page in someone else's userspace (details | examine) 03:34, 19 August 2016: SSUCCK MY PUSSSY AND FUCCK ME ALADDIN PLEASE!! (talk | contribs) triggered filter 733, performing the action "edit" on User:Sro23, hi. Actions taken: none; Filter description: New user creating a page in someone else's userspace (details | examine) 03:34, 19 August 2016: SSUCCK MY PUSSSY AND FUCCK ME ALADDIN PLEASE!! (talk | contribs) triggered filter 733, performing the action "edit" on User:Sro23, hi. Actions taken: none; Filter description: New user creating a page in someone else's userspace (details | examine)

in the Abuse Log No usernames exist or registered. VarunFEB2003 ^{I am Offline} 13:05, 22 August 2016 (UTC)

@VarunFEB2003: If you're wondering why it seems like the user made these edits, with no action taken, multiple times, that's because their edits were disallowed by other filters. Sam Walton (talk) 13:18, 22 August 2016 (UTC)

Oh wait, I think I see what you mean. The user is apparently blocked (I see 'change block'), but there's nothing in the block log for them for some reason. Sam Walton (talk) 13:20, 22 August 2016 (UTC)

It's a vandal. The edits were disallowed by other filters. You can tell they exist from the 'contribs' link when you're looking at their userpages. You can tell they were blocked and suppressed from the 'accounts' link at the bottom of the contribs page. -- zzuuzz ^(talk) 13:21, 22 August 2016 (UTC)

HTML tidy or ?

Isanae and PrimeHunter posted a thread at Wikipedia:Help desk about a quirk which I was able to simplify to the following:

Example

Item 1

This is a table for Item 2

Item 3 (double indented)

why is this text indented?

and why is this text indented?

but this finally breaks the indentation (at least as viewed in Firefox).

What is causing this? HTML tidy? thank you. Frietjes (talk) 14:00, 22 August 2016 (UTC)

Category:Created via preloaddraft should not be visible in mainspace

But it is. This may need some fix now and to prevent it from being mainspace-visible in the future. --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 14:31, 22 August 2016 (UTC)