Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia
Jump to: navigation, search
  Policy   Technical   Proposals   Idea lab   Miscellaneous  
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.

« Older discussions, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148
Centralized discussion
Proposals: policy other Discussions Ideas

For a listing of ongoing discussions, see the dashboard.

Note: entries for inactive discussions, closed or not, should be moved to the archive.


August 4 Echo changes[edit]

Echo icons still backwards[edit]

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?—cyberpowerChat: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.—cyberpowerChat: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.—cyberpowerChat: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, –Davey2010Talk 09:48, 5 August 2016 (UTC)
  • So with a unanimous discussion so far, can these be flipped?—cyberpowerChat: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?—cyberpowerChat: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.—cyberpowerChat:Online 11:25, 8 August 2016 (UTC)
Thread bump. Any update on this?—cyberpowerChat: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.—cyberpowerChat:Online 11:26, 16 August 2016 (UTC)
FWIW, I never understood the intended meanings of the 2 icons in the first place. Nevermind being "backwards" or not: to me, the icons don't carry any clear meaning (oh, that's an Inbox?? OK…). And the labels, "Your alerts" and "Your notices", don't really help at all. (And I'm a native English speaker.) - dcljr (talk) 10:18, 24 August 2016 (UTC)
@Dcljr: Do what I do - when one of them lights up, click it to see why. Don't worry about the shapes or meanings of the symbols, just the colours - red=danger; blue=probably nice. --Redrose64 (talk) 10:54, 24 August 2016 (UTC)
I've said it a gazillion times. To me the symbols have a very clear meaning and they are backwards. It seems to be clear that we need entirely different icons here. Especially when someone thinks the letter tray looks like a bikini top. :p—cyberpowerChat:Offline 00:31, 26 August 2016 (UTC)
I'm with Rose, although I've only said it once. Actually I don't even care about the colors. The one on the left (port) appears to be for reverts, pings, etc., and the one on the right (starboard) for thanks, user talk, etc. No matter which one shows a number on it, I'll always have time to click it within a minute or two, and I won't see more urgency for one than for the other. I think the one on the left could be seen as a stylized hat of some kind, maybe a tall derby, and so what, and I don't care if some people see a bikini top in the other one (what, are some offended by their own Rorschach-like pornographic interpretations of icons?). It would make no difference to me if the icons were A and B, X and Y, or butterfly and bumblebee, they would lose no functionality. Any effect on the brand-new, first-time editor lasts about 5 minutes, and much of that would exist no matter what the icons looked like. I almost never call WP:BIKESHED, but I'll make an exception here. ―Mandruss  02:17, 26 August 2016 (UTC)
@Cyberpower678: If you would like the two icons exchanged, that's easy:
#pt-notifications-notice .mw-echo-notifications-badge::before {
  background-image: url(data:image/svg+xml,;
  background-image: url(/w/extensions/Echo/modules/icons/bell.svg?26cec)!ie;
#pt-notifications-alert .mw-echo-notifications-badge::before {
  background-image: url(data:image/svg+xml,;
  background-image: url(/w/extensions/Echo/modules/icons/tray.svg?e57e5)!ie;
this goes in m:Special:MyPage/global.css. You can also change the icons to anything you like, if you either have a file ready, or understand SVG. Yes, those two icons are pure SVG, just percent-encoded; this is what they look like afrer unencoding:
<?xml version="1.0" encoding="utf-8"?>
<svg xmlns="" width="24" height="24" viewBox="0 0 24 24">
    <path d="M17.5 14V9c0-3-2.3-5-5.5-5S6.5 6 6.5 9v5c0 2 0 3-2 3v1h15v-1c-2 0-2-1-2-3zM12 20H9c0 1 1.6 2 3 2s3-1 3-2h-3z"/>
<?xml version="1.0" encoding="utf-8"?>
<svg xmlns="" width="24" height="24" viewBox="0 0 24 24">
    <path d="M3 13.35l1.8-7.2c.2-.996.81-1.8 1.8-1.8h10.8c.99 0 1.6.867 1.8 1.8l1.8 7.2v4.5c0 .99-.81 1.8-1.8 1.8H4.8c-.99 0-1.8-.81-1.8-1.8v-4.5zm6.96 1.8h4.08c-.49.557-1.212.9-2.04.9a2.68 2.68 0 0 1-2.04-.9h4.08c.414-.472.66-1.098.66-1.8h4.14l-1.44-7.2H6.6l-1.44 7.2H9.3c0 .702.246 1.328.66 1.8z" id="tray"/>
Only two elements in each icon, and just one of them actually makes a shape, it's a path element. --Redrose64 (talk) 09:15, 26 August 2016 (UTC)
Thank you thank you thank you. My problems are now solved. :D—cyberpowerChat:Online 12:38, 26 August 2016 (UTC)

Echo bell icon glitch[edit]

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.--JohnBlackburnewordsdeeds 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.--JohnBlackburnewordsdeeds 20:19, 4 August 2016 (UTC)
Ah, my own darn fault. fixed.--JohnBlackburnewordsdeeds 20:28, 4 August 2016 (UTC)

Notification icons[edit]

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)
Vpt redrose64 alerts.PNG
@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—cyberpowerChat:Online 08:17, 5 August 2016 (UTC)
Does IE still exist ? .... Thought it had died years ago! Face-smile.svg}. –Davey2010Talk 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.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.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;
Vpt redrose64 alerts3.PNG
Vpt redrose64 alerts2.PNG
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[edit]

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:

#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—cyberpowerChat: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.—cyberpowerChat: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[edit]

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—cyberpowerChat: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—cyberpowerChat: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[edit]

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[edit]

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

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: 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!!![edit]

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)

Inline math tags on mobile[edit]

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 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)
@Whatamidoing (WMF): the mobile team does a great job trying to make wikipedia on mobile devices better. unfortunatley it seems that math support was something they did not have on the radar. However, now they try to fix the problem. my recommondations is not use images for mathematical expressions at all since they are integral part of the text. Better use and get nice math rendering without images--Physikerwelt (talk) 19:44, 26 August 2016 (UTC)

Recent changes concerning mobiles[edit]

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 (talkcontribs) 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)
@Prisonermonkeys thank you for reporting this, and thanks @TheDJ for the confirmation. I filed We'll need potentially several days to troubleshoot.
This seems familiar, I think that it may be related to Wikipedia:Village pump (technical)/Archive 144#NBSP is not working. --Redrose64 (talk) 20:32, 22 August 2016 (UTC)
@Melamrawy (WMF) — the issue has mostly been fixed, but it is still not quite right. There should be a space between the flag and the following text; as it is, they're hard up against one another (and in some cases, like the Swiss flag), they overlap. I tried sticking a non-breaking space into an article to fix it, but to no avail.
This is what it looks like now.
Hope that helps. Prisonermonkeys (talk) 20:41, 23 August 2016 (UTC)
Spacing issue appears to have been resolved, but now flags are too big for the apace allowed, so they end up showing about 60% of the actual flag. Prisonermonkeys (talk) 23:20, 23 August 2016 (UTC)


@Melamrawy (WMF), @TheDJ, @PrimeHunter — not quite sure who I should be tagging here, but the flagicons (and, I assume, the related issues) are nearly fixed, but are not quite there:

This is what it looks like now

Prisonermonkeys (talk) 20:17, 25 August 2016 (UTC)

Display of {{Routemap}} in mobile view[edit]

{{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 (talkcontribs) 11:14, 22 August 2016 (UTC)
@TheDJ: It seems that it apparently doesn't require CSS rules (amazingly enough), so never mind that. On the other hand, I didn't notice this before but the inline images (like the interchange logos and arrows) in the infoboxes (section 2 in the testcases page) display below the text because of the .lazy-image-placeholder class (which makes the images display:block). How could this be fixed? Jc86035 (talk • contribs) Use {{re|Jc86035}} to reply to me 15:23, 22 August 2016 (UTC)
@Jc86035: Yeah, note how a few topics higher, there are problems with images for tables of Formula 1 races. This is the same cause. If you use the desktop site with useskin=minerva, you don't get that experiment, and things probably behave as you might expect. —TheDJ (talkcontribs) 08:31, 23 August 2016 (UTC)
@TheDJ: Oh, okay then; hopefully they'll fix it soon. Thanks! Jc86035 (talk • contribs) Use {{re|Jc86035}} to reply to me 11:07, 23 August 2016 (UTC)
{{Routemap}} is a PITA. I simply cannot work out its syntax, nor why there is a sudden drive to convert all RDTs to this weird non-intuitive format. The only valid reason for conversion is if articles transcluding such RDTs are in Category:Pages where template include size is exceeded and all other fixes have failed. When somebody does this for no discernable reason, and I revert, and they then do it again without so much as starting a discussion, it's clearly disruptive. --Redrose64 (talk) 20:42, 22 August 2016 (UTC)
@Redrose64: This doesn't really have much to do with its display problems (which both {{BS-map}} and {{BS-table}} share), but I've tried to make the documentation slightly easier to understand (colouring, correcting the grammar, etc.). Jc86035 (talk • contribs) Use {{re|Jc86035}} to reply to me 07:35, 23 August 2016 (UTC)
If Useddenim decided to convert a diagram… well, we had an RfC last year. I note that the closing comment was obviously very vague in regards to converting diagrams and the discussion below stalled mainly because of your and Mjroots's opposition, so perhaps we might need another one to clarify when (or if) diagrams should be converted (especially in regards to double-sidebar diagrams). Jc86035 (talk • contribs) Use {{re|Jc86035}} to reply to me 07:44, 23 August 2016 (UTC)
Useddenim needs to remember that it's WP:BRD, not WP:BR∞(D[maybe]). My position hasn't changed. Diagrams should only be converted where there is a technical need to do so. New diagrams should be a matter of creator's choice, and not converted from one to the other unless necessary as outlined above. Mjroots (talk) 06:41, 24 August 2016 (UTC)
As I mentioned at en:User talk:Redrose64#Medway area RDT, "{{Routemap}} ... does make editing double-side ({{BS-2}}) RDTs substantially easier (because {{Routemap}} parses left-to-right, as displayed, instead of 'icons | left | right | left | right | right') ... So for double-sided diagrams I do consider the conversion 'technically necessary'." Useddenim (talk) 15:42, 24 August 2016 (UTC)

Also broken for math[edit]

It seems this same experiment has broken the rendering of math images on the mobile website. Filed a separate report. —TheDJ (talkcontribs) 07:56, 24 August 2016 (UTC)

A reader contacted Wikimedia (ticket:2016082710000806) with a problem viewing math equations so I automatically assumed it was related to this. However they note: "I'm using Safari 5.0.6 as my browser and am on a MacBook, OS 10.5.8." This doesn't sound like the mobile problem.--S Philbrick(Talk) 21:54, 28 August 2016 (UTC)

Purge links require confirmation step[edit]

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 --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've suggested a slightly improved (IMO) version to preserve other query parameters and the fragment, if any. Something like one or the other will probably make it into MediaWiki:Common.js. In the meantime, people can put it in their personal common.js.
mw.loader.using( [ 'mediawiki.api' ], function () {
	if ( mw.config.get( 'wgAction' ) !== 'purge' ) {
	new mw.Api().post( {
		action: 'purge',
		titles: mw.config.get( 'wgPageName' )
	} ).then( function () {
			location.pathname +
				.replace( /(?:\?|&)action=purge$/ , '' )
				.replace( /(\?|&)action=purge&/ , '$1' ) +
	}, function ( e ) {
		console.log( 'Purge failed', e );
	} );
} );
--Unready (talk) 12:49, 23 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 (talkcontribs)
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)
Hi Whatamidoing (WMF) - this is mostly of the "annoying" variety - though it is the same behavior of rolling out changes without reviewing the use cases that was caused when this same change was made for the rollback action. The overall impact is certainly less, but so long as "purging" is something that is needed to get the the current version presented to readers available - I don't expect the need for the purge ability to go away soon. — xaosflux Talk 14:56, 22 August 2016 (UTC)
Just to be extra-clear: nobody's interested in taking away the purge function. Whatamidoing (WMF) (talk) 20:09, 22 August 2016 (UTC)
Somehow I didn't get a ping (Why?) Now @Xaosflux: @Whatamidoing (WMF): what I am going to tell you is something you might have forgotten. Do you often come across Update/Refresh links. We often use them instead of 'purge' to not directly show new users because it is bound they will get confused because purge is a new term for them. The extra step creates more confusion for new users as it asks you - "Do you wish to purge this page" which makes them feel as if they are going to perform a big step. {{Purge button}} has an update link that was specifically designed so that new users don't get confused See its talk page. If the code given above ↑ is telling that this step is going to be removed then forget this request of mine. I look forward to this issue being resolved and that silly confirmation be removed. What harm can a direct purge even do? GET to achieve a POST result I didn't get this! VarunFEB2003 I am Offline 13:31, 23 August 2016 (UTC)
@VarunFEB2003: You didn't get a notification because in this edit, Whatamidoing (WMF) (talk · contribs) didn't add a new post, they modified an existing line.
HTTP GET and HTTP POST are the two principal methods of submitting a query to a web server. The main difference is that with GET, you put all the parameters (name=value pairs, separated by ampersands) into the URL as a query string. When you visit a page like this is a GET request and the query string is title=Wikipedia:Village_pump_(technical)&action=history which has two parameters. POST does not use a query string, it sends all the data in one big block. When you edit a Wikipedia page and click Save page, this sends a POST request. --Redrose64 (talk) 17:12, 23 August 2016 (UTC)
@Redrose64: @Whatamidoing (WMF): Sounds gibberish for a technically illiterate(almost) like me! I am just waiting when this problem will be resolved. Most of the wikipedians are against it! VarunFEB2003 I am Offline 11:18, 24 August 2016 (UTC)
@VarunFEB2003: You asked why you didn't get a notification, so I told you. You said "GET to achieve a POST result I didn't get this" so I gave information on HTTP GET and HTTP POST. --Redrose64 (talk) 11:44, 24 August 2016 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────OkVarunFEB2003 I am Offline 11:52, 24 August 2016 (UTC)

@Whatamidoing (WMF): When are the changes being made to the global js? VarunFEB2003 I am Offline 14:52, 24 August 2016 (UTC)
I don't know if it will be done. MediaWiki:Common.js is normally handled by local admins, so I am not involved in scheduling anything there. Whatamidoing (WMF) (talk) 07:55, 26 August 2016 (UTC)

HTML tidy or ?[edit]

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

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)

You can see the page source:


<dd>Item 1</dd>




<td>This is a table for Item 2</td>




<dd>Item 3 (double indented)</dd>


<p>why is this text indented?</p>

<p>and why is this text indented?</p>



<p>but this finally breaks the indentation (at least as viewed in Firefox).</p>
The user inputed code is not modified. So, it is looks like parser confusion. Ruslik_Zero 19:57, 22 August 2016 (UTC)
This is related to Wikipedia:Village pump (technical)/Archive 148#Nested templates are glitching, can't find the reason. --Redrose64 (talk) 22:09, 22 August 2016 (UTC)
And Frietjes - this edit won't have notified Isanae. But this one will. --Redrose64 (talk) 22:13, 22 August 2016 (UTC)
Alright, I've dug a bit into mediawiki. This has nothing to do with tidy, I can reproduce the bug with and without it. It's how it parses block elements such as ; or : in doBlockLevels() from includes/parser/Parser.php. The parser opens a <dl><dd> block when it sees a prefixed : and will close it with </dd></dl> at the next line without a :. But it doesn't seem to notice that there are other tags that were opened by the user (such as <table> here) and so will close a block even if a table (or anything, really) is still opened. A quick fix to the example above is to add a : to the second line:
Item 1
This is a table for Item 2
Item 3 (this is okay)

not indented anymore

neither is this

So the fix that was done at IPv4 by Frietjes was to add HTML comments in a way that the whole thing ends up on one line (comments are removed prior to parsing).
I don't have a quick fix. doBlockLevels() seems very messy. I see stuff like "eh?", "The one nasty exception", a "XXX" about using stacks for nestable elements (which might be it) and notes about bugs #5718 and $785, all that in 200 lines. Isa (talk) 01:07, 23 August 2016 (UTC)
Tim_Starling looked at rewriting doBlockLevels() properly a couple of months ago. Unfortunately, I think he came to the conclusion that there's no easy fix. C. Scott Ananian (talk) 21:29, 23 August 2016 (UTC)
A line break terminates a wiki-formatted list item, so attempting to straddle HTML tags across the line break boundary is incorrect and will have unintended consequences regardless of how we choose to clean it up. You should use HTML tags for template output formatting where possible, since they are less sensitive to line breaks. -- Tim Starling (talk) 23:59, 23 August 2016 (UTC)
@Tim Starling: Just out of curiosity, what would you have done instead of this? I can't put ; within the template markup to prevent the parser from closing blocks. Are you saying that in this particular instance a <dl><dd> block should be used instead of ;? Isa (talk) 01:19, 24 August 2016 (UTC)
Yes. I tried it out and it seemed like a huge improvement, so I was bold and went ahead and hit save. The source is much more readable thanks to extra line breaks and the removal of all workaround templates like {{unordered list}} and {{paragraph}}. -- Tim Starling (talk) 06:48, 24 August 2016 (UTC)
for definition lists we also have {{term}} and {{defn}}, but you can't put wikitables inside without using something like {{aligned table}} or changing all of the bars to {{!}}. an even better option for that article, in my opinion, would be to use subsections rather than the term/definition list format. Frietjes (talk) 12:37, 24 August 2016 (UTC)
For completeness, FWIW, this is probably also related: Wikipedia:Help desk/Archives/2016 January 23#text not left-justified after nested tables. Basically dropped as minor/lack of interest. For posterity, here is a permalink to the relevant user sandbox page: [1]. ―Mandruss  00:28, 24 August 2016 (UTC)

Page Curation toolbar innaccessible after I edit the article[edit]


I was doing page curation and came to Ooredoo Oman. I did a few edits to improve sourcing and tone as well as to tag and then went to mark the page reviewed. The Page Curation toolbar had disappeared and was not in the toolbox on the left hand side. This is the second time this happens (I can't remember the name of the first article). Is it perhaps some sort of smart "page creator" detector going wonky? (BTW I'm running Chrome on Windows 8.1) Happy Squirrel (talk) 22:33, 22 August 2016 (UTC)

FWIW, the page was marked as patrolled over three months ago. Graham87 07:47, 23 August 2016 (UTC)
Yes, but it was expanded from a redirect more recently so it shows up at Special:NewPagesFeed as being in need of review. Happy Squirrel (talk) 14:48, 23 August 2016 (UTC)
Did you try reloading the page? You made three edits, and the last was in the wikitext editor. Did it reappear after that third edit? Whatamidoing (WMF) (talk) 07:26, 24 August 2016 (UTC)
It's still not appeared and I've tried reloading a few times. It has started happening on articles I have not edited. Happy Squirrel (talk) 15:21, 24 August 2016 (UTC)
@Happysquirrel: Briefly: Just reload Special:NewPagesFeed, if the toolbar isn't appearing, which will reset the related cookie. Context: The logic for when the toolbar appears is a bit complicated; IIUC this is to prevent multiple-additional server requests on every article load (e.g "is this article reviewed yet" and "does this viewer have the user-right to patrol"). HTH. Quiddity (WMF) (talk) 17:34, 26 August 2016 (UTC)

Buggy blocking page[edit]

This all grows out of a joke block, but it may have non-joke applications.

See, the block log for the block-test account User:ThisIsaTest. I discovered that a block duration of 0.9999999999 seconds causes the block to expire in 2001, a block duration of 0.99999999999 seconds, i.e. one more "9" than the previous block, causes it to expire in 2286, and 0.999999999 seconds, one "9" shorter than the first block, causes it to expire in 1973. All generally irrelevant to real-life blocks. I then wondered about shorter blocks; 0.999999 seconds has a 1970 expiration, but 0.9 through 0.99999 are impossible because "Expiry time is in the past".

Why is it possible to block people with an expiration in the past under certain circumstances, but it's not possible in other circumstances? Obviously it's intended that blocks with past-date expirations be prohibited, so the fact that it's possible to make a past-date block is a problem. Real-life blocks can always be set in the past if you make a typo somewhere in the block settings, so it seems to me that despite its joke origins, this is a problem that actually needs to be addressed. Nyttend (talk) 03:11, 23 August 2016 (UTC)

See, T133438. To avoid, it appears you simply have to avoid decimals in a block duration. ~ Matthewrbowker Drop me a note 05:27, 23 August 2016 (UTC)
I understand (that's the joke side), but the issue is the fact that past blocking dates aren't always prohibited, whether or not they're jokes. Perhaps you'd put in a specific date for expiration, and you accidentally type 2015 instead of 2016. In at least some cases, the software allows such a block to work, even though it also records a past date; I'm suggesting that (if it's an easy change to make) the software always consider the date that will be put in the block log, and see if it's a future date, before allowing the block to go through. Nyttend (talk) 11:58, 23 August 2016 (UTC)
That seems to me like something that should have been done years ago. I don't see any useful reason for allowing blocks that expire in the past. I also think decimals, fractions, etc. ought to be disallowed. Their unexpected behavior is a wellspring of confusion for anyone who isn't a programmer with intimate knowledge of floating point and PHP behavior. -- (talk) 00:28, 27 August 2016 (UTC)

Can stats histories be merged after a page move?[edit]

Price Daniel, Jr. was moved to Price Daniel Jr. (the difference being no comma). The edit history merged with the move. However, the stats history remains with the old page, now a redirect. Is there a way to merge the stats? Redirects, old or new, are often at Category:Candidates for speedy deletion. I'm thinking the stats history gets lost entirely with a redirect delete. Any solutions? — Maile (talk) 12:53, 23 August 2016 (UTC)

@Maile66: It took me a while to nut out your message, but I assume you're talking about the output of the "Revision history statistics" tooll found from the history. The output of that tool is delayed by replication lag on the Wikimedia Labs server. It seems fine now. Graham87 03:42, 24 August 2016 (UTC)
Graham87 You misunderstood. Nothing was wrong with the stats tool. I should have linked for you. The stats tool only reflects the history as of the date the article was moved, new article name stats history. All the previous stats history is on the redirect created by the move redirect stats history. This happens with every page move. My question, is can the old stats history under the redirect be merged into the new stats history? — Maile (talk) 11:50, 24 August 2016 (UTC)
@Maile66: Ah, you meant the page view stats tool. Nope, that cannot be done, and IMO it isn't advisable because someone might like to know the page view stats for a page title before it became an article. P.s. your attempt to fix your ping to me didn't work because the mentions system requires a completely new line with a new signature to function properly. Graham87 12:07, 25 August 2016 (UTC)

Deployment of ORES review tool in English Wikipedia as a beta feature[edit]

Hey folks,

A "likely damaging" edit is highlighted in Special:RecentChanges by the ORES extension.

We (The Revision Scoring Team) are happy to announce the deployment of the ORES review tool as a beta feature on English Wikipedia. Once enabled, ORES highlights edits that are likely to be damaging in Special:RecentChanges, Special:Watchlist and Special:Contributions to help you prioritize your patrolling work. ORES detects damaging edits using a basic prediction model based on past damage. ORES is an experimental technology. We encourage you to take advantage of it but also to be skeptical of the predictions made. It's a tool to support you – it can't replace you. Please reach out to us with your questions and concerns.

mw:ORES review tool, mw:Extension:ORES, and m:ORES
Bugs & feature requests

--:)Ladsgroupoverleg 18:07, 23 August 2016 (UTC)

I'm really happy we've made it here, folks. This tool has been deployed to Persian, Turkish, Russian, Portuguese, and Dutch Wikipedias as well as Wikidata. The only reason it took so long to deploy here is because of how active English Wikipedia is. With recent work to build capacity, we were now confident enough to deploy. I hope you find the tool useful. Either way, we look forward to your feedback. See also mw:Edit Review Improvements for some design work that mw:Collaboration is doing to make patrolling and other types of boundary-work more efficient. --EpochFail (talkcontribs) 18:23, 23 August 2016 (UTC)
Hate to rain on the parade, but I just received a complaint from a productive editor who's already been flagged twice. Miniapolis 20:14, 23 August 2016 (UTC)
Also, the predictions seem ridiculously biased against IPs. I filtered my watchlist for IPs only and all of today's IP edits there have been flagged, including such edits as [2] and [3]. And that's on the "low sensitivity" setting. Shame; I was very excited for this, but I'm disappointed now it's out. BethNaught (talk) 20:25, 23 August 2016 (UTC)
Yes, I've noticed that as well on Wikidata. I've submitted "good edits" before but it was not into some kind of learning system, that I'm aware of. --Izno (talk) 20:38, 23 August 2016 (UTC)
(EC) It seems this might be a UI bug. I checked out a couple of the edits and ORES **does not** think they are vandalism. E.g. see Special:Diff/735738822 and I've filed a bug for this. See Phab:T143738. I think that either by changing the UI or making some changes in ORES, we can have this issue addressed during tomorrow's deployment. Thank you for reporting. --EpochFail (talkcontribs) 20:41, 23 August 2016 (UTC)
  • How are the scores calculated? Is it possible to improve them by reviewing edits, like you can for ClueBot NG? BethNaught (talk) 20:49, 23 August 2016 (UTC)
  • There also seems to be an issue about reviewing the marked edits. The guide notes say "If you reviewed an edit and realized it's not vandalism, you can simply mark it as patrolled and the highlighting and flag will be removed." Most of the edits do not show in any list as unpatrolled so the [Mark page as patrolled] option doesn't appear. Nthep (talk) 20:56, 23 August 2016 (UTC)
    • This is because RC Patrolling is disabled for English Wikipedia. I've filed a task to get that enabled, but there might need to be an RFC. See Phab:T143791. --EpochFail (talkcontribs) 14:41, 24 August 2016 (UTC)
    I agree. Of the 6 most recent changes which were marked, 2 were undoubtedly good - this is a style issue which looks better after the fact, and this clarifies the point the article is trying to make. עוד מישהו Od Mishehu 03:54, 24 August 2016 (UTC)
  • I just turned it on (yay!) and found that almost none of the highlighted edits were worrisome. In some, I could easily see why it was concerned (e.g., the use of the word victim), but in others, it was flagging minor things (e.g., fixing capitalization). Are we absolutely certain that it's reading the correct side of the diff? This edit was highlighted, but it's the reversion of spammy vandalism. WhatamIdoing (talk) 08:27, 24 August 2016 (UTC)

I put some notes in the mediawiki page. I repeat it here "Note that we deliberately set the default threshold so low to capture all vandalism cases so false positives are expected unlike anti-vandalism bot that set the threshold so high to capture only vandalism cases (and don't have false positives). If you don't want to see the flag for most edits, you can simply change ORES sensitivity (see below)." :)Ladsgroupoverleg 10:32, 24 August 2016 (UTC)

  • Bit more rain on this new, and seemingly too early, WMF deployment. I found Special:Contributions/Dharmadhyaksha of User:Dharmadhyaksha quite shocking after reviewing some 'questionable' edits on my watchlist. 16 out of 50 edits (2 days worth of editing) are flagged, and that on an editor who is here for 5 years. Don't bite the newbies ... but ... --Dirk Beetstra T C 11:11, 24 August 2016 (UTC)
@Beetstra: Have you tried changing the ORES sensitivity in your preferences? :)Ladsgroupoverleg 11:38, 24 August 2016 (UTC)
@Ladsgroup: No. But if I do set the sensitivity lower they indeed disappear. But on low they still trigger on Special:Contributions/Bayonett, someone who is here since 2007. --Dirk Beetstra T C 12:01, 24 August 2016 (UTC)
@Beetstra: One edit is bearable. Overall, I need to explain it's AI and it only recommends and false positives are expected. We can set the threshold so high that you won't see any false positives but you will lose so true vandalisms too. We are iterating to make it better and have better balance in number of false positives and percentage of vandalism we can catch but that's how AI works. :)Ladsgroupoverleg 12:08, 24 August 2016 (UTC)
Ladsgroup, I asked above but it seems you didn't see: is there a way we can help review edits to train the AI? I believe ClueBot does this. BethNaught (talk) 12:15, 24 August 2016 (UTC)
I second that part, indeed. All flagged edits should just get 'not vandalism' / 'correct, this is vandalism' / 'meh' links, that editors can click to 'teach' the engine mistakes, good edits and questionable cases. Otherwise the AI stays stupid (and currently it flags obviously good edits). --Dirk Beetstra T C 12:28, 24 August 2016 (UTC)
@BethNaught and Beetstra: Yes, See WP:Labels :)Ladsgroupoverleg 12:31, 24 August 2016 (UTC)
@Ladsgroup: Regarding User:Bayonett. They now have two edits out of 6 to a page flagged:
  • diff - removal from one section, not flagged
  • diff - re-addition of the same info, somewhere else, flagged
  • diff - removal from one section, not flagged
  • diff - re-addition of the same info, somewhere else, not flagged
  • diff - addition of new info of the same style as the previous two additions, flagged
Seems all very inconsistent. --Dirk Beetstra T C 12:39, 24 August 2016 (UTC)
Side note: This tool is currently a Beta Feature, so it's restricted to logged-in users who have personally opted in. It's not really "deployed". Whatamidoing (WMF) (talk) 08:03, 26 August 2016 (UTC)

@Ladsgroup: so to help educate the AI needs the installation of another gadget? That I suppose is about ok but what is lacking now is the simple button that says "I have reviewed this edit and it is no longer problematic so please remove the flag so it doesn't show for me or any other editor as needs reviewing". I'm not really bothered if this educates the AI or not but it stops human time being wasted looking at edits that others have already reviewed. Nthep (talk) 13:30, 24 August 2016 (UTC)

Hi Nthep, most other Wikipedias have RecentChanges mw:Extension:Patroller enabled. That provides the exact functionality you are looking for and ORES is designed to integrate with it. I've filed a task to enable this on English Wikipedia. See Phab:T143791, but you'll probably need to do an RFC to get consensus. --EpochFail (talkcontribs) 14:29, 24 August 2016 (UTC)
A couple of notes:
  1. Wikipedia:Labels/Edit quality is the homepage for those looking to help us with training ORES to make better predictions about the quality of edits.
  2. It looks like I was mistaken re. mw:Extension:Patroller. It's not what we're looking for since RC Patrolling has been integrated into MediaWiki core. Instead, we need to enable it with $wgEnableRCPatrolling config flag. --EpochFail (talkcontribs) 14:38, 24 August 2016 (UTC)
Is there any way of specifically working on tagging specific changes to specific article, for example those that show up on my watchlist? Happy Squirrel (talk) 15:35, 24 August 2016 (UTC)

I wanted to note that we changed the default ORES sensitivity from "High" to "Low" meaning you will feel a drop in number of false positives if you haven't changed your preferences. You can simply change it back in your preferences if you think the old way was better. :)Ladsgroupoverleg 20:34, 24 August 2016 (UTC)

@Ladsgroup: in the code, do 'high' and 'Low' numerical 'thresholds' or is it binary? If it are 'percentages' then I would suggest to make more levels. At the moment, Low misses A LOT, and high, as noted above, irrationally catches a lot. --Dirk Beetstra T C 11:49, 25 August 2016 (UTC)
The threshold is not binary, We chose it based on recall and precision. The "low" one has 75% recall and 86% precision. The "high" one has 90% recall and 69% precision. Source :)Ladsgroupoverleg 09:21, 26 August 2016 (UTC)

Enabled it, noticed that every flagged edit now appears four times in my watchlist (one highlighted and three non-highlighted). This includes perfectly innocuous edits by (WMF)-labeled accounts like here, which is ironic but not helpful. this edit was shown four times in my watchlist and highlighted twice, meaning??? Well-established editors editing their own user page usually don't need review[4][5] Seeing my own edits[6] as needing review is useless.

Worst of all, when going down my watchlist, it shows all edits I expect to see from the most recent until the first one highlighted for review. From then on (i.e. going back in time) it only shows edits needing review and hides all other edits on my watchlist. The duplication of edits was annoying, but this is actually detrimental. As seems to be the habit with WMF deployments (beta or not), this is one to forget as soon as possible. Fram (talk) 16:15, 29 August 2016 (UTC)

I've been using it since WAID noted it on the Project Medicine noticeboard the other day. I rather like the highlighting, it takes no time for it to show me those things I may be interested in. I have noted a preponderance for it to show me real footballers, and what I think of as a very high number of BLPs, but perhaps that is a reflection of what is going on, vandalwise. As to the comments above, I'm sixty years old, you guys appear to be speaking in forrin. -Roxy the dog™ bark 16:49, 29 August 2016 (UTC)
Now I've just seen my watchlist. I'll just go and sit in this corner, at the back. -Roxy the dog™ bark 16:57, 29 August 2016 (UTC)

Regex or user script for simplifying piped links of mixed case[edit]

Moved to Wikipedia talk:User scripts#Regex or user script for simplifying piped links of mixed case. - dcljr (talk) 02:03, 25 August 2016 (UTC)

Check box[edit]

<inputbox> type=search namespaces=Main**,Help </inputbox> Displays:

How can I just take out the checkbox from it(I just need that box which is checkible on clicking. VarunFEB2003 I am Offline 13:57, 24 August 2016 (UTC)

Do you mean this:
See more at mw:Extension:InputBox. PrimeHunter (talk) 15:22, 24 August 2016 (UTC)
I knew that I'd seen this before, Wikipedia:Help desk/Archives/2016 July 16#Checkboxes. Wikipedia:Village pump (technical)/Archive 97#Inputbox with namespaces is broken seems strangely similar. --Redrose64 (talk) 20:52, 24 August 2016 (UTC)
@Redrose64: I just need the box containg the tick mark so when I click it, it gets checked and vice-versa! 11:28, 25 August 2016 (UTC)
Sounds like you're looking for mw:OOjs UI/Widgets/Inputs#Checkbox inputs. But what would you use the checkboxes for? — Mr. Stradivarius ♪ talk ♪ 12:29, 25 August 2016 (UTC)
That is exactly what I want but it ain't working in Wikipedia markup how do I use it here in the same form {{Checkbox}} is used. Those dropdown lists and all how can I use it here? @Mr. Stradivarius: VarunFEB2003 I am Offline 17:36, 27 August 2016 (UTC)


I have some JavaScript codes How do I make them work on Wiki? var checkbox1 = new OO.ui.CheckboxInputWidget( { value: 'a', selected: true } ); produces a selected checkbox. How do I and where do I place this Java Script code to get that checkbox this code produces? (I mean what steps should I follow to get that checkbox) VarunFEB2003 I am Offline 06:34, 28 August 2016 (UTC)

@VarunFEB2003: The answer to "where to place this code that produces a checkbox?" depends on where exactly you want the checkbox to be shown. Currently only you know the answer, I'm afraid... :) --Malyacko (talk) 11:50, 28 August 2016 (UTC)
I was coming back to withdraw this request did you see - {{Checkbox (Clickable)}} I succeeded in creating something that was considered almost impossible. VarunFEB2003 I am Offline 11:54, 28 August 2016 (UTC)
Ehm, that checkbox is not guaranteed to work / can break at any time. It for instance already does funky stuff on the mobile version. Please try to avoid such things, as they are not durable technology. For general information about the Javascript and styling stack of MediaWiki, you can turn to Developing with ResourceLoader, for information about the object oriented foundations of OOjs UI, read OOjs and OOjs UI. —TheDJ (talkcontribs) 08:16, 29 August 2016 (UTC)


I've seen {{localurl}} used in templates; but Template:localurl doesn't exist, and I can't find any documentation for it. Is there any? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:10, 24 August 2016 (UTC)

It's magic. See WP:MAGIC#Paths. -- zzuuzz (talk) 18:13, 24 August 2016 (UTC)

cross project use of templates?[edit]

How do you post the picture of the day from WikiMedia Commons on your userpage on Wikipedia? The Transhumanist 03:16, 25 August 2016 (UTC)

Do you know of another user that has this feature on their userpage? That is, is this a specific "how did they do that?" question or a more general "I have this idea..." plan? DMacks (talk) 03:21, 25 August 2016 (UTC)
@The Transhumanist and DMacks: Per Special:Interwiki the interwiki transclusion option is not active for any wiki. Which (I believe) means Scary Transclusion is not active on Enwiki. --Majora (talk) 03:35, 25 August 2016 (UTC)
There are ways to do commons images, and the specific example of "commons image of the day" would probably be doable in one of several ways with current configurations (and without making the servers keel over generally:). DMacks (talk) 03:45, 25 August 2016 (UTC)
@DMacks: You forgot to mention how. Make a template locally? The Transhumanist 03:49, 25 August 2016 (UTC)
(edit conflict) Image links and template transclusions work differently as far as I know. You can do File:Paul Chabas September Morn The Metropolitan Museum of Art.jpg and get today's Commons Picture of the Day. But you can't do {{c:Potd}} (c:template:Potd) and get a transclued version of it. I'm not aware of any way to get around that but I would be interested to know if you have any ideas. --Majora (talk) 03:52, 25 August 2016 (UTC)
That's why I asked about the scope of the idea here. Links and images are easy; transclusions definitely not-so-much on WMF projects. DMacks (talk) 03:55, 25 August 2016 (UTC)
I'm still experimenting:) But my first approach is to have the commons featured-image folks maintain a redirect to the daily picture from some static other filename that is not present on other wikis, updating it each time the main page rotates. Then anyone on any wiki can embed that image and it shows through. It works. But we'd need to get someone on commons to put this into their workflow. DMacks (talk) 03:54, 25 August 2016 (UTC)
It would probably just be easier to ask for scary transclusion to be turned on and only activated for the c: interwiki redirect. Unless you can program a bot for Commons that would update that redirect. I don't see the admins of Commons being too keen on adding additional work for themselves just to allow other wikis to have their POTD on their user pages. They have enough issues keeping up with all the copyvios. --Majora (talk) 04:00, 25 August 2016 (UTC)
Just realized that you were a Commons admin as well. Silly me. --Majora (talk) 04:01, 25 August 2016 (UTC)
Looks like #REDIRECT can only take a static pagename for file transclusion to work, so commons would have to manually update it each day (unlike the main page there, which determines it dynamically by templates). That is, a "File:foo" page that is "#REDIRECT [[{{something that determines a filename}}]]" will correctly display the image when viewing File:foo, but "[[File:foo]]" will not embed it properly. That might be a reasonable generic feature-request. DMacks (talk) 04:15, 25 August 2016 (UTC)
"It would probably just be easier to ask for scary transclusion to be turned on and only activated for the c: interwiki redirect." It has 'scary' in the name for a reason. I don't suspect the chances of getting this enabled on wikimedia websites is very high. —TheDJ (talkcontribs) 08:27, 25 August 2016 (UTC)
Wikipedia:Wikimedia Commons/POTD was based on copying data from Commons but it wasn't maintained and is marked historical. I updated Wikipedia:Wikimedia Commons/POTD/data and it displays the correct image and caption right now, but with some red links to English Wikipedia pages instead of the blue links at commons:Template:Potd. PrimeHunter (talk) 11:05, 25 August 2016 (UTC)
Scary transclusion is infeasible on enwiki for performance reasons, if I recall correctly. There are three other ways you could conceivably do this, though:
  1. Write a default gadget that pulls the data dynamically from Commons. This solution is quite neat, but given that only a few people would use it, it would be hard to justify the extra JavaScript code that every visitor to enwiki would have to download. Every extra bit of default JavaScript we use makes the site a little bit slower to load (although this is mitigated on repeat views by caching downloaded scripts).
  2. Write a MediaWiki extension to pull the data dynamically from Commons. This solution doesn't require all our visitors to download extra code, but all MediaWiki extensions need to go through security review and performance review from WMF staff, and given that it would likely only be used by a few people, they might be reluctant to turn it on. It is also the most technically complex solution, in my opinion. Which leaves us with:
  3. Write a bot to query Commons and save the data on enwiki when it changes. This has the disadvantage of not being in real time, and of the bot having to make a lot of edits for something that in an ideal world would require no edits, but is probably the best solution overall. The only approval needed would be a bot request (and if it edits in the bot's userspace, not even that, I think), and it wouldn't require all visitors to enwiki to download any extra code. — Mr. Stradivarius ♪ talk ♪ 12:50, 25 August 2016 (UTC)
If the data was updated daily at Wikidata then other wikis could pull it with a template. For example, [[File:{{#property:P117|from=Q153}}|thumb|{{#property:P274|from=Q153}}]] pulls a file name from wikidata:Q153#P117 (ethanol) and displays it with wikidata:Q153#P274 as caption. PrimeHunter (talk) 14:10, 25 August 2016 (UTC)
Ah, yes, that's a very good idea. I'm not sure how feasible it would be for the Commons people to update their workflow to include Wikidata, but if they don't want to change how they do things Wikidata could always be updated by bot. — Mr. Stradivarius ♪ talk ♪ 14:45, 25 August 2016 (UTC) and[edit]

Many articles use these websites as references for climate (weather) data in {{weather box}}. However, they have been changed (".net" removed, "www." added, "pogoda" changed into "pogodaiklimat"; "dossier.ogp" changed to "ftp.atdd", "/pub" added after ".gov") and now all those URLs are broken.

Does someone know how to fix this? To run bot or AWB (to add arhiveurls that exist [archivedate is around May 2012 for, for example; cannot or at least has not been archived] or to modify urls so that they work, by bot), or to write to their webmasters? Why don't they keep old URL formation still valid as they should know that many websites use them as sources?

And interesting is that some URLs still does not exist, e.g. is Sarajevo (; after search in archive (, entering "14654" and getting "Sarajevo (Босния и Герцеговина)", and clicking "Климат города" – result is "По запрошенному Вами геопункту климатические данные отсутствуют.".--Obsuser (talk) 10:30, 25 August 2016 (UTC)

[EC] The best solution would be to i) make a template, so that when the URL changes, we just have one update to make (this would mean using markup like {{Pogda klimat|22892}}) and ii) migrate the IDs to Wikidata, and have the template fetch them from there (this would mean using markup like {{Pogda klimat|22892}}). Once i) is done (and I'll get on that shortly), we can ask for a bot to convert existing uses, at WP:BOTREQ. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:57, 25 August 2016 (UTC)
One done: {{Pogda klimat}}, now used on Vyborg. Here is an example conversion. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:31, 25 August 2016 (UTC)
Another: {{NOAA normals}}, now used on Seychelles. Here is the Seychelles example diff. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:54, 25 August 2016 (UTC)
@Pigsonthewing: Very good solutions.
Should template get renamed as weather is "pogoda" in Russian, not "pogda"? My suggestion is {{pogodaiklimat}}, according to the current domain name. Redirect {{pogda klimat}} can be deleted after changing to {{pogodaiklimat}}, and then we may create one or two redirects – {{pogoda}} and {{}}, just in case.
Second question is why are pogodaiklimat WMO/ICAO values still not working if converted this way; can someone find another way to reformat old pogoda URL so e.g. 14654 (BH, Sarajevo) is working? I don't think that they deleted anything from website but I get "По запрошенному Вами геопункту климатические данные отсутствуют." for this particular WMO (WMO 22892 conversion for Vyborg worked, on the other hand)... --Obsuser (talk) 15:43, 25 August 2016 (UTC)

Routemap RfC[edit]

If anyone cares, I've opened an RFC on the conversion of route diagram templates to the Routemap format here. Jc86035 (talk • contribs) Use {{re|Jc86035}} to reply to me 11:42, 25 August 2016 (UTC)

Lua error: too many expensive function calls[edit]

Edit requests ({{edit semi-protected}}) are generating this error on Talk:Lena Dunham. There is one current request + error - the previous request made the same error when it was made. Can someone help to fix it? -- zzuuzz (talk) 20:04, 25 August 2016 (UTC)

Any Lua template is beyond my capabilities of fixing. Have you informed the template's maintainers, at Template talk:Edit semi-protected? Or it's module's maintainers, at Module talk:Protected edit request? --Redrose64 (talk) 20:50, 25 August 2016 (UTC)
It's been difficult to know where to begin, but I'll try the module talk page if there's no luck here. -- zzuuzz (talk) 21:02, 25 August 2016 (UTC)
It's not primarily a Lua problem. The page is reaching the expensive function call limit. The main issue is actually {{MonthlyArchive}} which is using about ~450 of the 500 call limit for the page. That leaves little room for other templates and Lua functions, with the last edit semi-protected template just going over the limit and failing. Dragons flight (talk) 21:08, 25 August 2016 (UTC)
476 to be precise. Yikes. {{MonthlyLinks}} calls #ifexist 34 times for a year, and {{MonthlyArchive}} uses it on each year since 2003. 34×14 = 476. If 2017 is added the same way then it will make 510 calls and always break the limit so we will soon have to deal with it. Tests for 2001 and 2002 were removed in 2014 after discussion at Template talk:MonthlyArchive. {{MonthlyLinks}} makes one initial test for only the year and then three for each month, by name or number with or without leading 0 (month 10, 11, 12 skip the leading 0 test). 1 + 12×3 − 3 = 34. PrimeHunter (talk) 22:08, 25 August 2016 (UTC)
I fixed the immediate problem for Talk:Lena Dunham by adding a |startyear= parameter to the template which cuts down the number of calls to {{MonthlyLinks}} - Evad37 [talk] 23:00, 25 August 2016 (UTC)
That's exactly what I was planning to do! PrimeHunter (talk) 23:07, 25 August 2016 (UTC)
I also added a |monthformat= parameter to both templates, which will further reduce the number of expensive calls. Now someone just needs to go through the transclusions, add the parameters with appropriate values, and we should be right until around 2040 - Evad37 [talk] 23:47, 25 August 2016 (UTC)

Entries showing up in deletion log[edit]

Hi, this is quite new... apparently deletion entries have started showing up in my deletion log despite not being a sysop. The operation was a simple move over 1-revision valid redirect. Was it re-implemented recently? — Andy W. (talk ·ctb) 21:39, 25 August 2016 (UTC)

Yes, see #Tech_News:_2016-34TheDJ (talkcontribs) 22:13, 25 August 2016 (UTC)
Right, mw:MediaWiki 1.28/wmf.16 was installed here today. The linked page should have contained a changelog but it's currently missing. Compare to mw:MediaWiki 1.28/wmf.15 which displays mw:MediaWiki 1.28/wmf.15/Changelog, while mw:MediaWiki 1.28/wmf.16/Changelog hasn't been created. PrimeHunter (talk) 22:29, 25 August 2016 (UTC)
There's something else related to this as well. For moves over redirects since 9 October 2013, the overridden redirect still appears with just the edit summary when viewing the contribs in mobile with an offset time near the original creation of the overridden redirect. Compare [7] with [8]. The overridden redirect is included in the former (from User:Jianhui67/sandbox to User:Jianhui67/sandbox/Gwendolyn Lee under 8 October 2013 next to 12:31), but not in the latter (from Red Tour to The Red Tour). These redirects were overridden in the moves by Jianhui67 (the same as the original creator of the overridden redirect) at 07:12, 9 October 2013 and Tbhotch at 05:59, 9 October 2013, respectively. Now overridden redirects no longer appear for moves over redirects done today, due to the above change. We should probably run deleteOrphanedRevisions.php (which might have last ran on 9 October 2013) so that overridden redirects will not be shown when viewing the contribs in mobile again. GeoffreyT2000 (talk) 01:54, 26 August 2016 (UTC)
Getting a closer offset: mobile vs desktop. Special:MobileDiff/576280881 shows up (incorrectly) only in Mobile view, whereas it's hidden in Desktop. Special:Diff/576290491 and Special:MobileDiff/576290491 works fine in both. Does this have a Phab ticket attached? — Andy W. (talk ·ctb) 03:31, 26 August 2016 (UTC)
Just got here to ask about this. Jo-Jo Eumerus (talk, contributions) 08:39, 26 August 2016 (UTC)

Talkpage alerts not in sequence[edit]

Why do my talkpage alerts now appear in apparently random sequence, rather than chronologically as before? Then, the latest alerts always topped the list; now, I have to scroll down the list to find the latest addition. At present, from the top, my alert timestamps are 4 days, 19 days, 1 month, 43 minutes, 44 minutes, 1 hour, 2 hours, 2 days...etc etc. Is this everyone's experience? Brianboulton (talk) 13:47, 26 August 2016 (UTC)

Searches including other wikipedias?[edit]

When did the search tool start including hits on *other* wikipedias? See , it gives one hit on the english language wikipedia and 3 on the portuguese wikipedia.Naraht (talk) 13:59, 26 August 2016 (UTC)

Just since last month. See the blog post Wikipedia seeks to speak your language for context, and mw:TextCat for technical details. HTH. Quiddity (WMF) (talk) 17:46, 26 August 2016 (UTC)

Missing a new article I'm working on in Sandbox[edit]

I was writing a new article in my sandbox yesterday at home on my laptop. I am now trying to work on it on another computer, and my work is not there! I am not the most technical it because I am on a different computer? Is there a way to retrieve it? Could I have accidentally sent it to be checked for posting? Please Help! I spent a lot of time on it (esp. with the technical aspect!) Thanks! — Preceding unsigned comment added by Pepspotbib (talkcontribs) 19:25, 26 August 2016 (UTC)

@Pepspotbib: I'm sorry but there is no sign of such an edit in Special:Contributions/Pepspotbib or other logs, and User:Pepspotbib/sandbox has not been edited since 2012. Inexperienced users sometimes misunderstand the interface and incorrectly think they have saved an edit. I guess you either clicked "Show preview" or overlooked a message after clicking "Save page". If you were logged in to this account and the browser window you were working in has been closed then your text cannot be retrieved. PrimeHunter (talk) 20:10, 26 August 2016 (UTC)
Is there any chance it was on a different Wikipedia project (i.e., not en)? --Unready (talk) 21:36, 26 August 2016 (UTC)
"other logs" in my post included Special:CentralAuth/Pepspotbib, deleted contributions and the edit filter. Nothing was found. PrimeHunter (talk) 22:11, 26 August 2016 (UTC)

Equazcion ScriptInstaller[edit]

When I try to use Equazcion's ScriptInstaller on a script such as User:Mr.Z-man/closeAFD2.js, the installation takes too long to complete. GeoffreyT2000 (talk) 23:22, 26 August 2016 (UTC)

Ordinarily I'd sugesst dropping a note on the user's talk page, but Equazcion (talk · contribs) hasn't edited in almost four months. --Redrose64 (talk) 20:15, 27 August 2016 (UTC)

Remove autosigning from Watchlist notifications[edit]

A situation just arose where an editor proposed on an article's Talk page some text that he wanted to insert in the article. Two minutes after he proposed the text, Sinebot autosigned his post. Later, when I accessed my Watchlist, only the Sinebot entry appeared and I dismissed it as a routine signing of an old post. I was therefore unaware of the editor's proposal. The matter came to light when I reverted his edit 2 days later. He had taken the 2 days of silence as approval. It appears that other interested parties may have also been fooled by the autosign notification. I know this is not the correct place to raise this (and don't know where that is), but could it be made that Sinebot's autosignings don't appear in Watchlist notifications? They are, after all, trivial and of no informative value, and as in this case can confuse, rather than inform. Akld guy (talk) 00:25, 27 August 2016 (UTC)

There isn't a way to do that. SineBot only signs new posts; I thought that was common knowledge. Graham87 06:11, 27 August 2016 (UTC)
Well, yes, it signs posts that posters don't sign. I don't understand your point and how it relates to engineering things so that Sinebot signings don't appear in Watchlists. Akld guy (talk) 07:05, 27 August 2016 (UTC)
You can preclude all bot edits from being displayed on your watchlist by checking the box to hide bot edits in the "Watchlist options" panel just above the top watchlist item being displayed.--John Cline (talk) 07:34, 27 August 2016 (UTC)
Watchlists can show the usernames (or IP addresses, for unregistered users) that have edited the page. With that turned on, you would have seen both Sinebot and the editor, and you would have been less likely to dismiss it. This may not seem ideal to you, but it does have the advantage of not requiring any software changes, which would in turn require you to sell the change. @John Cline: Unless I'm mistaken, that option would simply show nothing for that page in this situation. ―Mandruss  07:37, 27 August 2016 (UTC)
I'm sorry, I was focused on the comment preceding mine, which sought to "engineer things so that Sinebot signings don't appear in Watchlists." To ensure you are still able to view the actual unsigned edit, go to your preferences, select watchlist, then go to advanced options and check "Expand watchlist to show all changes, not just the most recent" as well as "Hide bot edits from the watchlist" and save your new preferences. This will accomplish what is being sought. Best regards.--John Cline (talk) 07:51, 27 August 2016 (UTC)
@John Cline: That appears to be a solution to the problem. I ticked and saved the "Hide bot edits from the watchlist" and reloaded my watchlist. A Yobot edit didn't reappear, while a ClueBot NG edit (a reversion of vandalism) remained. I'm hopeful that has solved my problem. Thank you John Cline. Akld guy (talk) 08:46, 27 August 2016 (UTC)
@Akld guy: you also need to ensure that Preferences → Watchlist → Expand watchlist to show all changes, not just the most recent is enabled, otherwise, if the most recent edit was a bot edit, you won't get any. --Redrose64 (talk) 20:07, 27 August 2016 (UTC)
@Redrose64: All right, I've now done that too. Thank you. Akld guy (talk) 20:21, 27 August 2016 (UTC)

Margin-left/margin-right for images[edit]

For example, image in my wiki-page: [[File:New shot of Proxima Centauri, our nearest neighbour.jpg|114px|right]]. How can I set the value 0 margin-left or margin-right around the image? Thanks.--Парис "Анима" надаль (talk) 16:00, 27 August 2016 (UTC)

New shot of Proxima Centauri, our nearest neighbour.jpg
Usually we have predefined ways to do this. Like the 'thumb', right left etc keywords, which create consistent styling for all elements. When you want/need to do something more specific, you wrap with a div and will have to apply all the styling yourself. —TheDJ (talkcontribs) 17:33, 27 August 2016 (UTC)
And could you give us a specific example? I need to remove the distance between this picture and your answer. Thanks.--Парис "Анима" надаль (talk) 18:41, 27 August 2016 (UTC)
@Парис "Анима" надаль: div.floatright { margin-left: 0; } will reduce the gap to a minimum. --Redrose64 (talk) 20:13, 27 August 2016 (UTC)
@Redrose64:, where can I read about the use of CSS in the Mediawiki code? I did not know where I should insert CSS submitted by you. I need to retreat did not have any visitor wiki-site, not just me. Thank you.--Парис "Анима" надаль (talk) 04:35, 28 August 2016 (UTC)
To set it on English Wikipedia only, it goes in Special:MyPage/common.css; for Russian Wikipedia only, it goes in ru:Special:MyPage/common.css; to set it for all Wikimedia wikis, put it in m:Special:MyPage/global.css. But I don't know what "I need to retreat did not have any visitor wiki-site, not just me" means. --Redrose64 (talk) 10:05, 28 August 2016 (UTC)
New shot of Proxima Centauri, our nearest neighbour.jpg
The code is for you to see images without margins, without affecting others. If you want a specific image displayed without margin for everybody then the code is <div class="floatright" style="margin-left: 0;">[[File:New shot of Proxima Centauri, our nearest neighbour.jpg|114px]]</div>. PrimeHunter (talk) 11:10, 28 August 2016 (UTC)

This sidebar appears on various Economics page; where is the code to alter it and update it[edit]

{{Economics sidebar|left}} This sidebar appears on various Economics page; where is the code to alter it and update it? Cheers. Fountains-of-Paris (talk) 16:17, 27 August 2016 (UTC)

Template:Economics sidebar. (talk) 17:16, 27 August 2016 (UTC)
I guess that's a start, though it doesn't give me the actual code for it. Only gives: Place {{tlx|Economics sidebar}}. I need the insides of this actual template so that I can do other sidebar's from it. Is it simply transforming and converting the navbox into this Sidebar, that is, you need to do the Navbox first and then you get the Sidebar with the App applied to the Navbox? Cheers. Fountains-of-Paris (talk) 17:39, 27 August 2016 (UTC)
"Updating" a template such as this, first needs consensus as any changes affect every use of the template, and there are over 200 - click the T (Talk) at the bottom RH corner, to get to the talk page. For the code, Click the E (Edit) - Arjayay (talk) 17:49, 27 August 2016 (UTC)
No, Arjayay, Fountains-of-Paris clarified in the second comment that they want to do other sidebars from it, which is OK. Fountains, if you "Edit" the template page you can see - and copy - the code. --ColinFine (talk) 17:52, 27 August 2016 (UTC)
Yes, that's it precisely. Thanks to both editors for comments. Cheers. Fountains-of-Paris (talk) 17:56, 27 August 2016 (UTC)
My bad - it was the opening line "alter it and update it" - Arjayay (talk) 18:03, 27 August 2016 (UTC)

Policy Tech[edit]

Is there, to others knowledge, policy or guidelines related to the use of HTML in Wikipedia articles? I haven't seen anything robust enough to settle a matter; preference, best practice, or otherwise, yet I am aware of systemic bias in resounding favor of wikimarkup. I thank whomever finds in them a reply. Best regards.--John Cline (talk) 11:27, 28 August 2016 (UTC)

@John Cline: See for a list. (If I understood your question correctly.) --Malyacko (talk) 11:53, 28 August 2016 (UTC)
@John Cline: See both Help:HTML in wikitext and m:Help:HTML in wikitext Thanks VarunFEB2003 I am Offline 11:59, 28 August 2016 (UTC)
Thank you Malyacko; that is helpful and could be used in developing some policy, if none exists. It is policy or guideline pages I am most interested to see yet I am glad you shared the above link as I hadn't seen that page. Thanks to Varun as well. Best.--John Cline (talk) 12:13, 28 August 2016 (UTC)
Wikipedia:Manual of Style/Tables#Formatting says: "It is recommended that wikitables be used in place of HTML tables, as they are easier to customize and maintain". Wikipedia:Manual of Style/Text formatting#cite_note-HTML_b_and_i-1 says: "Technically, it is also possible to use the <b>...</b> HTML element for boldface and the <i>...</i> element for italics, but that is not recommended style on Wikipedia." PrimeHunter (talk) 12:59, 28 August 2016 (UTC)
Thank you PrimeHunter, that is good stuff; it puts many things I have observed in congruent context although I am not yet ready to acquiesce its propriety. More policy will be greatly appreciated; in the interim, can someone help me understand why the one markup is reasonably better than the other? Is the creation of templates like {{em}} an acceptable compromise? If so, please also tell of any list of such templates that already exist, or perhaps a well suited template with expansive versatility. I have worked out the syntax for a template that can accommodate any element as well as styling and class attributes. Perhaps its time has come? Best regards.--John Cline (talk) 14:28, 28 August 2016 (UTC)
{{em}} is in Category:Wikipedia XHTML tag-replacing templates. PrimeHunter (talk) 14:54, 28 August 2016 (UTC)
It's complex. People like myself prefer plain wikitext when possible (and minimal templates please!), and I have seen editors with the necessary skill replacing hmtl markup with wikitext. On the other hand, there is a case above at #HTML tidy or ? which involved IPv4—check its history to see how html was recently used. Johnuniq (talk) 23:26, 28 August 2016 (UTC)
Complex indeed. I'd say, the more user facing, the more preferably wikicode would be, but the more complex something gets, or the more complex the situation you need to solve, the better it is to go with HTML. —TheDJ (talkcontribs) 08:00, 29 August 2016 (UTC)

API parse, headhtml properties, modules such as "mediawiki.action.edit.styles" not returned?[edit]

For AWB to do page previews, we extract stylesheet calls using API parse call for headhtml properties e.g. This returns stylesheets whose links include site.styles and user.styles modules (I believe this uses the "ResourceLoader" functionality of mediawiki). However, rendering page preview HTML with just these stylesheets, pages are not as per browser display, items such as grey box around TOC are missing. Investigating, with a page preview in browser, the HTML source contains stylesheet calls for a series of additional modules including "mediawiki.action.edit.styles" and other important-sounding modules (encoded list for en-wiki is "ext.gadget.DRN-wizard%2CReferenceTooltips%2Ccharinsert%2Cextra-toolbar-buttons%2Cfeatured-articles-links%2CrefToolbar%2Cswitcher%2Cteahouse%2Cwatchlist-notice%7Cext.tmh.thumbnail.styles%7Cext.uls.nojs%7Cext.visualEditor.desktopArticleTarget.noscript%7Cext.wikimediaBadges%7Cmediawiki.action.edit.styles%7Cmediawiki.legacy.commonPrint%2Cshared%7Cmediawiki.sectionAnchor%7Cmediawiki.skinning.interface%7Cskins.vector.styles%7Cwikibase.client.init"). When logged in there are additional modules requested, seemingly for installed gadgets and scripts etc. According to user reports something changed mediawiki-side in the last week or so. So I'd like to ask, is is correct that API headhtml properties don't give stylesheet links for all these additional modules, as it seems we need them? (I have a locally-tested workaround in AWB to add in all these modules to the preview HTML we generate, but as I've little understanding of what modules operate on what language wikis, and other sites like wiktionary, commons etc., I'm dubious about my workaround being suitable across the board) Thanks Rjwilmsi 13:47, 28 August 2016 (UTC)

Seems the 'mediawiki.skinning.interface' and indeed a few more stylesheet modules are missing from that block. There were some changes to the positioning and generation of these links in the last weeks, and since headhtml is not used in normal production flows, that might have caused an oversight somewhere in the logic or something. Please file a ticket in the ResourceLoader project in Phabricator. —TheDJ (talkcontribs) 07:57, 29 August 2016 (UTC)


what is the wikilink for :

usage : Wright (disambiguation)

Xb2u7Zjzc32 (talk)

There isn't one. This may be the best way to make such a link. PrimeHunter (talk) 11:16, 29 August 2016 (UTC)
I made a template (not documented yet). {{Category from|Living people|Wright|This}} produces This. Adding |skip=yes produces This. PrimeHunter (talk) 11:58, 29 August 2016 (UTC)

Category:Fb templates[edit]

Hello.These templates consist of links only.Are these templates useful or should be substituted and deleted?Thank you --ديفيد عادل وهبة خليل 2 (talk) 11:35, 29 August 2016 (UTC)

They make table code and not just links. They are useful to football editors and should not be substituted or deleted without good reason. Two of the advantages of templates is simpler article code when you know the templates, and ability to change all articles at once if you want to change something like a table layout. PrimeHunter (talk) 12:04, 29 August 2016 (UTC)

TOC and similar non-printing instructions leave whitespace[edit]

I use a stylesheet that surpasses TOCs, which I do not find useful and use up a lot of space in any lengthy article. However this appears to interact with tags like __FORCETOC__ and similar which is rendered as vertical whitespace. For instance in this article I see the __FORCETOC__ leaves two blank lines. I'm not sure where the problem lies, but can anyone suggest a fix? Maury Markowitz (talk) 12:13, 29 August 2016 (UTC)

In that particular article, it's because the FORCETOC element appears to be outputting an extra return or some such, which combines with the page source. The fix on that particular article for your issue (which I can reproduce without hiding the TOC using CSS :D) is simply to remove the extra returns before and after the FORCETOC. However, the page actually outputs invalid html because there are multiple id="toc" due to the TOC lower in the article. I'm not sure of the best way to fix that issue, though I've removed the extra TOC for now. --Izno (talk) 12:27, 29 August 2016 (UTC)

Sorting in categories unreliable for ~24 hours[edit]

Short version: Because of a new algorithm, sorting in categories will be unreliable for ~24 hours, starting today August 29 around 18:00 UTC.

Longer version: In the 2015 Community Wishlist Survey, the 5th most popular proposal was numerical sorting in categories (for example, sort 99 before 100). The WMF Community Tech team is ready to implement this, but a pre-requisite for the change is that we must switch English Wikipedia's category collation from "uppercase" (a simple collation algorithm that sorts strings based on character values, but considers uppercase and lowercase letters the same) to "uca-default" (which is based on the Unicode Collation Algorithm (UCA), the official standard for how to sort Unicode characters). The most noticeable difference is that UCA groups characters with diacritics with the their non-diacritic versions. There are other advantages to using UCA collation, but they’re a bit technical, so if you’re interested I recommend you read the documentation: Unicode Root Collation, ICU User Guide: Collation, ICU User Guide: Collation Concepts.

We expect the maintenance script will take about 24 hours to run, during which sorting in categories will be unreliable, starting today August 29 around 18:00 UTC.

The community discussion (originally started on WP:VPT) around this, from a couple of months back, can be found here. /Johan (WMF) (talk) 13:14, 29 August 2016 (UTC)

Watchlist and contribution - repeated items showing[edit]

odd watchlist behaviour

Any idea why my watchlist (screenshot accompanies) and contributions list have suddenly started showing each item in quadruplicate? I'm using Modern skin on Pale Moon 26.4 and everything was ok until 20 minutes ago. Nthep (talk) 15:34, 29 August 2016 (UTC)

Using Vector on whatever is the latest Chrome version, can replicate. It must be a server caching error. Pinguinn 🐧 15:50, 29 August 2016 (UTC)
I'm seeing items in quadruplicate only when I have the "ORES" beta feature turned on. -- John of Reading (talk) 15:50, 29 August 2016 (UTC)
I'm fairly certain it's ORES. --Izno (talk) 15:57, 29 August 2016 (UTC)
The only ones that are doing it to me are ones with edits marked potentially harmful by ORES. I have opened a discussion at the ORES discussion page. — Jkudlick • t • c • s 16:45, 29 August 2016 (UTC)

I noticed this above at the ORES note (top of page now). For me, this is also has the effect that I have no un-ORESed watchlist entries older than the first entry flagged by ORES. I'm glad that it isn't just me but is indeed a typical WMF error. Uncheck at Beta features and everything is solved. Fram (talk) 16:53, 29 August 2016 (UTC)

Contrib and watchlist changes are now 4x[edit]

I just did a username change. Now I find that every change on my watchlist and in contributions lists that occurred before the username change going back one week in time are indicated as happening 4 times each. Anyone know what this is?

jps (talk) 17:21, 29 August 2016 (UTC)

See the ORES thread where I am currently standing in the corner, above. Roxy the dog™ bark 17:33, 29 August 2016 (UTC)
Works for me. jps (talk) 17:54, 29 August 2016 (UTC)

Tech News: 2016-35[edit]

16:01, 29 August 2016 (UTC)

Can't save or preview pages on Wikipedia from desktop[edit]

  • OS - Windows 10 version 1511, build 10586.545
  • Browser - Mozilla Firefox 48.0.2
  • Browser - Google Chrome version 52.0.2743.116 m
  • Browser - Microsoft Edge 25.10586.0.0

I am unable to save or preview pages on Wikipedia when I go to edit them. My internet is fine; all other websites work, and even the rest of Wikipedia works. However, when I go to edit a page, I find that I am unable to save or preview it. The browser I use the most, Mozilla Firefox, displays a status message of "Sending request to" and loading the grey spiral in the tab when I go to save or preview an edit. After 15-30 seconds, it gives up completely and just stays on the same page without loading any error screen. When I go to use Google Chrome, saving or previewing my edits leads to Chrome loading on the grey spiral on the tab and the status message stating "waiting for", before giving up completely after a minute or so and displaying the "This site can't be reached" error page. The error message displayed being "ERR_CONNECTION_RESET". Doing the same actions in Microsoft Edge lead to the grey spiral for a short time similar to Firefox, before giving up and displaying the "Hmm, we can't reach this page" error page. Sometimes it allows me to save/preview edits during windows of opportunity throughout the day at seemingly random. However, these windows are usually short, from a few seconds to a few minutes, before it goes back to not working again.

I have currently resorted to using my mobile and tablet, on which editing Wikipedia works perfectly fine, meaning the problem is not with my internet connection, rather my desktop computer's connection to Wikipedia when saving/previewing edits. I had a similar problem before, for which I addressed, but never got an answer for, in this talk page a few months ago. The problem went away thankfully, but it has come back. Hopefully this time we can find a solution :) Philip Terry Graham 16:12, 29 August 2016 (UTC)

Category populated by convoluted template[edit]

Is there anyone on here who can take a look at Template:Infobox NRHP and make it remotely easy to use? Currently it's populating a category redirect at Category:Historic districts in USA Virginia Northern and requests for help on the template talk page are not yielding answers. These convoluted templates are extremely frustrating and lock editors out. Timrollpickering (talk) 16:44, 29 August 2016 (UTC)