This page contains discussions that have been archived from Village pump (technical). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.
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 Access19:20, 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 Access21: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:Offline04: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, –Davey2010Talk09:48, 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:Online08: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:Online11:25, 8 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:Online11: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:Offline00: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:
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:
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.--JohnBlackburnewordsdeeds20:14, 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.--JohnBlackburnewordsdeeds20:19, 4 August 2016 (UTC)
@Quiddity (WMF): Here's what I have. This is with Firefox browser, MonoBook skin. The figures are so tiny they're unreadable, and the contrast (black on colour) is poor too - I can only just make out that there's a character there, which I'm guessing is a figure. When we first got the icons, the contrast was good, as it used white figures on a dark-coloured background, and the figures were large compared to the links at either side - I think they were boldfaced too. I could fix this by working out the CSS rules (yet again) that would make it readable for me, but I shouldn't need to. This is an accessibility issue. --Redrose64 (talk) 22:33, 4 August 2016 (UTC)
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)
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)
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)
@Quiddity (WMF) and Roan Kattouw (WMF): OK, I gave up waiting for the accessibility fix, so I put together some CSS rules which may benefit other people. They go in m:Special:MyPage/global.css and affect all Wikimedia sites. In this context, alert is the bell one on the left, which is normally black on pink, and notice is the car door one on the right, normally black on light blue.
/* Make the notifications counters a bit more noticeable. White on red for alerts where at least one is unseen */#pt-notifications-alert.mw-echo-notifications-badge.mw-echo-unseen-notifications::after,#pt-notifications-alert.mw-echo-notifications-badge.oo-ui-flaggedElement-unseen::after{background-color:#D11813;/* Vector's colour instead of MonoBook's #DEA4A2 */color:white;}/* White on blue for notices where at least one is unseen */#pt-notifications-notice.mw-echo-notifications-badge.mw-echo-unseen-notifications::after,#pt-notifications-notice.mw-echo-notifications-badge.oo-ui-flaggedElement-unseen::after{background-color:#0D5EF2;/* MonoBook's #B7CFFB reduced to 50% lightness */color:white;}/* Red on white for alerts which have all been seen (not necessarily marked as read) */#pt-notifications-alert.mw-echo-notifications-badge::after{font-size:1em;background-color:white;color:#D11813;}/* Blue on white for notices which have all been seen */#pt-notifications-notice.mw-echo-notifications-badge::after{font-size:1em;background-color:white;color:#0D5EF2;}
There are four rules, one for each principal combination. The idea is that if you've seen them all, the figure is dark on white, coloured appropriately (red or blue), see first screenshot; but when the alert or notice counter is increased, indicating a new notification, the colours flip to white on dark, attracting your attention, see second screenshot. This is the converse of the present arrangement where an unreadable black figure on pale background is supposed to be the attention-getter, but is less noticeable than the white-on-grey "you've seen all of these" figure. The font-size: 1em; declaration makes one heckuva difference to readability, and although it is in only two of the four rules, it's specific enough to affect all four combinations. --Redrose64 (talk) 19:40, 14 August 2016 (UTC)
@Redrose64: Apologies for the delay. I have some tweaks to the badge styles sitting in code review, including a change to font-size: 0.9em;. If all goes well they'll roll out next week; they missed the boat for this week's deployment, unfortunately.
As for the color tweaks, I think white text on a darker background is a good idea, we already use that in Vector anyway. I can write a patch that applies those changes; the only thing I'm confused about is where you say that #D11813 is the Vector color; it's #CC3333 AFAICT. Also, #0D5EF2 looks very similar to what Vector uses for unseen notices (#3366CC), so perhaps we could just have Monobook use the same colors as Vector? (i.e. #C33 for alerts and #36C for notices)
I think the colored text when things are seen is a neat idea, but I'm not that enamored with the white background. You may also be interested in this idea which would merge the two badges and present the alerts/notices distinction differently. --Roan Kattouw (WMF) (talk) 00:17, 17 August 2016 (UTC)
@Roan Kattouw (WMF): I've added two screenshots above to illustrate what my CSS blob does for me. The only remaining issue is that the figure uses a blurred font, rather than the sharp-edged font used in the rest of MonoBook (as seen with the Redrose64 and talk links on either side of the notifications in my screenshots). --Redrose64 (talk) 09:28, 17 August 2016 (UTC)
Excessive whitespace
Icon spacing before and after this CSS is used
Is there meant to be so much whitespace around the icons? I used the following code to reduce it:
/* ADJUST NOTIFICATION SYMBOL SPACING */#pt-notifications-notice{margin-left:1px!important;padding-right:4px!important;}#pt-mytalk{margin-left:0!important;}
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 the reducded spacing is still fine for two digits, its really when the numbers get above 99 that the extra space is needed. @Roan Kattouw (WMF): could the software adjust the spacing based on the number of notifications? just reread your comment - Evad37[talk]23:58, 5 August 2016 (UTC)
What the badges look like with Roan's patch We actually just made a change (which will be deployed on Thursday) that would make it easier for the width to be dynamic, but another problem with that (as a coworker reminded me) is that the popup with the list of notifications is anchored from the badge, so then when you mark a notification as read and the counter goes from 10 to 9, everything in the personal toolbar moves over and the popup moves too (because its anchor point moves). You can try this by going to beta labs and putting .mw-echo-notifications-badge { padding-right: 24px; width: auto !important; } in your user CSS.
That said, we can still reduce the spacing a bit, so that "99+" just barely fits (it's uncommon anyway). I've submitted a patch that does the equivalent of .mw-echo-notifications-badge { width: 24px !important; } .mw-echo-notification-badge:after { left: 50% !important; }. I've put some screenshots of that on the right. I'll try to get that patch reviewed on Monday so it can included in Thursday's deployment. --Roan Kattouw (WMF) (talk) 01:13, 6 August 2016 (UTC)
New alert pictures
Is it possible to replace the ghastly new alert pictures at the top of the screen (an alarm bell and whatever the other thing is) with the old ones, by adding a line to my .css page? (Please note, I am totally technically illiterate - someone did my .css for me.) zzz (talk) 04:19, 6 August 2016 (UTC)
I 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.
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 Access20: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. VarunFEB2003I am Offline 14:19, 13 August 2016 (UTC)
Consolidation and convergence
The icons being discussed here are called alerts and notifications. Conceptually, these seem to be similar to other entries in the line at the top of the screen – Talk and Watchlist. To me, the equivalence is
Alert — Watchlist
Notification — Talk
Perhaps these could be brought together by putting them together in the top line? There are also other similar features like the Geonotices and discussion links which serve a common purpose in letting me know that something is going on. Some convergence and consolidation of these features might help too. Andrew D. (talk) 10:09, 8 August 2016 (UTC)
Spacing in monobook
In vector the spacing looks OK, however monobook the new icons appear to be "top aligned" and rise higher than the rest of the line. Any site-wide hints to fix? — xaosfluxTalk13:36, 14 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)
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)
Page Curation toolbar innaccessible after I edit the article
Hello,
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)
@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)
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
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)
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 savvy...is 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 (talk • contribs) 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)
This all grows out of a joke block, but it may have non-joke applications.
See https://en.wikipedia.org/w/index.php?title=Special:Log&type=block&user=&page=User:ThisIsaTest, 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)
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. --47.138.165.200 (talk) 00:28, 27 August 2016 (UTC)
This sidebar appears on various Economics page; where is the code to alter it and update it
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)
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)
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)
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 (talk • contribs) 17:33, 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)
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 <divclass="floatright"style="margin-left: 0;">[[File:NewshotofProximaCentauri,ournearestneighbour.jpg|114px]]</div>. PrimeHunter (talk) 11:10, 28 August 2016 (UTC)
Policy Tech
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)
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)
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)
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 (talk • contribs) 08:00, 29 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) VarunFEB2003I 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)
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 (talk • contribs) 08:16, 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)
Can't save or preview pages on Wikipedia from desktop
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 en.wikipedia.org..." 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 en.wikipedia.org...", 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 Graham16:12, 29 August 2016 (UTC)
For AWB to do page previews, we extract stylesheet calls using API parse call for headhtml properties e.g. https://en.wikipedia.org/w/api.php?format=xml&action=parse&prop=headhtml&title=a&text=a. 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
(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 Rjwilmsi13: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 (talk • contribs) 07:57, 29 August 2016 (UTC)
Deployment of ORES review tool in English Wikipedia as a beta feature
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 ORESreview 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.
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 (talk • contribs) 18:23, 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 [1] and [2]. 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)
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)
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 Mishehu03: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)." :)Ladsgroupoverleg10: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 BeetstraTC11:11, 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. :)Ladsgroupoverleg12:08, 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 BeetstraTC12:28, 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 (talk • contribs) 14:29, 24 August 2016 (UTC)
A couple of notes:
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.
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. :)Ladsgroupoverleg20: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 BeetstraTC11: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:)Ladsgroupoverleg09: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[3][4] Seeing my own edits[5] 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™bark16:49, 29 August 2016 (UTC)
Watchlist and contribution - repeated items showing
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)
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
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?
I was unable to access Wikimedia sites for a half hour or so until a few minutes ago. For future reference, where does one report such problems when one can't access Wikimedia sites, including Phabricator - without having to subscribe to a mailing list? Nurg (talk) 08:46, 30 August 2016 (UTC)
Still having intermittent but frequent connection problems. Tracert suggests to me serious packet loss between Los Angeles and ULSFO. Nurg (talk) 08:59, 30 August 2016 (UTC)
Curious how the current font size for geonotices was determined. Looks like it's controlled by MediaWiki:Gadget-geonotice-core.css, being 144.5%. Is there a reason it's way larger than 100% by default and overpowers watchlist notices somewhat? Is it compatibility for mobile platforms or small screens? I think the default font size would be more consistent with watchlist notices, and be less intrusive, but still visible. Would there be any objection if I submitted an edit request to have the css line simply removed? Welcome any feedback — Andy W.(talk ·ctb)02:10, 30 August 2016 (UTC)
TOC and similar non-printing instructions leave whitespace
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)
@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) — 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.
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:
@Melamrawy (WMF), @TheDJ, @PrimeHunter — I hate to be a pain, but we're nearly there. The flags now display properly, but do not work with the nowrap template. The Formula One season pages use nowraps to keep table entries on one line to allow tables to use the sorting function without issue. Prisonermonkeys (talk) 01:16, 30 August 2016 (UTC)
Make that the flagicons don't work with any other template. The Formula One season pages use a results matrix in a template (here) to keep the articles stable. It includes flagicons, but it doesn't display properly. Prisonermonkeys (talk) 07:14, 30 August 2016 (UTC)
{{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)
@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 (talk • contribs) 08:31, 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 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)
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)
Editnotices and emailnotices editable by other editors
I received these replies (one today) regarding the possibility of this and this with a non-admin non-TE account. I'm wondering, on behalf of some others as well, if base userpage (and user talk page) editnotices (and emailnotices) are supposed to be editable by other editors and IPs, or if this is indeed a bug to be reported. Arguably, makes sense to have edit/move restrictions applied to these sorts of pages to the TE level (like other editnotices as of today). My hunch is that this could may need introducing new user permission that allows a user to edit his/her own editnotices?
Hi Jo-Jo Eumerus, yes, the reason they were moved to the new scheme is to bypass the blacklist, so users who own them can edit them. What I and others are wondering is if it's possible to restrict their editability to TEs (like other editnotices) + the specific user who owns them? For the record, I don't feel too strongly either way, but others are wondering. Davidwr, for example, is suggesting that a Phab ticket be opened. — Andy W.(talk ·ctb)21:39, 30 August 2016 (UTC)
Not suggesting a protection. We already have a sort of automatic "sysop + userspace owner" for user CSS/JS pages that the user creates in his/her userspace. (User:Example cannot edit anyone else's CSS/JS pages) — Andy W.(talk ·ctb)23:18, 30 August 2016 (UTC)
For Windows I recommend AdiIrc. For Mac I recommend LimeChat. Both are free and feature rich. For the iPhone I recommend Mutter. Those are the best clients in my opinion, after having dug around the internet for a while.—cyberpowerChat:Online16:28, 31 August 2016 (UTC)
Separating the ability to patrol articles from general page patrolling
In the summary information for the above image, the text is overrunning the right margin. This occurred after another editor using FurMe applied a different template. The problem seems to be caused by a few excessively long URLs (used to cite source images) not breaking as they did previously. (Observed in Win 10 64 bit; Chrome 52 and Edge 25.1 but likely not system/browser related.) — Box73 (talk) 21:08, 29 August 2016 (UTC)
OK, OK, it's not a problem for the 15% using Firefox, but I'd like to fix the problem itself. The overrun didn't exist until this template was applied. — Box73 (talk) 07:38, 30 August 2016 (UTC)
So why not convert them from meaningless bare URLs to meaningful external links? That is, alter http://www.example.com/ to [http://www.example.com/ Example page] --Redrose64 (talk) 11:01, 30 August 2016 (UTC)
That is one solution. So you think: Example 1, Example 2, etc. would be acceptable. I'm game with that. Thanks! And looking back, the long URLs problem always existed. FWIW NQ's sandbox shows that long URLs will break after 154 to 162 characters. Thanks for your kind help! — Box73 (talk) 21:04, 30 August 2016 (UTC)
@Redrose64: I'll do that and better place the material into the new template. One other question and I'll disappear: Two or three of the logos are registered trademarks, but the rendering and composition is mine. (Several others are marked ® as they are registered names but very dated logos.) Given this, am I handling the permission appropriately? I appreciate your feedback. — Box73 (talk) 08:37, 1 September 2016 (UTC)
Thanks! Indeed those break, and long URLs outside of the image template break. But look at the sandbox again. I took the liberty of adding a dummy image template with long nonsense URLs. Eventually long URLs break after 154-162 characters, which still pushed the template's right margin way off the screen. The same behavior happened in older versions of the page but I never noticed it. What is your opinion of Redrose64's idea of using meaningful URLs? It's an immediate solution. However, the glitch of long URLs not breaking inside of (some) templates remains. Thanks much for the test sandbox and your generous help! — Box73 (talk) 21:04, 30 August 2016 (UTC)
action=purge "writes are pending"
In the last day or two, trying to purge using forcelinkupdate with more than one page gives an error:
LinksUpdate::acquirePageLock: Cannot COMMIT to clear snapshot because writes are pending.
I have used this trick from mw:API:Purge to clear error tracking categories, and am wanting to clear this one because the error was fixed on 25 August 2016. Clicking this link gives the error. I'm happy to wait if this is a temporary problem, but thought I would mention it in case it is a symptom of something else. Johnuniq (talk) 09:27, 1 September 2016 (UTC)
Is it possible to have the sequential to add the 'desc' tag as well as 'asc'? That would be easier for looking for penultimate item, as second, rather than one before last. 213.205.252.115 (talk) 23:58, 31 August 2016 (UTC)
This question is a duplicate of one I asked in the Teahouse, (edit: archive link) where I was pointed to here.
Wikipedia uses its own syntax for bibliographic references, which is different from BibTeX, the de facto standard for academic articles in TCS and Maths, to which I am used.
Is there a way to automatically convert a BibTeX ref such as the above into Wiki format? Doing so manually seems soul-crushingly boring.
The closest I found was https://en.wikipedia.org/wiki/Help:Citation_tools, but of the only 2 entries that mention BibTeX, one is Mac-exclusive -- I use Linux, so that's out -- and the other exports to BibTeX.
(Beyond that, I'm interested in any documentation that facilitates / automates the transition from LaTeX-based documents to Wiki format)
I don't know how useful it is generally, but if I put "http://dblp.uni-trier.de/rec/bibtex/books/daglib/0011126" into the automatic citation generator in the visual editor, it spits out <ref>{{Cite book|url=http://dblp.uni-trier.de/rec/bibtex/books/daglib/0011126|title=Introduction to automata theory, languages, and computation - international edition (2. ed)|last=Hopcroft|first=John E.|last2=Motwani|first2=Rajeev|last3=Ullman|first3=Jeffrey D.|date=2003-01-01|publisher=Addison-Wesley|isbn=9780321210296}}</ref>, which looks to me to be a well formatted citation. So in the case that the citation you want to convert is on the internet, you're good. As for the general case, I'm not so sure, but the automatic citations (based on mw:citoid) can be quite powerful. — crh23 (Talk) 19:58, 2 September 2016 (UTC)
I had not tried the visual editor; pretty much all the cites I need are on DBLP, so that should work nicely, thanks! I'll look into citoid should that prove insufficient. Gamall Wednesday Ida (talk) 20:20, 2 September 2016 (UTC)
As side comment re citation terminology: "references" is such an ambiguous term (and concept) that its unqualified use tends to lead to misunderstanding. In this discussion it would be more precise, and less confusing, to specify "full citation". ~ J. Johnson (JJ) (talk) 00:11, 3 September 2016 (UTC)
Percentage tube
Hi, I was wondering if somebody could create me a giant tube measuring percentage to go at the top of Wikipedia:The 10,000 Challenge. 1527 articles out of 10,000 and what percent we're currently at. Like the Missing encyclopedia articles project with the tube and percentage but ideally a larger one, something which really stands out with a prominent/intentive design?♦ Dr. Blofeld14:11, 30 August 2016 (UTC)
Probably today or recently it seems the rollback features have totally disappeared from my watchlist - no links in the items. Not sure whether it's a known issue or just my own local. Brandmeistertalk14:44, 3 September 2016 (UTC)
As a rollbacker (it's part of the admin set, but I was a rollbacker before that) I can confirm that true rollback (not the Twinkle emulation, which I don't use) is still in the watchlist. AFAIK the watchlist has never had a direct "undo" link, although that is present in individual page histories. --Redrose64 (talk) 19:58, 3 September 2016 (UTC)
(Pigsonthewing, how fortunate that your section there is fortuitously just above mine!)
I saw some issues in List of women linguists and started to write them up on the Talk page as Sorting, correcting, robot wars. But the more I wrote and looked, the more problems I found, like continual edit-warring between two bots. I pinged some relevant Wikipedians as I was writing, and very shortly I had received a couple of replies. Please go there to read about the problems.
These are clearly not confined to this article, but may be present in any sortable table that is updated from Wikidata by a bot or (even worse, see previous paragraph) bots. The discussion belongs at a higher level than the single article. Can anyone suggest where?
I have had an image that changes through the month and shows the phases of the moon on my talk page for more than a year, and just now I saw that there was an "Expression error". I looked on the talk page of another editor who has the same image and it shows the same thing. What's wrong with it? – Corinne (talk) 02:19, 4 September 2016 (UTC)
(edit conflict) Thanks P (love the signature) here is what I was trying to post but I think you have already answered the question. Oops I realize that the link is only to the picture used in the template so that won't be where the problem is. I think that this {{left|{{User:Dbachmann/moon1|q={{#expr:((({{CURRENTJULIANDAY}}-2454000.98958)/29.530588*4000) mod 4000)/1000}} is the template script and this User:Dbachmann/moon1(edit | talk | history | links | watch | logs) is where it starts. Hopefully this will be more useful. MarnetteD|Talk02:36, 4 September 2016 (UTC)
I added a number of noincludes to some templates implied to be able to be substituted. If there's anything (else?) I personally need to act on or was involved, let me know. — Andy W.(talk ·ctb)04:30, 4 September 2016 (UTC)
You appear to have fixed the issue, Andy M. Wang. The reason I initially pinged you was a misdiagnosis of the cause of this error as a template you fufilled the tagging edit request for. Pppery (talk) 11:12, 4 September 2016 (UTC)
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Recent changes
Wikimedia mobile sites now don't load images if the user doesn't see them. This is to save mobile data and make the pages load faster. [6]
When you edit a table with the visual editor, pressing Tab in the last cell of a row will take you to the first cell in the next row. Pressing Shift and Tab in the first cell of a row will take you to the last cell in the previous row. [7]
Changes this week
The name of the "Save page" button will change. The button will say "Publish page" when you create a new page. It will say "Publish changes" when you change an existing page. [8][9]
The new version of MediaWiki will be on test wikis and MediaWiki.org from 30 August. It will be on non-Wikipedia wikis and some Wikipedias from 31 August. It will be on all wikis from 1 September (calendar).
Meetings
You can join the next meeting with the VisualEditor team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on 30 August at 19:00 (UTC). See how to join.
How many help pages refer to "Save page"? Who is going to change all of those? What advantage is there to outweigh all the trouble and confusion? --David Biddulph (talk) 12:41, 30 August 2016 (UTC)
The "save page" button saves the page. It doesn't publish it unless it's in article space. This change is going to confuse new users. Maproom (talk) 08:15, 4 September 2016 (UTC)
@Maproom: I think that the idea is that it's published, in the sense that saving the change makes it immediately visible to anyone on the Internet without (normally) requiring a moderation step. --Redrose64 (talk) 11:33, 4 September 2016 (UTC)
@Bosley John Bosley: It does go to the right place, but then the page skips up. This is due to the presence of several collapsible sections, one of which (the {{Family tree of Maekar Targaryen}} at the bottom of the section on House Targaryen) is set to autocollapse. What happens is that your browser loads the page with all these sections expanded, then it jumps to the correct heading, and then it collapses those sections that are set either to autocollapse or collapsed: and in doing that, the heading and section that you are interested in is pulled up out of the top of the page. This is a known problem whenever collapsible sections default to collapsed. --Redrose64 (talk) 16:41, 4 September 2016 (UTC)
I've noticed when editing on my phone that I'm now constantly getting a "Make page mobile friendly" bar at the bottom of my screen. I use the desktop client deliberately, since I do not find the mobile interface "friendly" at all. I've checked through preferences, but have no idea how to get rid of this, and it's quite annoying to have it keep popping up. Anyone know how to get rid of this? SeraphimbladeTalk to me14:37, 4 September 2016 (UTC)
Hey Seraphimblade, this is a chrome thing rather than a Wikipedia feature. Go to chrome://flags, scroll half way down and you'll find the "Reader Mode triggering" option, set it to "never" and you'll be able to get rid of it. Please note that the setting applies to all webpages, not just wikipedia. - NQ(talk)21:11, 4 September 2016 (UTC)
Hi all! One of our GLAM partners recently noticed that VE is currently not enabled for Wikipedia: namespace. While this might have had some sense back in the early days, currently I see no reason not to enable it as one of the options. It works great for editing wikiproject pages, and is a great tool for various GLAM-related pages where people updating them are often our GLAM partners, less fluent in Wikicode. It's been tried and tested in, among others, Czech, Catalan and Polish Wikipedias where VE is enabled for all namespaces but Template: and Module:. Why not give people the choice to edit with whatever editor they please? //Halibutt07:34, 5 September 2016 (UTC)
@Redrose64: Talk pages are a tad different case, and on Polish wiki they were way more controversial. Not sure if merging the two is the best idea.//Halibutt11:18, 5 September 2016 (UTC)
I don't see why we shouldn't have two discussions, they are about two slightly different topics, with different limitations and opportunities, started by different people. —TheDJ (talk • contribs) 14:26, 5 September 2016 (UTC)
That does seem weird. I detest VE, but I understand why some people like it, and the tool should not be forbidden to them on projectpages for no apparent reason. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 11:19, 5 September 2016 (UTC)
Nevermind; I just learned in the related VPPRO discussion that VE is still barfing up incorrect nowiki stuff all over the place. So, it is clearly not ready for prime-time yet. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 11:48, 5 September 2016 (UTC)
Ask reporter, over at the VPPRO thread. I have seen this behavior myself, but thought it was only happening when VE was used inside Flow. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 12:14, 5 September 2016 (UTC)
500 most recent edits in article space: none have "nowiki" added. 500 most recent VE edits in article space: 4 have nowiki added (which is relatively low, usually I get more hits for the VE + nowiki problem). This includes probable vandalism (here and here although this can be VE gone mad as well), but also VE not helping editors at all, like here and here. In other namespaces, we see a new editor making his userpage with VE, and then switching to wikitext editor because VE adds unwanted nowikis[10]. Fram (talk) 12:58, 5 September 2016 (UTC)
My opinion on this has not changed. Unless we start listing and counting cases where people make errors using wikicode, or are stopped from editing because of wikicode, a nowiki metric has little meaning to me. —TheDJ (talk • contribs) 14:30, 5 September 2016 (UTC)
Logs
Resolved
Hi, Apologies if this is in the wrong place but not entirely sure where to post,
Basically having seen a log issue on Nordic Nightfurys talkpage I decided to be nosey and look at my logs,
Anyone know what on earth these mean ?
logs
22:19, 13 February 2014 Davey2010 (talk | contribs) noaction
22:19, 13 February 2014 Davey2010 (talk | contribs) inappropriate
22:18, 13 February 2014 Davey2010 (talk | contribs) noaction
22:18, 13 February 2014 Davey2010 (talk | contribs) inappropriate
22:18, 13 February 2014 Davey2010 (talk | contribs) inappropriate
22:17, 13 February 2014 Davey2010 (talk | contribs) inappropriate
22:17, 13 February 2014 Davey2010 (talk | contribs) inappropriate
22:14, 13 February 2014 Davey2010 (talk | contribs) protect
18:30, 13 February 2014 Davey2010 (talk | contribs) noaction
18:28, 13 February 2014 Davey2010 (talk | contribs) noaction
18:28, 13 February 2014 Davey2010 (talk | contribs) inappropriate
18:14, 13 February 2014 Davey2010 (talk | contribs) noaction
18:13, 13 February 2014 Davey2010 (talk | contribs) noaction
18:13, 13 February 2014 Davey2010 (talk | contribs) noaction
18:12, 13 February 2014 Davey2010 (talk | contribs) inappropriate
18:11, 13 February 2014 Davey2010 (talk | contribs) inappropriate
18:09, 13 February 2014 Davey2010 (talk | contribs) noaction (We cant per copyright restrictions.)
18:08, 13 February 2014 Davey2010 (talk | contribs) resolve
18:08, 13 February 2014 Davey2010 (talk | contribs) noaction
18:07, 13 February 2014 Davey2010 (talk | contribs) noaction
18:07, 13 February 2014 Davey2010 (talk | contribs) feature
18:07, 13 February 2014 Davey2010 (talk | contribs) noaction
18:07, 13 February 2014 Davey2010 (talk | contribs) noaction
18:06, 13 February 2014 Davey2010 (talk | contribs) resolve
Ahhh that's probably what it was, I vaguely vaguely remember using it so that may of been what it was then, Okie dokie I was worried my account had been hacked or something so thought I'd ask, Thanks zzuuzz for your help - it's much appreciated, –Davey2010Talk16:36, 5 September 2016 (UTC)
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Recent changes
Word-level diffs now work in longer paragraphs. [11]
Interactive maps now have a frame by default. This is to make them look like other multimedia objects. This affects all Wikivoyages, the Catalan, Hebrew, Macedonian Wikipedias and Meta. [12]
When you preview the MediaWiki:Captcha-ip-whitelist page it will show a validation output of the listed IP addresses instead of the list of addresses only. This can help you to identify if your whitelist rules will work or not. [13]
Changes this week
You will be able to use <maplink> on all Wikipedias. It creates a link to a full screen map. [14][15]
Sometimes when you mention another user they don't get a notification. You will be able to get a notification when you successfully send out a mention to someone or be told if they did not get a notification. This will be opt-in. [16][17]
The new version of MediaWiki will be on test wikis and MediaWiki.org from 6 September. It will be on non-Wikipedia wikis and some Wikipedias from 7 September. It will be on all wikis from 8 September (calendar).
Meetings
You can join the next meeting with the VisualEditor team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on 6 September at 19:00 (UTC). See how to join.
I am trying to log in on Wikidata. Attempting to login throws me back to the content page with the message "You are centrally logged in. Reload this page to apply your user settings." as son as I click-on the password box, and sometimes even before. But I am still not logged in, even if I do reload.
Together with the very last revision of the International Phonetic Alphabet (2015), the International Phonetic Association released a set of three fonts to display it properly (see here): IPA Kiel as the "ideal typeface" (though this one is not an opensource), Doulos SIL and DejaVu Sans.
How do you suggest we do this? We have no control over which fonts our readers have installed, let alone set as their defaults, and we're certainly not going to force our readers to install a particular font just to read Wikipedia (as can be evidenced by the fact that your signature displays to me—and I assume to most other readers—as a string of mojibake). ‑ Iridescent18:15, 5 September 2016 (UTC)
@Iridescent: OK maybe I didn't express correctly what I want to say.
My signature contains Runic text (which is fully supported by many fonts. Btw I also added a Latin transcription for users that — like you, I guess — lack a proper typeface).
Wikipedia already has a list of templates used to "force" users' browsers to display certain kinds of scripts with certain kinds of fonts: Template:Script.
@Redrose64: Yes you're right, I had never used a template before in my signature... I just hoped to make it readable for more users. But, in fact, that template uses exactly the same font I had already specified in my signature (i.e., Junicode). I fixed it. ᚪᛋᚦᚩᚾᛏ (Asþont) | Talk20:06, 5 September 2016 (UTC)
How to update "popular pages" subpage of a Wikiproject?
As an OTRS agent, we often field requests regarding passwords. Not surprisingly, they assume that someone can look up and find out which email is associated with which account. I don't believe that is the case and in a recent email I started with the following:
I don't believe it is possible to identify the email address associated with your account. When you register your username and email address are added to a database, some of which is not humanly accessible. We can identify the time and date an account is registered but not the email address or even whether there is an email address.
I think I'm slightly overstating it as it might be technically possible for a developer to look at the information but we are not about to use up scarce developer time simply because someone is having trouble logging in, so other than that caveat I'd like to make sure the rest of the statement is largely correct because I may use it more often.--S Philbrick(Talk)22:00, 1 September 2016 (UTC)
@Sphilbrick: The only way to figure out someone's email address is to email them and then have them respond back to you. There is a log of emails but only checkusers can see it last I checked and I'm 100% positive that the log does not just contain everyone's email. --Majora (talk) 22:09, 1 September 2016 (UTC)
It is theoretically possible to look up the username for the email address, and the email address for the username, but no one will do this because I am pretty sure that it's prohibited by WMF's privacy policy. You can, however, check whether there is any email address associated with an account by visiting Special:Emailuser and attempting to email the user (you get a different error message if there is an email than if there isn't). Matma Rextalk22:12, 1 September 2016 (UTC)
Isn't there a potential privacy issue there? I may be wrong, but I don't think we should be providing information about whether or not a given email address is in use here to the general public. Enterprisey (talk!) 22:24, 1 September 2016 (UTC)
It's not public whether a specific email address is stored by any user. It's public whether a given user has stored some unspecified email address. If you have email enabled yourself then Special:EmailUser/Username for another user has three possibilities:
An email form to mail them. In this case their user page will have "Email this user" under "Tools".
"This user has not specified a valid email address".
Server administrators can change or set an email address for an account but I don't know in which circumstances they will do that. I think the password is only stored in an encrypted form that doesn't allow anyone to retrieve the actual password, not even with complete database access. When you log in, the entered password is encrypted and compared to the stored password which was encrypted with the same method. What's the difference if you can still hijack the account by setting an email adress and use Special:PasswordReset? The difference is that many people use the same password at multiple websites. You can only hijack their Wikimedia account if you gain full database access. PrimeHunter (talk) 22:33, 1 September 2016 (UTC)
Technically, the password is hashed, not encrypted (this distinction was pointed out on this page a few years ago either by Grandiose (talk·contribs) or Jarry1250 (talk·contribs)). But yes, the password is stored in hashed form, and the entered password is hashed and compared to the stored hashed password - there is no "de-hash" function. --Redrose64 (talk) 23:42, 1 September 2016 (UTC)
Thanks for the extensive answers. It looks like I'll have to modify my canned response a little bit as my wording was a bit too strong, but I'm confident that I can still respond that access to email addresses is not feasible. I am in treat and will test out the suggestion that there is the ability to figure out whether an email address has been stored. I have, on occasion, entertained a request in which someone thinks they've filed an email but aren't getting the password reset and it may be helpful if I can let them know that they have not actually recorded an email.--S Philbrick(Talk)13:51, 2 September 2016 (UTC)
It is actually feasible to see if a user has email enabled and what his address is (at least in Vector) In the left menu when you visit a user page of another user you will see "Email User" option that is visible only if that user has email enabled and you too have it enabled. Clicking the option takes you to Special:Email User where hovering over the name of the receiver shows you his Email address. So it's technically visible to everyone. VarunFEB200311:22, 6 September 2016 (UTC)
@VarunFEB2003: I believe you may have misunderstood the question or garbled your statement slightly - NQ has asked if you can see their physical email address, which I know for a fact isn't present in the underlying source code of the page (and thus will not show on hovering over the receiver) -- samtartalk or stalk12:43, 6 September 2016 (UTC)
Actuallly yes I seem to have misunderstood I was talking about that hovering shows (actually practically not shows) that you have an email assigned as Samyar stated. Therefore I both garbled my statement and misunderstood Sorry for that @NQ:@Samtar:VarunFEB200312:48, 6 September 2016 (UTC)
To reassure anybody who may be worried: the link given by NQ (talk·contribs) at 11:32, 6 September 2016 has the underlying HTML
Letting a bot do this would not be a good idea, as I have known editors to move pages which should not be deleted to user sandboxes and then request deletion. An administrator should check the history and realise that this has happened, but it would be impossible to program a bot to be intelligent enough to always recognise that this has been done. The editor who uses the pseudonym "JamesBWatson" (talk) 12:15, 6 September 2016 (UTC)
Having the bot check the history and ignore any request where the page has been moved from another namespace would take care of this. When such a deletion request is legit, a human administrator can process it anyway. Jo-Jo Eumerus (talk, contributions) 15:13, 6 September 2016 (UTC)
There are many issues. Moves are not in the page log of the target so the bot would have to examine each edit summary in the page history to look for a summary indicating a move. Vandals shouldn't be able to move others user pages and delete them. A user page can be tagged as a sock puppet. Should the user be able to move that to a sandbox and delete it? Should users be able to move their main talk page to a sandbox talk page and delete it? Users are allowed to remove warnings now but they can be found by non-admins. A user could get others to edit a sandbox draft and then copy-paste it to an article and delete the sandbox so attribution becomes impossible. An advertised userbox in userspace could be used by many other users and suddenly be deleted. The bot could malfunction and delete many pages it wasn't supposed to. Some concerns could be addressed by adding more limitations, e.g. only deleting pages which have never been moved and never been edited by others. But processing user requests for deletion is minor work for administrators and I see no need to avoid it. PrimeHunter (talk) 15:59, 6 September 2016 (UTC)
Some external links failing in tables
Some external links I am using are failing in tables. The thing they all have in common is a '?' character in the URL. Here is an examples:
I have tried replacing the '?' with an URL encoding, but it still fails. Does anyone know what is going on here and what can be done? Is this a known problem? The URL works fine as an external link anywhere else, but not inside a table. I have to wrap the URL in nowiki tags for it to display (when it is no longer a link). Carcharoth (talk) 06:06, 6 September 2016 (UTC)
Many thanks, John. And thanks to PrimeHunter for the phabricator link - interesting discussion there. I vaguely knew about the need to use named parameters ('1=') to avoid this, but had clearly forgotten it. Won't make that mistake again! I think it is mentioned on a help page somewhere, but I think it could be mentioned much more prominently. Anyone have any ideas where people would more likely look for documentation on this? Maybe Help:Template? That has Help:Template#Usage hints and workarounds, but is that prominent enough for people to see? People will most often stumble across this when using an URL with an '=' sign, so I suspect they also go hunting for advice at Help:Link. What I was thinking was that some advice there about how links with a '=' sign in them can break templates? Can anyone more technically minded think of something to put there? Carcharoth (talk) 19:16, 6 September 2016 (UTC)
"the text doesn't match" is very vague for a large page. Are you referring to the collapsed box in the diff not being displayed where its code is? It's displayed at the bottom of the page instead in both your links (at least for me in Firefox) because {{Collapse bottom}} is not at the start of a line so the table is not closed correctly. Tables with invalid code can be displayed in unexpected places. PrimeHunter (talk) 01:44, 7 September 2016 (UTC)
If you examine the first four rows of line 925, they begin:
* I agre
*'''Comm
{{Collap
:I am al
On the full page, row 3 above and through the rest of the diff is inserted at the bottom of the page:
...* 6 September 2016 (UTC)
<double line across page>
<green background> Off-topic...
I don't really want to repeat any more of the text from the page than necessary.
Also, if you look at the post made at that page two minutes after I posted here, another editor may have already found and fixed the problem. I understand what you are saying about collapse bottom and when I get time I will see if that was the fix applied. Thank you, Unscintillating (talk) 02:32, 7 September 2016 (UTC)
To fix this, you need to put {{collapse bottom}} on a new line. At the moment, the {{collapse bottom}} code is on a line starting with **. When this wikitext is turned into HTML, the closing </div> output by {{collapse bottom}} is placed inside the unsorted list generated by the two asterisks, which in turn means that the <div>...</div> tags generated by {{collapse top}} and {{collapse bottom}} are mismatched. The tag mismatch is the root cause of the problem you are seeing. As for the discrepancy in the location of the collapsed text on both of the links you provide, I assume that this is caused by HTML Tidy being configured to fix broken HTML markup on permanent link pages but not on diff pages, but I'm not sure of the exact details there. — Mr. Stradivarius♪ talk ♪07:00, 7 September 2016 (UTC)
As mentioned, I see the same at both links in Firefox, but it doesn't surprise me that the invalid code apparently causes other browsers to show something different. PrimeHunter (talk) 10:43, 7 September 2016 (UTC)
Infobox display option
Forgive me if this is a perennial idea that should be speedily closed, or if I came to the wrong pump. Would it be technically possible to create an option to display or not display infoboxes as a preference? (Different from a reader having to muck about with CSS.) Something akin, but not a direct copy of, the ability to disable the Media Viewer? I suspect that there may become an even greater infobox war over which way a default is set.... But for now I'm wondering about the technical aspects of it. LaughingVulcan02:01, 1 September 2016 (UTC)
LaughingVulcan - I appreciate it's probably not appropriate for this page but a gadget (or whatever) is not actually going to solve the problem. For instance, I personally do not see the need for IBs on some articles if the information is summarised in the lead but I do need to view the IBs that are included on virtually every dog breed article as they are persistently the target for long term vandalism. SagaciousPhil - Chat10:40, 1 September 2016 (UTC)
@Sagaciousphil, I myself raised the non-technical issue that I'd expect battles over the default setting. I personally do not see the harm on IBs repeating information from the lead or anywhere else, or even feel that if facts can be standardly displayed in an infobox with other items maybe that information shouldn't be in the lead in the first place. (Though I recognize the latter is probably a minority view, maybe extremely so.) I do take your point that editors who'd dislike an IB in a certain article or class of them may still feel the need to patrol them, and that the concept might not solve any problems at all or could even worsen them somehow.
@All, I think I was looking more for a solution where an IB wouldn't load at all because with a setting the information is never called to be rendered in the first place. (Maybe a better analogy would be a switch to not load any images for lower bandwidth overhead, rather than Media Viewer - just picked the one feature that I know can be turned off.) But I have no clue about the internals of MediaWiki; I'd have a clue how to achieve in a WordPress install. Thanks for the continuing input, though. LaughingVulcan11:38, 1 September 2016 (UTC)
@LaughingVulcan: Each registered editor has a personal cascading style sheet that you'll find at Special:MyPage/common.css. There are also separate style sheets for each skin that you can choose. I know this isn't precisely the question you are asking, but any registered editor can hide all infoboxes by placing .infobox {display: none;} in your common.css. My sandbox has an example of how an infobox can be adapted to display a lead image outside the infobox, which allows editors to turn off infoboxes without losing the lead image. It obviously doesn't solve the problem of hiding vandalism, but the mechanism to turn off a particular element is straightforward. --RexxS (talk) 16:45, 3 September 2016 (UTC)
@RexxS: Thanks for the background info! My idea came from seeing your idea referenced and then I forgot where. It is in the universe of what I was asking about above, and I'm going to go check your sandbox out for my own further technical edification. I think where I was running with your concept was looking to employ it by checking a box that makes those changes for that editor/reader.
There are many non-technical problems with it, and it can't be a complete solution to what I suspect is a human factors problem.
I think my takeaway here is, "yeah, this idea could probably be done technically, with the Foundation's cooperation, but it opens a metric ton of other issues." Or, paraphrasing Ian Malcolm, we can get so lost in figuring out if we could that we don't stop to think if we should.
Last on this one: Could a bot or script be developed that would edit the user's CSS with buttons or checkboxes? (So that a user not skilled or uninterested in hacking their css could toggle it?) Instructions are something like: Go to "InfoboxBot" and click the green or red buttons, or alternatively click preferences and choose "don' wanna see no iboxes no more!" Just stream-of-consciousness thinking out loud with this. LaughingVulcan17:50, 3 September 2016 (UTC)
Having been aware of the on-going controversy over infoboxes, I've been thinking about this type of solution for some time. However, today, it became even more pertinent because three long-time editors have just "retired", with disagreements over infoboxes being part of the reason. See Wikipedia talk:Featured article candidates#We are losing content editors. In reading the comments above, I am glad to see that there is hope of some easy option to display or not display infoboxes. However, there is one element to this discussion that has not been mentioned, and that is that some editors who feel strongly that there should be no infobox in articles in certain subject areas (such as biographies) would, I suspect, fight even the creation of an infobox for those types of articles. From discussions I've read, they feel strongly that the infobox can be misleading and/or that material that is in the lead should not be repeated in an infobox (I don't know if they object to repetition per se or if they want to ensure that readers read the article). So, if an infobox is created, they will, of course, argue that the default is no display of infoboxes, which will irritate those who like to see them displayed, which LaughingVulcan predicted. I'm thinking about our vast readership, many of whom are young people or people with little technical savvy with the computer, who, if the infobox is set at no-display, may never see an infobox. – Corinne (talk) 00:58, 4 September 2016 (UTC)
Thanks, Corinne. I think you have a good read on some of the potential objections and pitfalls. I was already aware of the controversy, as the retiring editors actually announced their intent a couple of days ago but the news is now spreading wider. (Full disclosure: one of the retirees appears to be blaming me personally (at minimum partially so) because of a conflict we had.)
An IB toggle may not address concerns at a more fundamental level, true, but IMVVHO it might be part of a compromise solution. (Might not, too.) The reason I started this journey here at technical pump was because I figured that A) if it weren't possible technically, there would be no use raising the issue at any other area so solve that first, and B) if it is technically possible any potential debate over whether it should be implemented or the details of that could be held elsewhere. I think you've also highlighted maybe it may not fix "the" problem in any event, which is possible.
But if I feel I have a solid technical ground that it could be done either way, then it could at least be raised as a possibility at any possible future conversation on Infobox solutions. May get shot down there, but at least I could offer it with the notion that it is technically feasible, so I won't get an objection of "hey, what you're suggesting isn't technically possible because ____." Maybe I've reached that technical fulfillment point here now, but I'd feel more confident if I knew with certainty that there would be some way that it could be option toggled as I described in the reply before. LaughingVulcan06:20, 4 September 2016 (UTC)
My question has morphed to now ask: Is it technically possible to create a bot with a button or Wiki settings checkbox to automatically/algorithmically alter the common.css file as per RexxS above? LaughingVulcan06:20, 4 September 2016 (UTC)
Second technical question, and this one is tougher. (Hat tip to Corinne for germinating the seed of this...) Is it possible to lay a variable in or around an infobox that both:
Does not display itself in the article (i.e. wikicode/template or equivalent), and
Could trigger the display or not-display of the infobox on default settings, likely as per RexxS above?
My reasons are collapsed; I really want to focus on the technical possibility aspect of this, and not the politics/social aspect at this moment if possible. But cookie to someone who can give an authoritative yes/no on the above.
Reasoning, not directly related to the questions
My thought here is to bring the infobox issue to a remove. Editors would then have to find consensus not on whether articles should have infoboxes or not, but rather if any given infobox should default display to a reader or not based on the local consensus at that article?
And I’m already thinking that this may just cause new heated squabbling over whether an article is then displayed by default or not. But it might be a compromise between those who feel an article (or more; class, project, wiki, whatever,) should have a box and those who feel all articles (or less; wiki, project, class, article, whatever,) should not have a box. It also respects the Arbs decision that iboxen debates should be a local article thing.
Bonus cookie for figuring out if a user could super-override that by setting/button, as per my immediate entry before this one, too. Box of cookies if user could also super-override to either show all infoboxes or show none. Let these overrides be a visible settings toggle on pages with infoboxes on the page itself, and I’ll buy you a cookie factory! That way the reader is still ultimately in control.
Disclaimer: LaughingVulcan does not got the sugar to buy cookie factories, and barely has the dough to buy individual cookies except virtually. Groan now, if you wish.LaughingVulcan16:05, 4 September 2016 (UTC)
From a CSS standpoint, the display:none property does what you want and can be triggered on a script (see [21] for a working example), so it should be completely possible to hide it via CSS sheets or through javascript. (That said, there should be an alternate display for every infobox template for what to display when the infobox is not used (ala a lead image), which can be toggled in the opposite way). And then with the cascading nature of infoboxes, it would be very easy to allow users to customize at least to a class of infoboxes, assuming each infobox template gets a unique CSS class name , as well as handling the super-override aspects. It's just a matter of two things, that I see: 1) adding a preferences gadget to help the user do this to their preferences, and 2) getting some per-page icon that trips the javascript to enable/hide the display of an infobox.
However, there is a small issue that is often tied to infoboxes, that being the use of references/footnotes to support data in them. It's not an issue, I don't think, if you have a reference in an infobox that's hidden (references in collapsed tables are still indexed in the reflist system, though that might be because they are "uncollapsed" at load and then collapsed after the page is loaded), but that now if you have a ref used and only used in the infobox, and you have it hidden, and the reader clicks on the leading "^" to jump to that reference use, they will land nowhere on the page. --MASEM (t) 16:45, 4 September 2016 (UTC)
I'm still digesting your post. Especially the second paragraph. If I understand both yours and RexxS earlier, the reflist would still carry the reference because the reference defintion markup is still present in the page generation - in the references section (obviously.) It would show a reference marker because the reference naming markup at the infobox is still present in the webpage as the infobox markup has been generated in the rendered page, it just hasn't been displayed. But calling the reference marker from the reflist, though, would lead to a place that is (invisible?) (never generated?) (the markup equivalent of an imaginary number?) in the page. And trying to do some kind of error trap that would display an alttext or error message of, "hey, this leads someplace you told me not to show you, reader! You're not in Kansas anymore, Toto!" would be a challenge of a whole different order if not impossible. And even if you could go there, what do you do when helpful_nonbox_displaying_editor sees reference problem and decides to delete the reference definition from the references section - what does that do to everyone who is still seeing the infobox? That could be the technical nail I was afraid of hitting. (And cookie calculations commencing, thank you!) LaughingVulcan21:31, 4 September 2016 (UTC)
The more I think about my last post above, if I got it straight and nobody wants to correct me, that does seem to be a show-stopper in terms of introducing a bug that has no easy solution. I guess I'm willing to let this sit here a little longer and let my brain spin on it, for a genius to correct my conclusion, or further confirm it. :( (thanks to everyone who's contributed so far, though.) LaughingVulcanGrok Page!02:40, 7 September 2016 (UTC)
It's not so much a bug as simply default behavior that conflicts with each other. There is a manual solution which is that no references be used in infobox (meaning that all information in an infobox must be duplicated and sourced in the body of the article). This avoids this problem but requires us to adjust all past infoboxes with references to fix that.
Another potential option, but I think this requires coding at the Wikimedia level, is that when one clicks on that "^" in a reference head, and that reference is located in an infobox, that should automatically triggered the infobox's display, if it is not already displayed. But (and this is without having detailed code knowledge) this would need close collaboration between en.wiki's markup and the Wikimedia code so that the engine knows when a reference is used in an hidden box as to know what box to reveal on the click. --MASEM (t) 13:50, 7 September 2016 (UTC)
Possible problem with {{ribbon devices}} wikicode when displaying more than one overlay.
I searched the bug tracker database, but "ribbon" and "devices" return tons of unrelated issues and "ribbon devices" returns none. The bug tracker file suggested post in the Pump for discussion first.
See Section: Awards (specifically the NASA Space Flight Medal line)
The problem is in this: |{{ribbon devices|number=2|type=award-star|ribbon=SpaceFltRib.gif|width=80}} || [[NASA Space Flight Medal]] || Three awards
When the variable "number" is 1, the display is correct, but when it is 2, the display error occurs. I've tested it with other ribbons and other types with the same issue arising, so I believe it will be a problem with any such military ribbon displays.
The table is displaying correctly now because of User:Huan's workaround (he removed one of the | bars between the "...80}}" and the "[[NASA..." and moved the following part of that line to a new line like this:
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.
Could this be the cause of a problem in which clicking on "P" or "Pa" in a category TOC leads to pages starting with "E"? If so, I'll ignore it for a day or so. See this discussion. – Jonesey95 (talk) 22:44, 29 August 2016 (UTC)
Yes, that's happening as a result of the new sorting script. I'm also seeing similar problems when you click (next page) on some categories. The problem should go away when the new script is finished.
If it helps, I've figured out a temporary workaround -- if you manually edit the URL to say (for example) &pagefrom=T, then it'll show you category entries further down the alphabet. It won't start with T, but the beginning of T should be in the results. Sorry for the current confusing state. -- DannyH (WMF) (talk) 23:03, 29 August 2016 (UTC)
@DannyH (WMF): Your work-around isn't working on at least some categories. For example Category:Cossinae stubbornly refuses to move any further than Hollowiella no matter which way I hijack the url. The issue appears to be the article Cossinae, which is forcedly sorted out-of-order and is the only thing it's willing to drop off the page, whether through next or through editing the URL. (Curiously, if I hijack the URL while the out-of-order article is displayed, it claims there are no pages or files in the category. If I hijack the URL after moving 'next page' and thus dropping the out-of-order article (and nothing else) off the page, it simply stays stuck on what it was already displaying.) AddWittyNameHere (talk) 03:02, 31 August 2016 (UTC)
@AddWittyNameHere:Category:Cossinae works now, because the script has worked its way through the Cs. :) The script is making steady progress, just slower than we originally thought. I'm sorry about the inconvenience this week; I hope it's not messing up people's workflows too badly. -- DannyH (WMF) (talk) 18:13, 31 August 2016 (UTC)
@DannyH (WMF): Thanks for letting me know about Cossinae and it having worked through the Cs! (Means that a few more of the categories I had noticed issues with should be fine now too, since they're also in the Cs, so that's nice) Can't speak for others, but for me/my workflow, it's been a bit annoying but not much more than that—it's mostly causing me to have to spend a bit more time here and there to find some of the stuff I'm working on, but I can still do what I was doing. Glad to know the script is still processing steadily even if slowly, means sooner or later it'll all work as it should again. (Is the current estimate still 'this weekend', by the way? If it looks like it's going to take longer than that, could y'all maybe post updates daily or so so we know which categories should be fine? Would make things a bit easier on workflow if I (and probably some others) can re-prioritize to working in categories that are fixed first, others later.) AddWittyNameHere (talk) 19:25, 31 August 2016 (UTC)
No, it's true that this date hasn't been mentioned on-wiki until the same day and was posted roughly five hours prior to the change. Previously, the information was available only in Phabricator, where few editors look. We held off because we were testing it on Swedish Wikipedia and didn't want to cause any confusion if we had to postpone it. Maybe that was a mistake – could be I underestimated the confusion this would cause. My apologies. I just didn't want to waste your time and energy if we had to do it later instead.
(Side note about Tech News: We're updating the wikis individually, not all at the same time. Something that's specific for one single wiki, like the date for when something happens on English Wikipedia, will typically not turn up in Tech News, because it doesn't make a lot of sense to put wiki-specific news into a newsletter that's distributed all across the Wikimedia world. The newsletter would contain too much information that wasn't relevant to many of it's readers because they don't edit that particular wiki, and the translators would spend too much time translating things not relevant for their home wikis. The exceptions are Commons and Wikidata, as other wikis depend on them.) /Johan (WMF) (talk) 14:18, 30 August 2016 (UTC)
Something must be wrong with the sorting mechanism at Category:BLP articles proposed for deletion by days left. Instead of sorting by days left, it is just lumping them all together as 0-9 days left. Of course, that makes it impossible to patrol the category for expired listings ready to be evaluated for deletion. Thanks for any help with this. --MelanieN (talk) 23:34, 29 August 2016 (UTC)
@MelanieN and PrimeHunter: Actually that isn't a temporary issue. All categories that begin with numbers (or whose sort keys begin with numbers) will now be sorted under "0–9" in numeric order, per the community's request. The system used for Category:BLP articles proposed for deletion by days left is an ugly hack. It's basically trying to use headers as subcategories. Instead, it should sort the articles into actual subcategories. The {{Prod blp}} template will need to be updated. Kaldari (talk) 04:16, 30 August 2016 (UTC)
Well, if they are lumped into 0-9 in numeric order - meaning that the oldest ones will be first - that means that the expired ones will be the first ones listed so we will still be able to patrol the category. That could be a temporary way around the problem. I do hope that someone creates another ugly hack to make it more obvious. 0;-D Thanks for the information. --MelanieN (talk) 15:40, 30 August 2016 (UTC)
I've been taking a long look at the contents of Category:Top-importance_United_States_articles, reassessing them when appropriate. Mostly in the Hs and Ls of late. At the present time, the category starts with the As, then goes to the Hs, then the Ls, then back to C (no Bs) and the rest alphabetically. What's going on here? And am I the only one to see this? pbp13:49, 31 August 2016 (UTC)
Hi, When I view Category:Living people it appears to be wrongly sorted, with 0-9 appearing between E and F, moreover I see A-F on the first page (which cant be right) and the (next page) and (previous page) buttons do not work... Is it just me, or is there a more fundamental issue with this category (I use IE 11) ! Thanks GrahamHardy (talk) 15:45, 31 August 2016 (UTC)
The category seems to be all messed up. A user, TheDeviantPro, added some games to it that I recently removed, namely Grand Theft Auto, Grand Theft Auto 2, Grand Theft Auto London, Grow Home, Dead Rising 4, Driver (video game series), Driver 3, Midnight Club (video game series), and Midnight Club: Street Racing. It seems that removing all these games from the category sets it back to alphabetical order, but another problem is occurring where if you click on next page, it just brings you back to the original page. And if you click previous page, only one game shows up.Dohvahkiin (talk) 16:34, 31 August 2016 (UTC)
I've just come across a weird category sorting problem; I don't know if this is an isolated incident or if there's a larger system bug, so I thought I should report it just in case. I just created a starter stub for the new Canadian television series Tricked — in some categories, such as Category:2010s Canadian television series, it sorts correctly in every respect, but in the categories Category:Hidden camera television series, Category:YTV shows and Category:Television series by Force Four Entertainment, its inclusion seems to be causing the letter T to become alphabetized between M and N instead of between S and U. And in the same categories, even within the letter T itself the entry is sorting at the top of the list, even ahead of "Ta", even though the sortkey in the article is typed correctly (in the categories where it isn't causing the entire T group to missort, however, it sorts correctly with the other Tr's.) Could somebody with more technical expertise than I've got take a look at this? Thanks. Bearcat (talk) 19:16, 31 August 2016 (UTC)
Never mind. I just saw the post above about the new category sorting algorithm and how it might mess some things up for a few days. Guess that answers my question. Bearcat (talk) 19:23, 31 August 2016 (UTC)
Updating documentation
There is some documentation that will need updating:
"By default, a page is sorted under the first letter of its full name including the namespace. Also, MediaWiki groups accented characters separately from their unaccented version, so pages starting by À, Á, Ä, will be listed under separate headings, instead of under heading A."
and
"Unlike at Special:Allpages and Special:Prefixindex, a space is treated as a space (coming before all other characters), not as an underscore. A page whose title begins with a number will be grouped only according to the first number. Thus "1 dog", "11 dogs", and "112 dogs" all appear under the "1" heading (not under "1", "10", and "100" headings). This will cause "112 dogs" to appear before "2 dogs" on the category page"
"Because the software uses an imperfect computer sorting rather than true alphabetical ordering (see details), it is important that some sort keys be adjusted. Accented characters must be replaced by their English-language counterparts. For example, the Łódź article uses "DEFAULTSORT:Lodz"."
and
"Only hyphens, apostrophes and periods/full stops punctuation marks should be kept in sort values. All other punctuation marks should be removed. The only exception is the apostrophe should be removed for names beginning with O'. For example, Eugene O'Neill is sorted "DEFAULTSORT:ONeill, Eugene"."
and
"Entries containing numbers sometimes need special sort keys to ensure numerical rather than alphabetical ordering (for example, 19 and 103 come before 2 in alphabetical order, and IX comes before V). So Haydn's 13th symphony might have the sort key "Symphony 013", the zero ensuring that it is listed before symphonies 100–108; Pope John IX might have a sort key "John 09". It is important to stick to the same system for all similar entries in a given category."
A bit more warning might have enabled people to find what needed updating - can anyone think of any other documentation pages that need updating? Maybe a suitable search will throw up more examples? Will probably affect some bots as well. From the older discussion linked above: "But someone should probably notify WP:BOT/WP:BAG, WP:AWB, WP:TWINKLE, WP:HOTCAT, etc., to make sure that this won't affect/break those tools." - did this notification and the relevant changes ever get done? Carcharoth (talk) 02:30, 1 September 2016 (UTC)
I'd like the cat table rebuild to finish first, so that we know the ultimate effects on non-Latin alphabet characters. Will Α and А still sort after Z, for instance. --Redrose64 (talk) 15:24, 1 September 2016 (UTC)
Update: The script, which is running through categories in alphabetical order, has passed Category:Living people, so we're heading for the Ms. The first half of the alphabet included all of the numbers (1950s novels, etc) and the second half of the alphabet has some uncommon letters like Q, X and Z, so I'd expect the second half to go faster. It's been running for three days, so my estimate is that it ought to finish on Saturday or Sunday. Sorry again for disrupting people's workflows; I know it's a pain. (Some pings: @AddWittyNameHere:@Purplebackpack89:@GrahamHardy:@Dohvahkiin:@Bearcat:@PrimeHunter:@John of Reading:@Foxj:@Redrose64:@Carcharoth: ) -- DannyH (WMF) (talk) 17:16, 1 September 2016 (UTC)
For reference, the rest of the alphabet looks like this:
| L | 6959353 |
| M | 3601568 |
| N | 6462946 |
| O | 732914 |
| P | 3643089 |
| Q | 51545 |
| R | 4884146 |
| S | 13874804 |
| T | 1456723 |
| U | 7522964 |
| V | 516546 |
| W | 14499808 |
| X | 16045 |
| Y | 298845 |
So S, and W are going to be slightly long, but mostly its shorter towards the end (Keep in mind A and the number 1 were excessively big). Bawolff (talk) 18:49, 1 September 2016 (UTC)
@GrahamHardy: That's really interesting, thanks for pointing that out. I just did a test on Meta-Wiki, which still has the original sorting, and it does put Andy Ennis before Jessica Ennis-Hill, as we would expect. But -- I also discovered in that test that the original sorting does this:
Jessica Ennis Hill
Andy Ennis
Bruce Ennis
Jessica Ennis-Hill
I'm not sure what that does in the new sorting. I filed a ticket (T144634), and I'll see what I can find out about this. I probably won't be able to talk to people until after the US holiday on Monday. Thanks again for the report. -- DannyH (WMF) (talk) 20:03, 2 September 2016 (UTC)
What should be done is not to look at the article name, but the sortkey that is used. For these four cases, the sortkeys will be:
Ennis Hill, Jessica
Ennis, Andy
Ennis, Bruce
Ennis-Hill, Jessica
It is known that space collates before all other characters, and that common punctuation collates before letters. So the question is: does the hyphen-minus character collate before or after the comma? --Redrose64 (talk) 22:39, 2 September 2016 (UTC)
The algorithm we are using (UCA) has several config options related to punctuation. In the default config ("non-ignorable" which we are using), punctuation characters are considered to be like letters, and the order goes " " (space) then "-" then ",". Bawolff (talk) 21:36, 3 September 2016 (UTC)
@Redrose64 and Bawolff: Yes, the root of the problem is the use of commas in DEFAULTSORT keys. Really we shouldn't be using commas, but I imagine this might be a hard convention to change. I imagine most people just assume that the commas are ignored, as they would be by a librarian seeing "Ennis Hill, Jessica" in a card catalog, but all the collation algorithms consider the comma as part of the string to sort. It's just that the old collation "incorrectly" sorted commas before hyphens, so no one noticed. So far, I haven't been able to find any UCA option combinations that would give us the desired order (" ", ",", "-"), nor does that seem like a very natural sorting order. It seems to me that the best options would be to either hack the DEFAULTSORT parser function to strip out commas or make a proposal to the English Wikipedia community to stop using commas in sort keys. Any thoughts on this? Kaldari (talk) 23:52, 6 September 2016 (UTC)
Hello. A very unusual one that even I as an IT consultant cannot fathom. In this category, which holds sub-categories in the main, the sub-cats are of course sorted alphabetically. Except that "S" falls between "H" and "L" (there is no "I", "J" or "K")! I've been trying a few tests to see if I can work it out but probably have a blind spot. Can someone please investigate? Thanks very much. BoJó | talk UTC 14:10, 3 September 2016 (UTC)
In fact, the whole thing has gone to pot. I just noticed that some temporary changes of piping I did have caused "M" to precede "A" and "T" to precede "P". If it's me, I apologise, but I'm not normally a Jonah. BoJó | talk UTC 14:10, 3 September 2016 (UTC)
The script is going alphabetically, and at press time, it's past category starting with "Wikipedia", so it shouldn't be long now. -- DannyH (WMF) (talk) 17:36, 4 September 2016 (UTC)
The new category collation script has finished running. Now, you should see categories sorting "0-9" in numerical order, and the weird hiccups should be gone. Thank you, everybody, for being patient during this process, especially the folks who helped to explain what was happening when people got confused.
We'll be looking more into the hyphenated names issue described above. You can follow progress on this ticket: T144634, and feel free to let me know if you have questions or more thoughts about this. Thanks! -- DannyH (WMF) (talk) 17:31, 6 September 2016 (UTC)
Coordinates parser function
Do the Geohack parameters of {{#coordinates:}} actually do anything? (The documentation says that the coordinates parameters are for the API access, but I'm not sure what the rest of the parser function does.) Jc86035 (talk) Use {{re|Jc86035}} to reply to me13:30, 8 September 2016 (UTC)
I don't see any such split; I do see that these two navboxes are significantly narrower than normal. But first, have you discussed with Davidbuddy9, either on their talk page or that of a relevant WikiProject? Is there consensus to have either a forced width, or the default navbox (full) width? --Redrose64 (talk) 21:35, 7 September 2016 (UTC)
Technically, it was always like this, but the width:auto feature broke so I was just resizing them to continue with the status quo. Running a WQHD screen (2560x1440) I don't see an issue with having titles break into two lines. If the issue with width:auto is fixed it would be fine just to revert to it. The biggest issue is fixing width:auto which would not make it browser dependent. Davidbuddy9Talk01:44, 8 September 2016 (UTC)
@Davidbuddy9: What do you mean by "the width:auto feature broke"? If I omit any width specification, it goes to full width, automatically. Moreover, this is how most other navboxes behave. --Redrose64 (talk) 09:48, 8 September 2016 (UTC)
@Redrose64: take a look at the code in this revision it was previously used to resize navboxes to an appropriate size automatically, this post here also talks about width:auto being broken, "Moreover, this is how most other navboxes behave" could be an illusion due to width:auto being broken. I've seen other navboxes also been resized like this too. Davidbuddy9Talk20:26, 8 September 2016 (UTC)
What you describe is a CSS declaration, and has been valid since Cascading Style Sheets, level 1 (CSS 1), and is still in the CSS 3 draft specs such as CSS basic box model. The MediaWiki software does not handle the effects of such declarations; they are processed by your browser, so any "breakage" is the fault of your browser's author(s). --Redrose64 (talk) 00:06, 9 September 2016 (UTC)
Wikipedia gets Map links and Geoshapes service
Dear community, this week we enabled <maplink> support on all Wikipedia and sister projects. This means that now an article can have a link to a map, and that map may contain highlighted regions and popups with information.
Demo:
<maplink>: The JSON content is not valid GeoJSON+simplestyle. The list below shows all attempts to interpret it according to the JSON Schema. Not all are errors.
/0/query: The property query is required
/0/ids: The property ids is required
/0: Failed to match at least one schema
/0/title: The property title is required
/0/service: The property service is required
/0: Failed to match exactly one schema
/0/geometries: The property geometries is required
/0/type: Does not have a value in the enumeration ["GeometryCollection"]
/0/type: Does not have a value in the enumeration ["MultiPolygon"]
/0/type: Does not have a value in the enumeration ["Point"]
/0/type: Does not have a value in the enumeration ["MultiPoint"]
/0/type: Does not have a value in the enumeration ["LineString"]
/0/type: Does not have a value in the enumeration ["MultiLineString"]
/0/type: Does not have a value in the enumeration ["Polygon"]
/0/coordinates: The property coordinates is required
/0/geometry: The property geometry is required
/0/type: Does not have a value in the enumeration ["Feature"]
/0/features: The property features is required
/0/type: Does not have a value in the enumeration ["FeatureCollection"]
Our next step is to add an informational sidebar to the map, similar to what is being shown on the "geohack" page (map link in the upper right corner of most location articles). Check out proposed screenshots.
We now also have a geoshapes service. So if Open Street Maps community has defined a region and assigned it a Wikidata ID, you can draw it on the map with that ID. Or you can use Wikidata Query Service (via SPARQL language), to query for those IDs and draw them on the map, coloring them and adding popup information. Geoshapes can also be used for the graphs demo.
Evad, we need to figure out how KML files are used, and if that information is an exact duplicate of what users contribute to the Open Street Map. I presume we don't want duplicates if we can avoid it, except possibly in some corner cases. It seems that most of the KML usage has been to draw a line representing some road, as well as some shapes to represent city limits. If so, OSM is a much much better location for such information - we have less than 10,000 shapes, they have millions. OSM community has much better ways to deal with the accuracy of such data, as well as some tools to annotate it, and it is automatically available to all the Wikipedia languages. For example,
<maplink>: The JSON content is not valid GeoJSON+simplestyle. The list below shows all attempts to interpret it according to the JSON Schema. Not all are errors.
/0/query: The property query is required
/0/ids: The property ids is required
/0: Failed to match at least one schema
/0/title: The property title is required
/0/service: The property service is required
/0: Failed to match exactly one schema
/0/geometries: The property geometries is required
/0/type: Does not have a value in the enumeration ["GeometryCollection"]
/0/type: Does not have a value in the enumeration ["MultiPolygon"]
/0/type: Does not have a value in the enumeration ["Point"]
/0/type: Does not have a value in the enumeration ["MultiPoint"]
/0/type: Does not have a value in the enumeration ["LineString"]
/0/type: Does not have a value in the enumeration ["MultiLineString"]
/0/type: Does not have a value in the enumeration ["Polygon"]
/0/coordinates: The property coordinates is required
/0/geometry: The property geometry is required
/0/type: Does not have a value in the enumeration ["Feature"]
/0/features: The property features is required
/0/type: Does not have a value in the enumeration ["FeatureCollection"]
does not require any data to be stored on the wiki, or any KML files. It simply references Berlin by its Wikidata ID Q64. That said, Wikidata IDs are very new to OSM community, and they need to be improved. Currently there are about 40,000 items in OSM db that have Wikidata ID.
The most massive KML usage - lines - is still a TODO. We might have all the needed data as OSM db, but we don't have it available to you yet. See T145175.
Lastly, geo data should be storable in one centralized location, e.g. Commons, and easily usable from all wikis. This is still a work in progress. --Yurik (talk) 04:43, 9 September 2016 (UTC)
(edit conflict) Thanks for the reply, Yurik. I continued the discussion on phabricator, since the scope is broader than English Wikipedia. (I did just intend this to be a pointer to the phab request, so that other users could contribute there if interested) - Evad37[talk]07:26, 9 September 2016 (UTC)
@Jc86035: my hope is that eventually <maplink> will provide all the functionality of GeoHack (and much more), so that {{Coord}} template can be changed to use <maplink> internally, instead of pointing to the wmflabs. Take a look at these screenshots, and let us know how it can be made better. Thx :) --Yurik (talk) 07:00, 9 September 2016 (UTC)
@Yurik: I guess the accuracy of OSM data in the overlays could be improved at zoom levels, and there could be a way of entering coordinates in DMS format. In addition, I've already posted this on Phabricator (no one noticed) but some OSM stopping points (maybe it's railway=stop?) are being unnecessarily rendered in the map tiles. Hope this is more widely implemented soon; looks much nicer than WikiMiniAtlas, Geohack and WIWOSM. Jc86035 (talk) Use {{re|Jc86035}} to reply to me07:21, 9 September 2016 (UTC)
User dropdown menu
On user pages and user talk pages, there used to be a dropdown menu called User that would allow you to see things like a user's block log, change log, and so on. Within the last week, it seems to have disappeared. What happened to it? Is it a bug? http://i.imgur.com/oA1QBdj.pngAmaury (talk | contribs) 02:25, 9 September 2016 (UTC)
@Amaury: You should also replace the mw.loader.load in your common.js with mw.loader.load('//ru.wikipedia.org/w/index.php?title=MediaWiki:Gadget-markblocked.js&action=raw&ctype=text/javascript'); which is what you originally intended to add. - NQ(talk)02:43, 9 September 2016 (UTC)
(edit conflict) @NQ: All fixed. Somehow got disabled, perhaps by an update. All good now, though. I will also fix my common.js as well per your comment. It's been a long time, but I'm sure that's what the instructions said to do, unless I missed something. I wonder if maybe that was part of it. Amaury (talk | contribs) 02:50, 9 September 2016 (UTC)
@Amaury: Probably just an oversight while copy-pasting. You could also replace the whole thing with importScript('User:NuclearWarfare/Mark-blocked script.js'); - all blocked users will be marked with a strikethrough. - NQ(talk)02:59, 9 September 2016 (UTC)
@NQ: One last question: Do you know if there's any way to keep the strike-through even when hovering over blocked users instead of having the normal underline text decoration? Amaury (talk | contribs) 03:16, 9 September 2016 (UTC)
Although I have no problem editing other articles, I am unable to remove the wikilink to the deleted article Wong Kai at Hong Kong Dreaming. Each time I make an attempt I get the same database error: "Function: WikiPage::lockAndGetLatest" and "Error: 1205 Lock wait timeout exceeded; try restarting transaction (10.64.32.27)". --Jezebel's Ponyobons mots16:22, 9 September 2016 (UTC)
When copying the code this page says to copy to my .css page, a warning comes up when trying to save it, saying there are errors. The other instructions did not lead me to any code either. Please tell me how best to proceed. Thank you.--John Cline (talk) 20:12, 9 September 2016 (UTC)
Redrose64, when I press "Save changes", a small grey box appears center-page, saying: The document contains errors. Are you sure you want to save? Incidentally, I started to undo the changes to my .css page, and the same warning appeared. I presume this indicates that the actual error is related to what was the existing page. Thank you for your insight.--John Cline (talk) 23:18, 9 September 2016 (UTC)
Wikipedia loading issues
For about a week now, when I first open my browser—Chrome—Wikipedia refuses to load. However, after about five minutes, if I click the reload button on the error page—or just refresh the page—everything works fine until the next day when the cycle repeats. It seemed to work okay yesterday, but it happened again today, so the data cleaning I did on Sunday before going to bed for Saturday doesn't appear to have done anything. Amaury (talk | contribs) 16:53, 5 September 2016 (UTC)
Have you got your watchlist set as a landing page when you open your browser? I've noticed that Wikipedia slows to a crawl sometimes when opening my watchlist—I assume the servers have a glitch somewhere. ‑ Iridescent17:09, 5 September 2016 (UTC)
@Amaury: Could you try doing a traceroute to en.wikipedia.org when this is occuring? The command on windows (from PowerShell/CMD) is tracert en.wikipedia.org and upload the output to pastebin or similar -- samtartalk or stalk15:37, 6 September 2016 (UTC)
@Amaury: I don't see anything concerning there (I've removed the link), I'll have a think - which ISP are you with, and where abouts are you located? I'm thinking, however, this could be system-related. Can you try in another browser? -- samtartalk or stalk15:09, 8 September 2016 (UTC)
@Samtar: Charter Communications and Ellensburg, Washington. Yes, I can try on my laptop tomorrow. Overall, it's really no big deal as after five minutes I'm able to reload and access WP, and it's only when I first open my browser after my computer's been off all night. However, you could be on to something; perhaps it's Windows 10's anniversary update, which hasn't rolled around to my laptop yet. Amaury (talk | contribs) 15:38, 8 September 2016 (UTC)
@Samtar: It worked okay the last couple of times. However, it happened again this morning, and a different browser did not work (Edge), but here's something interesting: I sometimes open Chrome incognito before opening it regularly to do my normal browsing to check something on the forums I visit as a guest, and when doing that, it always works. (It also works on Edge.) However, this is where it gets more interesting: if I then open Chrome regularly and it's the time that Wikipedia doesn't want to load for about the first five minutes, if I go back to incognito mode or Edge, Wikipedia now doesn't load. I've also been having similar issues with this, but not as frequently, I don't think, and not at the same time. It's pretty much the same thing of after minutes, it's fine, though I don't know if it's related despite the coincidence. Amaury (talk | contribs) 15:25, 10 September 2016 (UTC)
I've been having a similar issue on both Firefox and IE, for several days/weeks. Not all the time. And it hasn't happened (yet) today. I do not have WikEd checked on my Preferences, so that's not it. But when I open an edit window, it looks strange. Inbetween the edit window and the top of the page is a huge space of pastel colors all over the page, and the edit window seems to be all dark orange. If I do a preview, it straightens out. Sometimes I have to edit first and then Preview to straighten it out. I first started noticing it on the DYK queue and prep templates. But I've noticed it's not limited to templates or to DYK. And it's off and on. Just strange stuff. — Maile (talk) 16:06, 6 September 2016 (UTC)
Sports articles are the greatest offenders regarding navigation. There is a wrapper template ({{navboxes}}), but I strongly recommend removing him from those templates and those templates from his page. --Izno (talk) 19:57, 10 September 2016 (UTC)
Hello Adjutor101. The First template has audio clips. These audio clips are generated by {{IPA soundbox}} using which you can add audio's elsewhere. I didn't particularly get you, you want more audios in the article? (they are already lots!). The second template cannot be made smaller if we continue to the same infobox ({{IPA chart/core1}}) we need a smaller infobox. Though I work a lot with templates I am not the infobox expert you can put the second request at WP:Requested Templates and get a feedback! Thanks VarunFEB200311:26, 9 September 2016 (UTC)
When a user has added a spammy link to a bunch of articles (e.g. here) is there a way to undo these additions en masse or is it necessary to undo each one manually? Alexbrn (talk) 06:59, 11 September 2016 (UTC)
Seed technical article with LaTeX+BibTeX document, using Pandoc and wrangling Zotero's CSL
Hello,
This is an extension / followup to my previous question [23] (Is there a way to permalink to a section that'll survive when it gets archived?) Zotero is a very good tool for manual full cite insertion, (thanks @Pigsonthewing:) but...
...the problem I'm trying to solve is:automatically converting a semi simple LaTeX document (macros and BibTeX cites, but no sophisticated packages) into Wiki syntax.
Why solve it?:I (and I'd assume many other researchers in maths / computer science) spent years getting very comfortable writing documents in LaTeX, and have ressources that are already written in LaTeX. The secretarial work of getting comfortable with wiki markup, renouncing our preferred software and shortcuts (Kile, Emacs, Tex Maker,... + Git or SVN, etc), removing all macros from documents (that is very important: macros are the proper way to enforce consistent notations, so any good document is peppered with macros, and writing without them feels wrong), takes time, energy, and is an enthusiasm sink. (Those commodities are in short supply). Having a fully automated process to convert a LaTeX document would significantly lower the barrier of entry to create new articles, for me and more importantly (once documented someplace accessible) for many of my more knowledgeable colleagues.
(If I am wrong about Wikipedia not supporting article-scope LaTeX macros, I'd like to know !) (wikEd says "invalid bold/italics" here ??)
But how ?Pandoc seems like the answer. I have gotten quite close to a workable solution with this command:
See example result: [24]. (--variable link-citations=true doesn't seem to do anything, though). It's good enough to make usable articles, and crucially it expands macros, but the references are not in the usual wiki format.
From what I understand of Pandoc's manual, Pandoc uses Zotero's style definitions to format the cites. Zotero does export to mediawiki, but I can't find the export style in the repository. Can anyone versed in pandoc/Zotero find it? I feel I am one command-line parameter away from a full solution to my problem. If not, styles seem to be defined in an awful XML format called CSL, so a sufficiently courageous person (ie. not me) should be able to create a suitable export style. (But again, Zotero can already do it... the recipe must be here somewhere already...).
Gamall Wednesday Ida, I'm probably not the best person to comment here (it's an issue with Zotero rather than wikipedia, right?). Still, from what I remember from messing around with Zotero's styles a few years back, these xmls files (was the format called CSL – Citation Style Language?) define the formatting of a bibliography when it's created in Zotero. That has to do with what goes in what order, what is in italics, how numbers are styled etc. What you need, however, is the bit of Zotero that controls how it exports stuff in other formats (including wikipedia's citation templates) and that isn't controlled by the CSL files. Uanfala (talk) 20:42, 9 September 2016 (UTC)
Thanks, Uanfala. Problem is, that's the bit Pandoc gives me access to (that I've found). When it comes down to it, writing a Wiki-formatted cite is also just a matter of what goes in what order, with a bunch of string delimiters (opening and closing quotes, italics markup etc), so unless CSL lacks generality in some respect, it should at least theoretically be possible to (ab)use the formatting functions to export to cite templates. But you're probably right that Zotero is not meant to work that way: CSL states "font-style="italic"" in the style, and another layer presumably interprets what that means in terms of target output. Bummer. Gamall Wednesday Ida (talk) 10:05, 10 September 2016 (UTC)
The mw:citoid service uses Zotero translators to produce citation templates. Depending upon your needs, it might be faster to use it to re-generate the citations on wiki.
Here's another possibility: Can you display the LaTeX document in HTML (e.g., in your web browser, not raw HTML code)? If so, then you should be able to get document converted to wikitext merely by copying the document and pasting it into the visual editor. It'd be LaTeX to HTML to wikitext (two conversions = two opportunities for problems), but if it's relatively simple, it should work. You can use this sandbox for testing, if you want to try it out. Whatamidoing (WMF) (talk) 10:13, 11 September 2016 (UTC)
Thanks, Whatamidoing. There are LaTeX -> HTML converters, such as HeVeA. Depending on how smart the Visual Editor is in detecting cites in the text, that might work. Otherwise, pandoc followed by a manual pass with citoid seems like the way to go, for now. It may be a good while before I have time to do some testing again, though. (Thanks for the XKCD, btw, I don't recall that particular one). Gamall Wednesday Ida (talk) 11:25, 11 September 2016 (UTC)
Allow non-existing article in a language to list articles in other languages
Suggestion: Allow indicating that a non-existing article in current language exists in another language, so show the other language(s) in the Languages list, when suggesting creation of article.
Solution (idea): WikiData must allow language specification for a non-existing article in a certain language.
Advantage: Clicking on a read link for a non-existing article in a certain language could then give the option to read the article in other languages, in addition to creating the article. The reader can then get the information in another language of own choice, while the link still shows that the article is non-existing in the current language.
No, that extension is about displaying content from Wikidata in a non-existent article, not to display sitelinks on non-existent articles that point to homologous articles on other projects. Jo-Jo Eumerus (talk, contributions) 11:48, 10 September 2016 (UTC)
I used to be able to purge my cache without the confirmation warning prompt coming up each time. Is there a way to disable this prompt so I don't have to click "yes" each time? I did a quick look through my preferences and didn't see anything there. Did I miss it somewhere? Thanks, Mkdwtalk05:27, 7 September 2016 (UTC)
@Mkdw: Put the following code into your common.js page (I'll be designing the doc page of the script shortly) importScript("User:VarunFEB2003/Purge Skip.js"); It will allow you to skip the confirmation step for purging. Thanks VarunFEB200313:36, 7 September 2016 (UTC)
Thanks a lot Begoon the original code isn't working also. We can obviously use the original code but simplifying that into a line makes it easy that s why I was developing the Script! thanks VarunFEB200315:22, 7 September 2016 (UTC)
Well, I just tested Unready's code, and it worked fine for me with ?action=purge. You get a brief flash of the confirmation page, but you don't need to click anything, and the page refreshes. Without the code you need to click the "yes" button on the confirmation page. --Begoon15:33, 7 September 2016 (UTC)
Indeed it does, and that's what I actually use myself. Neat and functional. It doesn't "fix" the embedded "purge this page" buttons/links on some pages, but that doesn't really matter - just click the clock instead... --Begoon16:05, 7 September 2016 (UTC)
Thanks, I knew about the clock before but I have a few scripts I used to semi-automate administrative processes that I use such as closing AFDs. They were being interrupted with the confirmation prompt and I'd have to follow up the rest of the steps manually. I'll give the script above a try and see if it resolves my issue without being interrupted. Mkdwtalk03:49, 8 September 2016 (UTC)
First of all Thank you so much Mkdw for using my script it works perfectly tested it now! Begoon Unready's code is now working tested that too. Xaosflux I was actually thinking of getting Jimbo's help here to get a better solution because user convenience is on one side and system problems on other side we can have a better solution than confirmation! And as Jo-Jo Eumerus said we can use these scripts to avoid that thing I have dropped the idea of asking Jimbo!
All users who wish to avoid the confirmation step can put this code in their common.js
Thanks to the Graph extension, and specifically Module:Graph, it is possible to, for instance, easily create political maps visualizing which countries have ratified a certain treaty. I wonder now if there is also a way to make such maps (or <graph> elements more generally) accessible to visually impaired readers using a screen reader to browse Wikipedia. For images the recommendation is to use the "alt =" attribute -- is there something similar for <graph> elements? — Pajz (talk) 17:58, 11 September 2016 (UTC)
Pajz, there was a request for alt="..." tag a while ago phab:T98687. We might also consider implementing text="..." tag, and use that text as the graph's caption (frame). --Yurik (talk) 21:56, 11 September 2016 (UTC)
Yurik, thanks. So, looking at your comment on the Phabricator task, is it possible in the meantime to use <div alt="...">{{Graph:Map|...}}</div>, or wouldn't that work properly? Best, — Pajz (talk) 01:52, 12 September 2016 (UTC)
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Recent changes
The Wikimedia Commons app for Android can now show nearby places that need photos. [27]
The RevisionSlider will be available as a beta feature on all wikis from 13 September. This will make it easier to navigate between diffs in the page history. [30]
A new user right will allow most users to change the content model of pages. [31][32]
The new version of MediaWiki will be on test wikis and MediaWiki.org from 13 September. It will be on non-Wikipedia wikis and some Wikipedias from 14 September. It will be on all wikis from 15 September (calendar).
Meetings
You can join the next meeting with the VisualEditor team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on 13 September at 19:00 (UTC). See how to join.
Future changes
When you search on the Wikimedia wikis in the future you could see results from sister projects in your language. You can read more and discuss how this could work.
The edit summary for the first addition of a tracking category said temp tracking cat; will remove shortly. This was at 16:08 UTC, 8 September 2016 (1.5 days ago now). Since then, the two categories have been populating very slowly, with the numbers slowly increasing. Andy (incorrectly) thought that not many articles used these parameters. I suspect that nearly all 3000 transclusions of this template use these parameters, so the population of the categories may take some time (but shouldn't really be taking this long - is the job queue very slow for some reason?).
I don't know the current state of the job queue, but two weeks ago I saw an error tracking category with about 50 entries—the error had been reverted when I saw it, but it took many days for it clear. The category was unchanged for more than a week when it was manually purged (per here). Johnuniq (talk) 07:44, 10 September 2016 (UTC)
Full population of new tracking categories typically takes a few days, but it can take weeks, or even months. This is a very long-standing problem. The best practice for a temporary tracking category is to create it as a hidden category, wait for it to populate, use it for its intended purpose, remove the tracking code from the template, and then mark the category for speedy deletion. – Jonesey95 (talk) 19:48, 12 September 2016 (UTC)
Currently, there are several ways that we provide links in article to other relevant WP articles:
See also (for articles about drugs we can long lists of related chemicals, like this and longer even)
Navboxes (scroll down from the link provided above and you will see 4 heavily populated navboxes on that article)
Categories (scroll down from the link provided above to see the four categories for that article)
And very recently, a new way of presenting categories, which you can see here (a subsection of "See also" that shows the category tree)
The move to start adding things structured like #4 is what prompted the discussion at WT:MED; these were being added to articles about classes of drugs.
An issue that arose while discussing this, is that the mobile version of WP omits a number of elements such as navboxes and categories; Google strips it down yet further for users in developing countries. Compare these three views:
(The above information on what mobile omits and the three views, was posted by User:WhatamIdoing at WT:MED, and I copied it here)
Solution #4 doesn't work very well on mobile either.
So the questions are, how should we structure information about related WP articles, so that the desktop version is still acceptable and the mobile version actually displays related WP articles? And... Is there anything the developers can do to help with this, especially on mobile, or is there any input they have as to what would be "light" enough for mobile? Jytdog (talk) 19:13, 7 September 2016 (UTC)
Related pages and a new method to present categories are the current lines of thought for that, both being experimented with. The overall idea is 'more structured information, so that it is simpler to present a sub selection of that information'. —TheDJ (talk • contribs) 07:29, 8 September 2016 (UTC)
We actively discourage see also section in the WP:MEDMOS. Another reason why option 4 is not ideal. We as editors could build structured info formatted for mobile and than replace navboxes with it, but that requires a lot of work. Doc James (talk · contribs · email) 12:31, 8 September 2016 (UTC)
1 Related pages self-generates a kind of "see also" list?
2 How this relate to See also sections?
3 Starting around Oct 1, for mobile you all are starting "a staged roll out, where we exclude the top 6 Wikipedias in terms of article count, deploy the feature to all other wikis at once. This helps making stable bug fixes easier, given smaller traffic"
2 One is a structured data provider and a list generator that can be influenced by humans. The other is human curated non-structured wikicode.
3 The feature has been present in both mobile and desktop beta modes for several months. On mobile apps it already is in production and in mobile web it will be rolled into production soon. The production rollout will be staged, with popular wiki's to follow after the smaller wiki's have received it, just so that any left over bugs don't bother the larger wiki's. For desktop it seems to be on hold for now, possibly because there is too little added value there right now to disturb the community with such a new feature. That's my interpretation at least, but I haven't followed development much lately. —TheDJ (talk • contribs) 07:59, 11 September 2016 (UTC)
"You all" means "we all", if it includes volunteers such as TheDJ. User:Melamrawy (WMF) knows more about Related Pages than I do, but if you think about it this way, it might be easy: You read the article on Cancer. The computer searches for "cancer", and adds a few of the best hits as links at the bottom of the page. See this screenshot from desktop to get a basic idea (although it'll be a mobile-first deployment), or go to Special:Preferences#mw-prefsection-betafeatures and opt in to try it out.
IMO this will be most useful to the smaller wikis, which mostly don't have navboxes, ==See also== sections, or other human-curated methods of helping readers find related articles. (Also handy on smartphones, since I still don't see how anyone types on them.) WhatamIdoing (talk) 10:26, 11 September 2016 (UTC)
From September 13th on, RevisionSlider will be available as a beta feature in your wiki. The RevisionSlider adds a slider view to the diff page, so that you can easily move between revisions. The feature fulfills a wish from the German Community’s Technical Wishlist. Everyone is invited to test the feature and we hope that it will serve you well in your work!
The "deletion tag log" is a Page Curation-specific log, and there is no technical means for Twinkle or other tools to add entries to this log. AzaToth, the creator of Twinkle, requested this feature some years ago, but nothing has happened, and most likely nothing will happen. — This, that and the other (talk)10:24, 13 September 2016 (UTC)
mw:Page Curation#Log:Marked for Deletion claims: This functionality works regardless of how the template is injected into the page: it is an "on save" hook, and is not a special function of the Page Triage software.
This update is necessary for manual "speedy deletion request" also, as that would help find pages where speedy deletion was rejected by administrator with edit summary "credible claim of notability but doubtful, please take it to AFD". As some articles can be deleted only through AFD, not speedy deletion. MarvellousSpider-Man11:26, 13 September 2016 (UTC)
Greetings! The Project Grants program is accepting proposals from September 12 to October 11 to fund new tools, research, offline outreach (including editathon series, workshops, etc), online organizing (including contests), and other experiments that enhance the work of Wikimedia volunteers.
Project Grants can support you and your team’s project development time in addition to project expenses such as materials, travel, and rental space.
hi
i logged out and it works. Its just when I am logged in, the "load bar" is stuck at 80%. I tried my phone as well. same thing. I tried on Microsoft Edge and same thing. I think its my account so i reset my preferences. same thing. Pyrusca (talk) 18:40, 13 September 2016 (UTC)
First of all, let me distinguish two kinds of shortcut:
those intended to redirect to an article. Example: WP:N.
those intended to redirect to an anchor within an article, e.g. to a heading within the article. Example: WP:GNG.
As of at least the last few weeks, as far as I can tell, and quite possibly for much longer than this, the latter type of shortcut has not worked unless the user has JavaScript enabled in their browser.
Instead of taking the user to the anchor as intended, such shortcuts simply take users without JavaScript to the top of the article that the anchor sits within. That means that instead of seeing the intended section of the article, the user instead sees the article's heading and introduction. This can potentially be very confusing for the user, if the article's introduction is of limited relevance to the circumstance that caused the user to follow the shortcut.
Such breakage is especially unhelpful in the case of Wikipedia guidelines. It is common practice for Wikipedia editors to use such shortcuts to refer to Wikipedia guidelines. This works very well if the shortcuts work, but if the shortcuts don't work, then it leaves the user confused about the editor's intended meaning, and about which aspects of the guidelines the editor was trying to draw to their attention.
I therefore feel it is important that these shortcuts should not be broken: they should work as intended, regardless of whether the user has JavaScript enabled.
To forestall any replies to the effect that all users should enable JavaScript, let me note that there are many valid reasons why users might browse without JavaScript enabled, including:
Performance: enabling JavaScript can slow down some computers.
Lack of support: some Web browsers do not support JavaScript.
Security: many classes of security vulnerability can be avoided by avoiding executing JavaScript in the browser.
Accessibility: some users find animations and other dynamic uses of JavaScript to be an accessibility impediment.
Is this a known bug? I searched Phabricator but didn't find it reported.
It's a known problem, it goes back weeks or months, and when it was last raised I commented on it myself (something about the URL fragment being processed client-side) - but I can't find that thread. --Redrose64 (talk) 22:36, 5 September 2016 (UTC)
Thanks. Good to know it's not just me! Do please update here with links to any additional relevant discussions you manage to unearth. In the meantime, I have filed a bug report. zazpot (talk) 23:37, 5 September 2016 (UTC)
what browser type and version ? I've not experienced such problems with Safari, but if this truly is broken without javascript enabled, then most likely it is a browser specific issue, since without JS, this is a really fundamental part of how the browser works (with JS, we do some repositioning tricks, because there might be collapsible content interfering with the positioning of the anchor). —TheDJ (talk • contribs) 06:11, 6 September 2016 (UTC)
Hmm reading this again..., you are making a distinction between two shortcuts that is not relevant. If you point to an anchor somewhere along a page while using an HTTP redirect (used for wiki article redirects, Special:Permalink and other non-canonical urls) at the same time, then JS is required to reliably take you to that position with some browsers. If you don't enable Javascript, then redirects to pages are possible (like WP:N), redirects to an anchor inside a canonical page title are possible (like this section, but redirects to an anchor inside a redirected page (like this section via WP:VP/T), depend on if your browser preserves anchors across redirects (and if your browser doesn't, then that redirect might not work if you disable javascript). —TheDJ (talk • contribs) 11:25, 6 September 2016 (UTC)
what browser type and version? I would prefer not to publicly report my browser and version.
this is a really fundamental part of how the browser works. If you mean, "Your browser is faulty if it doesn't follow anchor links successfully" then my reply is: my browser is not faulty in this respect, and it does follow anchor links successfully. For example, if I open a new browser window or tab, enter https://en.wikipedia.org/wiki/Wikipedia:Notability#General_notability_guideline in the address bar and press Enter, then my browser does not take me to the top of that page. Rather, it takes me to the correct section of the page, as desired and expected, and my address bar shows https://en.wikipedia.org/wiki/Wikipedia:Notability#General_notability_guideline.
Thanks all. Looks like we've joined all the dots sufficient to identify the issue and confirm that it is affecting multiple people. Please let's preserve this discussion as it is for reference until the bug is fixed. I'm sure the Mediawiki devs will address it in due course. If anyone has any technical contributions to add (e.g. code patches, etc), please do so through the bug tracker (i.e. Phabricator). Thanks again. zazpot (talk) 12:55, 7 September 2016 (UTC)
However, it directs you to the beginning of the article, instead of section 9. Can some expert on redirection please fix it? Also, is the R-template necessary now? I believe it comes from an earlier revision. --RoyGoldsmith (talk) 14:37, 6 September 2016 (UTC)
Tried it again and it worked fine. My bad, I guess, although I use IE11 with JS on. Just for my curiosity, can anyone tell me what the R-from-capitalisation template means? --RoyGoldsmith (talk) 17:55, 6 September 2016 (UTC)
@Redrose64: OK. If I've got you right, the {{R from other capitalisation}} should be removed since "Suspension clause" and "Article One of the United States Constitution", with or without "Section 9", is not a capitalization difference. Right???
Also, I think I've discovered my original problem. If you are already on Article One of the United States Constitution and you have another tab with an article that redirects to Article One (say Martial law) and you click on the redirect (in this case right below the United States subsection of Martial law) then this second redirect will go to the top of "Article One of the United States Constitution" and stay there. At least it works that way for me in IE11. This may be a problem with the redirect software, instead of simply rephrasing the redirect page. --RoyGoldsmith (talk) 21:05, 6 September 2016 (UTC)
On the {{R from other capitalisation}}, even though it dates back from when this redirected to Suspension Clause (with a capital "C"), in my opinion it is useful to still keep the explanation around in case anyone wonders why both redirects exist. This part isn't really a technical issue, though, since the template is just informative and I doubt anyone would object if you edited it out. On the javascript issue, even when enabled there have been reliability issues in the past with certain browsers and conditions. See, e.g., T110501:RedirectToFragment script (redirects to section headers) behaving unreliably (now closed). You may have identified another one. 24.151.10.165 (talk) 19:14, 8 September 2016 (UTC)
It's actually useful. {{Redirect from other capitalisation}} (I prefer the full name variety for clarity) explains what the purpose of the redirect is (or originally was). Redirects are re-purposed by other people as synonym lists, and some of them are not suitable for that purpose. Editors also like to nominate redirects they don't understand for deletion. This modest amount of documentation saves valuable time, and reduces the number of incorrect deletions. All the best: RichFarmbrough, 19:35, 13 September 2016 (UTC).
BT DNS hijacking
BT have an issue where they hijack all DNS connections and display a message implying that this is due to BT Protect.
In the below nslookup example, attempting to use google-public-dns-a.google.com gives the malicious BT IP addresses, while using the BT hub, which uses the BT name servers works perfectly well.
All original research, but from a few web searches on BT's community board, it seems that this may be BT trying to direct your traffic toward network paths dedicated for Google. If this is the case, then only Google-related domains should be hijacked. It looks like sending DNS requests on a port other than 53 works, with some online resources recommending OpenDNS with DNSCrypt for this purpose. Mamyles (talk) 21:15, 13 September 2016 (UTC)
Some articles not found if Google search is restricted to site:wikipedia.org
Google search results can depend on country, time and probably other factors. Never assume others see the same. For me the only Wikipedia page in your first search is the top result in both searches: RMVB. It's also the top result for "RMVB site:en.wikipedia.org". PrimeHunter (talk) 01:42, 14 September 2016 (UTC)
Good point, I should have been more precise. I see the above faulty behavior when accessing Google with all browsers (including Incognito Windows) from Saint Paul, MN, USA. I don't see the faulty behavior when accessing Google from Paderborn, Germany. AxelBoldt (talk) 02:53, 14 September 2016 (UTC)
Question on _INDEX_ and Google.
I removed _INDEX_ from an article. An editor reverted saying it must be there because the article's title contained an apostrophe. Articles with apostrophes are not always picked up by Google. This isn't an issue with Bing. They said the article wasn't recognized by Google until _INDEX_ was added. Plus, the Google rank wasn't #1 or #2 without _INDEX_ being kept. I see no evidence of _INDEX_ and Google rank. I checked alot of new articles with apostrophes and all but one were listed by Google and Bing. Coeur d'Alene School District is listed by Bing and not by Google. Article was created about 26 hours ago.
Questions are: Does Google take awhile to list articles or just articles with apostrophes? I can't see anything in _INDEX_ that would cause anything to happen for an article, but is there something? Bgwhite (talk) 05:26, 13 September 2016 (UTC)
Hello Bgwhite Coeur d'Alene School Districtins listed by Google it takes no more than 1-2 hours for Google to list it. Article namespace is automatically indexed by all search engines including Google and Bing irrespective of their names. The INDEX Magic Word is for non article namespace which is not auto indexed. Placing __INDEX__ in an article is useless. It can be placed on user pages where you want to index it like Xaosflux's user page VarunFEB200306:07, 13 September 2016 (UTC)
It's true there are Google issues with names containing apostrophes. See phab:T106793. This is the first time I hear a claim that INDEX makes a difference and I doubt that. If an article appeared in Google or got a higher rank after INDEX was added then the timing was probably a coincidence and it would also have happened without INDEX. PrimeHunter (talk) 10:33, 13 September 2016 (UTC)
Significant change with implication for Draft namespace & AFC
Those of you who didn't read the latest Tech News may have missed that:
The name of the "Save page" button will change. The button will say "Publish page" when you create a new page. It will say "Publish changes" when you change an existing page. [34][35]
Oh, that's a bit awkward. Could it at least be changed from "Publish page" to "Publish draft" in the draft namespace? Joe Roe (talk) 16:56, 30 August 2016 (UTC)
I see the awkwardness, but it doesn't really do any harm. If a submitter thinks that they have published to mainspace, and they haven't, at least they haven't set up a deletion. A sort of opposite problem happens when someone submits a page to AFC because they don't understand what Submit means, but, again, at least, they haven't set up a deletion. (That is, they haven't set up a deletion unless they submitted something that is blatantly inappropriate such as an attack page or spam.) Robert McClenon (talk) 15:02, 2 September 2016 (UTC)
You appear to have overlooked at least one likely scenario - the user has finished working on a draft, and knows it is not ready for publication. The only options are "publish" [sic] or close the browser without doing so. We have a draft userspace, and sandboxes, for a reason. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits20:41, 2 September 2016 (UTC)
The new version seems to have been deployed. The save page, show preview and show changes buttons have significantly widened. However the name change to Publish hasn't yet taken place. Can the concerned WMF employee please provide some clarity here. Whatamidoing (WMF) are you aware of any changes related to this? VarunFEB200318:20, 3 September 2016 (UTC)
Quick replies:
The buttons all seem to be about the same size for me. Did you zoom in or change the font size in your browser?
Having a different button label per namespace is not feasible. That's why the labels were changed to say "page" instead of "article" (years ago).
Cut the "may be interested" snark. You've come up with the "what is publication" line plenty of times now. But the legal argument is clearly a sideshow to your UX argument. Save page has been fine for >10 years and if it were such a problem surely legal would have complained earlier. The problem is dealt with by the small print. Besides, if it is so important to you that Wikipedia's interface is in legalistic language, I can think of some other quite silly button changes. The problem with draftspace workflow is entirely of your making with this change. BethNaught (talk) 08:29, 5 September 2016 (UTC)
Andy has been thinking that putting content on the internet, where the general public has access to it, is somehow not "publishing" it. I believe that he may be interested in a different POV on that subject, e.g., the one held by the US Copyright Office. People truly are "publishing" their content in the draftspace. There are certainly other considerations, such as the reports from multiple studies with new users over the last 5+ years. But that wasn't his concern. His main concern seems to be that people will realize that putting an unfinished draft on the internet irrevocably constitutes "publishing" it (at least in some senses, e.g., the sense used in copyright law). Whatamidoing (WMF) (talk) 15:09, 5 September 2016 (UTC)
My initial concern at your apparent ability to read my thoughts is surpassed only by my relief at seeing you are in fact utterly unable to do so. Furthermore, while I am indeed interested in your attempts to sidestep the valid concerns I have raised here, and previously, by attempting to misrepresent me, I am only interested in as much that I see that you do so using a WMF account. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits15:31, 5 September 2016 (UTC)
What BethNaught said. From your link, "The way in which copyright protection is secured is frequently misunderstood. No publication or registration [...] is required to secure copyright. [...]Copyright is secured automatically when the work is created, and a work is “created” when it is fixed in a copy or phonorecord for the first time." The pages then go into detail about publication, yes, but nothing there indicates that having a "save" button or a "publish" button makes any difference at all for anyone involved. We do now have the problem that the disclaimer says "by clicking the "save page" button" and the button actualy says "save changes", making your disclaimer (or whatever you call that line) technically invalid. If you / the WMF are so worried about copyright and legal procedures, perhaps you should better look at that first. Fram (talk) 08:44, 5 September 2016 (UTC)
Whether your work is published or not doesn't change whether you hold copyright, but it does change certain effects of law, including how many years until it reaches the public domain. Whatamidoing (WMF) (talk) 15:09, 5 September 2016 (UTC)
And whether you publish by using a "save" or a "publish" button doesn't change this one bit of course. "The year of publication may determine the duration of copyright protection for anonymous and pseudonymous works": the year, not the method, never mind the text on the button. "Publication" doesn't require a "Publish" text on a button, and all your legal handwaving is nothing but that. Anyway, at least you are not trying to read my mind or threaten me, so I guess I am the lucky one in this discussion. Fram (talk) 16:50, 5 September 2016 (UTC)
But the button may "accurately inform" them in the heads of the WMF, but not to many editors apparently. Publishing a draft or a sandbox article gives the impression that it is sent to the mainspace, not that it is saved where it was already. The number of complaints from people who "saved" something and were unpleasantly surprised that it was already "published" seems to be minimal (as in indistinguishable from zero). The confusion the change from "save"' to "publish" will cause is a bigger problem than the pseaudo-legal "infomation" you hope to give. Fram (talk) 07:08, 6 September 2016 (UTC)
@Robert McClenon: I think harm is done if someone creates a (good) draft and, thinking it's "published" walks away and never submits it to AfC, or doesn't respond to the first review, etc. Besides, even if there isn't harm, having a confusing and inconsistently worded draft workflow will further alienate new users, probably create more volunteer work at the Teahouse etc., and just looks shoddy. Joe Roe (talk) 10:57, 5 September 2016 (UTC)
The relevant system messages are MediaWiki:Publishpage and MediaWiki:Publishchanges (there may be more, but that should cover wikitext editing). You could make a proposal that they be locally overridden. BTW, the change was merged but then reverted for a vague reason by a sysadmin, but it could land anytime now. BethNaught (talk) 08:46, 5 September 2016 (UTC)
Is that a threat, Whatamidoing (WMF)? -- Never mind, we know you oppose it, so your brief repetition must be interpreted aa a threat. Also, are you going to address Fram's comment about the incorrect small primt banner? BethNaught (talk) 16:15, 5 September 2016 (UTC)
I am not threatening anyone with anything. I am telling you that I continue to recommend against the course of action that you have repeatedly suggested. I started to explain why I don't recommend it again, but decided it was redundant. I think this is the fourth time we've had this conversation just on this page, so you already know why I disagree with you.
What you're calling the "small print banner" is supposed to be updated at the same time as the change (along with a couple of other messages, apparently). Whatamidoing (WMF) (talk) 23:31, 5 September 2016 (UTC)
@BethNaught:@Robert McClenon:@Whatamidoing (WMF): What we are forgetting is pending changes. Saying PUBLISH PAGE would be misleading on pages with Pending Changes protection as the user would think his edits are "published" while they would be still waiting for a review/acceptance. This would be misleading which is not at all good. VarunFEB200312:27, 5 September 2016 (UTC)
I agree that if Pending Changes is in effect it doesn't publish the page and is therefore just plain incorrect and misleadingly so. That is a real problem. I see the AFC issue. How do we have a confusing draft workflow? Is it because the author thinks that they "published" the page? I agree that we don't need to confuse new editors any more, since, in my opinion, many new users are completely confused as it is (some because they came here from wrong reasons, and some just because Wikipedia is complicated). Robert McClenon (talk) 14:29, 5 September 2016 (UTC)
I wouldn't wish to guess how a court of law might interpret PendingChanges, but as a purely technical matter, the "pending changes" are irrevocably shared with the public. Even if your edit is rejected, the contents are still available and visible through the page's history. See, e.g., the vandalized caption in the infobox in this article. That was rejected under Pending Changes, but you can still see when you look directly at the old version. Whatamidoing (WMF) (talk) 15:09, 5 September 2016 (UTC)
In other words, you are saying that if Pending Changes is in effect, it Saves the change, although it doesn't Publish the change. A change is, in my opinion, only Published if it is seen by readers with no special knowledge of Wikipedia. Saving the page saves the page. It only publishes the page if the change faces the world. A pending change doesn't face the world. Pending changes are only shared with those members of the public who know how to view pending changes. That isn't publication. Robert McClenon (talk) 15:24, 5 September 2016 (UTC)
That is exactly what I am not saying. I am saying this: If Pending Changes is in effect, and you click this button, then you actually are offering copies of your copyrighted material to some "members of the public" (to quote your phrase), and that "is" publication even if it doesn't "feel like" publication to non-lawyers.
Also, "knowing how to view pending changes" requires no skill beyond knowing how to click on a URL that someone posts on the internet. It is not necessary to use the PendingChanges interface, or even to visit Wikipedia, to reach that content. Whatamidoing (WMF) (talk) 23:31, 5 September 2016 (UTC)
There are several Phab tickets on the subject, and the two main ones have been linked repeatedly in these discussions. Mostly, however, I report concerns during a weekly meeting with product managers. This way, I know that the information isn't getting lost in someone's overflowing inbox. ;-)
As you can see from comments in the Phab tickets, some of these concerns have been accepted as significant issues and others have not. If you'd like an overall summary of comments that I've seen or heard about, then generally the concerns that get accepted focus on something small and specific (probably the most common case: translation problems for a particular language; probably the case that bothers the team the most: this is going to require updating a lot of help and introductory pages).
On the far other end of the spectrum, several common general complaints (e.g., "IANAL but the button is wrong because users don't publish anything") have been consistently rejected and will not be accepted no matter how many editors agree with them. (I recommend against re-posting such comments there, because the etiquette at Phabricator discourages repeating the same arguments as a waste of everyone's time.) Whatamidoing (WMF) (talk) 23:31, 5 September 2016 (UTC)
So, there are no public, traeable venues were you are liaising our concerns to the WMF. The rest of your comment is the same-old "no matter what the editors want, we will do whatever we like anyway, because we know better". Just like with MV, Gather, Flow, ACT, VE, Machine translation... So, how long do you think will it take for enwiki to change the English "translation" of Publish to "Save", even though you recommend against it? Fram (talk) 07:08, 6 September 2016 (UTC)
The only ticket I've seen mentioned in these discussions (as opposed to the announcement I quoted) is phab:T131132. It's certainly worth reading; if only as a case study in how bad decisions get pushed through against reasoned objections. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits11:31, 6 September 2016 (UTC)
If anyone things we are the only ones complaining, think again: "As a user and sysop on Wikinews I am protesting against this change as in most if not all that language versions the term "publish" (or its equivalents in other languages) is used for the one special edit when an article is considered ready, well after it was proofread, doublechecked and reviewed, when it usually get halfprotected and is added to the main page and declared to never again modified anymore. The change would add confusion to the redaction processes in Wikinews."[36] This post from 10 August 2016 got no reply at all (so much for Phabricator etiquette, another tool that is only used to silence critics but doesn't mean that serious concerns should get a serious response apparently).
I see Whatamidoing (WMF) on 21 June 2016 claiming that "Repeated user research studies with new editors have shown that some believed that "Save page" would save a private copy of a new page in their accounts, rather than permanently publishing their changes on the Web."[37]. When asked in Phabricator[38] "could you link to those studies?" (post from 25 August), the reply (this Monday, 5 September) was "Unfortunately, most of them haven't been published", "I'm trying to collect some more details.", " I [...] assume that some studies will not be found.", and so on. Not a single link to a study. But in the same discussion, on 6 July, Whatamidoing already stated "Risker, that's not the only study that has looked at this. AFAICT the most recent was just a few months ago (and involved six people, which is the industry standard, for better or worse). Also AFAICT every single study that touches this question (usually as part of something else) has come to the same conclusion: a sizeable fraction of non-editors/first-time editors expect "Save" to work like it does on WordPress, i.e., that "Publish" is a separate button."
Basically, he knows that every single study had the result they propose, and confirms this whenever necessary, but when asked to link to those studies it suddenly becomes very hard to do so. In other words, "trust your government, we know what's best for you".
On 20 August, in the same discussion, the question is asked "@Whatamidoing-WMF writes on Meta-Wiki that "The Legal team at the Wikimedia Foundation supports this change." What is the citation for this claim?" (that claim is given by Whatamidoing on that same info page from 21 June 2016). Again, no answer or link has been provided.
I can't publish reports that I didn't write because WP:COPYVIO. What I've learned since the last time I posted on this subject is that most of the research was done by people who are no longer with the Foundation. (The 2016 New User Experience study is an exception, and I have already excerpted that unpublished report's sole mention of this subject in full – all seven words, to be precise.) The unpublished raw data is videos of identifiable living people and cannot be published.
I don't believe in studies you can't even link to. Why would the WMF conduct or order studies that can't even be published afterwards (not even the conclusions?) because of copyvio? How stupid is that? Why should I believe that these studies exist, are conclusive and supportive of this change? The trackrecord of the WMF is not good enough to give me any confidence that unpublished studies (apart from one 7-word conclusion) really support this change in any meaningful way. As for Mzmcbride, if you get such a question which you don't understand, then you could perhaps reply there and ask for clarification? I'm pretty sure that "Please prove that you are not trying to get fired by telling lies about what the Legal team said" was not the intention of the question, if telling nonsense to support the WMF would have any risk of getting you fired then that would have already happened a few years ago surely. "a legal citation to a court case or statute? " Again, unlikely. Perhaps a published statement by someone from Legal that unequivocally states that they want this change for reason X, Y and Z? All we have now is "Legal wants it! (but I have no publishable evidence for this)" and "Multiple studies going back for years and years want it! (but they may not be published, not even the conclusions, and most I can't even find, but I still use them to support my claim)". This sounds a lot like "JDForrester wants it! (and I have to make up excuses to convince the communities)". I'm happy that this change seems to have been postponed though, let's hope it's indefinitely. Fram (talk) 07:47, 12 September 2016 (UTC)
The conclusions (and indeed whole reports) can be published – just not by me personally, which means that we need to wait for someone who is not me to do so. From what I've seen, though, the relevant parts provide very little detail beyond what has already been shared over the years. It's usually just a sentence that says something like "Some users were surprised to learn that clicking the 'Save' button immediately posted their changes on the internet". Whatamidoing (WMF) (talk) 17:00, 12 September 2016 (UTC)
Hi Whatamidoing. Regarding my question at phabricator:T131132#2569616, you could have responded on the task saying that you didn't understand the question and you could have asked for clarification there. I thought my request for a citation was reasonably clear. You stated on Meta-Wiki that "The Legal team at the Wikimedia Foundation supports this change." I would like to know who the speaker/author of this support was, when this support was made, and what the context of the support was. Any details you can provide would be helpful in evaluating your claim. As Wikipedians, we rely heavily on verifiability and there is no associated reference or citation with your claim in order for others to examine its veracity and scope. --MZMcBride (talk) 04:20, 13 September 2016 (UTC)
Has there even been done a reverse study, with a Wikipedia session where the buttons were changed to "publish" to see if "Some users were surprised to learn that clicking the 'publish' button in their sandbox / draft did not immediately post their changes on the main space" or anything similar? Now, some users stated that they were surprised (once, perhaps twice, then they surely had learned), but you don't know how many editors will be unpleasantly surprised by the new solution. Fram (talk) 06:39, 14 September 2016 (UTC)
I see the Save Page has been changed to Save Changes if editing an old page (but remains same if creating new page). But the Disclaimer above has not been changed it still says By clicking the "Save page" button, you agree to the Terms of Use and you irrevocably agree to release your contribution under the CC BY-SA 3.0 License and the GFDL with the understanding that a hyperlink or URL is sufficient for CC BY-SA 3.0 attribution. which maybe inappropriate. It should say By clicking the "Save page" or "Save changes" button, you agree to the Terms of Use and you irrevocably agree to release your contribution under the CC BY-SA 3.0 License and the GFDL with the understanding that a hyperlink or URL is sufficient for CC BY-SA 3.0 attribution. which is very very important because otherwise legally we are not agreeing to any Terms of Use or releasing contributions under CC BY-SA 3.0 License. Thanks Pinging Whatamidoing (WMF)VarunFEB200315:29, 8 September 2016 (UTC)
This interface message has been protected by WMF office action because altering it could have serious legal ramifications.
Do not edit it without clearing any potential changes through WMF legal counsel. Administrators should contact Maggie Dennis once they're ready to make a change, and permission will be granted if the change is safe.
This message refers to other messages, the "problem" is that depending on the page you are on, this may now display more than one message, "save page" is still valid for new pages. (It used to just save 'save'). So it should now either have an "or" to the other message, or have logic put in. — xaosfluxTalk00:12, 9 September 2016 (UTC)
I had mentioned this above in a discussion with one of our Community Liaisons (Whatamidoing (WMF)), but as usual she seems only to liaise from the WMF to the community, not the other way around: "We do now have the problem that the disclaimer says "by clicking the "save page" button" and the button actualy says "save changes", making your disclaimer (or whatever you call that line) technically invalid. If you / the WMF are so worried about copyright and legal procedures, perhaps you should better look at that first. Fram (talk) 08:44, 5 September 2016 (UTC) " Fram (talk) 07:50, 12 September 2016 (UTC)
As I told you above, the update was (and is, for future changes) already in the works. (For those who haven't followed this, this suggested change was declined in favor of Legal's currently preferred form, which does not mention the exact label on the button at all.) Whatamidoing (WMF) (talk) 17:04, 12 September 2016 (UTC)
You seem to have totally missed the point here. The change has already been done, in the way I suggested. Your reply "What you're calling the "small print banner" is supposed to be updated at the same time as the change (along with a couple of other messages, apparently)." was incorrect then, and is incorrect now, as the small print banner has already been updated after the start of this section, but not thanks to you obviously. Fram (talk) 18:26, 12 September 2016 (UTC)
So, @Whatamidoing (WMF): the timeline is: at 08:44, 5 September 2016 I note that the small print banner is "technically invalid [because the note and the button no longer match]. If you / the WMF are so worried about copyright and legal procedures, perhaps you should better look at that first." No reply from you. Bethnaught then asks at 16:15, 5 September 2016 (UTC) "are you going to address Fram's comment about the incorrect small primt banner?". You then replied "What you're calling the "small print banner" is supposed to be updated at the same time as the change (along with a couple of other messages, apparently). Whatamidoing (WMF) (talk) 23:31, 5 September 2016 (UTC)"
Then, User:VarunFEB2003 starts this section at 15:29, 8 September 2016 (UTC) with the exact same problem, pinging you as well. Thanks to some god work from a few Wikipedians and swift action by WMF people (not you), this was solved on 22:38, 9 September 2016 (UTC). But nearly three days later, on 17:04, 12 September 2016 (UTC), you still claim that "As I told you above, the update was (and is, for future changes) already in the works. (For those who haven't followed this, this suggested change was declined in favor of Legal's currently preferred form, which does not mention the exact label on the button at all.)" This is demonstrably false, the change (to the labels) had already happened at the time of my first post, and you didn't tell us that the change was already in the works, but that it was "is supposed to be changed at the same time as the change", which had already happened by then (I presume you meant the change to "publish", which still hasn't happened, but the banner has been changed meanwhile). Basically, a serious legal problem was brought to your attention by two people here, you ignored it (or didn't understand its importance), and only when other people here contacted other people at the WMF did anything happen (and rather swift then, as if they understood the importance). As a community liaiason, you should bring our concerns to the WMF. As is much too often the case, it seems you have again neglected to do your job here. Fram (talk) 06:50, 14 September 2016 (UTC)
Java Script help needed
how do I remove the signature and time stamp button at the top of the editing window (please give the js/css code)
how do I create a drop down menu besides the current Twinkles menu with my own user tools (code needed again for common.js)
1) To remove the button, put $( '#wpTextbox1' ).wikiEditor( 'removeFromToolbar', { 'section': 'main', 'group': 'insert', 'tool': 'signature' } ); into your common.js - NQ(talk)14:30, 12 September 2016 (UTC)
I believe that the solution for 1) provided by NQ should work in the 2010 wikitext editor, but none of the others. So if it's not working, you've probably changed your editor/toolbar in your prefs, and you'll need to tell us what your settings are. Whatamidoing (WMF) (talk) 17:12, 12 September 2016 (UTC)
You can completely remove bits of the interface, if you want to (and entirely at your own risk, caveat lector), via the JS DOM API (or equivalent). E.g. in your common.js:
@VarunFEB2003: Yeah, not knowing your level of JS knowledge, I possibly should have been less brief there. Here's a more or less complete example (again caveat lector, anyone using this owns the bugs they may find in it):
console.log("common.js: Starting");// Make sure the utilities module is loaded (will only load if not already)mw.loader.using('mediawiki.util',function(){console.log("common.js: Modules loaded");// Wait for the page to be parsed$(document).ready(function(){console.log("common.js: Document ready");// Start of your code that manipulates the pagevarelement=document.getElementById('pt-betafeatures');if(element){element.remove();}// End of your code that manipulates the pageconsole.log("common.js: Complete");});// document ready});// modules loaded
Other code styles exist to do the same thing, and are generally equally valid. Something else, being pedantic, CSS display: none; does not remove it, it just hides it; JS element.remove(); really removes it, it's completely gone from the HTML, no longer exists. You only need the top and bottom sections of that once, you can have lots of different things happening between the "Start of…" and "End of…" comments.
@Murph9000 and NQ: Thanks for the beta hide feature it seems to work but I still am unable to hide the signature button in my edit window it is the one that appears on top of the window besides bold, italics buttons. When I use the code NQ gave above it doesn't hide the signature insert button but instead fails the beta hide feature. I just this script installed that affects the editing window (and advisor.js too) How do I successfully hide or remove the 'Insert Signature' button that appears in the editing window. I use vector skin and do not have syntax highlighting enabled. Thanks a lot VarunFEB200307:08, 14 September 2016 (UTC)
varcustomizeToolbar=function(){$('#wpTextbox1').wikiEditor('removeFromToolbar',{'section':'main','group':'insert','tool':'signature'});};/* Check if view is in edit mode and that the required modules are available. Then, customize the toolbar … */if($.inArray(mw.config.get('wgAction'),['edit','submit'])!==-1){mw.loader.using('user.options',function(){// This can be the string "0" if the user disabled the preference ([[phab:T54542#555387]])if(mw.user.options.get('usebetatoolbar')==1){$.when(mw.loader.using('ext.wikiEditor.toolbar'),$.ready).then(customizeToolbar);}});}
It's a hack to only display a checkbox. The result cannot be used and the display may break if something in the software is modified later or it's viewed in other circumstances than it was designed. PrimeHunter (talk) 12:46, 7 September 2016 (UTC)
This is mostly not possible - but out of curiosity, Wetitpig0 what did you want this type of box to "do"? If storing data - how would that data later be used? — xaosfluxTalk12:57, 7 September 2016 (UTC)
A value will be generated according to the checkbox value. Then, the value will be concatenated into an URL to link users to the page. Thanks! Wetit🐷013:20, 7 September 2016 (UTC)
@PrimeHunter:Though you're right but maybe with lots and lots of code, I can achieve to get a page based on the checkbox value, however I need to test it because it will all depend on how {{Checkbox (clickable)}} works out to be. But it ain't entirely impossible. I can do it but the question is what is the purpose and where does he want to use it? VarunFEB200308:41, 10 September 2016 (UTC)
I have a peculiar problem. When I am on my ipad on safari, my common.js does not load on this page (VPT). Everywhere else it's fine. Same issue while using another account. The console says "Exception in module-execute in module mediawiki.legacy.wikibits > TypeError: Attempting to change configurable attribute of unconfigurable property.." and "Exception in module-execute in module user > ReferenceError: Can't find variable: importScript " Any ideas? - NQ(talk)09:54, 14 September 2016 (UTC)
I would suspect a race condition, wherein other pages and other browsers end up loading wikibits and get it done before your common.js needs it, but for some reason Safari on this page doesn't, so you "lose" the race. --Unready (talk) 11:29, 14 September 2016 (UTC)
@NQ: that is because you are using Safari. This VP/T page has a header "addOnloadHook", with the ID #addOnloadHook. It's a bit technical, but there is a little thing called named access in browsers that causes a global variable named addOnloadHook to be 'semi-defined'. You can easily override that variable, but we define a bit more advanced deprecation wrapper with that name to provide fallback functionality for addOnloadHook. On Safari specifically, this fails because of how those "named access variables" are implemented in that browser, and that failure takes the other legacy variables with it. I discovered the same yesterday and talked it over with Krinkle. It's a rather rare occurrence and pretty page specific, so it might be fixed at some point, but probably not in a rush. —TheDJ (talk • contribs) 11:43, 14 September 2016 (UTC)
I have noticed recently that "External video" boxes to americanarchive.org added all over dont work for 80 percent of our readers. Is there a way to fix this so non-Americans can view these or should the dead links be removed?
Should we be adding links to external videos in huge quote-boxes that the majority cant see and have not been vented by the community?
Last night and again today, Wikipedia articles are not rendering all the images with a number appearing with the "broken image" symbol. And repeated reloads seem to not render the same images (appears consistent) For example, on the All Hallows' School article, the not-rendered images are those captioned:
Bishop James Quinn, c. 1860
All Hallows' Main Building at Duncan Hill, c. 1889
All Hallows' School 1861–1863 location within the building in the foreground of St Stephen's Cathedral, c. 1910
A 1914 image of St Ann's Industrial School (part of All Hallows' School). Road level of Ann Street, Brisbane, has been lowered on numerous occasions since 1861 and this has affected the proportions of the current gate.
During World War 2, Brisbane was the headquarters of the Supreme Commander Allied Powers (Pacific), US General Douglas MacArthur and as such a major military staging point. In this image, Australian troops take part in a parade along Ann Street during 1942. Note the All Hallows' gates in the background.
The Ann Street frontage of the school is defined by this retaining wall which dominates the landscape. The wall is a result of the street level being lowered on three occasions until it reached the current level in 1927.
Mother Catherine McAuley – founder of Mercy Order.
When I click on the "broken image" symbol, I get shown the File page and the image is there, rendering just fine. So it doesn't seem there is any problem with the existence of the images. Some of the images are only on Wikipedia (e.g. the one of Bishop James Quinn) but others are from Commons. They seem to JPG files of normal sort of size (they aren't huge, they aren't new). There seems nothing particularly remarkable about the images that don't render.
I'm seeing this problem on lots of articles; I mention this particular one because it is the worst I've seen with several missing images. Using Chrome Version 53.0.2785.101 m. Kerry (talk) 23:59, 12 September 2016 (UTC)
I tried Reload, I tried purge, I disabled/enabling my network connections, I rebooted my laptop. All Hallows' School remains persistently without the same photos. Interestingly, if I start the Visual Editor, I see more of the photos but still not all. Saving in VE or the source editor doesn't seem to produce any changes. Kerry (talk) 05:21, 14 September 2016 (UTC)
Is there some one place, where I could get list of namespace names for all Wikipedias? That is, for templates .. enwiki: Template, dewiki: Vorlage ... , the same for categories and some other namespaces. --Edgars2007 (talk/contribs) 23:02, 9 September 2016 (UTC)
@Edgars2007: This is not a total list but I tried to find the most used template across all wikis. See wikidata:Q5400303 and look at the list ignoring the :! or !: depending on how the language reads (right-to-left or left-to-right). You would have to find something similar for the other namespaces. Unless there is a way to run a Quarry search to find something like that. --Majora (talk) 00:10, 10 September 2016 (UTC)
Namespaces numbered -2. -1 and 0 through 15 inclusive are the same purpose for all, although their names vary; not just by local language, but some projects have different English names for some namespaces as well. This is particularly the case with namespaces 4 and 5, which here are called "Wikipedia:" and "Wikipedia talk:"; at c: they're "Commons:" and "Commons talk:"; at wikt: they're "Wiktionary:" and "Wiktionary talk:", and so on - although the purpose is exactly the same. Where a project has Lua enabled, "Module:" and "Module talk:" are always numbered 828 and 829. There must be a master list, otherwise they wouldn't know what numbers to allot for namespaces created in the future. For instance, a few weeks ago, namespaces 2300 to 2303 were created here, and named "Gadget:", "Gadget talk:", "Gadget definition:" and "Gadget definition talk:", so they must have known that those numbers were vacant. When French Wikipedia requires namespaces of similar purpose to those four, they'll be numbered 2300 to 2303 as well, but their names will differ. --Redrose64 (talk) 07:16, 10 September 2016 (UTC)
It's not relevant to the question, but for anyone who may not have tried, nearly all the enwiki names work on all other projects, although "Project" is more likely to work than "Wikipedia". Each namespace has a name and a canonical name (see PrimeHunter's API link for an example), and either work. For example, bnwiki has bn:Module:Convert which is bn:মডিউল:Convert, and that module uses bn:Category:রূপান্তরজনিত ত্রুটি as the error tracking category. Johnuniq (talk) 07:59, 10 September 2016 (UTC)
I know that, but that won't work in my case. In my use-case (very, very boring Wikidata stuff, where no details will be interesting or helpful to anyone to answer) I have to work with localised namespaces. --Edgars2007 (talk/contribs) 08:12, 10 September 2016 (UTC)
So I tried to find a few more for you Edgars2007 and I got wikidata:Q4047087 (Category:People) and wikidata:Q4656249 (Wikipedia:Five pillars). I couldn't come up with anything that would be more used but other people might. The other namespaces are probably going to be impossible to do using this method. Wikidata linking is limited and user, file, and draft spaces aren't linked. I do know that namespace name change requests are made on phabricator on the MediaWiki-Internationalization board. Perhaps you can find some way to search through there for requests? --Majora (talk) 20:40, 10 September 2016 (UTC)
https://phabricator.wikimedia.org/diffusion/MW/browse/master/languages/messages/ has a list of message definitions for all languages. Each definition, e.g., MessagesFr.php for French, includes the namespace aliases (and other things) for vanilla MediaWiki. Vanilla MediaWiki is namespaces -2 (Media:) through 15 (Category talk:), so you won't get stuff like Module: and Gadget:, which are defined by their respective extensions. If you want to dig through all the message files, you can get all the vanilla aliases for every language currently localized. BTW, there are 328 languages (including English) as I write this post. The files also contain the localized aliases of Special: pages, if it matters. --Unready (talk) 22:04, 11 September 2016 (UTC)
I tried to find out whether the letter Ø̈ exists. For some reason, the Go button for Ø̈ thinks I mean Ǫ̈ and sends me to ogonek. Searching for Ǿ̨, a letter that actually contains an ogonek, the Go button for Ǿ̨ correctly tells me no such page exists and points me to the correct and helpful List of Latin-script letters. Is there some way to predict whether the Go button will send me to the search page or to an unrelated topic and could it please not do the latter? —Kusma (t·c) 14:32, 15 September 2016 (UTC)
In that case, the Go button seems to have worked as intended, as a page with the title searched for existed (and was confusing from a content point of view, but not from a technical point of view). In my example, I have two different non-existent titles, and the Go button performs Search for one of them and performs an incorrect "show me the first hit" for the other one, resulting in a page that does not contain the search term. —Kusma (t·c) 16:35, 15 September 2016 (UTC)
Rail map doesn't appear
At List of Auckland railway stations, the Geographic map no longer appears. Whatever has caused this has happened in the last few days. It's not the result of an edit to the article, or to the file, File:AucklandRailMap.png. The problem is reported as a technical issue and may be related to the 800px version called, as it's showing correctly in the 400px version at Public transport in Auckland#Trains. A resolution of this issue would be much appreciated. Akld guy (talk) 12:00, 15 September 2016 (UTC)
I dragged out my old iPad and, yes I see the map on it. I suspect the problem is specific to my Win7 laptop. Some Microsoft updates were installed on it a day or two ago. Thanks AK and V for your help. Akld guy (talk) 14:10, 15 September 2016 (UTC)
It's now almost 8:00 am and the map is showing after the laptop went into sleep mode overnight and I awakened it this morning. Obviously some glitch peculiar to the laptop. Problem resolved. Akld guy (talk) 19:55, 15 September 2016 (UTC)
User:Dudemanfellabra/AddCommonsCatLinks and other scripts / Chrome
I am a user of User:Dudemanfellabra/AddCommonsCatLinks which stopped working a few days ago. First it worked briefly after a browser reboot then it died altogether. Checking into the issue at a fellow users talkpage we discovered that more scripts ware affected (I use a custom script for WikiProject assesment) and that it only affects Chrome. Firefox works. Is there a recent Chrome/Mediawiki bug already known? Agathoclea (talk) 11:22, 16 September 2016 (UTC)
Yes, it works intermittently on chrome and I suspect it has something to do with $(window).load used in Dudemanfellabra's scripts that is causing some issue with Chrome. For eg. importScript('User:Dudemanfellabra/NRHPstats.js'); does not seem to work in chrome but a copy of the script at importScript('User:NQ-test/script1.js');) that uses $( document ).ready instead of $(window).load loads fine. Anyway, it's not like I know what I am talking about here, but hopefully this might help someone narrow down the issue. - NQ(talk)15:36, 16 September 2016 (UTC)
You do not have permission to apply change tags along with your changes.
When I exported and use Twinkle in my own wiki(not in wikipedia),it throw error like this and can't save edits.
"不能保存修改：You do not have permission to apply change tags along with your changes.”
1. I have no idea, when I click on the notifications icons, whether I will get Special:Notifications or the notifications dropdown. There seems to be no logic in when either of those happens. I would prefer always to get the dropdown, but I would least prefer to have some predicatble behaviour.
2. When I get special:notifications and mark everything as "read", the counters for enwiki notifications disappear (good), but the counter for cross-wiki notifications stays (and yes, I have set them to "read" and the number becomes grey instead of coloured). Only when I close the special page and succeed in getting the dropdown does the counter disappear (without further actions from my side).
3. Now, a few hours after I marked the notifications as read, I suddenly get a greyed-out counter again with "2". These are probably the two notifications I set to read this morning. I have no new notifications, but I can't seem to make the counter go away in a normal way. The only solution was to mark one as "unread" (which dropped the counter from 2 to 1), and then again mark it as read (counter disappeared).
I need "#" to appear as the first character in an infobox entry. It appears as "1." but needs to appear as "#" so it will match the Facebook page of the radio station.— Vchimpanzee • talk • contributions • 16:55, 16 September 2016 (UTC)
Vchimpanzee Are you still having this issue - it looks like you added what you wanted to WMYB (FM), if there is another example please provide the page and edit you are trying to make that is not working. — xaosfluxTalk16:59, 16 September 2016 (UTC)
Whenever I try to apply {{subst:orfurrev}} to a file page it is not working for me. This occurs when I try to do so with Twinkle as well as manually. The result is as follows:
{{
safesubst:#if:{{{nosubst|yes
| {{Orphaned non-free revisions|date=17 September 2016}}
| {{#invoke:Error|error| This template must be [[Wikipedia:Template substitution|substituted]]{{
#if:Orfurrev
|. Replace {{Orfurrev ...}} with {{subst:Orfurrev ...}}
}}.|tag=}}
}}
If someone could take a look at this I would appreciate it as it is a very important template in the file namespace. Thank you. --Majora (talk) 01:07, 17 September 2016 (UTC)
Thank you for the fix but please be more careful with changes to templates that can affect so many things in the future. This one in particular is extremely important for maintaining the entire file namespace and the hundreds of thousands of fair use images we have. --Majora (talk) 01:16, 17 September 2016 (UTC)
Yes! Jerodlycett and NQ. Thank you for the screen shot. It's an edit window issue. That's exactly the issue I've been experiencing for a week or so now. And it's not consistent. One time it will do it on an article/template, and not on the next article/template I edit in the exact same session. It happens in both Firefox and IE, so it is not browser specific.— Maile (talk) 12:20, 11 September 2016 (UTC)
I have the same problem shown in the screen shot. Ever since enabling the Syntax Highlighter gadget a few years ago, I had this problem maybe one or two out of a thousand edits. Now I get it in about half of my edits, starting a couple of weeks ago. I do not have the refToolbar gadget enabled. Does anyone know what other gadgets might be incompatible? – Jonesey95 (talk) 04:16, 14 September 2016 (UTC)
Thanks for the bug report. The syntax highlighter tries to wait until the page is loaded before creating the highlighting behind the textbox, but there is no way to know for sure that every other script is done moving things. If another script moves the textbox after the highlighter has started, the textbox will separate from the highlighting. I just edited the script to detect when the textbox is moved and proactively move the highlighting back behind it again. Please let me know if the problem continues. —Remember the dot(talk)03:17, 15 September 2016 (UTC)
I have some technical questions regarding pending changes (and PC2), but wasn't able to get through the massive WP:PCRFC to find solid answers (and some questions were not valid a year ago).
Are there just two "levels" of pending changes, i.e. autoaccept at autoconfirmed (PC1) and reviewer (PC2), and both visible settings to admins?
Does the software today allow a sysop to implement PC2+ECP (or the wacky PC2+TPROT) on a given page here on enwiki? Any visual indicator to deter this?
If a template's stable contents are "foo", and a pending revision changed it to "bar", does an editor whose setting is to always see the latest regardless of acceptance see "bar" and another whose setting is always to see a stable version sees "foo"? The appearance before and after acceptance is different, right? (If this is true, a wild scenario would be a highly visible template at PC2 prot)
@Andy M. Wang: 1: yes, but technically there are three, since the list that admins select from is
OFF: Accept all revisions
PC1: Review revisions from new and unregistered users
PC2: Review revisions from everyone except Reviewers
2: yes, any of the three levels of PC may be used at the same time as any of the five levels of edit protection, to give 15 combinations. They may have different durations - for example, Jenna Coleman has semi-prot for editing, expiring 13:08, 22 September 2016; and also PC1, expiring 13:08, 22 October 2016. Of course, the presence of the semi-protection means that the PC1 is presently ineffective; but when the semi-prot expires on Thursday, the PC1 will immediately become effective again. Similarly, if you have a page with both PC2 and either WP:ECP or WP:TPROT, one of them may be ineffective, but if it has a longer duration than the other, it will become effective someday. --Redrose64 (talk) 20:43, 17 September 2016 (UTC)
@Redrose64: Thanks, makes sense. Though I thought that the ability to review a page is not conditional on the ability to edit the page (unlike move)...? I'm under the impression that page at PC2+TPROT means that non-reviewer template editors can make edits to it, but it is not live until a reviewer (potentially non-TE) could review it. — Andy W.(talk ·ctb)01:48, 18 September 2016 (UTC)
Thanks anyway, I'm aware that PC2 criteria is still not set, and I've seen the tables. I have 2 scenarios pending answers, but I'll post again at a later date. Thanks — Andy W.(talk ·ctb)17:47, 18 September 2016 (UTC)
I was also missing many images at the time of your post but it's getting better. I saw many small images but not large so maybe something was temporarily limited for performance reasons. PrimeHunter (talk) 11:04, 18 September 2016 (UTC)
I see all images on all sites mentioned. See 'Rail map doesn't appear' section above. That identical problem manifested itself soon after about 8 Windows updates were installed on my Win7 machine, but came right after wakening out of overnight Sleep mode. Maybe parts of the updates didn't activate immediately. Akld guy (talk) 20:27, 18 September 2016 (UTC)
This is the sort of effect that happens when table rows have the wrong proportions of newlines, pipes and double pipes. Perhaps one of the templates that generate the taxobox has been amended recently, and either a newline or a pipe was removed in error? --Redrose64 (talk) 09:25, 16 September 2016 (UTC)
I've narrowed it down to {{taxobox colour|taxon={{Taxobox/taxon|1=Enantiornithes|2= }} }} and I need to go and catch my bus. --Redrose64 (talk) 09:54, 16 September 2016 (UTC)
Sort of. An involved template deliberately "gives up" to not risk hitting the expansion depth limit. It succeeds in not hitting it but the result of giving up is at least as bad here. PrimeHunter (talk) 20:13, 16 September 2016 (UTC)
Changing taxobox subtemplates to list non-nested levels: I am currently fixing those templates, of form {Taxonomy/xxx}, to allow listing upper taxon levels without using so many nested levels of other {Taxonomy/xxx} templates, as 75 levels where the templates wp:expansion depth limit is only 40/41 levels deep. The tactic is called "passing data via network interface rather than hierarchy" (or in this case "squeezing blood out of a turnip") to define taxon data in mid-hierarchy but display at lower levels of nested templates. The sandbox templates are working and fix ~300 pages for taxobox color. -Wikid77 (talk) 23:02, 16 September 2016 (UTC)
The reported formatting error (not in Enantiornithes after [40]) happened because {{Taxobox/Error colour}} added an error category to cell attributes which are applied to a cell by another template. Below is a simplified example.
The category is added to the page in both cases but in the second case it causes the cell attributes and pipe to be interpreted as part of the cell content. It's sometimes said that categories can be placed anywhere on the page but if you don't want side effects then there are apparently limitations. PrimeHunter (talk) 23:47, 16 September 2016 (UTC)
Plan to link taxobox-color category in taxobox infoboxes
Thanks folks, for investigating the infobox errors in Enantiornithes, tied to a taxobox-color depth error.
The invalid-color taxoboxes need to show invalid-color header as: Taxon , so I am planning to shift the link for invalid taxobox-color category from {{taxobox_colour}} into {{Taxobox/core}} and {{Taxonomy_key}}, to link "Category:Taxoboxes with an invalid color" and thereby fix the error in taxobox column headers (which showed: colspan=2 style="text-align: center; background-color: transparent; text-align:center; border: 1px solid red"). An infobox column style format cannot contain a wikilinked page or category, as of September 2016. Discuss at: Template talk:Taxobox#Invalid color category, for details. -Wikid77 (talk) 21:36, 18 September 2016 (UTC)
@Anomie:, I have User:Anomie/linkclassifier as an item under the Tools sidebar on the left to run on demand. Just a few moments ago the link disappeared. I'm not aware that I've done anything to change this. Has something else happened that affected this? older ≠ wiser20:28, 8 September 2016 (UTC)
All of my .js addPortletLink additions as well as the customized nav tabs stopped working as well - but seem to be back now. Hopefully was just a momentary glitch from some change that was eventually fixed. --- Barek (talk • contribs) - 01:48, 9 September 2016 (UTC)
I've got a script that normally sorts my watchlist, eg article pages, talk pages, etc., which is no longer working. Any idea why? Thanks. Doug Wellertalk16:31, 12 September 2016 (UTC)
Yeah, we have lots of very old scripts (with few users) that no one ever bothered updating that might start breaking soon indeed. Not sure why this would break specifically, but likely because it has expectations about execution order that can no longer be fulfilled. Then again, after 5 years of being deprecated... what are you gonna do :( —TheDJ (talk • contribs) 19:42, 12 September 2016 (UTC)
I just tested the addOnloadHook of watchlistsorter mentioned above, and it is not broken. It's just VERY VERY late now. It's loaded dead last, after even the least important things and all the images etc are handled. —TheDJ (talk • contribs) 19:59, 12 September 2016 (UTC)
SPI helper script problem
On the upper right of my screen I have Read Edit View History More Page TW. When I'm on an SPI page, I should be able to click the down arrow on More and see helper script entry(ies). Sometime recently, intermittently but often the drop down is empty. I then have to purge the page, sometimes as many as eight times. Not that I know much about it, but this doesn't sound like a script issue but something with the interface. Thanks for any help.--Bbb23 (talk) 20:01, 12 September 2016 (UTC)
When i load your vector.js, i get the following feedback in my developer console.
[Warning] Use of "importScriptURI" is deprecated. Use mw.loader instead. (load.php, line 155)
[Warning] Use of "wgUserName" is deprecated. Use mw.config instead. (load.php, line 155)
[Warning] Use of "addOnloadHook" is deprecated. Use jQuery instead. (load.php, line 155)
[Warning] Use of "wgPageName" is deprecated. Use mw.config instead. (load.php, line 155)
[Warning] Use of "addOnloadHook" is deprecated. Use jQuery instead. (load.php, line 155)
[Warning] Use of "addPortletLink" is deprecated. Use mw.util.addPortletLink instead (load.php, line 155)
So, like other people above, the scripts use addOnloadHook, which means that they are using a function that has been deprecated for 5 years. This function Functions added with addOnloadHook now are executed VERY late, after everything else on the page has loaded, in preparation for it's final removal. You should definitely consult the maintainers of your scripts. —TheDJ (talk • contribs) 20:19, 12 September 2016 (UTC)
I am having a similar problem with my scripts. For example there is one line in my common.js which hides the link to "my sandbox". On more than half of page loads I can see the link. A forced refresh will usually hide it again. It's also happening with other scripts, but only for the last week or two. -- zzuuzz(talk)20:16, 12 September 2016 (UTC)
have my site vojnaenciklopedija.com that uses wikisoftver (media wiki). The above code does not work on that site.
Gadget DeluxeHistory should show the color of ordinary User, then administrators, bureaucrats, and other bots. Gedget This allows us a much better overview of the changes that are happening on our site. You can see when you enter the page - List of monitoring, as well as on the website - Recent changes.
The website vojnaenciklopedija we do not like this color, and you can see on our site vojnaenciklopedija.com military exercises that it works without problems. It was also raised at once and on another site.
Even the site repeatedly shot down to force me to do, and I failed, and military exercises on the site is first started working.
Gadget where I copied all the other gadgets. They are found in the settings, and where they are all there gadget copied. With this gadget Gadget-DeluxeHistory.js we go two more gadgets and Gadget and Gadget-Objects.js-DeluxeHistory.css .. Maybe I could just copying this from the French Wikipedia, and there has only Deluxe Gadget-i-history.js gadget-Deluxe-History.css. Maybe then i worked. This is copied from another Wikipedia.
I do not know why you ask me where I copied the gadget, would still be a place to copy or is it enough just to a place where they and everyone else gezet. — Preceding unsigned comment added by Zoranzoki21 (talk • contribs) 14:31, 19 September 2016 (UTC)
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
The new version of MediaWiki will hopefully be on test wikis and MediaWiki.org from 20 September. It will be on non-Wikipedia wikis and some Wikipedias from 21 September. It will be on all wikis from 22 September (calendar). This is the version that was meant to go out last week.
Meetings
You can join the next meeting with the VisualEditor team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on 20 September at 19:00 (UTC). See how to join.
I am trying to use Template:Userboxtop and I have several collapsible tables contained within it. I would like to change the color of the box in which the title of the collapsible table is contained from its default purple color. Can someone help me with the syntax of how to do this? Thank you in advance. Ergo Sum23:32, 19 September 2016 (UTC)
If you mean the background color for "About Me", "Languages", "My Interests" and "Wikipedia" at User:Ergo Sum#On my username then you have code like:
! class="navbox-title" style="text-align: left;"| About Me
You can for example say style="text-align: left; background:silver;"
Not that I'm aware of. The only solution I can see is to persuade the aerodrome to change its name, so that we can rename our article about it to not be a sub-page, as they are currently incompatible with Wikipedia / MediaWiki. Murph9000 (talk) 05:50, 20 September 2016 (UTC)
Yeah, I can see how that makes sense. It shouldn't really matter that they are subpages. In technical terms (other than the breadcrumb links to parent page at the top), it would only really matter if an administrator deleted or moved the parent page with the "and subpages" option selected. Obviously, WP:COMMONNAME and other guidelines still apply, in non-technical terms. Murph9000 (talk) 06:30, 20 September 2016 (UTC)
Indents not being read properly in certain character sets
As we all know, : is supposed to indent when used as wiki markup. However, I got pinged on Commons for a Japanese language item, and I reported my findings here. I was in the MS Japanese IME, and as can be seen, the colons there were not reported as indents. I fixed it here, but I had to swap out of the IME and back to English to do it. I'd assume this is a question of the wiki software apparently not reading this character (：) as a colon when it should? MSJapan (talk) 03:35, 20 September 2016 (UTC)
@MSJapan: You're correct that the wiki software doesn't recognize the full-width colon (U+FF1A) as an equivalent of the normal colon (U+003A), but that doesn't necessarily mean that it should recognise it. If there is a template whose output starts with a fullwidth colon, for example, then changing the wiki software in the way you suggest would mean that that template would produce an indent where before it had produced a character. Making this kind of breaking change would require some thought on the part of the developers. (If you want to request that this be added to the wiki software anyway, then you can create a task for it in Phabricator.) As for the Japanese IME you are using, you don't necessarily have to switch in and out of it to get a normal colon. If you use the IME in Japanese mode, type a colon, then press space to see the different choices available, then one of those choices will usually be the regular colon. Trying this on Windows 10, I only get two choices: the full-width colon first, and then the normal colon. The normal one is labeled as 半, or half-width. — Mr. Stradivarius♪ talk ♪04:51, 20 September 2016 (UTC)
I know, I just don't usually like the half-width switching, because it usually ends up making me have to fix something else later. :) That does answer the question, though. MSJapan (talk) 07:23, 20 September 2016 (UTC)
Sending thanks
Clicking the "Thank" button has been taking me to a different page to confirm the thanks rather than staying on the current page and having me confirm it with either "Yes" or "No." Anyone else experiencing this? Seems to have started sometime this week. Amaury (talk | contribs) 15:13, 14 September 2016 (UTC)
I've found that it can also happen if you've gone to a diff page, and click the "thank" link before the page has finished loading (indicated by the spinny thing in the browser tab, which hasn't yet been replaced by the favicon). This is similar behaviour to some other actions that will also send you off to a different page if you try them before the page has finished loading - these include the "alerts" bell, "notices" car door, and the "unwatch" tab. --Redrose64 (talk) 08:57, 16 September 2016 (UTC)
Yes I use MonoBook because (a) that was the default when I created the account seven years ago; (b) it doesn't waste as much space as Vector, which spreads things out; (c) it doesn't use smudgy fonts that are difficult to read - with my eyesight, sharp-edged lettering is essential, so as far as I am concerned, Vector violates MOS:ACCESS big-time; (d) it's consistent - it doesn't use serif fonts where none are needed, like section headings. --Redrose64 (talk) 23:11, 19 September 2016 (UTC)
I'm cleaning up the Category "Maps in French" as a new user. A few times I've already got the notice, that my edits were automatically filtered, probably because of using the gadget Cat-a-Lot. So I would like to kindly ask: How many edits I must have to get out of this filtering?--Sauri-Arabier (talk) 12:01, 17 September 2016 (UTC)
That depends upon which filter is hitting you. For example, one filter requires new editors to have >50 edits and to have an account that is at least 180 days old. If there is a filter number in the notice, then you can find the exact filter and see what its requirements are. WhatamIdoing (talk) 15:31, 20 September 2016 (UTC)
Save page / save changes
Another of that idiotic problems caused by The Change to The Save Page button. Now if we go and edit the today's featured article we get a edit notice or whatever you call it saying by Pressing Save Page your edits will be visible at large. But the button has changed and so should the notice. Pinging @Xaosflux, Whatamidoing (WMF), and Fram: who have been previously involved. VarunFEB200308:19, 18 September 2016 (UTC)
What are you talking about? The change hasn't happened yet, in wikitext or in VE, and this is a known issue discussed to death. It can easily be fixed if the software change does go ahead by editing the editnotice. Moreover there is already a thread about this above. Please keep discussioms in one place and stop the disruptive editing which you have already been warned about on your talk page. BethNaught (talk) 09:49, 18 September 2016 (UTC)
Could someone help on how to get possibility of entering a longer caption for some image? My example was d:Q1461 (Manila), particularly P18 and Montage of Manila.png. Here, "Manila Bay" cannot get linked because then ]] would get deleted from Tondo Church; so, there is probably a limit for number/size of entered characters, and if they are Cyrillic – caption room gets really small. What would be a way to get around this?
I've tried to separate captions in more qualificators of same type (caption, you can see history of d:Q1461) and then use that ugly solution, i.e. {{#invoke:Wikidata|getValue|P2096|FETCH_WIKIDATA}} to get caption entries displayed as comma separated; it didn't work, only first entry was displayed.
And is there a way to translate some property value if there is no article on other Wiki (it is not yet created and/or connected to existing Wikidata item)? Example is "Metro Manila" in P131 (same d:Q1461).--Obsuser (talk) 16:04, 19 September 2016 (UTC)
Can you please confirm that there's a display error at Poland, exploding the size of the article fifty times the size of a standard monitor, both vertically and horizontally, thus making both scroll bars look tiny. Judging by my past experience, the possible source of the error is any-one of the templates used in that article. – Last time I was here with similar problem, I got excellent help from you guys, @Trappist the monk and PrimeHunter: so again, thank you in advance for your help. Poeticbenttalk19:39, 19 September 2016 (UTC)
On the desktop site, the styles for <blockquote>...</blockquote> reduce the text size; on the mobile site, the styles increase the text size. The increased size is problematic because space is already limited on mobile. It only becomes worse when quotations are nested. Additionally, on mobile the quotes property is set, meaning the quotation gets a pair of oversized quotation marks. This looks really silly IMO when it gets applied to the inner quotation. You can see an example at On the Jewish Question § Reference to Müntzer. On that page, I've fixed both issues using style=font-size:inherit;quotes=none and also mentioned the fix at Template:Quote/doc. I'm mentioning this here to gauge to what extent my changes are supported by consensus. Also I think it should be possible to fix this everywhere, without using style, by changing the style sheets with a rule like
"On the desktop site, the styles for <blockquote>...</blockquote> reduce the text size" That's only Monobook, not the Vector default... In general you shouldn't make too many assumptions about how things look in browsers, because skins and browsers differ. I think nested quotes are hard to read, no matter what defaults you configure though. In a case like this, I would go with a style that is unique to the nested quote, to distinguish it from the first level quote. (like a left border, or a simple unobtrusive background). —TheDJ (talk • contribs) 21:55, 20 September 2016 (UTC)
Lua error in Module:Coordinates
Hi! There seems to be an issue with the Module:Coordinates after I added picture and commonscat for a item in the List of Category A listed buildings in Highland. I'm not quite sure if this is a mistake on my side, but even looking at old versions of the list I still get the same error message "Lua error in Module:Coordinates at line 657: Tried to read nil global frame.". Can anyone help me fix the list? Braveheart (talk) 10:43, 20 September 2016 (UTC)
@Braveheart:This is a problem in Module:HS listed building; Module:Coordinates was recently modified to include the {{#coordinates:}} parser function. In Scribunto, you have to call parser functions from a frame (usually wikitext). Module:Coordinates, being called through HS listed building, treats HS listed building as the frame and this causes the error. I'm not sure how you could fix this, although you could try calling coordinates._coord of Module:Coordinates through Module:Arguments. Jc86035 (talk) Use {{re|Jc86035}} to reply to me11:09, 20 September 2016 (UTC)
@Jc86035: Thanks for explaining the underlying issue, unfortunately I'm miles away from becoming proficient in programming modules. It also only seems to affect lists that have been changed since the last modification, so I'll refrain from editing the other lists for the time being. I'll mention it on the talk page. :-) 14:43, 20 September 2016 (UTC) — Preceding unsigned comment added by Braveheart (talk • contribs)
@Braveheart: This is also primarily my fault, because I updated the module without checking if any other modules used it. Hopefully someone better at Lua than I am can fix this quickly. (Posted message on WT:Lua as well.) Jc86035 (talk) Use {{re|Jc86035}} to reply to me14:50, 20 September 2016 (UTC)
I'm trying to make {{Userbox}} not categorize pages that are just transcluding userboxes in Category:Potentially illegible userboxes. It turns out simply using <noinclude> tags won't work, I need to use frame:preprocess(). Doing return frame:getParent():preprocess('<noinclude>[[Category:Test]]</noinclude>') from a function in a minimal test module works, but when I try to use that in Module:Userbox/sandbox, it doesn't work, simply doesn't categorize pages using {{Userbox/sandbox}} with illegible colors. nyuszika7h (talk) 13:20, 10 September 2016 (UTC)
@Nyuszika7H:This is because preprocessing works the same way no matter which frame object frame:preprocess is called from. In other words, frame:preprocess('<noinclude>[[Category:Test]]</noinclude>') and frame:getParent():preprocess('<noinclude>[[Category:Test]]</noinclude>') do exactly the same thing. This means that the noinclude tag is actually taking effect on Template:Userbox/sandbox, not userboxes transcluding it. To work around this you will need to use some different logic. Maybe filter by namespace and/or page name? — Mr. Stradivarius♪ talk ♪06:52, 15 September 2016 (UTC)
That's strange, because I specifically tested that in a minimal module on my wiki, frame:preprocess() didn't work but frame.getParent():preprocess() worked fine. I can copy the test module here if needed. nyuszika7h (talk) 13:11, 15 September 2016 (UTC)
@Nyuszika7H: Thanks for the reply, and allow me to apologise - after testing it myself, I can see that I was just talking out of my hat about preprocess being the same between the frame object and the parent frame object. You are right, it does make a difference to things like <noinclude>...</noinclude> and <includeonly>...</includeonly>. It seems that the second half of my post was correct, however. So, with modules frame belongs to the module page (e.g. Module:Userbox) and frame:getParent() belongs to the page that uses #invoke (e.g. Template:Userbox). So if you use frame:preprocess('<noinclude>foo</noinclude>') then "foo" would theoretically show on the module page but on no pages that transcluded that module. (It doesn't actually display on module pages, though, because they have a special content model.) And if you use frame:getParent():preprocess('<noinclude>foo</noinclude>') then "foo" would show on the page that used #invoke (e.g. Template:Userbox) but on no pages that transclude that page. To use noinclude with pages transcluding Template:Userbox you would need to use frame:getParent():getParent():preprocess('<noinclude>foo</noinclude>'), but this is not possible, as grandparent frames cannot be accessed through Scribunto. There was some work done on exposing grandparent frames and above in gerrit:141052, but it doesn't look like it's going to be merged due to worries about people writing modules that are easily broken when page structure changes. — Mr. Stradivarius♪ talk ♪05:44, 16 September 2016 (UTC)
@Nyuszika7H: You might be able to get this to work by loading the content of the page and seeing if it contains the text {{userbox| and adding the category if it does. But that uses an expensive parser function, seems awfully kludgy and also categorizes pages that transclude illegible userbox template in addition to their own custom userbox. Pppery21:05, 20 September 2016 (UTC)
@Nyuszika7H: By the way, the traditional way of fixing this is to make userbox template authors pass in the name of their template as an argument. Then you can do something like
ifargs.templatename==mw.title.getCurrentTitle().prefixedTextthen-- Add a categoryend
That breaks if someone moves the page, though, and it requires adding new arguments to all the infoboxes out there. Maybe doing this in combination with namespace and page filters would get you the best results. — Mr. Stradivarius♪ talk ♪05:25, 21 September 2016 (UTC)
ORES article quality data as a database table
One of ORES applications is determining article quality. For example, What would be the best assessment of an article in the given revision. Users in Wikiprojects use ORES data to check if articles need re-assessment. e.g. if an article is in "Start" level and now good it's enough to be a "B" article.
As part of Q4 goals, we made a dataset of article quality scores of all articles in English Wikipedia (See phab:T135684, you can find the dataset there) and we are publishing it in figshare as something you can cite (phab:T145332) also we are working on publishing monthly data for researchers to track article quality data change over time. (phab:T145655)
As a pet project of mine, I always wanted to put these data in a database. So we can query the database and get much more useful data. For example quality of articles in category 'History_of_Essex' ([48][49]). The weighed sum is a measure of quality which is a decimal number between 0 (really stub) to 5 (a definitely featured article). We have also prediction column which is a number in this map for example if prediction is 5, it means ORES thinks it should be a featured article.
@Ladsgroup: Awesome! I'm an advocate of big data, so having this available is really useful - well done! Let us know if there is anything we can do to help out. As for a more permanent place, that table seems good enough - the labs guys might put it in a non-user table though if you ask nicely -- samtartalk or stalk09:31, 21 September 2016 (UTC)
unsafe websites
I don't know where to report these, but I had to remove them from an article, they are multiple popup nests. [http://www.osenegal.com/ ô senegal, un oeil sur le senegal] * [http://www.osenegal.com/videos/ videos au senegal] --Kintetsubuffalo (talk) 10:29, 22 September 2016 (UTC)
When links like that occur in citation templates, they may once have been valid sources correctly supporting article text but have since been usurped. See if you can recover an appropriate version of the source from an archive service (archive.org, etc). If you can, add |archive-url= and |archive-date= to the template and set |dead-url=unfit so that there is a historical record of the original url. |dead-url=unfit hides the original url in the citation template's rendering.
Many lists have annotations, which, while useful, may obscure the items in the list that they describe. Sometimes it is useful to look at the bare list, without annotations.
Here's a list with annotations:
List item 1 – Hi, how are you?
List item 2 – I'm an annotation.
List item 3 – Simple Simon met a pieman.
Here's the same list without annotations:
List item 1
List item 2
List item 3
What would it take to have a toggle feature to turn the display of annotations on and off?
Not hide/show as in templates (which work on a template by template basis). I'm referring to a feature that would turn off all annotations until you turn them back on.
Could it be done via gadget, or would it take a change to MediaWiki?
Those are not really distinct from the list item. I.e. what you are calling the annotation is not a separate element in markup terms, the emdash character is not part of the technical markup, it's just another character that is part of the list item. It would not be easy to implement either inside MediaWiki or inside JavaScript. JS would not have any distinct elements within the HTML DOM to show and hide, it would have to actually edit the contents of elements, which is considerably more involved than just hiding and showing them. To make it easy, you would really need all of them wrapped in something like a <span class="annotation">…</span> element, or similar (i.e. the articles would need to be changed to include that special new markup). Murph9000 (talk) 06:40, 20 September 2016 (UTC)
@Murph9000: If those items were wrapped in the special markup, how could they be toggled? Could you have a checkbox like the one for activating/deactivating WikEd? How would you go about implementing that? The Transhumanist19:59, 20 September 2016 (UTC)
@The Transhumanist: Well, the key thing there is having elements for JavaScript to target / manipulate; it removes the need for it to edit content on the fly, which is always better to be avoided when possible. With suitable classed elements present, something similar to the mw-collapsible, or the various older versions of the same thing, could be used. You could also use personal CSS to manipulate the static presentation of them. Obviously, in wiki markup terms, it would probably be best to use a template to wrap the HTML span (or there may be a more appropriate HTML5 semantic element to use, I'd need to check that, rather than generic span) around the content. Murph9000 (talk) 20:10, 20 September 2016 (UTC)
@Murph9000: Please provide links to documentation on mw-collapsible. Thank you for clarifying HTML DOM aspect of this potential endeavor. Now what about the toggling itself? Are there any simple javascripts you know of that toggle something on Wikipedia? Do you know of any that deal with presentation of HTML DOM elements? The Transhumanist20:55, 20 September 2016 (UTC)
@The Transhumanist: The above was meant to read "the mw-collapsible JS", so that's your modern sample JS for it. It is an official MW re-implementation of older NavFrame and collapsible JS in MediaWiki:Common.js, right here on EN-WP (not 100% certain, but I think it originated here). It might or might not be possible to leverage one of those to do the job, or they could at least provide a baseline for development of your idea. Last time I looked, {{Navbox}} was still using our local "collapsible" JS, so it's still essentially current. The NavFrame stuff should still work, but is pretty much deprecated, I believe. If it works for a given task, mw-collapsible is the more portable one (i.e. probably the better option), as it's available on all modern MW installs and does not need any local JS added. Docs at:
@Murph9000: Cool, another skin peeled off the onion. Okay, in MediaWiki:Common.js is the code for collapsible tables. There it says "deprecated since MediaWiki 1.20: Use class="mw-collapsible" instead which is supported in MediaWiki core." So, what is "MediaWiki core", and where can I find it? The Transhumanist00:14, 21 September 2016 (UTC)
@Murph9000: Digging into the core source seems daunting if there is an easier way to do it. In the manual you posted above is a link to jquery.makeCollapsible, which includes this: mw:ResourceLoader/Modules#Remote toggle, which says:
If you don't want the script to put the default toggle link (whether or not with a custom label) in your element, you can make one of your own. This could reside anywhere inside or outside the collapsible element. It's relationship to the collapsible element is detected by using an ID attribute with the prefix mw-customcollapsible and a corresponding class attribute with prefix mw-customtoggle for the collapsible element and the togglelink respectively.
Would you be so kind as to translate this to English for me?
P.S.: I'm concerned that if the HTML Span were wrapped in a template, the Wikipedia:Template limits would be exceeded on many lists, especially outines. Unfortunately, that page doesn't state what the limits are. -TT
@Murph9000: Requiring that the custom ID and Class be created in MediaWiki:Common.css? The custom class would essentially be a copy of the existing class known as what? And the script will process the toggle when clicked if the naming scheme mentioned in the quoted paragraph above is followed for the new ID and Class? The Transhumanist05:49, 21 September 2016 (UTC)
So, the elements might look like this, with the toggle (which would probably be located at the top of the page), followed by an annotated list entry (in the body of the list):
*[[Classical acting]]<span class="mw-customtoggle1"> – philosophy of acting that integrates the expression of the body, voice, imagination, personalizing, improvisation, external stimuli, and script analysis. It is based on the theories and systems of select classical actors and directors including [[Konstantin Stanislavski]] and [[Michel Saint-Denis]].</span>
@The Transhumanist: It would need to be something like that, yes. Each span should also have a generic class which can be used for visual styling from CSS (either site or personal CSS). I.e. <span id="whatever-toggleid" class="annotation-toggle">label</span> and <span class="annotation mw-collapsible whatever-toggleid">content</span>, or similar. However, looking at mw:ResourceLoader/Modules#jquery.makeCollapsible and testwiki:User:Krinkle/Test suite for mw-collapsible (linked from the official docs), I don't believe this can be achieved with the current mw-collapsible, as it seems to be limited to a single target due to opposite usage of the class and id (in the DOM, IDs must be unique). mw-collapsible can have many toggles controlling a single target collapsible, but not one toggle controlling many collapsibles (without a really ugly mess of classes on the toggle). It would need new JS code which could be based roughly on the existing mw-collapsible code, perhaps even as a new enhancement or extension to mw-collapsible.
Something I have to say at this point: the more I look at this, the more it seems like it's going to be an awful lot of additional markup (and effort to create and maintain that markup, either via templates or raw HTML) for fairly limited benefit. I honestly don't see there being a huge demand for this. Personally, I find it very easy to just scan this style of list by eye and separate out the two logical halves of the information, ignoring the bits I'm not bothered about at the time. Maybe I'm wrong about that, I don't know. Do we really need this? Is there demand for this solution? Is it worth the effort to develop and maintain an bunch of new JS collapsing code (either extending mw-collapsible, or in parallel to it)? Do we have a lot of lists with readability problems, where this would be the best way to improve things?
@Murph9000: Annotation toggling is a very nice outliner feature, along with level collapsing. Outlines on Wikipedia are essentially crippled (compared to an outline in an outline viewer or outliner), in part because Wikipedia lacks basic outline-oriented viewing features. Those make viewing an outline's component lists very convenient. They are nice features, and would make outlines on WP more useful and more user-friendly. And they are useful for more than mere viewing. For example, for when you need to copy and paste a bare list. One way to view outlines, in a streamlined fashion, is to have annotations off (which makes reading the outlines faster), and only toggle them on when you want to know the definition of a topic. Then you toggle it off again and continue browsing. If you come across an outline or outline section in which you don't know many of the terms, you leave the annotations on. The best form of toggle would be one that was page-independent, like a hot key or WikEd's toggle checkbox. Outlines are evolving to include annotations, and before I develop tools to speed up this process, I thought it might be a good idea to have their viewing feature in place first. Of course, outline viewing in a wiki is new as far as I can tell, and so, testing on a limited number of pages at first would be best. Then improve the concept and expand from there. The Transhumanist10:43, 21 September 2016 (UTC)
@The Transhumanist: Ok, that's interesting, and it does change things. I still don't know if we have a strong need for it, but I think it's interesting and it might well generate more interest with others. It's sounding like it possibly might be a MediaWiki extension. There might even already be extensions out there for such a thing, so I encourage you to have a browse of the MW site and see if something catches your eye. Murph9000 (talk) 11:14, 21 September 2016 (UTC)
One thing that concerns me is the amount of markup that would need to done to implement this concept. If delimiters are already included in the text (en dashes and newlines), making it parsable, I don't see why we couldn't use those, instead of inserting additional "markup code", especially if we're talking about writing an extension. Adding markup to existing pages would probably be done via parsing using regex anyways; so why parse twice if we don't have to? One major benefit of not having to rely on additional wiki-markup is that the functionality could be extended to include lists (which are essentially branches of multi-page outlines), without affecting the readability of the source text, and without requiring that a multitude of editors adopt the use of extraneous markup. We also avoid the issue of template overload entirely, and of editors stripping out the markup. We just give users a magic button, which they can opt to press or not. Adding more work for editors (in the form of marking up annotations that they write) would adversely affect scalability (we have tens of thousands of lists); while letting computers do all the work helps make the outline/list navigation system scalable (it's still far from complete). About the worst thing that could happen is that if the script encountered a piece of an outline (or list) it couldn't recognize (as annotations), the annotations there simply wouldn't disappear when the toggle was activated. The Transhumanist20:09, 21 September 2016 (UTC)
Yes, if it was an extension doing it, the likely implementation would be some form of extended wiki markup processing. The elements absolutely do need to be in the DOM inside the browser by some means, but they don't necessarily need to be in the wiki source text if something else adds them later in the processing pipeline. Some markup editing work is there regardless, as you will find a wide variety of styles across the wiki, such as colon, minus, en dash, em dash, probably plenty of other miscellaneous UTF-8 characters like bullets, bold followed by plain, etc. It would likely need something adding to the markup anyway, to enable the extension on a per-list basis, as there will be plenty of lists where it would not be appropriate (inside Infobox, Navbox, Sidebar, generic HLISTs inside table cells, etc. spring to mind, but probably plenty of in-article lists where it would be undesirable). I don't think it would be safe, and I don't think there would be community consensus for changing all lists into dynamic outlines (i.e. enabled by default). From an WP:ACCESSIBILITY point of view, many annotated lists should probably be converted to MOS:DEFLISTs anyway, which would be the obvious HTML elements for such an extension to use. Murph9000 (talk) 20:30, 21 September 2016 (UTC)
Sidebars and table entries don't have annotations, generally speaking, but those elements could be accounted for and skipped. Sounds like this whole concept can be implemented as viewing technology from any of a number of different starting points, without pre-alteration of the source data (except maybe standardizing some punctuation). Let's see... There's CSS & JS, gadget, MediaWiki (extension), grease monkey, browser add-on, and browser (built-in). Have I missed any? The Transhumanist21:26, 22 September 2016 (UTC)
Templates vs. raw markup
Split this off, as it's mostly a quick tangent that reached a quick conclusion.
Not using templates because of a theoretical issue with limits does not seem like a good plan to me. I'd want some kind of strong evidence that there was an actual problem before going to a less maintainable solution. Murph9000 (talk) 04:31, 21 September 2016 (UTC)
Whenever I upload a new image over an old one, the image no longer appears in linked pages. For instance, in the infobox here I see only the blue broken-image icon. Do other people see an image here? Any idea how to fix it one way or the other? Maury Markowitz (talk) 21:41, 22 September 2016 (UTC)
The New Yorker web page says that the article appeared in the "June 8 & 15, 2015 Issue", so the date is correct. There should be a way of suppressing the error message. —Anomalocaris (talk) 18:52, 22 September 2016 (UTC)
This is a followup to this VPT thread, in which I suggested using a Lua module to keep one single list of sensitive IP addresses that could be used from both templates and from JavaScript, in order to avoid us having to maintain separate lists. I believe I am just about finished writing all the code that is necessary for this to happen. Here are the various pieces:
Module:IP - A Lua library for parsing and doing operations on IP addresses and IP ranges. User:Johnuniq wrote the code that does the heavy lifting.
Module:Sensitive IP addresses/API - A Lua module that other modules can use to make queries about potentially sensitive IPs and ranges.
User:Mr. Stradivarius/gadgets/libLua.js - a library for calling functions in Lua modules from JavaScript. This will be moved to MediaWiki:Gadget-libLua.js and turned into a ResourceLoader gadget. I plan to set the options for it in MediaWiki:Gadgets-definition so that it is not visible in Preferences, but can still be loaded by other scripts. This means that it will have the advantages of ResourceLoader (like minification and reducing the number of HTTP requests) and that it won't clutter up the interface. This is the same as is done at Commons with c:MediaWiki:Gadget-libAPI.js and friends.
The API can potentially be used by non-JavaScript bots and tools as well, e.g. Huggle, although it is a bit fiddly without a library like libLua to help with the process.
I'd appreciate some new eyes on the code just in case I've done anything stupid - comments and questions welcome! If everything looks ok, I'll start rolling things out. — Mr. Stradivarius♪ talk ♪13:55, 22 September 2016 (UTC)
Great work Mr. S! I haven't examined the code since my last edit in that area, but I'll try to have a look next week. This is the most elegant code I've seen at Wikipedia, and it's documented! Johnuniq (talk) 00:35, 23 September 2016 (UTC)
Nigeria WikiProject
Resolved
Hi, Nigeria is currently running a Wiki Loves Women contest. I was wondering if somebody could edit Template:WikiProject Nigeria to allow for a WLWNG importance= parameter as importance for the women group may differ to general assessment. See here for instance, we want another on the end to assess it.♦ Dr. Blofeld14:03, 22 September 2016 (UTC)
@Dr. Blofeld: This is normally done by making a task force for the sub-project: I've made a stab at what that might look like at Template:WikiProject Nigeria/sandbox. The category pages still need to be created, and it's a pain to move them after they have been created and populated, so now would be a good time to check that all the names are correct. — Mr. Stradivarius♪ talk ♪04:41, 23 September 2016 (UTC)
Yes, there has apparently been a software change where pages with __NOINDEX__ are automatically added to a category specified by MediaWiki:Noindex-category. The default value is "Non-indexed pages". I have created the message with "Noindexed pages" to use our existing Category:Noindexed pages. It may take a long time (months) before the already categorized pages detect this unless they are edited. MediaWiki:Noindex-category is a system message and not a transcluded template so there is no job queue to process the pages automatically after an edit to the message. PrimeHunter (talk) 22:56, 22 September 2016 (UTC)
We're supposed to be able to notice such a change among the haystack of changes listed at mw:MediaWiki 1.28/wmf.20?
"Cleaned up some un needed wording in the English i18n file" adequately describes this?
It occurred to nobody that the projects should have been notified before the change, so that they could edit their MediaWiki:Noindex-category page in advance?
I suspect they simply didn't realize they were changing the name of a tracking category. Maybe they thought it was only a displayed text like MediaWiki:Noindex-category-desc which is displayed at Special:TrackingCategories. A Phabricator ticket would have drawn more attention and probably objections but they may have thought it was just an innocent rewording of something only meant for reading. Mistakes happen. PrimeHunter (talk) 00:50, 23 September 2016 (UTC)
OK, I'll assume good faith. Anyway, it's down to a third of its maximum size now, just over 500 members, so perhaps it won't take that long to clear. wbm1058 (talk) 01:48, 23 September 2016 (UTC)
@Wbm1058: 302061 is the index number used by the Gerrit software to track the change; this counts up from 1, although when I tried I could only access gerrit:5 and later. 522dcec5 is the prefix of the SHA-1 hash that the git software uses for the commit (in this case, the full hash is 522dcec59c7a01e53eb14bd22b9906378d13685f). There's some more info about git hashes in the git-scm book if you're interested. — Mr. Stradivarius♪ talk ♪02:39, 23 September 2016 (UTC)
Maybe there is an undocumented job queue or something similar after all. mw:Manual:Job queue doesn't mention it. Category:Pages with disallowed DISPLAYTITLE modifications is still adding old pages four months after the new tracking category was added by MediaWiki. But that's another situation where the software didn't store the pages anywhere before and wouldn't have a list to run a job queue on. Here the existing MediaWiki:Noindex-category changed value and MediaWiki would be able to process the pages in the category given by the former value. Or maybe somebody just poked something to push the updates through. PrimeHunter (talk) 13:23, 23 September 2016 (UTC)
Edits appearing twice in contributions pages while logged in
Edits that I made yesterday between around 8:25 and 9:38 UTC are appearing twice in my contributions page. They appeared only once in the page histories. Edits made by other users at around the same time seem to have the same problem. After I logged out, the edits appeared only once. Does anyone else see the same thing? Gulumeemee (talk) 00:13, 24 September 2016 (UTC)
}. –Davey2010Talk 09:51, 5 August 2016 (UTC)
Moved from Wikipedia:Village pump (miscellaneous)
Resolved
The new version of MediaWiki will be on test wikis and MediaWiki.org from 30 August. It will be on non-Wikipedia wikis and some Wikipedias from 31 August. It will be on all wikis from 1 September (calendar).
You can join the next meeting with the Architecture committee. The topic this week is "RfC: image and oldimage tables". The meeting will be on 31 August at 21:00 (UTC). See how to join.
Now you can benefit from the tool. Enjoy! Cyphoidbomb (talk) 05:54, 9 September 2016 (UTC)
Mississippi Roads; Delta Blues Musuem, 26:46, Mississippi Public Broadcasting
Done.mw:ConfirmEdit The captcha blocked the Twinkle from editing.小曹2015 (talk) 17:32, 16 September 2016 (UTC)
Bug fixed awaiting merge on Gerrit, see change 312524--Ⓩⓟⓟⓘⓧ (talk) 14:44, 23 September 2016 (UTC)
