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 wanted to find versions of an article that have been deleted, and went to the deletion log and put in the first word ("Novotech") that all the pages had. This pulls up Novotech which is fine, but I know there was also Novotech (Australia) Pty Limited and if I put that in, it finds that. There were two other ones, I think. I tried the typical wild card searches, adding a * or ~ at the end, but these searches came up null. Is there any kind of fuzzy search for logs? Jytdog (talk) 17:03, 3 June 2018 (UTC)
Thanks User:PrimeHunter. For me it would be useful to have fuzzy search capability in logs. Do you (or anybody else) see downside to that? Would it be worth asking the software people if this can be done? Jytdog (talk) 23:06, 3 June 2018 (UTC)
The last time I used the "what links here" tool, a link was present atop the list to "show redirects only". That link is currently, for me, no longer displayed. What happened? Is there a work around for this formerly useful feature? Thank you.--John Cline (talk) 22:45, 3 June 2018 (UTC)
The last few days, when I click on “what links here”, there is no option to list redirects only. What happened to that? Its absence is seriously hindering some of the work I do. NotARabbit (talk) 17:54, 4 June 2018 (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 MonoBook skin has been optimised for mobile devices. It now looks different. [1]
Redirect links in Special:WhatLinksHere now link to the original page and not the target page. This was done earlier and changed the used messages on some pages. This was a problem for wikis that customized the message. A new change fixed this by using the old messages with one more parameter for customization. Wikis that already changed their customized messages will have to move the customization back again. [4]
Problems
You will not be able to edit some wikis between 06:00 and 06:30 UTC on 13 June. You can see if your wiki is one of them.
MassMessage did not work 24–28 May. This is also why last week's Tech News was late. [5]
Changes later this week
The new version of MediaWiki will be on test wikis and MediaWiki.org from 5 June. It will be on non-Wikipedia wikis and some Wikipedias from 6 June. It will be on all wikis from 7 June (calendar).
Meetings
You can join the next meeting with the Editing team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on 5 June at 18:30 (UTC). See how to join.
You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 6 June at 15:00 (UTC). See how to join.
Note that the Monobook skin changes appear to be described inaccurately above. The skin changes were implemented for devices that the Mediawiki software perceives to be mobile devices, even if the Desktop view is requested. Discussion is in a section above, and at the phab link at the end of the sentence in this tech news. – Jonesey95 (talk) 22:01, 4 June 2018 (UTC)
{{DEFAULTSORT:}} and the default sort key
Currently, when {{DEFAULTSORT:<sort key>}} is used, the page is no longer found, in a category, at the default sort location but instead is found as sorted by the sort key used. How was it decided that it should be removed from one location to be listed at another? It seems intuitive to me that it should instead be listed in categories at both locations. Does anyone agree, or disagree, and how much of a technical challenge would it be to modify {{DEFAULTSORT:}}'s behavior to achieve the dual placement in categories such as I am suggesting here? Thank you.--John Cline (talk) 21:51, 3 June 2018 (UTC)
In a category, any given page will only be listed once. This has always been the case. If a page seems to be listed more than once, a maximum of one of them will be the page itself, all the rest will be redirects. See for example the first seven entries at Dodds - the spellings differ by one or two letters, they are different pages. --Redrose64 🌹 (talk) 22:15, 3 June 2018 (UTC)
I understand. The problem, as I see it, is that no redirect can be created form the default location because, of course, the page already exists. It just seems counter intuitive that using {{DEFAULTSORT:}} effectively means the one place a page will never be listed at is the default location of its common name title; the one place, above all, where it probably should appear. A work around would be to not use {{DEFAULTSORT:<sort key>}} on the page so it appears at its default sort location, and create an {{R from sort name}} redirect, ensuring to add the categorization used on the target page (since redirects do not inherit the categorization of the target page which they probably should) so it also appears in the category at the sort key location. I'd prefer, instead, to see the behavior of {{DEFAULTSORT:}} changed than to depreciate its use.--John Cline (talk) 23:21, 3 June 2018 (UTC)
Considering it's called "DEFAULTSORT" and not "ALTERNATIVESORT", the existing behavior makes complete sense to me. MediaWiki currently does not allow a page to appear more than once in a category. Anomie⚔23:31, 3 June 2018 (UTC)
I don't want many categories to list twice as many titles with half of them duplicates. And placing redirects with similar names in the same category as the target should very rarely be done. We have a search box if people are looking for a specific article. PrimeHunter (talk) 23:35, 3 June 2018 (UTC)
According to Wikipedia:Categorization, the central goal of the category system is to provide navigational links to Wikipedia pages .... Why would anyone prefer processes that undermine that central goal? In effect, you are saying: go somewhere else if you are desirous of navigational links to Wikipedia pages.--John Cline (talk) 00:04, 4 June 2018 (UTC)
I think few people would prefer your system as default but you could make a phab: request for a user preference. I don't think it would be implemented though. To reduce confusion it would require a way to distinguish the two listings. Italics are used to indicate redirects so something else would be needed. PrimeHunter (talk) 00:16, 4 June 2018 (UTC)
This must have been a recent change, but wow, it looks strange. I recall even just a week or so ago, there was more space between the "From Wikipedia, the free encyclopedia" at the top of every page and the next line of text below it. Where/why was this change made? And, if I can, I'd like to propose the change be reverted. Steel1943 (talk) 17:48, 4 June 2018 (UTC)
Looks very slightly egg-shaped to me. I'm using chrome version 67.0.3396.68 on Android 7.0. It's perhaps an optical illusion though, as it is very slight. Cesdeva(talk)08:27, 4 June 2018 (UTC)
I've uploaded a screenshot. The ones on {{pie chart}} that Cryptic linked above also display badly. Edge on Win 10. Same problem with Chrome on Android on my phone. It appears to be an issue with the blackscreen gadget, as when I switch that off they display ok. DuncanHill (talk) 11:01, 4 June 2018 (UTC)
{{Graph:PieChart}} doesn't use background-color. It uses mw:Extension:Graph to produce a transparent png image with black text and a colored graph. It's assumed the image will be shown with a light background but the gadget makes a black background. The produced image gets class="mw-graph-img" so maybe the gadget could be tweaked to consider this. PrimeHunter (talk) 13:47, 4 June 2018 (UTC)
So there's been a known problem with thumbnails, galleries, and more, because the original blackskin just clobbers all styles. Fixing it requires me to dig into Monobook and Vector styles. When done, I can order and receive packages from Amazon before an admin copies the changes. That frankly zaps motivation to work on it. — Dispenser04:14, 5 June 2018 (UTC)
How to export the deletion log?
Is there a way to export a portion of a given log? I'm specifically interested in the deletion log for the last couple of months. I don't see any obvious way of doing that from Special:Export. – Uanfala (talk)09:16, 5 June 2018 (UTC)
{{IPAc-it}} seems to be broken, see here. This came to my attention through an edit request on Talk:Benito Mussolini. It's making a whole bunch of links to MfD, but I'm not sure what that has to do with it since it seems to be in active discussion and nothing has come of it yet. In looking at Template:Usage of IPA templates, it seems that {{IPAc-mi}} is broken in the same fashion. I don't see any recent changes to either template that would explain this, so I wanted to raise it here and get someone more knowledgeable than I to take a look. Thanks much! ‑‑ElHef (Meep?) 16:04, 5 June 2018 (UTC)
Plans to graduate the New Filters on Watchlist out of beta
Collaboration team is announcing plans to graduate the New Filters for Edit Review out of beta on Watchlist by late June or early July. After launch, this suite of improved edit-search tools will be standard on all wikis. Individuals who prefer the existing Watchlist interface will be able to opt out by means of a new preference.
Over 70,000 people have activated the New Filters beta, which has been in testing on Watchlist for more than eight months. We feel confident that the features are stable and effective, but if you have thoughts about these tools or the beta graduation, please let us know on the project talk page. In particular, tell us if you know of a special incompatibility or other issue that makes the New Filters problematic on your wiki. We’ll examine the blocker and may delay release on your wiki until the issue can be addressed. - - Kaartic correct me, if i'm wrong16:23, 5 June 2018 (UTC)
I think the template counts sub-categories as well, so the items might be there only. Regards SoWhy12:30, 22 May 2018 (UTC)
Category:Candidates for speedy deletion has no real subcategories. The listed "Subcategories" are wikitext made by {{CSD/Subcategories}} in the category text. The problem is that {{PAGESINCATEGORY:Candidates for speedy deletion}} produces 152 at the time of writing (6 at the time this page was last rendered) while the category page only displays 13 pages at the time of writing. PrimeHunter (talk) 12:52, 22 May 2018 (UTC)
Assume this is related. Admin dashboard has been reporting an inflated CSD backlog for the last two days. And the problem seems to be getting worse. I first noticed it yesterday when it reported a backlog of 133 when we only had 43. Then it went to a backlog of 176 when the actual figure was 37. Currently, we have 66 backlog, but Dashboard says it's 209. — Maile (talk) 14:43, 22 May 2018 (UTC)
Dashboard now says there are 204 CSD backlog. There are only 27 CSD at the moment. There is one item only in a sub category. — Maile (talk) 18:37, 22 May 2018 (UTC)
As of right now, Dashboard says there are 777 items at CSD. In reality, there are only 8 items at CSD. Refer to above task opened at Phabricator. — Maile (talk) 00:22, 29 May 2018 (UTC)
The only comment in that Phabricator link (T195397) is Looks to be an ancient problem related to T18036. However, the problem has only appeared in recent days and seems to be confined to the CSD category, applying even when there are very few members and not applying to other categories with more members: Noyster (talk),09:59, 29 May 2018 (UTC)
The problem of category counts getting out of sync with reality is ancient. This particular manifestation of that problem is new though. Apparently the only solution is to completely empty the category! Good luck doing that. I did write a script to solve this, which is ready and able to be run on WMF servers (phab:T170737). There is a minor flaw in the output that the script prints to the command line, but that shouldn't get in the way of Reedy potentially running this on enwiki... — This, that and the other (talk)11:04, 29 May 2018 (UTC)
Screenshot of the issue on a Wikipedia article, using iOS 10 on an iPad 4. Notice that the line below the header disappears underneath the infobox for whatever reason, even though the infobox doesn't interfere at all with the header. In my view it would be aesthetically more appropriate if the line were to continue underneath the infobox, sadly this isn't the case for whatever reason and I'd like to know why. AlbanGeller (talk) 22:53, 4 June 2018 (UTC)
Does it help to edit the page and put {{clear}} just before the header? I don’t know how other screens and browsers would be affected by that, though. NotARabbit (talk) 03:27, 5 June 2018 (UTC)
”even though the infobox doesn't interfere at all with the header” from the screenshot it looks to me that the bottom (and bottom margin) of the infobox is lower than the top (and top margin) of the header. It therefore IS interfering with the header, this is expected behavior. —TheDJ (talk • contribs) 03:48, 5 June 2018 (UTC)
User:TheDJ, it might be technically interfering with it, though for most readers I doubt they'd be able to tell the difference. My point is, there's plenty of space for the line to continue underneath the infobox. That it doesn't just looks tacky and strange, in my opinion. AlbanGeller (talk) 18:31, 5 June 2018 (UTC)
@AlbanGellar: So what do you propose to do ? Reduce the margin on infoboxes in all situations? Reduce the margin on headers in all situations? Or do you want to write a proposal to W3C to change how webpages work ? —TheDJ (talk • contribs) 18:36, 5 June 2018 (UTC)
@TheDJ: I think we should reduce the margin on headers in all situations, though I'm not exactly sure where is the best venue to propose that. AlbanGeller (talk) 21:51, 5 June 2018 (UTC)
That won't do a thing to fix this (though it might obscure the problem (if you accept that it's a problem) in some cases). What would fix it would be to change the line from a bottom-border on the h2 etc elements to a separate hr or similar following them. That's a bad idea for numerous reasons, but I suppose it could be kludged in with javascript. —Cryptic22:24, 5 June 2018 (UTC)
@AlbanGeller, NotARabbit, and TheDJ: The word "Corruption", with an "[edit]" link to its right, is a heading, not a header.
@AlbanGeller: Headings should be considered to be bounded by invisible boxes, similar to how a table is normally bounded by a visible box. In the case of a level 2 heading (like "Corruption"), the bottom edge of the bounding box is made visible by having a border drawn along it. Outside that box is a transparent no-go area known as the margin, and margins cannot overlap except in special circumstances - they push each other to one side in order to stay out of each others way. There are two margins at work here: the heading's right margin and the infobox's left margin. So the right-hand edge of the heading, and thus the right-hand end of the heading's bottom border, is constrained in how far it can extend to the right. --Redrose64 🌹 (talk) 22:50, 5 June 2018 (UTC)
The editor often doesn't load, and I click the "reload the page" link to get it to work. When creating a new page, though, it does load, and is not very useful: it has no toolbar buttons except the "switch to visual editing" button, which is broken. Is this getting fixed, or has it been abandoned and I should give up on using it? Thanks. —{{u|Goldenshimmer}}｜✝️｜they/their｜😹｜T/C｜☮️｜John 15:12｜🍂21:52, 4 June 2018 (UTC)
Also, when I click Edit link, it shows a loading indicator *in* the page, but the browser stop button is not available, so the page is only loading inside it. This prevents stopping loading editing, which loading can take a good half minute, and renders the page unreadable while it loads, as well. How can I get this to be a normal link, instead of whatever JavaScript abomination it is? (I use the MinervaNeue theme.) Thanks. —{{u|Goldenshimmer}}｜✝️｜they/their｜😹｜T/C｜☮️｜John 15:12｜🍂22:07, 4 June 2018 (UTC)
Thanks. What you're seeing is the regular mobile editor. File:Switching edit modes on Mobile Web 2014-11-04.png is a little out of date (the menu shown in this screenshot has changed since 2014), but that's the editing environment you're getting.
Whatamidoing_(WMF), I have "New wikitext mode" checked, and "Editing mode" is set to "Show me both editor tabs". The current equivalent to the menu shown in the "Switching edit modes" doesn't seem to work for me (clicking on "Visual editing" does nothing). The only other browser I have installed is Links, which I don't think uses JavaScript and probably wouldn't show this issue. I'll install and test in Falkon, and let you know once I have the result. —{{u|Goldenshimmer}}｜✝️｜they/their｜😹｜T/C｜☮️｜John 15:12｜🍂18:59, 5 June 2018 (UTC)
I tried with Vector skin, and this resolves both these issues. I certainly won't switch to that skin, though. —{{u|Goldenshimmer}}｜✝️｜they/their｜😹｜T/C｜☮️｜John 15:12｜🍂19:30, 5 June 2018 (UTC)
Some more information that might be useful in the issue tracker ticket: I think the slowness is fairly reasonable, since I'm using a slow Internet connection (when my computer is uploading files, which is a lot of the time, the connection gets around 2 to 6 KB/s download rate). The problem is that I can't keep reading the article while I wait for the edit page to load, and can't cancel loading the editor if I click on it by accident. I think that is because MediaWiki uses JavaScript to load the edit page instead of it being a separate page. I don't really mind it being slow, I just don't want it to be impossible to stop, and I want to still be able to read while it's loading. —{{u|Goldenshimmer}}｜✝️｜they/their｜😹｜T/C｜☮️｜John 15:12｜🍂07:06, 6 June 2018 (UTC)
Template transclusions that generate a <strong class="error">
I need help regarding template transclusions whose functionality is derived from calls to invoke modules written in Lua; in particular, calls that return a <strong class="error"> message </strong> I'd like to track these by causing any return that includes <strong class="error"> to also return [[Category:Wikipedia page transclusions with strong class errors]] so that the affected pages will begin sorting through the tracking category mentioned afore. Is this possible? If so, will someone accomplish this on my behalf, please? Thank you in advance.--John Cline (talk) 01:02, 6 June 2018 (UTC)
The copyvio tool appears to be broken. When I use the Page > Tools > Copyright vio detector as usual, I get the message
"The URI you have requested, /copyvios?lang=en&project=wikipedia&title=Leucospermum_gueinzii&oldid=&action=search&use_engine=1&use_links=1, doesn't seem to actually exist."
It's unnecessary and users may waste time wondering why it's there or whether an anchor is missing. Module:EditAtWikidata by RexxS already tries to omit # when there is no anchor pid. But the code if propertyID assumes an empty string is considered as false. In Lua it's considered as true.[8]PrimeHunter (talk) 06:43, 7 June 2018 (UTC)
Thanks John! Your logic looks sound to me. I actually thought I'd set propertyID to be nil if it was empty, as I had done for qid. Thanks for catching it. --RexxS (talk) 17:19, 7 June 2018 (UTC)
Re: "Forgot password" emails
Not sure if this is the right place for this, but I've been getting a lot more than usual emails regarding password resets (Someone (probably you, from IP address xx.xx.xx.xx) requested a reset of your password...), and perhaps this has to do with the increase in failed login attempts. All of these temporary passwords have 10 characters: would it be possible to increase the number of characters in those (temp passwords would have 20 or so characters), or randomize the lengths of the temp passwords? SpencerT•C17:20, 7 June 2018 (UTC)
While we can't "message" them - we could make messages that APPEAR only for people in certain skins with skin specific css, such as a site notice. If you are wondering about the opt-out monobook stuff a general watchlist notice might be a good idea. — xaosfluxTalk19:42, 7 June 2018 (UTC)
There seems to be something wrong with the newly inserted( and rather irriating) box at Afd, which gives links to three essays as primers before commenting on a deletion discussion. The box has moved to the left, has been stripped of all background and borders, partially cut away and is pushing content downward on Minivera Skin. I am using a Moto G with a Chrome browser. (I will be able to upload a screenshot tomorrow) — FR+17:20, 5 June 2018 (UTC)
@FR30799386: Which Afd page? The main one, WP:AFD; one of the daily lists; or a specific discussion? Which box is it - which section is it in, what text dies it contain? --Redrose64 🌹 (talk) 17:59, 5 June 2018 (UTC)
They're likely talking about {{AFD Help}}. Which I've transcluded on this page. Looks fine here, so I'm not really sure what's wrong with it. Is the issue only with the Minivera skin? Headbomb {t · c · p · b}19:55, 5 June 2018 (UTC)
I'm using vector and have no issues with it. Is it really necessary to have this template on every AfD page? When someone's article is nominated, they should get a notice on their talk page anyway.Natureium (talk) 19:59, 5 June 2018 (UTC)
Only if they are notified via scripts or by someone who manually posts a notice (neither are a guarantee), and that notice doesn't give much help. That notice is also only given to one editor, which may have created a redirect ages ago, and isn't involved with 'creating the article' proper, or help people stumbling upon the deletion. But that's for Template talk:AFD Help if anything. Consensus was in favour of the notice though, and it's gotten much praise (e.g. User_talk:Headbomb#AFD_help_template, but elsewhere as well), so it certainly serves a use. Headbomb {t · c · p · b}20:15, 5 June 2018 (UTC)
Informative screenshot. What does the "previous AFDs" box look like? Their style coding is pretty similar, so I'm curious. Someguy1221 (talk) 04:39, 6 June 2018 (UTC)
I use Opera 36, I sometimes get blank rectangles like that when a page loads. Scrolling the page - even by just one line - usually fills in the missing content. --Redrose64 🌹 (talk) 07:05, 6 June 2018 (UTC)
Someguy1221-The "previous Afd" box does appear squashed to the left...stripped of any styling (like this one)....but text wrapping remains fine (on Minvera Neue). Headbomb- I can confirm that this weird stuff occurs only in MiniveraNeue on mobile (Trying it out on MiniveraNeue on desktop gives okay results). Redrose64-I tried scrolling but the problem did not go away. — FR+07:24, 6 June 2018 (UTC)
The problem seems to be in MinervaNeue's handling of a specified width inside a div, or some issue with the infobox class when a width is specified on that specific phone/OS. I can't offer much help here, we'll likely need an HTML specialist. Headbomb {t · c · p · b}08:43, 6 June 2018 (UTC)
Headbomb-I added the following hack to my Minivera.css and now the template works okay on AFD pages.The one which you trascluded on top of this thread is still having the same problem..afd-help-box{width:100% ! important;} — FR+09:25, 6 June 2018 (UTC)
"Infobox class" This triggered me to look at this. DONT use functional, semantic classes for purely visual effects. If you tell something is an infobox, the system will start making all kinds of assumptions and problems as described above are EXACTLY what you should be expecting (same with using navbox for anything that is not a navbox). Additionally, using things like 30% is really unpractical most of the time, as 30% also means 30% on a small screen. This can all be improved once we have TemplateStyles, but this is the best I can do for now —TheDJ (talk • contribs) 05:16, 7 June 2018 (UTC)
Sadly, the infobox class is used inside {{Afd2}}, which substs the 'old AFD nominations' "infobox" thing as well. And it seems things don't line up when infobox classes aren't used, or a width of 33% isn't used. I suppose AFD2 could be fixed, and pages updated, but whatever's done here should produce a consistent, well-lined up output, and fixed retroactively to June 1st or so. Headbomb {t · c · p · b}11:12, 7 June 2018 (UTC)
Okay, temp, scheduled downtime is reasonable and necessary. But couldn't they do a temp DNS adjustment and route everything for that server to another which puts up a rational advice message instead of leaving us in the dark? The Wikipedia-editing public didn't get the internal email. Mathglot (talk) 01:49, 8 June 2018 (UTC)
Templates hidden by default?
In WISE J2000+3629, there's two templates at the bottom of the page:
{{Nearest star systems|4}}
{{Stars of Cygnus}}
The first one displays in the hidden state, the second one in the open state. My template fu is pretty weak. How is that controlled? It seems to me it would be better if they both showed in the hidden state by default; the latter one in particular is a huge display which overshadows many of the articles it's part of. -- RoySmith(talk)13:44, 8 June 2018 (UTC)
Done@RoySmith: that second template has a 'state' parameter that can be used to control the "collapse" (not really "hidden") initial display. I set it for you on that article, is that what you wanted? — xaosfluxTalk13:47, 8 June 2018 (UTC)
If you want to change it for all instances, the | state = {{{state|<noinclude>uncollapsed</noinclude>}}} line in Template:Stars of Cygnus is what controls the default there, you could add a <includeonly>collapsed</includeonly> right after the noinclude section and before the closing curly braces. — xaosfluxTalk13:51, 8 June 2018 (UTC)
Ah, that's what I was looking for. Yeah, my intent was to fix it for all instances, not just for this one example. Thanks for your help. -- RoySmith(talk)13:56, 8 June 2018 (UTC)
Unexpected behaviour of search/go
Until recently, if I typed a non-existent article title into the search box and clicked go I got taken to the non-existent page and given the oppoertunity to create it, see what linked there, etc. Now I just get a list of search results. I noticed this just now. What is causing this unexpected and unhelpful behaviour, and how can it be fixed? Thanks, DuncanHill (talk) 22:31, 7 June 2018 (UTC)
It's been this way for me for a long while. What skin are you using?
You still have the option to create the page, you just have to click the red link that's the first result. Search for something like "hflegicljic," for example. The option to create the page has just one more click involved.
Showing search results (as a search bar would imply) allows one to find articles for which one can remember likely keywords or partial title but not the exact title. For example, I could find Magical Treatise of Solomon by searching "magical of solomon" or "Loutzipher". It would be less helpful to not have this feature. Ian.thomson (talk) 22:37, 7 June 2018 (UTC)
Ah now I think I've worked it out. I was searching for "Roland Baines", which is a salted title. When I search for unsalted titles I do get the redlink. It's rather annoying as I was trying to find socks adding links to the page. DuncanHill (talk) 23:27, 7 June 2018 (UTC)
Monobook, British EnglishHas anyone ever thought that rather than warning users of British or Canadian users that we'll get a sub-standard experience it might be worth improving the experience?, default on the search preference (which I was not aware of before). DuncanHill (talk) 15:30, 8 June 2018 (UTC)
Animated gif not animating
In the Brownian motion article, the first animated gif (File:2d_random_walk_ag_adatom_ag111.gif) appears static both when viewing the page and when I click on the image to view in the media viewer (or when just clicked on from the above link). However, when I click on the image once more so that Chrome is simply displaying the plain image file, it does display correctly as an animation. The next two images in the article are also animated gifs, and they both appear correctly however I view them. I have no idea where the problem lies here, so I thought I'd post about it to see if anyone else had any ideas. –Deacon Vorbis (carbon • videos) 17:46, 8 June 2018 (UTC)
The file description page states "Note: Due to technical limitations, thumbnails of high resolution GIF images such as this one will not be animated." --Redrose64 🌹 (talk) 17:56, 8 June 2018 (UTC)
value if different is "{{shortcut|WP:DRVPURPOSE}}"
I'm not grokking what the triple-brace notation does. I'm just a poor C++/Java/Python guy. All this template magic makes my brain hurt. -- RoySmith(talk)21:11, 8 June 2018 (UTC)
It's the shortcut parameter if there is one, or "yes" if there isn't. Help:Template#Handling parameters. So if there's a shortcut parameter and it's equal to "no", then evaluate to nothing; else evaluate to {{shortcut|WP:DRVPURPOSE}}. —Cryptic21:21, 8 June 2018 (UTC)
Not quite, PrimeHunter: the form {{{shortcut|X}}} only reduces to X if |shortcut= is absent - or of course if explicitly set to |shortcut=X. If this parameter is present but empty, {{{shortcut|X}}} reduces to an empty string. --Redrose64 🌹 (talk) 22:18, 8 June 2018 (UTC)
Ah, I got it. It's set to "no" in Wikipedia:Closing discussions#Challenging a deletion: {{Wikipedia:Deletion review/Purpose|shortcut=no}}. And (I think this is the part that really made my brain hurt) the parameter name "shortcut" in "shortcut=no", is in a different namespace from the template named "shortcut" in {{shortcut|WP:DRVPURPOSE}}. -- RoySmith(talk)22:55, 8 June 2018 (UTC)
POTD in desktop view ≠ mobile view
I saw a lovely Picture of the Day, commons:File:Ilsenburg, Ilsetal, Ilsefälle -- 2017 -- 0143.jpg, on my Android smartphone. It had a minor error in the caption: instead of "Ilse Falls" ("waterfall named Ilse"), it was "Ilse falls" (as if "Ilse is falling"). I went to my laptop to fix that error, but I couldn't find the image anywhere among POTDs, present, future, or recent.
Why is POTD different in mobile and desktop view? It's the same Wikipedia. Of course it's http://en.m.wikipedia.org/... instead of http://wiki.riteme.site/..., but I've never known there to be a difference in content: just a difference in format, layout, and wikistuff (links, sidebars, etc.) to make it suitable for smaller screens.
Just for curiosity, does someone know what happened to job queue management from March 5, 2018? See Graphana Job Queue Health last graph. From that day job queue is always very very low. Check for example the API link: it will report "jobs": 0, I am in Wikipedia from many years and I don't remember that value less than ~1000. I am interested in some technical detail. Thanks in advance. --Rotpunkt (talk) 14:57, 8 June 2018 (UTC)
Thanks to Isarra's awesome work, the MonoBook skin is now responsive, meaning it will have a mobile-optimized view for smaller devices (similar to the new Timeless skin). You can try it out on the beta cluster by shrinking your browser window to see what the new layout looks like. This change only affects people who use the MonoBook skin on their mobile devices (and potentially other smaller screens like tablets). Feedback/bugs/suggestions can be reported here or on the Phabricator task.
If you don't like the new layout, it should be possible for you to opt out by using your mobile browser's "request desktop site" option (Firefox for Android documentation). This will be deployed as part of this week's wmf.6 deployment (today or tomorrow depending on your timezone).
Well the usual question, how does one get the previous layout back as the default on the "Desktop version" without having to set the desktop setting every time in the mobile browser? —Mr. Matté (Talk/Contrib) 20:36, 31 May 2018 (UTC)
This is horrible. And it's impossible to get the good layout on an iPad. In Safari, "Request Desktop Site" takes me to the mobile site. I then either request it again or scroll down and select "Desktop", and I'm back where I started. It doesn't work in Chrome either. The ability to permanently opt out of this is desperately needed. MANdARAX•XAЯAbИAM21:51, 31 May 2018 (UTC)
I would have to agree. If I wanted nesting menus, I would just use a desktop program. I'm trained on using Monobook on all of my devices, no matter how kludgy it might be on an iPhone screen. The icons are too random and so tiny as to be useless to contextualize the menu option beneath it; if I'm keeping this I'd like the option to use text titles. I'm annoyed enough with the WP app wanting to grab anything I surf to, and this doesn't help mobile browsing/editing. Nate•(chatter)22:18, 31 May 2018 (UTC)
Is this what's screwed up the screen when I request the desktop site on mobile? I now get some horrible and meaningless icons at the top of the screen. Please stop "improving" things by making them worse. DuncanHill (talk) 22:51, 31 May 2018 (UTC)
Chiming in as the developer who approved the relevant patchsets and who has been working closely with Isarra on this...
First of all, thank you for providing feedback! Given that a lot of volunteer time and effort has been put into testing this change and ironing out bugs, it's surprising to see that some persistent bugs are still present — and I'm hoping you can help us squash those bugs for once and for all!
This is important because while there are, for example, many tablets released by Apple sold as "iPad", there are many significant differences between the different "generations" of devices — sometimes these differences are so major, in fact, that you could legitimately call them entirely different things! (Of course "iPad" is a well-estabilished brand and Apple will want to hold onto it and its good reputation, hence why it's more than likely they'll continue using the iPad brand even in the future.) Providing as accurate data as possible about the devices helps us in — hopefully — finding a device similar to that or a someone who owns a similar device and is able to assist in the development process.
E.g. 1920x1080px/full HD, etc.; you can find out sites which can help you in finding out your screen resolution by searching Google for "what is my screen resolution", for example, since on mobile devices it can be trickier to find out the screen resolution than on desktop or laptop computers
The browser you were using at the time, and if possible, its version
Finding out the browser version can be trickier, again. If you search Google for "what is my user agent", Google will display your browser's user agent which usually includes the browser name and version. Most browsers should have a menu labeled "Settings" (or something similar) under which you can find an item like "About <browser name>" or such, which allows you to find the browser version number without resorting to Google. On Firefox for Android (Fennec) 47.0, this menu can be accessed by tapping the three dots (on the same row as the address bar, choosing "Settings", then "Mozilla Firefox" and finally "About Firefox".
Name or URL of the page where the problem is occurring
Is the problem present only on the Main Page? Or on a certain article? All articles? All Wikipedia: pages? etc.
Ideally, a screenshot or even a video of the issue actually taking place!
To elaborate a bit more on what is being done and why...mobile devices are ubiquitous these days. The MonoBook skin was written originally in 2004, back when almost nobody had heard the words "responsive web design"; if MonoBook were written today, it would naturally feature responsiveness since in 2018 — and, frankly, for many years before, responsiveness has been a de facto standard for most web sites out there; MediaWiki has and still is lagging behind, partially because Wikipedia and other Wikimedia sites (Wiktionary, Wikivoyage, etc.) use the MobileFrontend extension to serve a rather different view to users of mobile devices. --Jack Phoenix(Contact)00:49, 1 June 2018 (UTC)
Samsung Galaxy J3 SM-J320FN, Android 5.1.1, Chrome 66.0.3359.158 (32 bit), screen 360x640. I have lost the talk/edit/history etc tabs at the top of the page, they have been replaced by illegible and meaningless icons. I can't see an option on the upload wizard for Wikipedia screenshots. DuncanHill (talk) 01:26, 1 June 2018 (UTC)
Hi DuncanHill. Icons in a user interface are very common. For example, the wrench and hammer to mean "tools" seems straightforward to me. If the meaning of the icons is not immediately obvious, when you click on the icon, it shows a "Tools" box. I'm not sure I understand what the objection here is. In the screenshot you provided, the icons are legible and meaningful. The user icon is the same guy who's been sitting next to the user tools all these years. The pencil icon means edit. The speech bubbles are for the talk page. And so on. --MZMcBride (talk) 02:50, 1 June 2018 (UTC)
They take up more space than the text, and are not by any means as readily understandable. One of the reasons I like monobook is because the tabs are so much clearer to me than on the other skins. They also make me have to click twice for some functions that I only had to click once for before. Also, PLEASE DO NOT PING OR @ ME. Getting rid of the notification on the new display is a pig. And more, it makes the desktop display on a mobile much more like the mobile site display, which is exactly what I'm trying to avoid. It makes articles take more scrolling to get through, contents lists take up the whole damn width of the screen, pictures take up the whole width. It's nasty. DuncanHill (talk) 02:59, 1 June 2018 (UTC)
Yes, exactly this. I would imagine that if someone is deliberately using the desktop view on mobile devices, he or she probably is used to the desktop view and wants it to look exactly the same on all devices. Responsive web design is exactly the opposite of what such users want. They like one view and don't want it to change, and they would like to keep using it everywhere. And at least my personal opinion places no weight on "lagging behind" when the desktop view has already been very optimised for editing; if we change it, it should be because something actually is broken, not to keep up with the Joneses. It strikes me that these efforts would be better spent on the mobile view, where they would be aimed at a public that actually wants this. A pertinent question might be if anyone on WP actually asked for this, or if it was simply imposed because some higher-ups from the WMF decided we had to keep up with the Joneses (never mind that the Joneses are doing something completely different and have completely different needs). An even more pertinent question might be if anyone actually realised the counterproductiveness of applying responsive web design to the desktop view on mobile devices. Double sharp (talk) 03:32, 1 June 2018 (UTC)
Something I've forgotten to add is that editing on the desktop view even on a mobile device allows you to do layout fixes even when not on a desktop, with the desktop view as the showcase one as it ought to be (there you have the biggest screen and the most complete experience, after all; it's quite difficult to research and edit on a smartphone simultaneously due to the amount of tab-swapping needed, so while it could be done, I do most of my large edits on the desktop). On the mobile view and this responsive quasi-mobile view, this can't be checked because pictures take up the whole width and override any chosen settings (never mind the mistakes that sometimes result when this is done, like unscrollable images that spill off the screen). Double sharp (talk) 06:13, 1 June 2018 (UTC)
I see, from Isarra's comment further down, that (to quote her) "the WMF was actually against this, as they feared pretty much precisely this reaction, which just goes to show that they have learned from previous incidents". I find this quite heartening and agree with her that it shows they've learned. I also see the link below showing where this was previously discussed, albeit without much publicity. Nevertheless, I still wonder if anybody along the lines realised the counterproductiveness of this, because the only people who are likely to see this are the people who are likely not to want it. Double sharp (talk) 10:37, 2 June 2018 (UTC)
@Jack Phoenix and Isarra: Please provide a way to permanently revert/disable this feature; as a screen reader user, I have no interest in it and never will (not to mention that it disables the access keys). I receive it in desktop view on my 15.6-inch laptop (!), a 2012 HP Pavilion dv6 Notebook PC running Windows 10 with a screen resolution of 1366×768 (the maximum) in IE11 when the window is restored (but not when it is maximised, and not at all in FF57). IE11 is easiest to use here for various screen-reader-related reasons, and Edge is not an option. Graham8701:37, 1 June 2018 (UTC)
Hi Graham87. What do you mean the access keys are disabled? When I press, for example, option+control+e, it works fine for me. What are you trying that isn't working?
@MZMcBride: It turns out that the "Edit this page" shortcut is the only one that works here when the new mode is active; I was trying the talk shortcut, which in my case is alt-t. They all still work with the normal Monobook.
Re: CSS ... that's really weird; the navigation/search links still display for me in all combinations of JAWS and NVDA (the two primary Windows screen readers) with Firefox and IE. Graham8703:36, 1 June 2018 (UTC)
There was a separate change to the jump links this week: phab:T195256. I haven't investigated yet whether that could be related, but just mentioning it for completeness. Legoktm (talk) 05:49, 1 June 2018 (UTC)
@Graham To disable the jump-to links, use .mw-jump-link{display: none;}. Notice the class name containing "link". The explicit disabling of accessibility links (in addition to being visually hidden by default) is not something MonoBook offered officially before, but I hope this snippet helps you to keep disabling it. Krinkle (talk) 20:42, 1 June 2018 (UTC)
@Graham: That's unfortunate. Which browser and operating system are you experiencing this on? I have tried myself with MonoBook in IE 11 on Windows 8, and also in Chrome and Firefox on macOS. Without the change to monobook.css it is visually hidden but becomes visible when tabbed to. With the change to monobook.css it is always hidden and not part of the accessibility tree and tab sequence. I have also tried adding the rest of your monobook.css customisations and are still not able to reproduce the issue. --Krinkle (talk) 21:05, 2 June 2018 (UTC)
@Krinkle: Hmmm, that's really weird! I get it in all combinations of JAWS/NVDA, the two most popular Windows screen readers, with IE11/FF60 unnder Windows 10. Could be a screen reader thing. After a couple of days of having it like this, I find it doesn't bother me anywhere near as much as the (now-reverted) responsive skin changes, however. Graham8702:13, 3 June 2018 (UTC)
I now have to have my zoom size at 150% (instead of 175%) to maintain my previous layout. TBH, I wish ya'll would leave things alone. GoodDay (talk) 01:59, 1 June 2018 (UTC)
Here we go again. Did anyone actually ask for this? Selecting "Desktop view" on my phone does absolutely nothing to get rid of this. I'd like a way to have all the main functions (main/talk/edit/watch/history/move) back in their tabs in one click. If I want any of them on my smartphone, I just zoom in on them and then tap the screen, not try to interpret tiny icons. Double sharp (talk) 02:40, 1 June 2018 (UTC)
Don't know if this is related, but it seems to have just started together with this: the multiple images at my talk page won't fit on my mobile screen anymore and won't allow me to scroll to see the parts cut off. Samsung Galaxy Core Prime (SM-G360G), Android 5.1.1, 534×320 (landscape, although the same problem occurs in portrait), Samsung Browser 3.3 on Android (Lollipop). Double sharp (talk) 03:32, 1 June 2018 (UTC)
I logged in this evening and found myself looking at whatever this mobile skin is. Except I am definitely not using a mobile device. Please fix immediately. Thank you.
My devices are an iPhone 7+ and the iPad Pro 10.5" running the most current Safari version (under a beta; I'm on 11.4 public beta 2). 1920x1080 on the iPhone, 2224x1668 on the iPad. It isn't as bad on the iPhone (though again I'd love a text labels icon over the pinpoint-sized icons), but I use the iPad because it renders a page how it should on a desktop. I don't need it to render the 'mobile version' on that device. Nate•(chatter)03:19, 1 June 2018 (UTC)
How do we get the hell rid of this? I don't use Monobook for "responsive design", I use it for a familiar workflow that's now entirely broken. Please either revert this change, Isarra and MZMcBride, or at very least provide an opt out (that isn't "fiddle with your phone settings.") This is the same kind of tone deaf "You'll love it once it's rammed down your throat hard enough!" that WMF likes to pull every so often. SeraphimbladeTalk to me04:57, 1 June 2018 (UTC)
What the flying fuck, please get rid of this abomination on mobile NOW. If I ask for the desktop version while I'm on my phone, that's because I want the goddamn desktop version, not a crapfest of unusability buried 20,000 leagues deep under barely legible icons that convey little to no information.Headbomb {t · c · p · b}08:48, 1 June 2018 (UTC)
Oh god, this affects the desktop view on desktops as well if you aren't in full screen mode. Revert this abomination ASAP please! Headbomb {t · c · p · b}08:55, 1 June 2018 (UTC)
As so many others have said: How the hell do I get rid of this? The icons are invisible because I work with images off, and the useful text links are at the bottom of the page, which can be a long way down. If you wanted to create a new 'responsive' skin, that's what you should have done, not broken Monobook. BlackcurrantTea (talk) 09:55, 1 June 2018 (UTC)
Legoktm, I was using a version of Firefox old enough to have a convenient prefs checkbox to disable them. (On a laptop, by the way, not a mobile device.) When I saw your mention here I tried to test it on the computer I'm using now, but you'd reverted the change, for which I heartily thank you. Please, pleaseleave it reverted.BlackcurrantTea (talk) 08:37, 2 June 2018 (UTC)
Would it be all right if I sorted the responses here into... general buckets of what they are/are discussing? It would make it much easier for me to respond to stuff, pull out actionable items, etc. Also maybe help figure out what we should do with this moving forward, and such. -— Isarra༆11:02, 1 June 2018 (UTC)
(ec) I'm sorry, but I am another person who thinks this change was very much for the worse, and it is impossible to get the old look back for me (iPhone 6s, Safari). Apart from the fact that the new design is considerably less useful for me than the old one which worked really well for me personally (so yes, why not create a new skin for people who do not like the old version, and allow those of us who to like it to keep using it?), I now can't see e.g. the full "Open for discussion" table at Wikipedia:Requests for adminship without flipping the phone into landscape mode, which I usually prefer not to do. This is certainly not intended behaviour. (By "can't see" I mean that it is too wide for the screen and the leftmost part of the table is cut off, so on my screen it starts with the "Support" column.) And that's in the desktop version on the mobile, not the mobile version, so I can't in fact "return" to the desktop version and fix it in that manner. --bonadeacontributionstalk11:07, 1 June 2018 (UTC)
Issues/problems/questions
I'll try to address specific concerns here. If I've missed something, please feel free to add an item, or comment on anything here already. (Responses to specific things above also coming shortly, but I'd prefer if further issues etc are added below, as this will make them much easier to keep track of and address.) -— Isarra༆12:12, 1 June 2018 (UTC)
On second thought, I can't follow the source of the above at all. I've tried to add all issues below. -— Isarra༆13:56, 1 June 2018 (UTC)
Who asked for this?
Third-party MediaWiki sites, primarily. There is a serious lack of mobile support in the skins currently shipped with MediaWiki, and MobileFrontend often does not entirely meet their needs either. Making more of the available skins themselves responsive is a good step toward supporting their need for a mobile-friendly site for visitors.
I did enquire what people thought of this change here in april once I had the basic prototype, but no issues were raised and nobody objected at the time. -— Isarra༆12:12, 1 June 2018 (UTC)
Opt-out methods not working
Mobile browsers have a browser option to request the desktop site - this works in firefox, but due to bugs in the browsers themselves, apparently not so much in safari and chrome.
There is a link in the page footer for 'Mobile view' or 'Desktop view' - this is a part of MobileFrontend, and has nothing to do with this change.
No way to opt-out on desktop - there may be browser extensions for this? I'm not sure. This is, frankly, a very unusual request. (If all else fails it might be doable to add a user preference, though? But that's apt to be very messy source-side, as mw isn't exactly built for these kinds of options either.) -— Isarra༆12:12, 1 June 2018 (UTC)
Is this a response to me? If you thought I wanted the ability to opt out of seeing the Mobile/Desktop view links, then you've misunderstood me. (If not, then I guess I've misunderstood you, but that's the only thing I can think of that would qualify as a "very unusual request".) I mentioned the Desktop link because Legoktm said that one could opt out of the new layout by requesting the desktop site, and I wanted to point out that it didn't work no matter how I attempted to get the desktop view. What I wanted the ability to opt out of is the same thing everybody else here is talking about. MANdARAX•XAЯAbИAM06:16, 2 June 2018 (UTC)
If a change is known not to work on common browsers, maybe don't introduce it? Or only introduce it on a new skin that people can choose to use if they want to. DuncanHill (talk) 12:29, 1 June 2018 (UTC)
But the new look is what is visible on the mobile after requesting the desktop site (Safari). It's the mobile version of the desktop site that has changed; the en.m.wikipedia version is the same from what I can tell (I always scroll down and click "Desktop" whenever I am redirected to the mobile site so don't have that much experience with what it is supposed to look like, exactly). --bonadeacontributionstalk12:42, 1 June 2018 (UTC)
A bit clearer of an explanation for people: The new design doesn't actually switch on "desktop" versus "mobile", it switches on the effective viewport width being greater than or less than 850 pixels. On (some) mobile browsers, the browser's "Request Desktop Site" option forces the minimum viewport width to a value larger than 850px which is why it functions to bypass the new responsiveness in Monobook. Anomie⚔13:18, 1 June 2018 (UTC)
And the toggle on the bottom of the page is for MobileFrontend, which turns MF specifically on/off, regardless of viewport. We really need to make this less confusing, but for now that's how it is. -— Isarra༆13:27, 1 June 2018 (UTC)
This is definitely a bug. Could you please specify exactly which things aren't working? Which access keys, which labels, links etc. -— Isarra༆12:12, 1 June 2018 (UTC)
@Isarra: The article/talk access keys don't work; the "edit this page" link (and it turns out all the others!) work fine. Graham8716:50, 1 June 2018 (UTC)
Also, this is probably obvious but I'll say it anyway ... the access keys for the hidden elements don't work when they're hidden (by design). Having to unhide them first kinda defeats the purpose of the access keys as a quick navigation tool. Graham8703:47, 2 June 2018 (UTC)
@Graham87: The problem here is I can't replicate this elsewhere, and if the mobile hiding is the problem, then none of them should be working, including talk, history, etc. Based on what this change actually does, the page-related access keys should either all work or none, so if some still work and others don't, this suggests that this may indeed be caused by something else entirely. (The other change? What was the other change?)
We're reverting this for now, but... agh. (Also, in general, are you saying that display: none on a parent disables accesskeys in general in screen readers? Because if so I may have a few other skins that definitely need fixing... )
Also thank you, seriously, for your specific feedback and bearing with us on this. Very helpful. -— Isarra༆08:52, 2 June 2018 (UTC)
@Isarra: I can't replicate this problem here anymore (obviously), but I can replicate it on your prototype with the latest stable versions of both JAWS and NVDA, the two most popular Windows screen readers, in both IE and Firefox (again with the latest stable versions ... I had to hugely increase the zoom for the elements to be hidden there). Not sure if this was clear enough before (perhaps it wasn't!), but this is only a problem for me when the elements are hidden; they work fine otherwise. Maybe it's a display:none thing ... who knows? Graham8709:50, 2 June 2018 (UTC)
@Graham87: Ah, thanks! That actually helps clarify a lot. Now I get what you're saying, and... yeah, this will definitely be fixed. -— Isarra༆21:49, 2 June 2018 (UTC)
This is necessary because there are an arbitrary number of tabs with fairly arbitrary content across languages. The only way to make them fit on a set size is to set their size as well, and the only way to do that is to remove the text and replace it. The reason why they would now appear bigger is because they also have extra padding so they're easier to hit with random body parts that do not have the precision of a mouse pointer.
We cannot simply have them as text that wraps and moves the rest of the page content down because they are technically after the page content in the DOM.
A fallback for something to appear when the icons are disabled should be added. The problem is I'm not sure how to do that. Any ideas? This is important for a lot of things, frankly, not just (mobile) MonoBook. -— Isarra༆12:12, 1 June 2018 (UTC)
Hides navigation and requires extra steps to find/use it
General workflow changes are to be expected when using different kinds of devices. However they should not be so significant, so if anyone running into issues here can describe exactly what you would do before, and then compare to after, that would be quite useful to improve the situation. -— Isarra༆12:12, 1 June 2018 (UTC)
Well, before I would just do what I would do on my pc, all the tabs etc were in exactly the same place and looked exactly the same. I can't give you any screenshots because my Tardis is broken. Now, I have to work out what the icons mean, work out where some of them are hiding as they don't all show at once (see screenshot above), and I can't dismiss notifications without navigating away from the page I am on. DuncanHill (talk) 12:29, 1 June 2018 (UTC)
I know this is a long shot, but could I ask you to please try to bear with it for few of days, see what you think after you've had a chance to get more used to it, and then let me know what problems/things are still being specifically annoying at that point? I know this kind of came out of the blue, and I'm sorry about that, but Wikimedia's update deployments are a little... strange compared to how the sites I usually work with are (third-party mw sites tend to have actual versioning, as opposed to rolling-release updates), and I'm apparently still not very good at handling it appropriately. -— Isarra༆13:27, 1 June 2018 (UTC)
I don't want to use it at all, certainly not get used to it. It's grim for reading, and awful for editing. Telling people to "get used to it" is not helpful. DuncanHill (talk) 15:01, 1 June 2018 (UTC)
WMF shoving things down users' throats
The WMF was actually against this, as they feared pretty much precisely this reaction, which just goes to show that they have learned from previous incidents. This, on the other hand, is a volunteer-driven initiative targeted more toward the needs of third-party MediaWiki users, with the understanding that nobody objected when I asked about it here earlier, so it was probably fine. -— Isarra༆12:12, 1 June 2018 (UTC)
I'd expect suggested changes that are expected to affect a large majority of the Wikipedia community to be at least publicised by a watchlist notice and/or a link at Wikipedia:Centralised discussion. I'm not so tech-savvy that VPT is somewhere I go often; I mostly go here if something's not showing up right, whether because of recent changes or because the stuff on my .js and .css pages (all written by others) are not working properly. I'd expect this to be true of quite a few other Wikipedians. Double sharp (talk) 14:48, 1 June 2018 (UTC)
And if I was unclear in what I said, I didn't mean that this was WMF's idea. I said it was like the time WMF has pulled similar things, generally with very little notice (most people don't follow VPT, and even fewer read every discussion). For the vast majority of Monobook users, me included, this was just a sudden change with no explanation. I actually originally thought it was some kind of weird bug, and came here to see if anyone else had reported experiencing the same thing. I certainly did not expect to find that it was done intentionally. A proposed change like this, especially if it will not have an opt-out, should have first gone through a well-publicized RfC to see if the community wants the change to begin with. SeraphimbladeTalk to me17:23, 1 June 2018 (UTC)
What's more public than VPT? – I also do not think VPT is sufficiently "public". I'm a frequent editor but don't read VPT unless I'm following a discussion about a problem after it occurs. I'm only here now because I noticed the change to the skin and saw the watchlist notification. Mitch Ames (talk) 14:03, 8 June 2018 (UTC)
The WMF was actually against this apparently not against it enough to block promoting it to production... — xaosfluxTalk01:34, 4 June 2018 (UTC)
'Notifications' is just a link to Special:Notifications instead of a flyout with the actual notifications displayed
I have noooo idea what to do about this. Apparently Special:Notifications just doesn't entirely work, but we also can't use the usual echo flyouts on mobile because OOUI doesn't support mobile either. Um. -— Isarra༆13:27, 1 June 2018 (UTC)
Previewing/fixing formatting problems for desktop/mobile from either device
This is a longstanding issue that's been brought up time and again - that mobile and desktop render differently, and people need to be able to preview changes on either regardless of which they're actually editing from. Having skins that responsively support both should improve the situation in that you can focus on the content itself more than the formatting, but... hmm, not sure if this helps, since indeed it does seem to kill the ability to zoom out and crap on a phone. -— Isarra༆13:56, 1 June 2018 (UTC)
Wait, nevermind, that's what the 'Request desktop site' thing is for. Actual problem is that it only seems to entirely work in firefox. -— Isarra༆13:58, 1 June 2018 (UTC)
Should have a tablet/small-desktop view
I think a tablet/small-desktop view, which hides the sidebar but still shows labels for the tabs, would be a good idea. I find this works quite well in Timeless. Why give users a phone experience if they're on a mid-to-large sized device or small desktop screen? - Evad37[talk]14:43, 1 June 2018 (UTC)
@Evad37: Main reason was because I didn't want to figure out how to make collapsible tabs because vector's implementation scares me and just making the cutoff wider sort of avoided the problem, but since people seem to feel a lot more strongly about this than expected, yeah. This seems definitely in order. -— Isarra༆20:18, 1 June 2018 (UTC)
It makes Wikipedia much harder to use on mobile, it forces people to have what is essentially a mobile view despite them asking for desktop. If people want a different skin for mobiles then make one, don't impose it on people. Kind of dumb is an understatement. I do appreciate that a lot of hard work went into it, and it was well-intentioned, but you know what they say about good intentions. Please get rid of it. DuncanHill (talk) 12:22, 1 June 2018 (UTC)
I was wondering why the Mediawiki skin wasn't rendering properly. Now I know why. Please revert, it's causing major problems. Cesdeva(talk)14:01, 1 June 2018 (UTC)
No one addressed my issue above about this change affecting an actual desktop user. So whatever you're doing, please revert until this is addressed. Sephiroth9611 (talk) 14:12, 1 June 2018 (UTC)
Get rid of it NOW. Either create a new skin, or don't enable 'responsiveness' without providing an opt-out/opt-in mechanism via preferences or something. Headbomb {t · c · p · b}16:10, 1 June 2018 (UTC)
Get rid of it for now, until there's an opt-out feature, for screen reader users. I also get this new view on a non-mobile device. Graham8716:50, 1 June 2018 (UTC)
The mere fact that Graham87 (talk·contribs) is being denied their normal experience is a killer for this enhancement, and so on grounds of accessibility alone, must be reverted forthwith. We cannot assume that all our users can use a mouse - or even that they can see. --Redrose64 🌹 (talk) 21:49, 1 June 2018 (UTC)
This hasn't affected me either, as I use vector, but when you are making editing and even reading difficult for power users and blind people, it's time to revert and rethink. – Jonesey95 (talk) 03:12, 2 June 2018 (UTC)
People keep talking about mobile, but I'm seeing it on desktop. With no warning, I suddenly can't find anything anymore. So I go looking, and I find some things and not others. Then on another computer, it shows up the way it used to. Huh? Eventually I figure out that it's determined by the zoom level, so as long as I don't need to make anything too big, I can have the controls where I know how to find them. There seems to be no relationship between the two control layouts, and it just toggles back and forth depending on the zoom. In what universe is this supposed to be an intuitive UI? --Trovatore (talk) 07:05, 2 June 2018 (UTC)
I saw it on a laptop, and it made editing close to impossible until I switched to another skin. Any change of this magnitude should be opt-in, and the accessibility problems Graham87 mentioned are a dealbreaker. As I said above, if you want a 'responsive' skin, then create one. Don't break Monobook to do it. BlackcurrantTea (talk) 08:55, 2 June 2018 (UTC)
Yesterday, when I went to Wikipedia on my laptop (I do not own a 'phone, so I don't know anything about or have any connection to mobile), I saw the new UI. I had no idea how to do anything on it other than search. I thought I was going to have to quit editing on the English Wikipedia. Kdammers (talk) 09:55, 2 June 2018 (UTC)
I'm not fundamentally against a responsive skin, or icons, or anything to make the system more usable on mobile in general. For large parts of the world, mobile is the only way people access the internet, and they need to be supported. That said, there also needs to be a way for people to get the plain-old desktop version if they want it. I'm a power-user, and I've learned my way around the desktop U/I. When I'm on mobile, I generally find the mobile version to be annoying, because I no longer know where things are. -- RoySmith(talk)16:32, 2 June 2018 (UTC)
I use the desktop view on my mobile devices because the mobile view is shit and always has been. I prefer to have a page that won't fit on the screen to a view that is a complete pain to navigate. As an admin I see a constant procession of IPs and new users who think they have had to jump through hoops to get to the talk page (or get to talk to anybody). It is completely couterproductive for my mobile devices to default to the mobile view. If I wanted that I would set it, or use a different skin. Having said that, making the skin responsive on desktops might be useful to me. The only time I look at mobile view is to check what mobile users are seeing. Being able to do that just by shrinking the screen would be cool, but I definitely do not want this on mobile devices. SpinningSpark15:36, 8 June 2018 (UTC)
I also use desktop view on mobile devices. Having it (or worse, my desktop, as some point out above) essentially revert to mobile view with a "mobile view" link at the bottom for irony, would go against my stated preference, not to mention be a waste of JavaScript, with which the WP editing window is already bloated to the max. I'm tired enough of websites making the letters 5 cm tall when I'm browsing on a 720p computer screen (and also of having to switch off JS on my phone because WP won't go to desktop view if I don't enable cookies, which I'd then have to enable for all websites). WP doesn't need to join the club for the sake of satisfying the web design keyword of the week. DaßWölf15:51, 8 June 2018 (UTC)
Personally, I think MediaWiki needs to have a new interface built around responsiveness, rather than trying to shoehorn a square peg into a round hole that is the former default theme. Responsive design is about mobile-first by default. ViperSnake151 Talk 15:39, 10 June 2018 (UTC)
A different suggestion for implementation
Isarra has said above that a user preference to toggle on or off the "responsive" nature would be difficult. How about a different solution, then? Revert the "classic" Monobook to work as it did, and put the new version as a skin option in Preferences. It could be called "Monobook for Mobile" or something. That way, those who do like the changes can continue using them, those who don't get their Monobook as they already like it, third party Mediawiki users still get their "mobile Monobook", and...don't really see any downside? SeraphimbladeTalk to me17:19, 1 June 2018 (UTC)
See also this XKCD comic. This is 2018, responsive web design should be the standard, not an opt-in. If we do end up forking monobook, the old (non-responsive) version should be called something else (perhaps "throwback") and responsive monobook shipped along with MediaWiki to third parties. For folks that want to opt-out of responsive design, they would then be free to switch the skin to the forked version in their preferences. It is going to be impossible to please everyone, but we must be forward thinking in terms of the MediaWiki software design, and a small but vocal minority of those who would rather be stuck in 1999 cannot hamper progress. This is not to say the current iteration of responsive monobook is perfect, and if you have found issues which hamper your experience with the skin beyond "I don't like it because it's different", then please let us know about it. These are the things that need to be discovered and addressed in order to make the skin work great in mobile as well as desktop. Unfortunately, it's difficult to uncover all of these issues beforehand given the various workflows that people have, so if you bear with us during this teething process and offer constructive feedback and criticism, the skin will come out better for it :). Unfortunately, forking monobook into a throwback version is not free; it adds maintenance burden to the WMF as they now have one additional skin to test against and ensure it remains up-to-date and secure. Ideally, those who detest responsive monobook can figure out what real issues they have with it (versus feelings or knee-jerk reactions against change) and report them so they can be looked into and resolved, and we end up with responsive monobook as the only monobook at the end of the process. --Skizzerz (talk) 20:16, 1 June 2018 (UTC)
There have been plenty of valid issues given. Your response is patronising and dismissive of the real problems listed above. It makes Wikipedia harder to use. It's not a "knee jerk reaction" to object to a degradation of service and function. DuncanHill (talk) 20:31, 1 June 2018 (UTC) More - To dismiss the complaints as a case of "I don't like it because it's different" shews that you either haven't read the problems above, or you simply do not care about user experience. I am appalled at your comment. You should not be involved in dealing with volunteers if that is your attitude to us. DuncanHill (talk) 20:34, 1 June 2018 (UTC)
I am a professional software developer. If I responded to client complaints about a UI change as Skizzerz did above, I would be promptly out of a job, and rightly so. (Hint.) I fully agree with DuncanHill here. This sort of major UI change should never be imposed with little or now warning except oin an opt-in basis, particualry when doing it instead as a new varient skin would apparently have been simple. DES(talk)DESiegel Contribs22:44, 1 June 2018 (UTC)
@Skizzerz: Here's the issue with the "responsive" skin: it's responsive. This is a negative-value feature and no amount of "fixes" and "improvements" will ever change that. People who use monobook, as opposed to say vector, use monobook because it's the power editor skin. All the features we want are exposed there, directly. Not buried in 482 layers of unrecognizable icons spread over 47 submenus. Headbomb {t · c · p · b}22:58, 1 June 2018 (UTC)
@Skizzerz: I will echo DESiegel's comment that if I treated the users of my software in the dismissive and sarcastic way that you've done here, I would swiftly be out of a job (and yes, I do it professionally too, and have for over a decade now). Rather, I treat those users as valued partners, since at the end of the day, the software I write means nothing at all if the people who use it cannot get done with it what they want to get done. I do understand that you feel attached to what you've written, but your dismissive citation of an xkcd cartoon (and by the way, I have read xkcd every Monday, Wednesday, and Friday morning for years now, and yes I saw that one) as some kind of justification doesn't say much for you. Yes, all changes break something, but that doesn't mean all changes that break something are by definition good ones. I would challenge you to specifically refute what I've asked here, to put "Monobook" and "Monobook Mobile" as separate skins. I can see no downside to that, aside from perhaps as you said some additional maintenance costs, but well, you made these changes, so if the additional maintenance isn't worth it, revert them back. When a substantial proportion of your users wants the "classic" or "legacy" functionality, you do need to maintain that until and unless you convince them that what's newer really is better. SeraphimbladeTalk to me00:23, 2 June 2018 (UTC)
@Skizzerz: Question: is there any argument at all for responsive web design for WP besides "it's 2018 and all the cool kids are doing it?" Surely we should at least ask ourselves why the cool kids are doing it and if their situation is applicable to ours. I rather find that no, it really isn't. The simple fact of the matter is that contributing seriously to Wikipedia is quite different from contributing seriously to a lot of other sites: you can't just write what you think, because that is going be non-neutral original research. Being a serious WP editor is not that easy and you will end up using pretty much all the sidebar and header tools all the time, and I do not think that any change that hides them is an improvement. If anything I think it would make it more difficult for readers to become editors (and that is already difficult enough as it stands). Double sharp (talk) 03:27, 2 June 2018 (UTC)
Going to try to respond to all of the above in one go (if you couldn't tell, I don't visit here much).
@DuncanHill: I am not trying to be dismissive of any of the issues already raised which are actually issues, of which there are quite a few in the sections above. This kind of feedback is very valuable and I encourage people to keep raising these sorts of issues. For example, from the feedback above it's pretty clear that the iconography could probably use more work to be clearer, the breakpoints could be re-evaluated so that it breaks only on lower resolutions (perhaps with the introduction of a tablet-friendly view so it doesn't go straight from desktop to phone), the thing with screen readers and access keys not working is a major issue, the orange is odd/confusing, and so on. All of these are valid issues, and if people see more things like that, they should by all means report them. The types of feedback that is not useful or at all helpful is neatly encapsulated in Headbomb's comment above. That type of feedback is entirely useless and pointless, and would be promptly ignored if I was in charge of the project (I'm not; I just happen to be friends with Isarra -- I haven't contributed anything to the project itself as of yet). You don't like it because it's different? Keep it to yourself, we don't need to hear it. You don't like it because there are actual issues that impact its usability or aesthetics? Let us know so we can work with you to address them.
@Double sharp: The applicability of responsive design stems from the increasingly larger percentage of users who browse Wikipedia with their mobile devices as days go by. The existing mobile site (MobileFrontend) largely goes about solving the issue in the wrong manner. By having an entirely separate mobile skin, features which editors or power users may need are simply nonexistent, whereas if we made a desktop skin responsive those features would still be present (albeit perhaps behind a menu in order to ensure the content is given top priority for screen real estate). As an example, the MobileFrontend skin makes it impossible to view the diffs between non-adjacent revisions, so if one user makes 5 edits in a row you cannot easily see the full diff combining those 5 edits. However, in a responsive skin, those features would still be present in some fashion as the same skin is serving both mobile devices and desktop users. For things such as checking up on vandalism on the go, these sorts of features are invaluable even though they don't impact the vast majority of users (hence why MobileFrontend doesn't support them).
@Seraphimblade: It is not my decision to introduce this as a second variant of the skin. Should that discussion come up, I will fight as hard as I can to make responsive monobook the default one, and have the non-responsive one introduced as a separate skin that people can switch to if they absolutely hate the new monobook. Your "substantial proportion" is less than a fraction of a percent of all users of monobook across all wikis, and English Wikipedia's community does not and should not have any say over what MediaWiki as a whole serves to 3rd party users. We ship monobook along with the tarball, so forcing those 3rd party users who have been asking for responsive skins for years to go out and download one separately instead of bundling it and automatically upgrading their wikis to use it once we do ship it is only doing them a massive disservice. The English Wikipedia's community does and should have absolute say over what happens to English Wikipedia itself, so if the community really wants the skin to be forked, that will be a decision the WMF will need to weigh and perhaps implement. I think that decision is premature, however. Once the bulk of issues mentioned in the above sections are ironed out, that is the time to evaluate what the community really thinks about it. Causing riots due to an alpha-quality responsive skin is incredibly short-sighted. Now, you may have questions as to why an alpha-quality skin was deployed to English Wikipedia, and well, so do I. This probably should have been deployed to the test Wikipedia for a month or two to gather this sort of feedback rather than abruptly and without much advance warning deploying it to a production wiki.
@Lots of people: I'm a professional developer too. I'm not posting in a professional capacity. You are not my clients, I am not representing anyone but myself with my comment, and I am not being paid to sit here and type these words. I'm a volunteer who happens to have opinions on software design, and saw a colleague (who is also a volunteer) being raked over the coals by negative responses which had no business being that negative. So, I jumped in with a somewhat snarky comment asking for people to state the actual issues they have (for the actual issues which exist, of which there are many), and for people who just want everything to stay the same for 20 years without any attempts at improvement to either go away or stop being curmudgeons and offer constructive feedback instead so that we can move forwards as a platform and as a community. If you want my respect, start respecting the efforts of other volunteers, and work with them instead of attacking them. --Skizzerz (talk) 18:26, 2 June 2018 (UTC)
@Skizzerz: In order to work on the layout of WP articles, and ensure that they look good on desktop as well as on mobile, we need a mobile view that matches the desktop view in this respect, instead of one that (like the current one) makes all images take the entire screen width. We also really don't have enough room on mobile to have all the tabs, sidebar links, and top links without making the text a lot smaller, but these need to be directly accessible to be really useful. But once we keep those the same as the desktop view, don't we essentially have the desktop view already? Even just adding references on a smartphone is time-consuming and pretty painful already, and we don't need to make things even more painful by requiring more clicks and possible loading time at each step along the way to doing small edits that are still practical on smartphone. Double sharp (talk) 16:02, 5 June 2018 (UTC)
Oddly enough, one gets the previous display restored via reducing 'font size' to 150%. But, I'm used to having my fonts at 175% GoodDay (talk) 11:55, 2 June 2018 (UTC)
@Skizzerz: Re:"Keep it to yourself, we don't need to hear it." This change was forced upon on me/us, with no way to opt out, so yes, you/the devs do need to hear it. More importantly, this change needs to be reverted, and promptly so. Which apparently it was.Headbomb {t · c · p · b}18:32, 2 June 2018 (UTC)
Skizzerz(talk·contribs·deleted contribs·logs·filter log·block user·block log) "You don't like it because it's different? Keep it to yourself, we don't need to hear it. You don't like it because there are actual issues that impact its usability or aesthetics? Let us know so we can work with you to address them." I have been telling you actual issues that affect its usability and its aesthetics. I am a vastly more active editor on Wikipedia than you are, so I think I have rather more right than you, who hadn't edited here in over 6 years before your patronising post above, to say that something degrades usability, and I think you would do well to defer to people who actually edit this Wikipedia on such issues. If you want our respect Skizzerz try being a productive editor rather than someone who just turns up to be snide and ignore genuine issues. DuncanHill (talk) 18:48, 2 June 2018 (UTC)
(edit conflict) @Headbomb: There was a way to opt out: it was the "request desktop site" feature of your mobile browser. This apparently didn't work on iOS (and also impacted actual desktop users who didn't fullscreen their browsers), so reverting seems a sensible course of action while those issues as well as the other issues raised above are addressed. As I mentioned in my reply above, I don't think this should have been deployed here as-is, rather it should have been on test Wikipedia for a couple of months to gather this sort of feedback in a non-production environment. The skin will continue to be worked on and these issues addressed, and hopefully the deployment process for it next time will be more sensible and with more advanced notice. To come back to what you were actually responding to, a good feedback would be "The opt out isn't working" or "I don't see a way to opt out" or "It's showing the phone version when I'm on my desktop with the browser window still large but not full-screen" rather than peppering it with swears, calling it an abomination, and other inflammatory remarks. @Duncan: Wikipedia is not the world, and is not the only wiki running the MediaWiki software. We are both volunteers, you have exactly zero more and zero less rights than I do. I honestly do not care one whit about Wikipedia, as my focus areas are more towards supporting 3rd party MediaWiki instances, and I have made numerous contributions in that area, just as you have made numerous contributions here because presumably you care about Wikipedia and this is one of your focus areas. The size of my e-penis edit count compared to yours here has absolutely no bearing on the validity of all of the above statements I made. I was not accusing you of not pointing out issues in a constructive manner; my initial comment did not name any names or call anyone out. My follow-up to you specifically in fact noted that a lot of the issues that you and others raised were in fact "valid issues" according to my original comment, to make it clear that I was not flippantly discarding everything said in the above sections. I am not "ignoring" genuine issues. I was asking everyone to have less grar and derogatory comments so that the genuine issues could stand out so they can be addressed. --Skizzerz (talk) 18:58, 2 June 2018 (UTC)
No, "request desktop site" was not a way to opt out of this. This affected the desktop versions as well, both when seen from a phone, or from a desktop. Headbomb {t · c · p · b}19:00, 2 June 2018 (UTC)
Holy hell, this guy doesn't even have 25 edits on Wikipedia this is how he talks to power users? Headbomb {t · c · p · b}18:54, 2 June 2018 (UTC)
@Skizzerz:You certainly shouldn't dismiss the concerns of people who do a lot of editing and who have told you that these changes make editing harder when you do not have any real experience to base your dismissal on. If you are telling the truth when you say you don't care about Wikipedia then you really shouldn't be diving into discussions like this, especially when you mischaracterise the contributions of others and fail to respond to genuine concerns. DuncanHill (talk) 19:08, 2 June 2018 (UTC)
I am finding it difficult to understand why this has been a problem for third party users. If they don't like the non-responsiveness of monobook then they don't have to install it on their system. After all, monobook has not been the default skin here for many years; it is not essential for third parties. If they are asking for a monobook-like skin that is responsive, then as several editors have already suggested, develop a new skin that does that for them. Don't mess with the skin the grognards are using. By definition, they won't like it. SpinningSpark15:44, 8 June 2018 (UTC)
I wrote a much more elaborate post on Phabricator, but I've temporarily reverted this for now due to some of the accessibility problems mentioned above. Legoktm (talk) 07:44, 2 June 2018 (UTC)
Please do revert back, and then implement this properly: As an opt-in change for those who want it, not a forced change for those who do not. SeraphimbladeTalk to me10:00, 2 June 2018 (UTC)
So, Legoktm, note that the revert ticket included "and consensus". You have indicated neither on the Phabricator ticket nor here why it would be somehow impractical to keep in place the Monobook functionality which has been working for over a decade along with whatever shiny new toy is supposed to replace it. But let's be clear: If there's really a choice between the venerable, well-loved, widely used Monobook and the shiny new toy, it is the toy, not the well-loved and well-used version, that must be discarded. SeraphimbladeTalk to me10:42, 2 June 2018 (UTC)
At that time I hadn't tried to see how much work it would be to support both. It turned out to be reasonably possible to add in a user preference to control the responsiveness. In general we try and avoid adding in new preferences/conditionals like this, but I think we'll be able to deal with the extra maintenance burden in the future. Legoktm (talk) 08:51, 7 June 2018 (UTC)
And apparently phab contributors think they don't need any community consensus to push this on us (having removed a community consensus project tag)? It is bad enough when staff push an unwanted change, now we have to fight with volunteers too? — xaosfluxTalk17:38, 2 June 2018 (UTC)
Well that's correct...ish. Generally, individual technical changes don't go through any form of community consensus review, and on the scale of things, this was only supposed to affect people who use the MonoBook skin on mobile devices, which is a pretty small set of people. But that didn't work out as planned due to the mobile breakpoint triggering for people with high zoom levels on laptop/desktop devices, and that we only started announcing and socializing the change a bit too late. Legoktm (talk) 08:42, 7 June 2018 (UTC)
Because of my background I could understand this to mean: developing/documenting a capability, providing tech support, and publicizing the 'how to do it' to a community. --Ancheta Wis (talk | contribs)20:07, 7 June 2018 (UTC)
GoodDay, I think we're going to need more information. Which page? What web browser and operating system? How big is your screen? What does it look like when it's out of whack? Whatamidoing (WMF) (talk) 23:01, 31 May 2018 (UTC)
(edit conflict) "out of wack" is very vague for something depending on your skin, browser, window size, the specific page and other factors. Above 150% is a lot and it does not surprise me if something displays poorly. PrimeHunter (talk) 23:01, 31 May 2018 (UTC)
It just doesn't display the same, anymore. I can't explain it without showing what it looks like, which I can't do. An example: the 'Search' box, should be on the left of the screen, but instead is at the top. GoodDay (talk) 23:27, 31 May 2018 (UTC)
If your search box is usually on the left then you don't have the default Vector skin at Special:Preferences#mw-prefsection-rendering. I guess you have MonoBook and are seeing an effect of the new responsive MonoBook feature in the previous section. It will vary when it happens for different users. You can maybe also get it to happen at 100% or less by narrowing the browser window. PrimeHunter (talk) 00:41, 1 June 2018 (UTC)
Hi, here's an update. This is going to be redeployed today, as part of the weekly MediaWiki deployment train, with two important changes. First, as soon as it's deployed, you can go to Special:Preferences Appearance tab, uncheck "use responsive MonoBook design", and it'll revert to the normal desktop styles. Secondly, the threshold for devices being considered mobile has been lowered, so people with high zoom levels are less likely to even see it in the first place.
I hope that this resolves most people's immediate concerns (please let me know if it doesn't). There's a list of other bugs/proposed improvements listed as subtasks on Phabricator, as well as additional discussion behind these changes on that task. Legoktm (talk) 08:22, 7 June 2018 (UTC)
Do you have suggestions on where else this should be announced? Relatively speaking, this change should not affect that many users... Legoktm (talk) 19:05, 7 June 2018 (UTC)
MediaWiki:Watchlist-messages and MediaWiki:Sitenotice spring immediately to mind. WP:AN is also a good place to announce changes which are likely to confuse editors. VP:T isn't quite a disused lavatory with a sign on the door saying "Beware of the Leopard", but it's not Trafalgar Square either. Why is it opt-out instead of opt-in? DuncanHill (talk) 19:47, 7 June 2018 (UTC)
Yes, why is it opt-out instead of opt-in? Since this is for Monobook rather than Vector, the people who are going to see it are mostly power editors, who will largely have no use for it. Double sharp (talk) 23:20, 7 June 2018 (UTC)
I suppose a more flexible question here would be, is the opting default something that can be configured per project? — xaosfluxTalk00:00, 8 June 2018 (UTC)
Opt-out or opt-in makes very little difference to individual users in the end, save that if it's opt-in, very few people will choose to opt-in since they won't even know it's an option (how often to you check your preferences to see if something new is out there). I don't care which of the two is chosen by whomever, for whatever reason, as long as those who don't want it don't have it forced on them. Headbomb {t · c · p · b}01:25, 8 June 2018 (UTC)
Yes, but if it's opt-out, I imagine people will also not know for the most part how to opt out in the absence of a wider announcement than VPT, for exactly the same reason. DuncanHill's edit request at Mediawiki talk:Watchlist-messages will of course lead to a wide announcement, so this is likely to be less of a problem now. I nevertheless wonder how strong the correlation will be between high mainspace activity and opting out. Double sharp (talk) 05:03, 8 June 2018 (UTC)
Good Day
Very much I ask to check all changes on objects which connected with the territory of Ukraine together with the Crimea. The problem consists that a huge number of articles are created on sources in Russian that leads to distortion of information or to problems in categories. When the people born in the territory of Ukraine write down as Russians, - only because, were born in the Russian empire.
Because of it the Ukrainian geniuses, at you register as the Russian architect, the Russian artist. and so on. therefore, that I was born in the territory of Ukraine - check his biography not only on the Russian sources. Given rise in the territory of Ukraine during the Russian Empire. Then it is very difficult to correct.
- under a question the Russian categories (was born in the territory of Ukraine, built in Ukraine and Russia) What sense Soviet to duplicate as Russian?. It is wrong when the Ukrainians who were born in the Russian empire, turn automatically in Russians / Russians of category have written down because all sources are Russians.
I have given it as an example, have met recently.
And when the Ukrainian is written down as Russian, it is possible to meet not once.
Or Crimean Bridge (Crimea) - the Crimea the disputed territory of Ukraine and Russia. In the table in the right top corner where "locale" is written only Russia, there is no Ukraine. This violation of a neutrality and short information that to mislead the reader.
--Bohdan Bondar (talk) 21:47, 9 June 2018 (UTC)
According to Ukraine: "While Russia and ten other UN member states recognize Crimea as part of the Russian Federation, Ukraine continues to claim Crimea as an integral part of its territory, supported by most foreign governments and United Nations General Assembly Resolution 68/262." As such, I agree with you that the English Wikipedia should recognize Crimea as part of Ukraine and things like infoboxes (such as the "locale" field in the infobox of Crimean Bridge (Crimea)) should say Ukraine. However, this is not the right forum it is for technical matters such as computer software. This could be a large and contentious issue akin to the great Talk:Gdansk/Vote of 2005. -- GreenC13:58, 11 June 2018 (UTC)
Confirm watch/unwatch
Resolved
I have "Add direct unwatch/watch markers (×/+) to watched pages with changes" ticked in Preferences→Watchlist. Clicking the x used to quietly remove the page from my watchlist. For the last few days, it has instead taken me to a confirmation screen, which I find less convenient. Has anything changed? Is there a way to restore the previous functionality? Thanks, Certes (talk) 19:56, 10 June 2018 (UTC)
It's now mysteriously working again. It seems to work intermittently. I'm using Firefox 60.0.1 on Ubuntu with the default skin. Certes (talk) 23:15, 10 June 2018 (UTC)
Certes This sometimes happens to me as well — it seems to occur when the watchlist isn't fully loaded, either because I clicked too soon or the browser/interwebs crapped out. I've (largely) trained myself to deal with the former. ~ Amory(u • t • c)00:59, 11 June 2018 (UTC)
Thanks. I've had short outages this week on my normally reliable connection, so that's probably the cause. Certes (talk) 09:59, 11 June 2018 (UTC)
A few weeks ago the font size in this box (on Vector it's located at the upper right side) suddenly shrank to what appears to be about 8-point. I poked around in the Village pump archive (the CSS documentation, & what Help pages I could find) to figure out where I could make it larger & easier for my eyes but failed to find the correct discussion. Anyone know what parameter needs to be changed to increase the font size for this field? -- llywrch (talk) 18:31, 11 June 2018 (UTC)
I don't know why it changed for you but try this in your CSS to override whatever changed it:
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
In the Wikipedia app for Android or iOS users can create reading lists. The reading lists can be seen on different devices if you are logged in to your account. There is now a browser extension so you can add pages to your reading list from a web browser. At the moment it works with Firefox and Chrome. [9]
There is a new version of Pywikibot. Pywikibot is a tool to automate tasks on MediaWiki wikis. [10]
Problems
The MonoBook skin was changed to make it work better for mobile users. This caused some problems. The change was rolled back to fix them. The new version is now back on the wikis. MonoBook users can opt out from the new responsive design. [11]
Changes later this week
The new filters for edit review tools and interface for watchlists will leave beta. For most wikis this will happen on 18 June. For the rest it will happen on 25 June. [12][13]
The new version of MediaWiki will be on test wikis and MediaWiki.org from 12 June. It will be on non-Wikipedia wikis and some Wikipedias from 13 June. It will be on all wikis from 14 June (calendar).
Meetings
You can join the Readers Web team IRC office hour. There you can discuss tools to contribute on the mobile web for the existing MediaWiki skins. The meeting will be on 18 June at 16:00 (UTC). See how to join.
You can join the next meeting with the Editing team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on 12 June at 18:30 (UTC). See how to join.
You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 13 June at 15:00 (UTC). See how to join.
Tracking categories show as having subcategories, but I don't see them
I am seeing five of the tracking categories on the Category:CS1 errors page as having subcategories in their short listings, but when I click the triangle to fold down the category list, I see "nothing found". When I open the category page, I do not see any subcategories. This has been happening for at least a few weeks now; I was hoping it would resolve itself. I have tried purging both pages, to no avail.
These categories have sometimes contained categories in the past, but it has always been because someone added a citation to a category page, and that citation had an error in it. Those categories were always visible on the category's page, in a list separate from the lists for pages and files.
Please help translate to other languages.
Hi everyone. The Readers web team has recently begun working on exposing issue templates on the mobile website. Currently, details about issues with page content are generally hidden on the mobile website. This leaves readers unaware of the reliability of the pages they are reading. The goal of this project is to improve awareness of particular issues within an article on the mobile web. We will do this by changing the visual styling of page issues.
The new treatment increases awareness of page issues among participants. This is true particularly when they are in a more evaluative/critical mode.
Page issues make sense to readers and they understand how they work
Readers care about page issues and consider them important
Readers had overwhelmingly positive sentiments towards Wikipedia associated with learning about page issues
Our next step would be to start implementing these changes. We wanted to reach out to you for any concerns, thoughts, and suggestions you might have before beginning development. Please visit the project page where we have more information and mockups of how this may look. Please leave feedback on the talk page.
Because of maintenance work, English Wikipedia will be read-only for up to 30 minutes on 18 July (that is in a little bit over a month, not in a few days). Everyone will be able to read it, but you can’t edit. This is just to give you an early warning.
The template {{San Pablo City}} is transcluded on 17 articles. When I search for hlist, nine of those articles show up in the search results with the template source exposed, even though it does not show on the actual article pages. Can someone who understands templates figure out what is going on? Is there another element on those nine pages but not on the other eight that makes this happen? It’s been like this for days, so it’s not just a lag problem in the search.NotARabbit (talk) 04:56, 15 June 2018 (UTC)
Any and all help evaluating and tagging these potential misspellings is welcome. Once these redirects are appropriately identified and categorized, other database reports such as Linked misspellings (configuration) can then highlight instances where we are currently linking to these misspellings, so that the misspellings can be fixed.
This report has some false positives and the list of misspelling pairs needs a lot of expansion. If you have additional pairs that we should be scanning for or you have other feedback about this report, that is also welcome. --MZMcBride (talk) 03:35, 15 June 2018 (UTC)
Currently the report is updated manually. It could be automated in the future. The tracking strategy is basically the use of the "R from" templates and their associated categories. For example, once a page is marked as a misspelling and gets categorized in Category:Redirects from misspellings, it will no longer appear in future versions of the report. --MZMcBride (talk) 14:59, 15 June 2018 (UTC)
Cannot remove unread status for "The page Continue? has been reviewed"
At the top right corner of the page, when I click on "The page Continue? has been reviewed", it will not remove the "unread status". --Jax 0677 (talk) 11:36, 9 June 2018 (UTC)
Wikipedia:WikiProject Cornwall no longer displays properly. The Noticeboard section in particular. One can no longer edit the different boards (articles needing attention, new articles, etc), and they overlap and straggle on down the page. Can anyone see what has caused this and help to fix it please? DuncanHill (talk) 13:16, 13 June 2018 (UTC)
Not sure. I know the page was displaying correctly in May, when I last updated the "New Articles" box. Could the degradation be in some way related to the changes to Portals that happened recently? DuncanHill (talk) 13:37, 13 June 2018 (UTC)
Thanks, that's fixed the overlaps and straggling, but one still cannot edit the noticeboards, and there are no edit links for any of the sections. DuncanHill (talk) 13:47, 13 June 2018 (UTC)
Thanks all for the quick responses and action :) Not sure about the lack of section edit links, but still a great improvement. DuncanHill (talk) 14:10, 13 June 2018 (UTC)
At the time I deleted it, it had had no content (blank page) for a while, and was on a long list of unused portal subpages for deletion. There were probably no direct links to it, but we have found that some templates and modules are calling subpages of pages where they are transcluded, which can be relatively tricky to track down. If this happens again, please report on the WikiProject:Portals talk page, as there are a few of us who now know how to deal with this problem.
DuncanHill, I don't think the members of Wikipedia:WikiProject Portals were expecting portal boxes to be transcluded into WikiProject pages, though as far as I am concerned it is a reasonable thing to do. If you are maintaining Portal:Cornwall as part of WikiProject Cormwall, please let the portal project know how you prefer to manage it, so we can try to avoid any further problems. Cheers, · · · Peter (Southwood)(talk): 15:12, 13 June 2018 (UTC)
The new articles, articles needing attention, etc, boxes are Wikiproject material that the portal uses, not portal boxes that the wikiproject uses. I also had to fix a link here where a redirect was deleted without incoming links being corrected. DuncanHill (talk) 15:22, 13 June 2018 (UTC)
DuncanHill, Fair enough, they are conceptually project pages which use portal components, which is probably why people were not expecting this kind of side-effect. I cannot speak with certainty for the people who listed the portal subpage for deletion, but I would not have guessed that it was transcluded into a project page through a series of about two templates and a Lua module. It happened, and the important thing is whether it has been fixed. We will try to look out for similar side effects, but often the only way to find them is when they happen. Cheers, · · · Peter (Southwood)(talk): 03:24, 14 June 2018 (UTC)
Underlines not being removed when linking to an anchor using built-in feature
Not really an actual problem, but just trying to figure out why. Internal links look like this: [[User talk:Amaury#Discussion Archives|My Archives]] However, if I use the built-in link feature to make that a link semi-automatically, the underlines aren't removed for some reason: [[User_talk:Amaury#Discussion_Archives|My Archives]]. Why are the underlines not being removed? Here's a quick step-by-step. [16] and [17]. Clicking Internal Link does not remove the underlines. Amaury (talk | contribs) 01:06, 16 June 2018 (UTC)
The images are from a feature on the chain icon in the default toolbar. I never use it but the url to page name conversion seems very limited. It cannot handle percent encoded url's like https://wiki.riteme.site/wiki/T%C3%A9a_Leoni for Téa Leoni. I guess the feature was created to make either external links, or wikilinks where the user enters the page name. The conversion option looks like an afterthought with primitive implementation which just removes https://wiki.riteme.site/wiki/. PrimeHunter (talk) 09:58, 16 June 2018 (UTC)
Tool for mass redirects?
Based on Wikipedia:Articles for deletion/WNG560, I want to redirect a couple hundred articles to NOAA Weather Radio. I did the first batch by opening a bunch of browser tabs and having a copy-pasting. That got old fast. I could write something that goes through the API to automate this, but that's almost more effort than it's worth (and would probably require bot approval). Is there some existing tool to automate the rest of these? -- RoySmith(talk)22:02, 16 June 2018 (UTC)
On my WinPho 8.1 (I know, there aren't many of us left, and it's Internet Explorer): I have experienced two new degradations in the past 2+ days, when going to en.m.wikipedia.org:
It keeps forgetting that I am logged in. Each time I go to the front page, it's logged out again. By contrast with en.m.wikipedia.org on a PC, the "keep me logged in" checkbox isn't displayed.
After I do log in, the hamburger menu greets me by name, but the Nearby and Watchlist buttons are missing. I'd really like the Watchlist back.
Hi David. I don't think you're alone, I'm experiencing similar problems on my Windows Phone too. I have a Lumia 535 running Win10, and I can't get it to work properly on anything using Mediawiki. I've not specifically tried it in Wikipedia, but I suspect it's not limited to WP. Dane|Geld00:44, 10 June 2018 (UTC)
@DaneGeld:@DuncanHill: No, as I'm using the Vector skin. Here are the screenshots: phone first, then desktop (on Edge, but Internet Explorer works properly on desktop too). As you can see, the URL is en.m.wikipedia.org. A couple of days ago these menus had the same content.
Problem #1 seems to suggest that at the same time, a couple of days ago, the logged-in cookie started to be created non-persistent (has no expiration date specified) on the phone, and automatically goes away when the browser tab closes. But that's just the symptom; I can't debug cookies on this phone. David Brooks (talk) 03:00, 11 June 2018 (UTC)
ETA overnight- I guess that, although I don't use Monobook so assumed its mobile skin change was not related, the mere fact of tinkering with the mobile interface could have caused some collateral damage? David Brooks (talk) 12:45, 11 June 2018 (UTC)
@Jdlrobson:Mozilla/5.0 (Mobile; Windows Phone 8.1; Android 4.0; ARM; Trident/7.0; Touch; rv:11.0; IEMobile/11.0; NOKIA; 909) like iPhone OS 7_0_3 Mac OS X AppleWebKit/537 (KHTML, like Gecko) Mobile Safari/537. I never looked at that before; must be pretty confusing. Again, this is Windows Phone 8.1, which of course is no longer supported by MS. David Brooks (talk)
In this context, I should probably point out what I mentioned above: the "keep me logged in" checkbox is also now missing, which probably explains the cookie non-persistence. David Brooks (talk) 15:02, 12 June 2018 (UTC)
Right, so it looks like we dropped JS support for this browser so Nearby is not going to work thus hidden. I think we can restore the watchlist link and display a checkbox to allow you to keep logged in on mobile. We have tasks for both and will hopefully get those addressed soonish Jdlrobson (talk) 18:39, 12 June 2018 (UTC)
In case anyone else comes across this thread, I just discovered UC Browser (from Alibaba) which still works. Maybe I'm the last WinPho 8.1 user on the planet to know about it. Although it doesn't display the checkbox, it does persist login, and it does show the missing menu options. Each user will have to decide whether this is worth the reported privacy/security flaws. David Brooks (talk) 12:15, 17 June 2018 (UTC)
br after template
Using a template inside an article sometimes the next line goes to a new paragraph. It like there is a <br>. Any solution. Xaris333 (talk) 16:02, 16 June 2018 (UTC)
That is usually because the template has a newline at the end of the output. The solution is to remove the newline from the template, e.g. by starting a noinclude part on the same line as the last template output, but you didn't name any template so we cannot examine your situation. PrimeHunter (talk) 18:59, 16 June 2018 (UTC)
Is anyone aware if there has been a Phabricator ticket yet to address the issue of the UI for inserting an edit summary when rejecting pending changes does not yet allow reviewers to make use of the new maximum character limit for edit summaries? For reviewers reverting just one edit or those of us with rollback rights, there are workarounds to this, but for the average reviewer trying to disentangle multiple vandalism edits or mixed constructive and non-constructive edits, this is a challenge, as the edit summary is the best way to unpack these details in a way which novice editors trying to make changes are most likely see. Indeed, I was more excited for the increased edit summary cap in the context of pending changes reviews than any other single area of maintenance--until I realized the UI was not yet on the same page. Indeed, I think the pending changes process needs an overhaul from top to bottom, but this would a be a good start. I attempted a search in the Fabricator archives, but I go there so infrequently, I am not sure I am using the search functions exhaustively. Has anyone seen this come up anywhere in recent months? Snowlet's rap22:39, 16 June 2018 (UTC)
Hi @Home Lander: thanks much for the response and for the head's up about Twinkle; I'll add that to the toolbox of workarounds! To be honest, I've already figured out a few means of sidestepping the limitations of the UI in most circumstances, but I still think a request into Phabricator to cure the UI limitations would be useful, if there is no previous ticket; aside from streamlining the process, there's an argument to be made for this on the basis that some novice reviewers who do not use Twinkle may be unaware that there is any workaround. And as I say, PC reviews often require more complicated edit summaries than just about any other quasi-administrative task. Snowlet's rap02:41, 17 June 2018 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
The TemplateStyles extension will, in brief, allow custom CSS pages to be used to style content without an administrator having to edit sitewide CSS. This will make it more convenient for editors to style templates; for example, those templates for which the sitewide CSS for the mobile skin or another skin (e.g. Timeless) currently negatively affects the display of the template. The extension is already in use on some other Wikipedias, and should not open any avenues for vandalism which are not already possible with existing templates and inline styling. However, it cannot be implemented until HTML Tidy is replaced with RemexHtml, which is scheduled to happen for the English Wikipedia after June 2018.
Currently, TemplateStyles is being enabled for Wikipedias on a case-by-case basis, and if this RfC is successful then a Phabricator task will be made requesting the extension's deployment at the same time as RemexHtml.
Support - I can think of excellent use cases for this - making templates responsive with media queries is the first one that comes to mind. Richard061217:48, 18 May 2018 (UTC)
Support, because it will be much easier for any template editor (not that particular user right, but an editor of template) to request a custom styling for certain templates. I, too, can think of places where custom CSS will be very handy. epicgenius (talk) 21:19, 18 May 2018 (UTC)
So basically, this can't (at least straightforwardly) change say an existing string to a different string, but would rather apply things like font changes, width changes, and other CSS type of changes on a per-template basis? I think we still ought to have some restrictions on that (Evad37's restrictions/best practices below seem very reasonable) especially for accessibility reasons, but I don't why what that couldn't be rolled out now (i.e. support), with the understanding that people using this are careful/use WP:COMMONSENSE. Headbomb {t · c · p · b}11:43, 19 May 2018 (UTC)
Conditional support, if we get some sort of guidelines and/or best-practices in place first. Stuff like "only style the template's output", "avoid using !important", "use selectors and class names that are highly likely to be unique to that template (i.e. myTemplate-row rather than row)", "only images which don't require attribution can be used as background images". - Evad37[talk]02:01, 19 May 2018 (UTC)
Support I've been waiting a long time for this. This will allow us to fix a lot of templates for mobile, and also to reduce the size of the HTML we produce by getting rid of duplicated inline CSS. — Mr. Stradivarius♪ talk ♪07:38, 19 May 2018 (UTC)
Sure, seems useful. I'd worry about abuse and keeping track of it all — it seems like the potential for pages could be huge — and would definitely support some level of baseline protection status (probably AC default, elevate to TE if heavily used). Basically, if TheDJ and Stradivarius think it'd be good, it's probably good. ~ Amory(u • t • c)11:58, 19 May 2018 (UTC)
Support It looks like it would be useful. Guidance will be developed in the usual way. There may be occasional misuses but they will be reversible. I assume changes will show up on watchlists in the usual way? · · · Peter (Southwood)(talk): 08:29, 22 May 2018 (UTC)
Support Not having any useful way to code responsively (or even use CSS correctly) is a real pain, it's like trying to build a car with no wheels and the wrong chassis, and it makes everything on wikipedia look like it's from the early 2000's. Because it is. This would be so helpful. JLJ001 (talk) 17:19, 24 May 2018 (UTC)SOCKSTRIKE. Primefac (talk) 18:37, 31 May 2018 (UTC)
Support As long as we have guidelines in place to control how this is used. We don't want editors going wild with this. — AfroThundr(t•c)07:48, 27 May 2018 (UTC)
Conditional support, per Evad37. I was going to saying something like this myself (and I think I did in a previous round), but Evad37's got the gist of that minor issue. I fully support going forward with this feature implementation, it just can't be dumped on the community without pre-addressing the potential problem points. — SMcCandlish☏¢ 😼 04:24, 2 June 2018 (UTC)
Sounds scary - if I understand correctly, a template in one part of an article would be able to completely or partially mangle the display/styling of a different template in a completely different section of the page. And not just from vandalism, but also good-faith edits if they just happen to result in templates with conflicting rules, which might not be obvious at the time of editing. - Evad37[talk]15:41, 18 May 2018 (UTC)
Hmm, people who make use of it should I hope make sure their styling does not affect the rest of the page/other templates but only the target template. People who vandalize can perfectly well cover screen-fuls of page with image vandalism so not going to dramatically up the possibilities of vandalism Galobtter (pingó mió) 16:00, 18 May 2018 (UTC)
Correct, but if that becomes unmanageable, we could elevate edit permissions to templateeditor or something. the benefits will outweigh the negatives. Besides. postion:absolute bothers me on half the user pages and that seems perfectly acceptable to the community. —TheDJ (talk • contribs) 17:37, 18 May 2018 (UTC)
So for this custom CSS, which namespace would it be hosted in? Would users be restricted from editing these CSS pages (e.g. limiting these pages to administrators/template-editors only)? epicgenius (talk) 21:19, 18 May 2018 (UTC)
It would be in the Template: namespace, and protection could be applied as needed. High-exposure pages will inevitably be TE-protected. Richard061221:30, 18 May 2018 (UTC)
A usage guideline I'm thinking we should have if going forward is that styles should be easily able to be identified and edited by being associated with a specific template or group of templates. In general, this means it should be a subpage related to the such as: Template:xxxx/styleyyyy.css. Explicitly, for articles styles should never be configured to pull from the User: namespace. — xaosfluxTalk21:51, 19 May 2018 (UTC)
TemplateStyles CSS pages must have the sanitized-css (Sanitized CSS) content model, which is the default for subpages in the template namespace that end with .css (Template:Foo/bar.css). Only users with changecontentmodel (admins only here) can create them elsewhere. — JJMC89 (T·C) 23:02, 19 May 2018 (UTC)
To touch on some points above, by default any confirmed user would be able to create/edit these type of pages. If we want the default to be something else we can implement controls in a few ways. The title blacklist could be used limit creations to templateeditors similar to the way we do editnotices. We could also do various things with the edit filter. As mentioned in the above section, individual pages could always be dealt with via page protections. If moving forward, do we want to establish any technical controls here? — xaosfluxTalk21:47, 19 May 2018 (UTC)
Is there any reason not to restrict these like editnotices? I'm not sure what a usecase would be where it would be necessary to make these visible and frequently edited. ~ Amory(u • t • c)01:02, 20 May 2018 (UTC)
They should really have the same protection level as their parent template. Otherwise you just encourage styles to remain inline, or get inline styles added on top of the TemplateStyles CSS since the template was editable but not the css. Perhaps an adminbot could do the protections automatically? - Evad37[talk]03:32, 20 May 2018 (UTC)
If a template is unprotected, presumably its css page would also be unprotected. What would there be to prevent a rule being maliciously added to that css page? For example, one having a selector that is not specific to the template's code, but perhaps matches some other part of a page - maybe as broad as
It says "Styles included by a template can currently affect content on the page outside of the content generated by that template" which is what I am worried about. --Redrose64 🌹 (talk) 20:06, 20 May 2018 (UTC)
Oh that's true, absolutely. If there's (e.g.) a div on the page that the CSS selects, it'll be affected. But the styles couldn't affect the body or any other elements of the interface. Then again, if a vandal could edit the CSS to cause chaos, they could edit the template itself to cause chaos. Hence the logic that the CSS should have the same level of protection as its parent template. Richard061220:20, 20 May 2018 (UTC)
Hey! I'm the current product owner for TemplateStyles. I'm really glad that you're all excited about having TemplateStyles here on the English Wikipedia. The goal is to get TemplateStyles rolled out everywhere, and so far it's been rolled out to the German, Swedish, and Russian Wikipedias as a result of community requests, as well as some other sister projects, and it's working well on those wikis. As others have noted, TemplateStyles is dependent RemexHtml, which isn't being used on this wiki right now, so it can't be turned on here yet. I'll let you all know when RemexHtml is enabled here, so that TemplateStyles can be turned on. In the mean time, I suggest you all keep working on the guidelines, so that TemplateStyles can be turned on as soon after RemexHtml as possible. Thanks! --Deskana (WMF) (talk) 23:12, 16 June 2018 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I do not see any technical problems with this page. It has at least two links to disambiguation pages; those should be fixed. I added a References section with a {{reflist}} template. – Jonesey95 (talk) 14:19, 18 June 2018 (UTC)
Indenting ":" doesn't work to right of image: should it?
The reason I changed the indenting ":" to a bulleting "*" is that the indent didn't work for me. My paragraph appeared directly below the original question (to the right of the image, because I'm using a wide window) without indentation. I tried multiple colons up to ":::::" and there was still no indentation. After making the change I also tried adding another paragraph with "**" and this was formatted just like the "*" paragaph.
However, if I narrow the window so that the original text occupies more lines and comes down below the picture, then indentation in the later text works correctly. So clearly what's going on is that ":" doesn't indent (and "*" doesn't add indenting) in text that's to the right of an image.
Is this a bug or a documented feature?
(Please reply here, not to my current IP address's talk page.)
Left-floating images are often problematic. Indentation is measured from the left margin and not from the edge of the image. If there is enough indentation then it eventually leaves the image. Below are examples but don't try that. The result will vary between users. You can just make the image right-floating. That is default for |thumb so you don't have to write anything. PrimeHunter (talk) 22:41, 17 June 2018 (UTC)
[I'm guessing that this has already been reported, but I don't see it in the contents list, and I can't think what to search for].
I'm frequently finding when I edit a section (generally on WP:HD or WP:TH) after I complete and save, the URL still has "?action=edit" in it - i.e. it is not following normal practice and redirecting to a GET URL after completing.
I started noticing this a couple of weeks ago, when refreshing a page (F5) kept putting me into the editor unexpectedly; but I only remembered to look at the URL a few days ago. I have an example in another tab right now: I have just replied to a question at the Teahouse, and the edit has saved, but the URL in my browser address bar is https://wiki.riteme.site/wiki/Wikipedia:Teahouse?action=edit#Disputed_text
Dunno, Izno. Looking at my preferences, I have "Always give me the source editor" checked, and "New WikiText Mode" checked on the Beta Features tab. --ColinFine (talk) 23:14, 16 June 2018 (UTC)
Okay, you're using the 2017 wikitext editor. I see this behavior also in Firefox (have for a while) and it probably deserves a task in Phabricator. I don't see one there. I think we need figure out the exacts of when it happens still. --Izno (talk) 13:04, 17 June 2018 (UTC)
@Izno: I think what happens is the page "reloads" with JavaScript and then doesn't change the URL in the address bar. I haven't tested this with VisualEditor. Jc86035 (talk) 11:21, 18 June 2018 (UTC)
I'll just confirm that I also have this issue in Firefox with the 2017 editor. Haven't noticed it in Edge (at work) though. — AfroThundr (u · t · c)12:04, 18 June 2018 (UTC)
I take that back, Edge is doing the same thing. What's more, sometimes the post-edit URL isn't even the same page I was on; it changes the page URL to 'undefined' like so: https://wiki.riteme.site/wiki/undefined?action=edit. This would cause me to edit the page for Undefined if I refresh the page after editing. I've gotten used to clicking on the article or talk tab again to put the correct URL back in the bar. Has anyone opened a phabricator ticket for this yet? — AfroThundr (u · t · c)12:08, 18 June 2018 (UTC)
I've just been looking at the Pageviews analysis for yesterday and it appears that the bot went down and failed to capture the pageviews for articles. (example here). Are we able to look into this and retrieve the views for yesterday? The C of E God Save the Queen! (talk)07:08, 15 June 2018 (UTC)
In my experience the most recent data in that tool is often two days old. If you have no other indicator of missing data then data for yesterday will probably come tomorrow or later today. If you request the latest 10 days [18] then you currently get June 4 to June 13. PrimeHunter (talk) 09:20, 15 June 2018 (UTC)
Yes PrimeHunter is correct. My guess is if you check back tomorrow, the data will be there. I have no idea how this works (it happens in the Analytics cluster), but some articles may have data for today/yesterday, others not. I've briefly documented this at [19]— MusikAnimaltalk15:32, 15 June 2018 (UTC)
Is there likely to be a backfill process so that the 14th will show up relatively soon, or is it likely to be missing forever (or an extended time)? I have some automation that is blocked waiting for the data for the 14th at the moment, and want to know if I should just tell it the 14th is never coming and to skip it, or to just hang on a bit longer expecting it will show up within a few days at the latest... — Preceding unsigned comment added by Abulsme (talk • contribs) 16:46, 16 June 2018 (UTC)
(The C of E here). It's still not showing the stats for the day and I don't have much trust in the alternative view counters. Do we have an explanation for this and can the stats be retrieved? The Royal C (talk) 13:07, 17 June 2018 (UTC)
Looks like the backfill happened. At least my application is happy now and got caught up to the present. :-) Abulsme (talk) 18:13, 18 June 2018 (UTC)
Yup, everything should be there now. Rigorous caching on the pageviews API may mean the data is still missing for some, but it will show up eventually. In the meantime you should be able to change the date range, etc., and the data will show. — MusikAnimaltalk18:35, 18 June 2018 (UTC)
With the New Filters for Edit Review feature enabled, there's now not enough space above announcements on the watchlist page when using the Vector skin. Here's a screenshot of the old (top) and new (bottom) designs – since the view/edit/clear links got moved in the new design, the annoucement is too close to the page title. (I'm using Chrome 68, in case that's relevant.)
Hopefully this is the right place to report things like this? I mentioned it on the feature's talk page on MW, and got asked to report it on enwiki. An Owl Called Josh 🦉 (talk) 14:22, 18 June 2018 (UTC)
Done with Special:Diff/846412391. I used padding instead of margin, because it would otherwise overlap with the margin of .firstHeading. Merely a minor nitpick =p I assume all wikis have the same issue, so maybe this CSS change should be added to core or wherever the code for the new review filters lives? — MusikAnimaltalk16:34, 18 June 2018 (UTC)
When looking at an article with unreviewed pending changes (for example: List of video game developers), the message on top says:
The latest accepted revision was accepted on 9 June 2018. There are template/file revisions awaiting review.
The "template/file revisions" part doesn't fit for an article. Not really a big issue, but the message text should be fixed/tweaked. I am a pending changes reviewer using Vector skin, and have clicked a "Pending changes" tab on top of the article to see the above message. If i remember correctly, the message was different a few days ago and probably has changed recently. GermanJoe (talk) 21:05, 15 June 2018 (UTC)
Agree. "Changes" would be slightly clearer in this context, when the message is supposed to refer to template and file changes within an article. Thank you for looking into this. GermanJoe (talk) 10:17, 16 June 2018 (UTC)
Why can't the time in the footer identify the time zone?
I'm not sure what controls the standard footer text at the bottom of articles and pages such as this one. At the moment it reads:
This page was last edited on 12 June 2018, at 20:58.
A reader wrote to Wikimedia to ask which time zone is associated with the time. While veteran editors, especially those who have customized their preferences to select a time zone will know the answer (UTC, unless you specify a different one) why couldn't we include the time zone in the standard message. It doesn't seem to be a space issue, and most of our readers are unlikely to know that UTC is the default.
What's the harm in changing it to read:
This page was last edited on 12 June 2018, at 20:58 UTC.
or
This page was last edited on 12 June 2018, at 20:58 (UTC).
--S Philbrick(Talk) 21:46, 12 June 2018 (UTC
Putting UTC in parenthesis would be preferable to not doing so, in order to be consistent with the format used in discussion timestamps. --Redrose64 🌹 (talk) 22:48, 12 June 2018 (UTC)
I've just found that for a few weeks in 2009, we did indeed emit a hardcoded " (UTC)" that was appended to the passed-in time. Admins might like to look at this. --Redrose64 🌹 (talk) 22:52, 12 June 2018 (UTC)
As I suspected, it is moderately complicated. But following up on Primehunter's suggestion, oen can argue that if you affirmatively chose a time zone, you know which one you chose, and if you didn't, you can, so showing (UTC) to unregistered users would always be accurate, and would clarify the time zone for the readers most likely not to know the answer.--S Philbrick(Talk)00:05, 13 June 2018 (UTC)
The suggested solution would send <span class="anonymous-show"> UTC</span> to everybody and rely on the browser to hide "UTC" for registered users. If CSS for anonymous-show fails to load from MediaWiki:Group-user.css then registered users will also see "UTC". Pages are occasionally displayed with no or broken CSS but I guess this willl be rare and it's not a serious problem if a few users see "UTC" on a non-UTC time on a page which may look broken. PrimeHunter (talk) 09:55, 15 June 2018 (UTC)
I support that. 12:00<span class="anonymous-show"> (UTC)</span>. produces "12:00 (UTC)." which renders as "12:00 ." with a space for me in Firefox (not caused by the added parentheses). We could say 12:00<span class="anonymous-show"> (UTC)</span>. instead. This produces "12:00 (UTC)." which renders as "12:00." for me with no space. PrimeHunter (talk) 10:47, 15 June 2018 (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
Syntax highlighting has been a beta feature on Wikimedia wikis with text written from left to right. It is now a normal feature. It is based on CodeMirror. [24]
Changes later this week
There is no new MediaWiki version this week.
Meetings
You can join the next meeting with the Editing team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on 19 June at 18:30 (UTC). See how to join.
You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 20 June at 15:00 (UTC). See how to join.
Future changes
Some old web browsers will not be able to read the Wikimedia wikis. This is because they use an insecure way to connect to them. This means that we get less security for everyone else too. This affects about 0.08% of all traffic to the Wikimedia wikis. This affects for example those who read Wikipedia on a PlayStation 3. [25][26]
The new filters for edit review tools and interface for watchlists will leave beta. Because there is no new MediaWiki version this week it will happen on 25 June for most wikis. For the rest it will happen in early July. [27][28]
Looks backward to me. Arrow pointing away from the text should mean removal, pointing toward the text should indicate insertion. After a couple of weeks of trying to comprehend the rationale, it still seems counter-intuitive. ―Mandruss☎22:47, 18 June 2018 (UTC)
Problem with Cyberbot I
There is an issue with the Cyberbot I(BRFA·contribs·actions log·block log·flag log·user rights) task which creates and populates Template:Adminstats subpages for administrators and account creators. It's creating and re-creating adminstats subpages for users who are neither administrators nor account creators and which have been deleted multiple times after discussions at TfD, and also seems to be creating and re-creating adminstats subpages for certain users who have not requested the bot to run. I've already posted on Cyberpower678's talk page, but if anyone more active in bot coding would like to take a look or weigh in, please see the discussion. Thanks. Ivanvector (Talk/Edits) 12:32, 19 June 2018 (UTC)
Thing to help add incoming links to an article
I seem to remember using some kind of tool that helped to add incoming links to an article. You fed in the article name, it pulled up articles with corresponding text, and added the links very quickly. Can't for the life of me remember what it was called, can anyone point me in the right direction please? DuncanHill (talk) 21:48, 18 June 2018 (UTC)
I have a Google search box which I use. The tool I remember was a bit like Find Link, but Find Link doesn't actually open up the edit box and insert the link ready for you to click Publish, which the tool I remember did. DuncanHill (talk) 11:16, 19 June 2018 (UTC)
Since the main coder for WP:CS1 templates (Trappist the monk (talk)) is unresponsive, it would be great to have Lua coders to help with long-standing requests
One thing which could help to improve article readability is a gadget that would highlight an article's longest sentence and the one with the most punctuation marks. By this simple expedient we could draw editors' attention to where it is most needed. Would anyone be interested in crafting such a tool? Pretty please? LeadSongDogcome howl!17:12, 19 June 2018 (UTC)
Is there a way to make a uw template automatically show different text for anonymous vs registered users, or based on a user's permissions? Specifically, the text at {{uw-incompleteAFD}} has a section about unregistered users, but I most commonly use it for registered users. ansh66606:51, 19 June 2018 (UTC)
Wrap it in spans with class .anonymous-show or .user-show. For example, this sentence is only shown to registered users.For example, this sentence is only shown to unregistered users. There's similar classes for most user groups; look for .sysop-show in MediaWiki:Common.css. —Cryptic07:17, 19 June 2018 (UTC)
In this case, wouldn't it be easier to check if the user whose talk page the template is being placed on is an IP or not and subst accordingly? {{3x|p}}ery (talk) 16:05, 19 June 2018 (UTC)
Yes, but I'm lazy (and it's probably better to just have one template for everyone anyways). Thanks, I'll look into it. ansh66620:19, 19 June 2018 (UTC)
@Ansh666: Note that if you're substing the template (which you really should for anything going on a user talk page), the CSS "hidden" text will still show up in the wikitext editor. A better way would be {{{{{|safesubst:}}}#if:{{IsIPAddress|{{ROOTPAGENAME}}}}|Text for unregistered|Text for registered}} --Ahecht (TALK PAGE) 22:38, 19 June 2018 (UTC)
Apart from the user interface and omitting some things in the mobile version, we should very rarely show different text to different users. It causes confusion when they edit or discuss the same page, and registered users should be able to see what an IP was told in a warning. Testing the type of user page to display specific content to all readers of the page is fine. PrimeHunter (talk) 22:51, 19 June 2018 (UTC)
Just some time ago I experienced difficulties saving an edit to Wikipedia:Articles for deletion/Vandana Singh (actress) on the Minivera skin... At first the screen just redirected me back to the save form...after scrolling downwards a poorly rendered (It overlapped with my signature) black error message stating something in the effect of "Error:Your edit could not be saved." appeared. After further investigation (in the process of which I lost the source of the edit) I discovered that I had accidentally included a Accelerated_Mobile_Pages link instead of a link to the actual site. This had caused the mw:Extension:SpamBlacklist to blocked it. Can the aforementioned extension's error messages be made compatible with MiniverNeue?— Preceding unsigned comment added by FR30799386 (talk • contribs) 10:26, 20 June 2018 (UTC)
I am I am experimenting with using programming way to find cross-language fact conflicts in large scale. Here is a small sample of data I was able to produce for now. I like to ask for some early feedback. Do you think these data would be useful, if yes, can you think of any usecase? If not, what other information can I include to make it more useful?
Please leave comments here.
For now I plan to produce EN v FR, EN v DE. I post related data to the related Wikipedias too.
Hi @Dodger67, Thanks for your encouragement. On a high-level, the steps are: (1) extract facts from a Wikipedia Article. (2) compare the information that should have a unique value (e.g. a personal can only be born once) across languages. (3)turn this comparison into a Map-Reduce-like large scale pipeline. (4) filter the conflicting data with constraints. Not all technologies I used are open-sourced yet, so I still need sometime to get the code to a status of release-able. Other comments, thoughts? I wonder if people will also think it helpful to fix facts on Wikipedia, too? Xinbenlv (talk) 23:31, 15 June 2018 (UTC)
Xinbenlv, have you asked over at d:Wikidata:Project chat? I think this would be very useful to Wikidata editors (probably much more than Wikipedia editors), as information is routinely imported from smaller projects like the Russian Wikipedia, which might not have data as good as the English Wikipedia's. There are also probably more editors who are used to querying databases, and there are some tools (with a GUI) which I think can import entire infoboxes from groups of articles. Jc86035 (talk) 09:05, 17 June 2018 (UTC)
@Xinbenlv: Great idea. The first thing to do imho, is to find a stable home for this. VPT is a fast-moving page and this discussion will either get archived and lost, or get too big to live here. In any case, may I suggest finding a new home for it, and moving this discussion there? Ideally for starters, your data, examples and technical material could live on a new Project page, with this discussion moved to the Talk page associated with it. I can offer some suggestions if you like. Mathglot (talk) 03:21, 19 June 2018 (UTC)
Uploading problem
I'm having trouble getting an image to upload to en.wiki - I keep getting a 400 Bad Request error. Anybody know if there's a server problem or something? Parsecboy (talk) 10:17, 21 June 2018 (UTC)
At the top, between the links to my user and user talk pages, there are the "bell" and "TV set" icons. The latter has the figure "2" superimposed, implying that I have two unread thanks notifications, but when I click it, I get "There are no notifications." Not even a list of old thanks, which is what I got before today. Clicking the bell icon lists all the old mentions, reverts etc. Is something broken in the thanks system? Oh, it's Thursday - of course it's broken. How silly of me. --Redrose64 🌹 (talk) 20:12, 14 June 2018 (UTC)
Something is broken: I click on mine and get the "Our servers are currently under maintenance or experiencing a technical problem." page "PHP fatal error: Class undefined: PageTriageMarkAsReviewedPresentationModel" --Masem (t) 20:16, 14 June 2018 (UTC)
Mine is not working either, the bubble shows up with the number of notifications but when I click on it it says there are none. Home Lander (talk) 20:22, 14 June 2018 (UTC)
And I get credit for explaining, for the benefit of those who have never seen a typewriter or a rotary telephone, that it's not a TV set but rather an inbox. BTW if someone can explain why some things ring the bell and some go in the inbox, it would take one small load off my tiny, tiny brain. EEng13:54, 20 June 2018 (UTC)
I have been told (when I have complained that the things were in the wrong list) that the difference is urgent vs non-urgent. I have never found out why good news (e.g., Thanks) is not considered an urgent matter. Whatamidoing (WMF) (talk) 15:05, 21 June 2018 (UTC)
The Watchlist option (period to display, hide various types of user, minor edits, etc) have disappeared from my watchlist on my desktop. They are still there on my phone. Monobook on both, Edge on Win10 on the desktop, Chrome on Android and desktop view on the phone. DuncanHill (talk) 11:20, 21 June 2018 (UTC)
This is somewhere in the realm of "nope" and "never" because of how talk pages work. Might be something to add to WP:PERENNIAL at this point. --Izno (talk) 18:17, 15 June 2018 (UTC)
Oh dear dear, that might not be too complex. Developers/Software engineers have only to add some special icons for additional functions, and, in mobile version there is already a kind of GUI interface with a textbox. May I know who are the developers of wikipedia and how it works and how can I contact them for this? :) Thanks. Shevonsilva (talk) 20:44, 15 June 2018 (UTC)
No, it is definitely too complex. If you are sincerely interested in submitting a task, which is 100% likely to be declined, contact information can be found at Help:Bug reports. --Izno (talk) 21:05, 15 June 2018 (UTC)
Thanks for the link. Why do you think it is complex? :) We have to allocate new functions to new toolbar bottons and can directly use the existing API through inheritance and polymorphism. This cannot be a big task as I believe. Shevonsilva (talk) 06:35, 16 June 2018 (UTC)
The phab linked here helpfully quotes/links mw:Help:VisualEditor/FAQ, which, near the bottom, answers your questions. In short, The visual editor is designed to edit content, plain pages of text and Talk pages aren't content. ~ Amory(u • t • c)00:42, 16 June 2018 (UTC)
Thanks, yes, as we have similar text content (in talk pages and discussions) with additional functionalites, we can simply extend the interface for other text contents as simply we can re-use the API and add new functionalities for this. :) Shevonsilva (talk) 06:35, 16 June 2018 (UTC)
If you think that it's simple, then you try to do it; and on no account may you break existing functionality (broadly construed). It will also be your responsibility to explain why you have done this against consensus. --Redrose64 🌹 (talk) 09:01, 16 June 2018 (UTC)
@Shevonsilva: I'm definitely of the opinion that the current setup of talk pages is not very good, and I think it's great that you want to help with that! The problem is, talk and discussion pages have a large array of disparate functions, and designing a solution for all of them simultaneously is very hard. The visual editor is designed to edit content pages, and modifying it so that it serves the two totally different needs will end up meaning it serves neither of the functions well. To be totally honest, I think your efforts would be better focused in a different space; if you're interested in MediaWiki development, then more help is always welcome, and I can absolutely point you to places where you could help out. --Deskana (WMF) (talk) 23:00, 16 June 2018 (UTC)
Hello. I am most active in Greek Wikipedia and in Wikidata. Recently, I have added all population history for municipalities and communities for Limassol District in Wikidata. Through a template w:el:Πρότυπο:Πληθυσμός απογραφών Κύπρου, all the data of a place is showing in Greek Wikipedia article of the place, with all the sources. For example, w:el:Πελένδρι#Πληθυσμός. Noticed, that most of the sources are in English and if some of them are in Greek, in Wikidata I have added also the translated titles etc. The problem is that I want to add these informations to English Wikipedia article with the same way, with the template. It's more easier and effective, than try to write them by hand. The problem is that Module:Wikidata and Template:Wikidata are different in each Wikipedia and I need help to create the template W:el:Πρότυπο:Πληθυσμός απογραφών Κύπρου to English Wikipedia. Xaris333 (talk) 13:07, 19 June 2018 (UTC)
No, I am not telling that. I need help to create my template to English Wikipedia according to Wikidata templates of English Wikipedia. Xaris333 (talk) 16:07, 19 June 2018 (UTC)
I'm trying to figure out how to override my preferences and load different editing toolbars (enhanced in main, old elsewhere, and code editor if page ends in .js or .css). I thought mw.user.options.set would work, but I seem to be calling it too late to make a difference. The options API directly changes the preferences (so requires an API call on every page and a page reload) so what I'd really like to do is directly load the enhanced or old toolbar directly in userjs, but how? ~ Amory(u • t • c)14:43, 20 June 2018 (UTC)
If "old" means the 2006 wikitext editor (see mw:Editor to figure it out), then it's probably going to be removed from the servers later this year (a long-stalled project that supposedly is back on track now).
That said, I believe that the French Wikipedia has an 2006-like toolbar that is entirely handled in user Javascript (a gadget), so perhaps what you need is enhanced in main, and "nothing" (2003) elsewhere, except to then replace nothing with a user script that happens to duplicate the 2006 toolbar. Whatamidoing (WMF) (talk) 15:31, 21 June 2018 (UTC)
@Whatamidoing (WMF): Thanks, that's it in a nutshell I suppose. I'll be sad to see my old friend go, but being the change-averse community we know it is, I expect I'll find it in a gadget soon after. If I opt for "nothing" in my preferences, is there a way to load the enhanced editor via javascript? I suppose the alternative is to actually opt for the enhanced toolbar in the preferences and do $('#wikiEditor-ui-toolbar').hide() everywhere but main and js pages, but that'd be more inefficient and adds a noticeable lag to loading the edit screen. ~ Amory(u • t • c)19:31, 21 June 2018 (UTC)
I understand that the teams affected would have no objection to the 2006 toolbar being re-created as a gadget (whether now or later). I understand their problem is strictly about whether the dozen-year-old code remains officially supported as part of MediaWiki. If volunteers choose to keep it alive as a gadget for another dozen years, that's no skin off the devs' backs. I wouldn't be surprised if some of them chose to use such a gadget themselves.
Didn't mean to suggest they shouldn't! Just some poking fun at myself and our editor colleagues. ~ Amory(u • t • c)20:10, 21 June 2018 (UTC)
Syntax highlighting will no longer turn off / Forced into 2017 Editor
I just hit the edit button and my editor has gone nuts. There is syntax highlighting; Headers now have increased font size etc. Essentially my 2010 editor has been forced to the 2017 editor even though I have not enabled it. This screws up my entire work flow and prevents me from using my browser based snippet program. I have looked through Preferences to find a way to turn it off but have found nothing. Is there a way to get the old, simple wikitext editor back? The new features are neat but neat is only good if it does not break stuff. Jbh Talk23:57, 13 June 2018 (UTC)
@Jbhunley: There should be a pencil icon in your editing toolbar, last button before the "Advanced" menu. This will toggle syntax highlighting. Does that work for you? — MusikAnimaltalk00:01, 14 June 2018 (UTC)
(edit conflict)}Yes! I do not know whether to feel relieved or stupid. Thank you! I was fearing I would have to go back to writing WikiText by hand… I assumed it was the 2017 editor since the highlighting scheme looked like the one I saw in the 2017 editor rather than what I remembered the 2010 highlighting to look like ie actually changing the font size and face rather than just different colors. The 2017 version was not toggled in Beta so I thought a new default setting had been pushed out. I was, in fact, still in the 2010 editor. Jbh Talk00:12, 14 June 2018 (UTC)
Not just you — that pencil thing is new, when did that get added? Nice feature, but wish it wasn't on by default. Was editing a .js page so couldn't turn it off. ~ Amory(u • t • c)01:13, 14 June 2018 (UTC)
It is has been available as a beta feature for a while, and today it was graduated out of beta. However it definitely shouldn't have turned itself on. I logged into a few alternate test accounts, where I had never used syntax highlighting, and it was not turned on. So not everyone is affected, it seems. At any rate, you can turn it off, and if you do so it should stay that way. Note the JavaScript/CSS syntax highlighting is a different feature that has been around for quite some time. You can also turn that off, though -- click on the "<>" button at the far left of the editing toolbar. — MusikAnimaltalk03:00, 14 June 2018 (UTC)
The pencil has been there all along? Didn't notice it. And perhaps it was a "if you've ever turned it on" thing? At any rate, it colors nowiki on js pages, that's how I saw it. As a public service announcement, if anyone uses User:ערן/autocomplete.js, it breaks on this. ~ Amory(u • t • c)10:31, 14 June 2018 (UTC)
Regarding autocomplete, I may try to adapt it to syntax highlight once phab:T170001 is fixed - but I prefer to not invest time on fixing it as the infrastructure may rewritten (with or without CodeMirror) to properly support all languages. Eran (talk) 17:53, 14 June 2018 (UTC)
And of course the pencil icon isn't there at all if the toolbar is turned off in Preferences, Editing.
If I was inclined to give the syntax highlighting a try, is there a documented way of configuring it?
No, the pencil icon hasn't been there all along. It has been if you had "syntax highlighting" turned on in your beta preferences. Now it is out of beta so everyone gets the pencil. @Amorymeltzer: When you edit a JS page, like User:Amorymeltzer/dashes.js, you see the new syntax highlighting? It has occurred to me that to have the (preexisting) JS/CSS editor, you need "Enable enhanced editing toolbar" turned on in your preferences. I'm guessing you do not. Indeed JS pages don't seem to work well with the new syntax highlighting, because it's not wikitext. I think we can disable this feature on JS/CSS/JSON pages, if you think that's a good idea? (by the way, I definitely recommend the "enhanced editing toolbar" when editing JS!!).
@Mitch Ames: Indeed there is no pencil icon if the toolbar is turned off (because there's nowhere to put it). We could use a link in the sidebar, maybe, but the old toolbar-less editor is going to be phased out anyway, as I understand. — MusikAnimaltalk15:55, 14 June 2018 (UTC)
"That pencil icon" has been in the corner of the toolbar for several years, and it switches you to the visual editor. "That highlighter pen icon" just arrived, and it toggles syntax highlighting. It appears that the complaints that the highlighter marker looks too much like the editing pencil are being collected at phab:T174145. Whatamidoing (WMF) (talk) 16:30, 14 June 2018 (UTC)
You are right, thanks for clarifying. I didn't even notice the pencil on the right! I assume we were all talking about the highlighter, though, which indeed looks an awful lot like a pencil. — MusikAnimaltalk17:21, 14 June 2018 (UTC)
@MusikAnimal and Whatamidoing (WMF): Yes, indeed, the highlighter. I use the old toolbar, as I only really use it for citation stuff anyway (hence, I only see one "pencil" since visual editor isn't an option) and the highlighter button shows up there. It's not a huge deal, but regardless of toolbar used, this new highlighter button doesn't show up in user js pages. That's good, but when using the old toolbar, js pages mirror the last used highlighting state, and you can't turn it off there since there's no button (or toolbar); you have to go to another page, click edit, turn it off, then reload your js page. With the enhanced toolbar, this isn't an issue. I can file a phab, since that's almost certainly not expected behavior. MediaWiki js pages also show the highlighting, but they also show the old toolbar, so it's reparable. Also, holy shit, thank you, enhanced toolbar for js is amazing! ~ Amory(u • t • c)17:41, 14 June 2018 (UTC)
I personally feel it shouldn't have been graduated from beta just yet. There are still some serious performance issues that I am noticing, especially when I'm on my phone. The syntax highlighter, especially on larger bodies of wikitext, take up to 2 seconds to process sometimes and in doing so blocks key inputs to the text area. If you type regularly, the key inputs queue up and so you sit there waiting for the syntax highlighter to re-process every key stroke. This is even more noticeable on my phone, and as a result auto-correct really messes up my text in those instances. I would like to see the syntax highlighter implement a waiting period before processing. Say like 1.5 seconds after the last keystroke, it should process what's in the textarea, and go to sleep while the user is actively typing. Development IDEs do this already.—CYBERPOWER(Around)12:40, 14 June 2018 (UTC)
Concur. I regularly use charinsert for wiki markup, most often to create <code><nowiki></nowiki></code>, two clicks which should leave the cursor inside the <nowiki></nowiki>. But, with the highlighter enabled, the cursor is always moved to the start of the line. The new functionality should not break the old tried and true.
I think that is what breaks ProKeys as well. It can not find the current cursor position when the macro proscessing is invoked so it can not tell if the preceding text has a snippet associated with it or where to insert the text if there is one. A brief delay before processing might fix that. It would be nice to be able to use syntax highlighting. The new version is quite nice. Jbh Talk15:20, 14 June 2018 (UTC)
@Cyberpower678: I'm not sure what IDE you're referring to, but I assume one that is not within the browser? The syntax highlighting uses a JavaScript library called CodeMirror. This is the same library that GitHub's editor uses, for instance, and also the web inspector that comes with Chrome. The nature of the implementation means very large bodies of content, or a slower devices (like some smartphones), will have a noticeable performance impact. Despite these issues, the time had come that we at least let people decide if they want to use it, and switch it on/off as desired.
@MusikAnimal: When I referred to an IDE, I meant any IDE in general such as PyCharm or PhpStorm. When you make modifications to large chunks of code there, it will generally wait until you have finished typing before processing the text and update the highlighting. What I'm asking for is that this JS do the same. As it stands right now it updates after every keystroke and that produces a major slowdown as the text gets larger, even on a computer. It should be possible to insert a sleep timer that gets reset on every key stroke, and when the timer elapses it updates the highlighting. That would add a major performance improvement, not to mention reduce CPU usage as I am currently observing mine spike to 20% as I type in this window.—CYBERPOWER(Chat)17:00, 14 June 2018 (UTC)
I don't know, all of that logic is part of the CodeMirror library. In general we haven't had to many complaints about performance, except on large pages. Your IDE is compiled to assembly and runs directly on your operating system. It will always be faster than your browser (certainly your phone!), which has to interpret the JavaScript. I've actually never used an IDE that doesn't highlight on every keystroke, but I digress. Hopefully we're still looking at a net positive of the syntax highlighting feature being available. All I can recommend is to turn it off if you're experiencing problems. Sorry! — MusikAnimaltalk17:21, 14 June 2018 (UTC)
@MusikAnimal: Then what about giving users the option to have the highlighter not kick in if it takes to long per run, or if the page size exceeds a certain limit?—CYBERPOWER(Chat)17:31, 14 June 2018 (UTC)
Interesting idea! Yes I think that is certainly possible. My suggestion would be to make a documented way of configuring this in your Special:MyPage/common.js, such as CodeMirror.maxPageSize = 100000; or something. I don't think we'd want to expose this in the interface, or add more preferences. An initial timeout (takes too long to load) is probably something it should do automatically, and perhaps could be disabled in your user JS (e.g. CodeMirror.timeout = false). Would you mind creating a Phabricator task? — MusikAnimaltalk17:36, 14 June 2018 (UTC)
@MusikAnimal: you mentioned above that the WikiText editor is now using CodeMirror. Is that just for syntax highlighting or the editor in general? Is it possible to load CodeMirror alternate keymap files i.e keymap/vim.js? Jbh Talk20:33, 14 June 2018 (UTC)
Just for syntax highlighting, but that effectively takes over the editor itself. I am not aware of how to load alternate keymaps in CodeMirror, but sounds like it's worth exploring! By the way, the bug with cursor placement is filed at phab:T197263 and we are looking into it. — MusikAnimaltalk20:39, 14 June 2018 (UTC)
Yep... Being able to hack the WikiText editor via exposed CodeMirror configuration would be great but that capability seems to go in the opposite direction of what the push to Visual Editor indicates (more technical rather than less). It is a nice wish though. Thank you for looking into the cirsor issue. Jbh Talk20:09, 15 June 2018 (UTC)
Potentially related problem
Is this change in syntax highlighting the reason that I am experiencing a strange editing problem? For the last week (or perhaps less), I have found that on occasion an edit window is extremely slow. It does not happen on all pages; it does not happen in every section of an affected page. For example, at Wikipedia:Bot requests, every section that I have tried to edit works just fine - with one exception. If I try to edit the section Wikipedia:Bot requests#Indexing talk page, the edit screen takes noticeably longer than normal to load - and once it has loaded, typing a single character takes ten seconds, so a few words take several minutes to type in. The same happens with the edit summary window. It is replicable: exiting the page and trying the "[edit]" link again produces the same result, as does using Ctrl+F5 to reload the page "clean". It's also persistent: closing the browser and restarting it yields exactly the same issue. In case you are wondering how I made this edit: having found that it was a slow edit screen. I composed my reply in a plain text editor, and copypasted it in. The paste took ten seconds to achieve, so that demonstrates that it is keystrokes and not characters that are the limiting factor. So: is it possible to prevent the syntax highlighting script from loading? --Redrose64 🌹 (talk) 18:16, 19 June 2018 (UTC)
If you want the syntax highlighter off, then I believe that you just need to toggle the button off in the toolbar, and it will remember that state (in a hidden pref or equivalent) until you toggle it back on someday. Whatamidoing (WMF) (talk) 15:16, 21 June 2018 (UTC)
It's off. It's always been off, unless it's somehow there and I can't see it. I have no button - I don't even have a toolbar, because that consumes noticeable page load time (as does VE), so at Preferences → Editing I have the following:
⧼tog-showtoolbar⧽ - no
Enable the editing toolbar - no
⧼visualeditor-preference-betatempdisable⧽ - yes
The slow edit window problem doesn't happen all the time, or even in all sections of one page; it happens with particular sections of particular pages. Rebooting the machine has no effect. --Redrose64 🌹 (talk) 20:58, 21 June 2018 (UTC)
I've left a note for the team, but I don't expect to have an answer before Monday. In the meantime, if you enable one of those toolbars, you should be able to determine whether it's turned on (and then turn it off, if it's on). Whatamidoing (WMF) (talk) 20:58, 22 June 2018 (UTC)
Left hand column with menu (Main page, contents, languages etc) showing while in edit field stopping me from saving
And they're clickable and across the publish changes button. Luckily hitting return in the edit summary field works as I can't use the publish button. This is even worse than the occasional file image overlaying the corner of the edit window. This seems to be Firefox problem as I don't have it in Chrome. On the other hand when I start a new section I can't save at all, so I had to switch to Chrome in he miffle of writing this. I'm using Vector. Doug Wellertalk11:17, 18 June 2018 (UTC)
@PrimeHunter: It doesn't seem FF related after all, it's WikEd related - it only happens when WikEd is turned on, and Chrome doesn't have it turned on. Turning it off in FF fixes the problem. Doug Wellertalk14:38, 18 June 2018 (UTC)
But only sometimes. And in any case, I don't get the templates box when I use wikEd, I should get it with both. On another page just now I couldn't even change between them. Doug Wellertalk18:28, 18 June 2018 (UTC)
Alt+⇧ Shift+p should preview. If you are desperate you could try hiding the whole left panel in edit and preview with the below in your CSS but body.action-submit may hit other things than preview. PrimeHunter (talk) 11:09, 23 June 2018 (UTC)
I've been getting one inconsistently when opening the edit window as well, for the past week or two. Mine says
Javascript Error https://wiki.riteme.site/w/load.php?debug=false&lang=en&modules=ext.3d%2CCodeMirror%2Ccharinsert%2CeventLogging%2CnavigationTiming%2CwikimediaEvents%7Cext.CodeMirror.data%2Clib%7Cext.CodeMirror.mode.mediawiki%7Cext.centralNotice.geoIP%7Cext.centralauth.ForeignApi%7Cext.centralauth.centralautologin.clearcookie%7Cext.echo.api%2Cinit%7Cext.eventLogging.subscriber%7Cext.uls.common%2Ceventlogger%2Cinit%2Cinterface%2Cpreferences%2Cwebfonts%7Cext.visualEditor.desktopArticleTarget.init%7Cext.visualEditor.supportCheck%2CtargetLoader%2CtempWikitextEditorWidget%2Ctrack%2Cve%7Cext.wikimediaEvents.loggedin%7Cjquery.accessKeyLabel%2CcheckboxShiftClick%2Cclient%2Ccookie%2CgetAttrs%2ChighlightText%2ClengthLimit%2CmakeCollapsible%2Cspinner%2Csuggestions%2CtabIndex%2CtextSelection%2Cthrottle-debounce%7Cjquery.makeCollapsible.styles%7Cjquery.uls.data%7Cmediawiki.ForeignApi%2CRegExp%2CString%2CTitle%2CUri%2Capi%2Ccldr%2CconfirmCloseWindow%2Ccookie%2Cexperiments%2Cicon%2CjqueryMsg%2Clanguage%2Cnotify%2CsearchSuggest%2Cstorage%2Ctemplate%2Cuser%2Cutil%7Cmediawiki.ForeignApi.core%7Cmediawiki.action.edit%7Cmediawiki.action.edit.collapsibleFooter%2CeditWarning%7Cmediawiki.api.options%7Cmediawiki.language.data%2Cinit%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.ready%2Cstartup%7Cmediawiki.page.watch.ajax%7Cmediawiki.template.regexp%7Cmediawiki.widgets.visibleLengthLimit%7Coojs%2Coojs-ui-core%2Coojs-ui-widgets%2Csite%7Coojs-ui-widgets.styles%7Coojs-ui.styles.icons-editing-advanced%2Cicons-editing-styling%2Cicons-moderation%2Cicons-movement%7Cschema.UniversalLanguageSelector%7Cskins.vector.js%7Cuser.defaults%7Cwikibase.client.action.edit.collapsibleFooter&skin=vector&version=1u4c16z at line 6: TypeError: $button.toggleClass(...).data(...) is not a function
The Firefox console shows:
TypeError: $button.toggleClass(...).data(...) is not a function[Learn More] load.php:6:700
updateToolbarButton https://wiki.riteme.site/w/load.php:6:700
addToolbarButton/</< https://wiki.riteme.site/w/load.php:8:489
mightThrow https://wiki.riteme.site/w/load.php:49:590
resolve/</process< https://wiki.riteme.site/w/load.php:50:269
I don't know if they are related to the same cause as Doug Weller's errors above, but maybe someone here has a clue about them. I'm guessing it's something in my vector.js that has degraded in its interactions with the MW code base, but I haven't changed anything. – Jonesey95 (talk) 14:13, 23 June 2018 (UTC)
@Doug Weller: When you encounter these problems (which are btw reported by the Gadget you enabled in your preferences, normally they are hidden for users) please also record on which page you encountered them and what browser and skin you were using. That makes it a lot easier to find the problem, as javascript errors are very context dependent. It can also be important to check if the issue occurs if you load that same page with the "safemode=1" parameter in in the url. That parameter disables all userscripts and gadgets (where most of these problems are). If it disappears, then likely it is a gadget or userscript, and you should try and narrow down, by disabling and reanabling them until you figure out which combination introduces the problem. Specifically however:
"TypeError: /oldid=(.+)/.exec(...)" seems to be an error by Twinkle. Likely on a diff page. As no one else has reported this problem, it makes me suspect that another gadget or something has changed the diff page, causing twinkle to not be able to find the html that it is normally looking for.
I recently created Category:2018 photographs, and included it in Category:2010s photographs. When I look at the parent category, it lists the five pre-existing cats (2010, 2011, 2013, 2014, 2016) in a section at the top, then a section head 0-9, then my 2018 cat. What did I do wrong/different to make 2018 get split out into a separate section? -- RoySmith(talk)15:45, 23 June 2018 (UTC)
A space as category sort key was added in [30] after your post. Without a sort key it sorted under "0-9" because "2018 photographs" starts with a digit. You could have examined the source of one of the other categories like Category:2016 photographs to see what they do different. They also add {{navseasoncats}} which I have now done. PrimeHunter (talk) 16:06, 23 June 2018 (UTC)
And the others have sort keys for all parent categories.[31] When I create a category I always look for a similar category and adapt its source. PrimeHunter (talk) 16:11, 23 June 2018 (UTC)
Polluted categories
I've been working on Wikipedia:Database reports/Polluted categories maintenance, and have come across an issue that I wanted to ask if anything can be done to fix. The thing is that while the original database report detects and lists both User: and User talk: pages in content categories, actually using the "User [search]" link next to each category only generates a list of User: pages while not picking up or displaying User talk: titles — which means that to actually ensure that a category is fully clean, I have to manually perform a second followup search for user talk pages.
For example, I just had a category where the search link found one user page, but it turned out that the page had been created after the most recent list generation and thus could not have been the cause of the category getting detected on the current report in the first place — so I researched, and found that there was also a user talk page in the category. But that page had not appeared at all in the original searchlink list, so had I not done that followup research I would have missed that page and the category would have remained polluted. It's also not a feasible alternative to simply go directly to the category instead of using the search link — some of the polluted categories have hundreds or even thousands of pages in them, so having to manually eyeball everything in the category is not a viable way to actually find the one or two userspace pages in the haystack.
So is there any way to recode that report so that the search link picks up user talk: pages as well as user: pages? Or alternatively (and even better, if possible) is there any way that instead of generating a list of the polluted categories from which each category has to be individually searched for the polluting content, the report instead generates a list of the individual pages that are causing the pollution so that an editor working on maintenance tasks can copy them into AWB and get through a batch much faster? Bearcat (talk) 18:29, 22 June 2018 (UTC)
Well, for the search link, I think all that needs doing is adding &ns3=1 to Template:Dbr link; I've gone and done that. For changing the report, you'd want to ask MZMcBride, although I imagine that'd be difficult — I don't think it's immediately obvious to a database which pages are correct and which are wrong. ~ Amory(u • t • c)18:57, 22 June 2018 (UTC)
Fair enough. In the vast majority of cases, the categories involved are mainspace categories which should never contain any user or user talk pages at all, which is pretty straightforward, but there are a smaller number of categories in the list where the actual problem flips because the category was meant for non-mainspace stuff like userpages but somebody has erroneously added one or more articles to it. I suppose it would be hard for an automated database report to figure out which is which — though I do wonder if it would be possible to give each category a code for "what type of content is supposed to be filed here and what type of content is not", so that a "pollution" report run could just check for any categories which include content types the category is coded as not meant to be including (e.g. user pages filed in categories coded as not to include user pages, draft pages filed in categories coded as not to include draft pages, etc.) But that's just me spitballing, it might not be technically feasible.
Thanks for the quick change on the search link coding, though — I've already caught at least one user talk page in a category that had previously reported as already cleaned up, so it definitely worked. Bearcat (talk) 19:09, 22 June 2018 (UTC)
Identifying whether a category is for articles or for user pages is pretty straightforward. A quick look at the category members usually gives it away. --MZMcBride (talk) 19:32, 22 June 2018 (UTC)
To human eyes, absolutely. A machine-generated datadump might have a harder time telling what type of content a category is meant to contain, however. Bearcat (talk) 21:01, 22 June 2018 (UTC)
Now that I think about it a bit, I think I agree with MZM. It might be a lot of overhead, but unless they're very polluted a script could look at the members and find the odd-namespace(s)-out. Might not be perfect, but would be a good approximation, no? ~ Amory(u • t • c)01:08, 23 June 2018 (UTC)
Or rather than guessing, we could just provide the per-namespace membership counts or percentages across a specified category. For example, for Category:2001 births:
MariaDB [enwiki_p]> select page_namespace, count(*) from page join categorylinks on cl_from = page_id where cl_to = '2001_births' group by page_namespace;
+----------------+----------+
| page_namespace | count(*) |
+----------------+----------+
| 0 | 595 |
| 2 | 1 |
+----------------+----------+
2 rows in set (0.01 sec)
Alternately we could say "99.83% of pages are in the article namespace and 0.17% of pages are the user namespace for this category." I kind of thought we already did this. --MZMcBride (talk) 02:40, 23 June 2018 (UTC)
On a related but distinct note, I've caught another bug in the polluted categories list. The new batch ran overnight, but there are still a few categories on it which hadn't actually dropped from last week's run even though last week's run looked completely "cleared" as of yesterday afternoon and still technically looked "cleared" now. But I found it incredibly unlikely that Category:21st-century American politicians, for example, was clean yesterday afternoon, then suddenly had a userspace page filed in it just in time to get redetected again by the new batch run, and then immediately had that page pulled back out by somebody else before I looked at the category again just a few hours later — so I deep-scanned the category in AWB, and found that it actually has had an undetected userspace page in it all along: a page in which articlespace categories were sitting behind a redirect to a draftspace page. And the same thing happened in Category:Dirt track racing and Category:Baja California: userspace pages that had articlespace categories lurking behind redirects to mainspace, so they were getting detected by the initial batch run but not actually shown when I clicked the search link to find them. So it appears that the batch programming is properly detecting these categories as polluted with userspace content, but the search link is failing to display them because they're functionally redirects to other namespaces rather than standalone pages, so the category looks clean even when it's actually not. So is there another code that can be added to the search link (e.g. "don't follow redirects") to ensure that it displays pages like this as well? Bearcat (talk) 16:13, 23 June 2018 (UTC)
any way to retrieve wikitext/external links from template parameters?
Using Quarry I'm trying to grab some external links from wiki pages, but apparently links made by template aren't stored in externallinks; and the content of template calls is not stored in templatelinks. Is there any way using Quarry to get the "bar" portion of {{Foo|bar}}? Outriggr (talk) 04:33, 24 June 2018 (UTC)
How can I see how the largest articles on Wikipedia?
I was asking about the following over at Wikipedia talk:Article size and this VP was recommended as a place to maybe get an answer...
So, how can I access this information? Is there a tool I can run or a page around here somewhere that has a list? I want to see which articles are the largest and which types of articles - biographies or histories or whatever - are the largest. Thanks, Shearonink (talk) 11:11, 24 June 2018 (UTC)
I'm using mwclient in python to explore the category space. Is it possible to suppress listing hidden categories via mwclient? -- RoySmith(talk)01:02, 25 June 2018 (UTC)
VisualEditor table bug
visual editor table bug
In tables when you add yes or no template an extra | will be added
If memory serves, those templates were officially declared "unsupported" in the visual editor about four years ago. I'm actually surprised that it didn't create any problems. Whatamidoing (WMF) (talk) 05:08, 25 June 2018 (UTC)
I don't know how VisualEditor deals with adding table columns and cell attributes but {{yes}} and {{no}} include cell attributes so they have a vertical bar inside their output to separate cell attributes and cell content. Maybe this confuses VisualEditor. The lead of Wikipedia:VisualEditor says: "VisualEditor still has many bugs and missing features. If you encounter an issue, please report it on the Feedback page." PrimeHunter (talk) 21:27, 24 June 2018 (UTC)
See the diff linked in the section above; adding the "no" template was not the cause of the error. M-G, please provide a link to a diff that shows the error you are reporting in this section. I see this edit, in which you added an extra pipe without a new line, which caused problems. If Visual Editor showed you that you were adding a column, but it actually produced the output in this diff, that may be a bug to report at the Visual Editor Feedback page with a diff link. – Jonesey95 (talk) 04:36, 25 June 2018 (UTC)
Now this is more like what I expected. ;-) I added a column and inserted these templates, and it looked like a nightmare of exposed HTML. There is no way that someone would have added that and thought that anything was working. However, when I saved it, it looked perfect. (Feel free to mess around in my sandbox.) I don't know what's going on. Maybe this requires starting with a structural problem in the original table layout? Whatamidoing (WMF) (talk) 05:17, 25 June 2018 (UTC)
I was able to reproduce the originally reported bug: [32]. Diff for original report. The problem happens when VisualEditor inserts a column before a cell which already has {{no}}. VisualEditor doesn't have to add {{no}} for the bug to occur. PrimeHunter (talk) 10:11, 25 June 2018 (UTC)
"Missing" archive-pages for an article's talk page because of a series of moves...
You already moved it? I would have done that once I knew (or was reminded) what was supposed to be done according to policy/guidelines but thanks. I'll know for next time. Cheers, Shearonink (talk) 05:05, 25 June 2018 (UTC)
@Shearonink: We typically leave redirects behind in most cases. Sometimes the problem with moving is that there is a page at the target that needs to be moved around, but that wasn't the case here. What I usually do is try and see if it works or not first and then I complain to a page mover or admin about it. :) --Izno (talk) 13:13, 25 June 2018 (UTC)
Is there a tool for gauging WP participation traffic?
I've been wondering for months if participation in Wikipedia is losing steam. And what makes me wonder is that, from my experience, the basic admin stuff I deal with on a daily basis, WP:AIV, WP:RFPP and overall listings on the Admin dashboard seem far less than last year at this time. But ... maybe I'm having selective memory on it being more active in previous years. — Maile (talk) 20:49, 25 June 2018 (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.
When a link text was in italics or had other formatting you could sometimes not edit it in the visual editor. This has now been fixed. [33][34]
Changes later this week
Content translation users who translate between any two of Arabic, English, French, Japanese and Russian will be asked to be part of a research project. This is to create better tools for translating articles. [35]
The new version of MediaWiki will be on test wikis and MediaWiki.org from 26 June. It will be on non-Wikipedia wikis and some Wikipedias from 27 June. It will be on all wikis from 28 June (calendar).
Meetings
You can join the next meeting with the Editing team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on 26 June at 18:30 (UTC). See how to join.
You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 27 June at 15:00 (UTC). See how to join.
The WP:USMIL task force cited in the taskforce examples suggests that it should be possible to get separate assessment statistics for each taskforce, I assume as a subset of the assessment statistics for the parent WikiProject - is this correct? And if so, what do I need to do in order to create the assessment statistics tables? I've attempted to update the project data for RegSys as a test, but the assessment tool says that RegSys is not in the database. I get the feeling I'm missing something quite basic, any help appreciated. Thanks! Amkilpatrick (talk) 18:26, 20 June 2018 (UTC)
I assume cookie blocks for IPs are now implemented because Phabricator says they have been. Am I correct in that assumption? I've not seen any notification and there is nothing obviously different on the blocking page. Do admins have any control over whether or not cookie blocks will be applied or is it an entirely automated process? SpinningSpark00:13, 26 June 2018 (UTC)
I am sure that I added my name to the list of users in the correct format and have received issues every week for some time. However I seem to have been omitted from the list this week. — FR+17:31, 26 June 2018 (UTC)
This usually means that there is a problem part-way through the mailing list, and recipients listed after that point will have been skipped. --Redrose64 🌹 (talk) 17:59, 26 June 2018 (UTC)
FR, I've checked the list and I can't find you there, even before Ignacio's unfortunate edit. Maybe you use another account or username? Trizek (WMF) (talk) 07:19, 27 June 2018 (UTC)
WP:Help desk is currently missing the "Edit source" links for each separate section. Other WP forums (for example WP:Teahouse) still have these additional edit links per section (using FireFox 52.9.0 and Vector skin). I am (almost) certain that help desk had such edit links for sections too, unless I missed a memo or am starting to imagine stuff ;). Any help would be appreciated. GermanJoe (talk) 12:48, 27 June 2018 (UTC)
I would guess someone put a __NOEDITSECTION__ somewhere in one of the transcluded templates. --Izno (talk) 12:57, 27 June 2018 (UTC)
Postponement of the deployment of the New Filters on Watchlist
There was a recent announcement about the plans to graduate the New Filters for Edit Review out of beta for this Wiki. It stated that the deployment would happen by late June or early July. Since that announcement, we received feedback about a performance issue related to the change which is being actively worked upon. As a consequence, the deployment is postponed until further notice. Sorry for the inconvenience caused, if any.
No convenient way, to my knowledge - Special:Undelete only seems to allow identifying a diff by its timestamp. You can convert a revision id to a timestamp with a db query, either through Quarry or a Labs account -
yields 20180624114944, so the diff you're looking for is [36]. I'm not terribly proficient with the API; maybe there's a less circuitous route using that? —Cryptic14:16, 27 June 2018 (UTC)
Hi RoySmith, have you tried with the API? Go on this special page. I've already set up the query. To change the diff id, go to "action=query" and change the input with the name "revids". Lofhi (talk) 17:33, 27 June 2018 (UTC)
The "SUL Info" tool linked from the Contributions page footer
Persistently demonstrating template rendering without using subst
This may be my poor memory and decent imagination, but I remember there used to be a way to persistently render a template in a way that will not change even when the template changes, which does not involve subst. The reason I am asking is that we are discussion changes in {{Single chart}} and substing it adds 85k to the talk page, as I did here, which is obviously not going to work. I vaguely remember a few years back there was a way to fixate templates without subst. --Muhandes (talk) 16:06, 29 June 2018 (UTC)
This is not possible. Your options include: Link a version in the page history, make a screenshot, copy a version of the template to another page and transclude that, use subst (which usually only substitutes the outermost template call), use Special:ExpandTemplates (which substitutes everything recursively) and copy the resulting code. PrimeHunter (talk) 16:28, 29 June 2018 (UTC)
Oh, comeon Anomalocaris, these were easy ones that you should have been able to fix with experience from many moons ago. ;) --Izno (talk) 01:43, 30 June 2018 (UTC)
This module apparently transcludes onto over 67k pages, including the June 28 TFA, but it does not actually exist. Should it exist, or if not, should it be protected from creation to prevent vandalism from transcluding onto all these? Home Lander (talk) 20:23, 26 June 2018 (UTC)
I added creation protection to this, any admin is welcome to override/modify as they deem appropriate without consultation. — xaosfluxTalk20:42, 26 June 2018 (UTC)
@Xaosflux, Nthep, and Johnuniq: Wouldn't it be easier to just revert the edit by Ans, instead of protecting lots of /i18n subpages which will never be needed? I find it unlikely that some random module is going to have an /i18n subpage which needs to supersede the i18n table of Module:Wikidata (which is apparently what the change is supposed to allow for). Jc86035 (talk) 21:38, 26 June 2018 (UTC)
I won't have a chance to look at that for perhaps 24 hours but judging by my 2017 comment in the archived discussion linked above I thought the i18n code was not desirable. If no one beats me to it, I will unwind the code to remove that apparently unused feature. It is conceivable that it is used on other projects. If that is the case I would find a solution which does not cause the alarming red-links seen here. Johnuniq (talk) 23:18, 26 June 2018 (UTC)
Doing the same search on several other Wikipedias shows that this particular function is basically a completely useless feature right now since it hasn't caught on yet. There are a few dozen modules which use i18n tables, like Module:Routemap and Module:Video game reviews, but only one or two modules use subpages named /i18n. Jc86035 (talk) 03:26, 27 June 2018 (UTC)
@RexxS and Pppery: Are Module:Wikidata/i18n and Module:Wd/i18n actually useful? As far as I'm aware these are the only two modules which actually use an /i18n subpage, so much of the i18n subpage code in the main modules (the parts which handle the table merging and replacement) can probably be discarded to avoid massive amounts of redlinks being created. Jc86035 (talk) 22:44, 27 June 2018 (UTC)
@Jc86035: The sub-modules are not actually useful on enwiki. Their value would be in helping those who wish to use these sort of modules on foreign wikis. The intention was that the main module can be regularly updated by copy-paste from the master on enwiki while the English messages etc. will simply be overridden by a local internationalised /i18n sub-module in the local language where that exists. However, if it turns out that nobody is taking advantage of that, then it seems pointless to keep the framework here. --RexxS (talk) 23:39, 27 June 2018 (UTC)
@RexxS: Furthermore, was the calling of random i18n subpages like Infobox/i18n intended? If not then maybe the aforementioned edit by Ans should be reverted, and maybe the equivalent functionality (if any) should be removed from Module:Wd and from Module:I18n. Jc86035 (talk) 23:55, 27 June 2018 (UTC)
I'm not the right person to ask, because I don't believe in the value of any kind of modification of code to make it easier to copy to a different project at all, so of course think that Module:I18n and all forms of /i18n subpage are code bloat. {{3x|p}}ery (talk) 01:37, 28 June 2018 (UTC)
Like RexxS said, the value is maintainability across projects. To Module:Wd the /i18n submodule is only relevant to the parent module and I suppose that should be the case for any of these internationalisation submodules. Other modules should not worry or care about such submodules related only to the modules they include, since it should be self-contained. I'm not sure what's causing this to go wrong for the Infobox module, but it seems like this internationalisation concept was either misunderstood or interpreted differently by someone. Thayts•••11:06, 30 June 2018 (UTC)
Yes it does do something useful, see the talk page. But I'm not sure if ... by itself is part of the cause of the problem described here at all. Thayts•••11:06, 30 June 2018 (UTC)
List items containing sublists
Is there any way, a template or anything, to allow a single* list item to span multiple lines and continue after sublists? Is something like the following possible with syntactically correct wikimarkup? (I’m using numbered lists here to better illustrate what’s happening.)
Some stuff.
Some other stuff, including:
things
other things
and stuff like that.
Yet more stuff.
This is easily doable in HTML, as I did here: just keep typing after closing the sublist. In wikimarkup, a purely visual effect is possible by using : after the sublist, but that’s syntactically very wrong.
Expand me if you’re not sure why that’s wrong.
This list should be identical to the above, but the final item changes from 3 to 1 because there’s something in between.
Markup
Renders as
*Some stuff.
*Some other stuff, including:
**things
**other things
:and stuff like that.
*Yet more stuff.
Some stuff.
Some other stuff, including:
things
other things
and stuff like that.
Yet more stuff.
The problem being, the use of a colon results in a type of MOS:LISTGAP situation: it terminates the original list, creates a newdescription list of one, then creates a third list containing what was supposed to be the rest of the first. We don’t want three lists of different types. Just one continuous list that isn’t syntactically awful and doesn’t cause accessibility issues.
Is there any workaround besides laying out the entire thing in HTML (or rewriting)? Maybe a templated implementation of lists? Thanks. —67.14.236.193 (talk) 03:56, 28 June 2018 (UTC)
I just found {{bulleted list}}, which seems to be partly exactly what I just asked for.
markup
Markup
Renders as
{{bulleted list
|Some stuff.
|Some other stuff, including:
*things
*other things
and stuff like that.
|Yet more stuff.}}
Some stuff.
Some other stuff, including:
things
other things
and stuff like that.
Yet more stuff.
The HTML source of that is about identical to my first example above. I don’t think it would work in every scenario, but it definitely helps. —67.14.236.193 (talk) 04:19, 28 June 2018 (UTC)
Nope, {{bulleted list}} is no good. If there’s nothing on a line after a sublist (for instance, if the line “and stuff like that” were removed above), that sublist never ends, and the entire rest of the list gets indented. So, back to square one. Help? —67.14.236.193 (talk) 05:39, 28 June 2018 (UTC)
markup
Markup
Renders as
{{bulleted list
|Some stuff.
|Some other stuff, including:
*things
*other things
|Yet more stuff.}}
@Jonesey95: I’ve taken the liberty of collapsing all the markup (they’re kinda bulky), but I actually meant within the param, after the sublist:
markup
Markup
Renders as
{{bulleted list
|Some stuff.
|Some other stuff, including:
*things
*other things
|Yet more stuff.}}
Some stuff.
Some other stuff, including:
things
other things
Yet more stuff.
That’s a problem. And probably not what this template is meant for, anyway. BUT! This works:
markup
Markup
Renders as
{{bulleted list
|Some stuff.
|Some other stuff, including:
{{bulleted list
|things
|other things
}}
and stuff like that.
|Yet more stuff.}}
Some stuff.
Some other stuff, including:
things
other things
and stuff like that.
Yet more stuff.
So we can’t (or shouldn’t) mix wiki lists and template lists, but we can nest the template in itself. So… is there anything more editor-friendly that kinda does the same thing? —67.14.236.193 (talk) 06:56, 28 June 2018 (UTC)
I'm not sure if we are allowed, or if it is technically feasible, to do this. MOS:LIST#Tables is the only place on that page "columns" is mentioned, and it says tables are discouraged except for cases like, for example, where three or more columns are warranted; but what if I only want two columns? Specifically, I think the page List of Man'yōshū poets would benefit from this, as much of the page only uses the left half of the screen. I was torn between asking this question on WT:MOS (with an emphasis on whether it was recommended) and here, but really I'm more interested in whether it is possible, so here. Hijiri 88 (聖やや) 09:57, 27 June 2018 (UTC)
Listing a specific number of columns is generally deprecated (on Wikipedia) because it is not very responsive. You can set a colwidth with a template like the one that Racklever linked and that will flex depending on how wide the reader's screen is. --Izno (talk) 12:40, 27 June 2018 (UTC)
Annoyingly, the default for {{div col}} without any parameters is to produce two fixed columns. That really ought to be fixed. --RexxS (talk) 00:06, 28 June 2018 (UTC)
It looks like there were some discussions in the March timeframe, and there are edits queued in the sandbox for the default behavior to change, but it is not obvious to me that anyone is working Jonesey's recommended path (which is, not to implement the sandbox until the remaining 10k articles or so are cleaned). I don't think I agree with that path, but I don't feel like chasing the talk page about it. Feel free to drop by there and see if there is large resistance to moving implementation forward. --Izno (talk) 02:52, 28 June 2018 (UTC)
TheSandDoctor began running a bot task (DeprecatedFixerBot, see Wikipedia:Bots/Requests for approval/DeprecatedFixerBot 2) to remove the deprecated parameters, then halted the bot while a lively discussion ensued on the operator's talk page. As of 7 June, TheSandDoctor intended to restart the bot, and then got caught up in becoming an administrator and hasn't had a spare moment, what with all of the mopping. Once the bot finishes its work, the template can be updated based on the sandbox code, or something close to it. – Jonesey95 (talk) 05:01, 28 June 2018 (UTC)
That is correct Jonesey95 and thanks for the prod. I have now resumed the bot with a one thousand page run. Of course, it isn't going to be able to handle every page (so won't touch ones that don't match specific conditions), that is just the "sample size" of the run. --TheSandDoctorTalk05:43, 28 June 2018 (UTC)
@RexxS: I hope you don't mind, but I've undone your change to the article linked at the top of this thread. I don't exactly understand why (if I did I wouldn't have needed to come here for technical advice), but on every screen I have access to at the moment the list with the "colwidth" parameter added looks identical to the list without the div col template in place at all; even if it's deprecated, this really seems like an IAR situation because the page looks a lot better (at least on my laptop, tablet and phone) with the columns, and without them the "List" heading I added here is meaningless (I actually used the preview button a few times to figure out how best to work it, and only included the heading to keep the right-hand column from running parallel to the table of contents). Hijiri 88 (聖やや) 00:53, 30 June 2018 (UTC)
@Hijiri88: It doesn't matter whether I mind or not: having two fixed columns is bad for readers who have very narrow screens or very wide ones. If {{div col|30em}} gives you one column on every screen you have, then you don't have a screen wider than about 1000px, but lots of other readers do. It's not fair to make an article look good on just a narrow range of screen sizes without taking into account other readers. I've tried again with colwidth set to 30em in the hope you find that acceptable. If not, you really ought to be trying 25em or 20em for yourself - you can do it in preview - rather than reverting to two fixed columns.
@Jonesey95: You finished your cleanup in March. Isn't it about time that we updated this template to remove support for fixed widthsnumber of columns? --RexxS (talk) 01:48, 30 June 2018 (UTC)
Maybe so, but the article definitely looked worse on my laptop screen (which apparently has more pixels than my phone or tablet, unsurprisingly) under your initial edit than under your new, revised edit that actually fixed the problem. I came here and politely asked a technical question for which I should not be expected to know the answer, and you responded by effectively undoing my edit (at least for all readers whose screens are the same size as my laptop's). You have my thanks for now having resolved the issue (honestly I still think the two columns looked better on my iPad than the one that shows up now, but I guess that's a matter of opinion), but in future please just explain up-front why 20em, 25em or 30em would be better than two fixed columns (40em is definitely worse than two fixed columns on every screen I have access to at the moment) rather than implementing an edit that moots the whole point of the question without offering an explanation on the original thread. I don't even know what an "em" is, and I'm pretty this page is supposed to allow folks like me to ask for assistance with these problems (this is actually unclear, though -- both the page header and Wikipedia:Village pump (technical)/Before posting variously imply that the page is only for one or the other of asking questions or reporting bugs and other issues). Hijiri 88 (聖やや) 02:02, 30 June 2018 (UTC)
Yes, I did some work in March, but we have been waiting for the bot job to finish (i.e. for the deprecated parameter category to be cleared out) before completely removing the deprecated parameters. This is just normal template conversion work; sometimes it takes time, especially when there are thousands of articles involved. The bot has been quite active in the past few days, reducing the categories from about 8,000 pages to just under 4,000 pages. Once the bot is done, humans will need to clean up the cases that were not fixable by the bot. Patience, grasshopper.
Also, just to be clear, we are not removing support for fixed widths. We are removing support for a fixed number of columns. It may be better to continue this discussion at Template Talk:Div col. – Jonesey95 (talk) 05:12, 30 June 2018 (UTC)
@Hijiri88: You need to compare my amendment with your revert on a wider screen sometime to get the full picture and understand why a fixed number of columns is a bad idea.
@Jonesey95: I have little patience with poor template implementations. Why should readers have to wait years for an obvious fix to materialise? Reflist was fixed in fraction of the time once we worked on it. Screen resolutions are diverging continually and responsive layouts are essential to catering for as wide a range of readers' screens as possible. The 'fixed widths' was obviously a typo on my part, and I've corrected that. --RexxS (talk) 09:52, 30 June 2018 (UTC)
The template implementation was not poor when it was developed, since responsive design was either nonexistent or in its infancy. Software migrations take human effort to perform in ways that don't leave readers looking at bad formatting in articles. If you're out of patience, you're welcome to clean out the deprecated parameter categories. Take a look at the BRFA for details on the fixes that should be applied to {{div col}} and {{columns-list}}. I manually fixed at least 99% of templates that are affected. There are only about 3,000 pages in article space left. I've been chipping away at them slowly over the past week or so. – Jonesey95 (talk) 20:05, 30 June 2018 (UTC)
Deleted page message not displaying in British English
Recently I've noticed that the successful page deletion message (MediaWiki:Deletedtext/enGB since I use British English) doesn't display when I delete a page, and just gives me a single one-line message instead. The page hasn't changed - it simple transcludes the default language message. If I change my language settings to the default (American) English, it displays correctly. Can anyone explain/fix this? Optimist on the run (talk) 14:10, 30 June 2018 (UTC)
MediaWiki:Deletedtext/enGB isn't used. The correct name is MediaWiki:Deletedtext/en-gb which hasn't been customized. There are hundreds of interface languages and hundreds of customized messages, giving a huge number of combinations. A few messages have been customized for en-gb but there are no plans to systematically customize messages for users who change away from the default language "en - English". PrimeHunter (talk) 15:21, 30 June 2018 (UTC)
The value of the parameters $1 and $2 are not passed from MediaWiki:Deletedtext/en-gb to MediaWiki:Deletedtext, and it's not possible to pass them without recoding MediaWiki:Deletedtext to receive and use them. As far as I know there is nothing which can be saved in MediaWiki:Deletedtext/en-gb to make it always behave like MediaWiki:Deletedtext, and it's the same with all customized messages with parameters. See Wikipedia:Village pump (technical)/Archive 158#Odd looking block message for my attempts. I advice all users against selecting en-gb or en-ca as interface language, and especially admins. They should generally see the same interface as the users they interact with (at least the users who haven't changed language). Here is a possibly complete summary of differences between en and en-gb in 2014: uncategorized/uncategorised, "$1"/‘$1’ (different quote characters in many messages), color/colour, canceled/cancelled, vandalized/vandalised, Kilometers/Kilometres, meters/metres, digitize/digitise, program/programme, License/Licence. There may be a couple more today but for a few British spellings and different quotation marks, you lose hundreds of customized messages, often with links to relevant tools, help pages, processes, guidelines and policies at the English Wikipedia. en-gb is basically a trap we lead unsuspecting users into. We only give them a vague message with MediaWiki:Preferences-summary/en-gb displayed at top of preferences. It causes a lot of wasted time for users who don't see our customized messages, and for other users who have confused discussions with them. But some British users object whenever it's suggested we should advice against selecting en-gb as interface language. They may say we should change the software instead but that's easier said than done, and instead we keep a poor system indefinitely. PrimeHunter (talk) 21:09, 30 June 2018 (UTC)
@PrimeHunter: - you're right, my attempt didn't work (I'd forgotten to change my preferences back to en-gb before testing) so I've deleted it. I've left my preference for en for the time being, though this still doesn't explain why it'd worked for me in the past. Optimist on the run (talk) 21:43, 30 June 2018 (UTC)
Adding a navbox to a category adds a random selection of articles to which the navbox links to the category?
This has me stumped. I did a bit of work on Template:Japanese princesses yesterday, which apparently brought its attention to someone who added it to a navbox category. This seems reasonable enough, but when I clicked on the category itself and noticed that a bunch of the princesses in question were mysteriously listed in the category now. None of the subcategories seem to have this problem, and I can't for the life of me figure out what happened; I considered just reverting the change as doing more harm than good, pending someone figuring it out, but I figured asking here would be better. Hijiri 88 (聖やや) 00:51, 1 July 2018 (UTC)
Thank you User:StarryGrandma for the advice, which (I think?) I botched on implementation, and thank you User:PrimeHunter for (I think?) fixing my botching. I still don't quite understand why including a navbox in a category without noinclude will automatically add several (but not apparently all?) of the linked articles in the navbox, and so don't know why my edit didn't initially work or whether PH's amendment was what finally fixed it, but I guess it's done now. :-) Hijiri 88 (聖やや) 11:20, 1 July 2018 (UTC)
All pages transcluding the navbox would be added to the category but the job queue may not have updated all link tables when you examined it. Your edit [37] fixed the category issue. My removal of a newline [38] didn't affect categorisation but just prevented some articles from displaying whitespace after the navbox. A noinclude part should nearly always start at the end of the last line and not on a new line. PrimeHunter (talk) 13:56, 1 July 2018 (UTC)
I created this category for importers (or is it better call them converters?) of infoboxes. Are there only that little such importers? If not, how can I find and add others? Wikisaurus (talk) 19:34, 1 July 2018 (UTC)
Just updated to Firefox 61.0 32-bit, still with Windows 10, Modern skin. Tab viewing. Firefox did some funky stuff when it updated, and reset some of my non-Wikipedia settings. But everything otherwise looked normal on Wikipedia. Now my edit window is missing the toolbar, and looks like I'm typing on a plain sheet of paper, instead of the different colored diffs that are usually there. Access to my user space pages in Firefox is gone. I can click my main User page and User talk, but there is no tab to let me access my user space pages. Preferences, instead of being tabbed, is one long straight page. In Chrome, I see that my common.js script is still intact. But I can't access any of my user space pages on Firefox. What happened? — Maile (talk) 21:14, 1 July 2018 (UTC)
I'll be darned. It was the latest version of NoScript, which listed Wikipedia.org as an untrusted site. Problem solved. — Maile (talk) 21:30, 1 July 2018 (UTC)
...which is quite an eyesore. The pass statement should go (either line 44 and following are on the same level of indentation as line 43 and do something, then nuke line 43, or they are not, then nuke lines 42-43). This reeks of vestigial code. TigraanClick here to contact me16:24, 29 June 2018 (UTC)
Huh, Dr.K., what I propose is not a solution to the problem you reported (hence the side note); it is a purely cosmetic change to the code and should not affect how it runs. (I doubt it's worth a bug report.) TigraanClick here to contact me09:06, 2 July 2018 (UTC)
Proposal to make discretionary sanctions actually work, by auto-delivering the required DS "awareness" notices
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 database for tags will be changed. This will happen on 2 July on French Wikipedia and 9 July on all other wikis. Please report if recent changes get slower or you can't save edits. This could especially affect editors who use the database on ToolForge. [40]
Problems
Last week's MediaWiki update was rolled back. This was because of a database problem. [41]
Changes later this week
There is no new MediaWiki version this week.
Meetings
You can join the next meeting with the Editing team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on 3 July at 18:30 (UTC). See how to join.
You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 4 July at 15:00 (UTC). See how to join.
When I open the article atan2 in the wikipedia beta android app, the image at the top (i.e. File:Atan2definition.svg) is cropped a bit, halfway through the letter "x" on the right. Also, someone told me they saw the exact same crop problem in a browser, albeit sporadically (depending on zoom level, whether they were viewing the main article or a history comparison, etc.). I can't reproduce it in a browser, but anyway that hints to me that it's something about the picture or article, not just a specific bug in the android app.
Before I file a bug report, am I doing something stupid? (Current version is [42], image is invoked as [[File:Atan2definition.svg|thumb|(caption text)]]). Thank you very much in advance!! --Steve (talk) 00:23, 2 July 2018 (UTC)
I wouldn't say the image is cropped. It just doesn't have room for all the text in some cases. SVG images can store text as characters instead of images. SVG software then displays the text as part of an image. Our software converts SVG to PNG images. The conversion is done independently for each size and the result can vary. The spacing (kerning) in the text varies in your example so some sizes cannot fit the whole text within the margin. Try to make a version where the text isn't so close to the margin. PrimeHunter (talk) 00:59, 2 July 2018 (UTC)
How I see the current version
100px, ends in middle x150px, large margin200px, ends after x250px, small margin300px, ends in right part of x
The description in the captions is what I see at 100% zoom in Firefox. srcset is actually used to give the browser a choice between PNG versions at different sizes. If you zoom then you may see another version with another spacing and resulting cutoff. For example, the html for |100 px says: <img alt="" src="//upload.wikimedia.org/wikipedia/commons/thumb/a/ad/Atan2definition.svg/100px-Atan2definition.svg.png" width="100" height="86" class="thumbimage" srcset="//upload.wikimedia.org/wikipedia/commons/thumb/a/ad/Atan2definition.svg/150px-Atan2definition.svg.png 1.5x, //upload.wikimedia.org/wikipedia/commons/thumb/a/ad/Atan2definition.svg/200px-Atan2definition.svg.png 2x" data-file-width="815" data-file-height="698" />. So for |100 px you may see a MediaWiki-generated PNG image with size 100px, 150px or 200px, scaled to some other size by your own browser. PrimeHunter (talk) 01:32, 2 July 2018 (UTC)
I've uploaded two images this week to update images into articles; the first was a logo on WKAQ-TV for the 'NBC Puerto Rico' subchannel (File:WKAQ-DT3 Logo.png), the second a new logo for WLPR-FM (File:WLPR-FM Logo.png). In my browser (Chrome 68), the article page doesn't show either image within their infoboxes as transparent (white background instead), though it's fine on the actual image page and showing transparent there (I have reproduced the same result in Edge, Firefox and Safari iOS with white backgrounds on article pages, transparent on image pages). Am I doing something wrong, is this local to my systems or reproducible outside it, or is there a bug that needs to be traced down? I've used Paint.NET for years to create PNGs and never had any issues with it until now, so any insight is appreciated. Nate•(chatter)07:18, 2 July 2018 (UTC)
Glad to see there's a report on it and others are having issues on other wikis; hopefully this helped with this bug report. Thanks! Nate•(chatter)08:37, 3 July 2018 (UTC)
Problems with the DS template documentation
Resolved
I noticed that the documentation for several templates related to discretionary sanctions, such as Template:Ds/talk notice and Template:Ds/alert, shows the wrong code for the templates (such as "subst:alert" instead of "subst:Ds/alert" or "subst:Ds" instead of "Ds/talk notice"). I cannot figure out how the code for the documentation works though. Can someone with more skills take a look? Regards SoWhy09:32, 2 July 2018 (UTC)
It seemed weird and annoying that after all this time, the {{tag}} template (for HTML tags) did not support a means to link to the meaning of the element in question, the way {{xtag}} does for MediaWiki elements (e.g. {{xtag|ref}} → <ref>) so I fixed it.
Does anyone know why whenever I go to Spanish Wikipedia, I get a message stating "Defendamos una Red abierta", and it will not allow me to access that Wikipedia? Please {{ping}} me when you respond. --Jax 0677 (talk) 08:13, 4 July 2018 (UTC)
Apparently communities can request this access be assigned, (ckbwiki has it on adminbots for example), but enwiki is a bit riskier since we have some pages with huge histories that a bigdelete could cause problems for. This one "only" has 8,230 revisions though so it should go ok if a steward does it. — xaosfluxTalk23:05, 3 July 2018 (UTC)
Okay, the membership box at Wikipedia:WikiProject Women in Red just got wonky, with no edits anywhere. And one of the members reports she has lost rollback, and her new articles are being patrolled (I think she has auto reviewed rights normally). So is there something new we should know about? NotARabbit (talk)18:04, 4 July 2018 (UTC)
@NotARabbit: thats a lot going on, lets break it down:
Doubtful. Remex is tomorrow, and even if it weren't, the template in question looks well-formed. NAR's reported issues are certainly unrelated to each other. The template looks fine on its own page, so I would guess there's something wrong with the participants lists. The autopatrolled issue is probably the one Xaos linked. As for rollback, that's likely Javascript not loading fully for the user (or the user having some legacy Javascript lying around). --Izno (talk) 18:38, 4 July 2018 (UTC)
No, the template does not look fine on its own page. There are definite cosmetic issues, though I’d be hard put to describe exactly what. I’ve asked some of the other editors to come here. NotARabbit (talk) 18:41, 4 July 2018 (UTC)
I lost the ability to rollback. [45] and my new articles are still being patrolled (most recent notification was 5 hours ago). I don't have the technical know how to explain the membership sign up issues. Thank you NotARabbit for trying to help. As a non-tech-oriented editor, trying to explain what happens typically is out of my league. SusunW (talk) 18:51, 4 July 2018 (UTC)
Cryptic sorry, I do not understand any of those questions about skin, importing scripts, or breakage, nor have any idea how to answer them. I do not see an option to rollback at all, only undo. I don't know what safemode is. SusunW (talk) 19:18, 4 July 2018 (UTC)
Cryptic I am really sorry, I have no idea what I am supposed to look for when I go to my sandbox, that preference page or those pages that end in .js, or even what to do, once I go to those pages. The very reason I don't post on pages such as this, trying to communicate is overwhelming to me on technical problems. I am a writer and a researcher, I have zero and I do mean zero skill with technology other than type, preview, save. I truly do not understand what it is that I am supposed to be looking for, nor what it is supposed to be telling me. Under skin on the preference page a "*" appears before Vector (default | Preview | Custom CSS | Custom JavaScript) does that mean something? It should be quite clear that I did not install anything, nor make changes to it, as I honestly would have no idea how to do that. If we must work together to solve this, you are going to need to explain items in great detail and step by step—go here, find X, press Y, etc. SusunW (talk) 19:49, 4 July 2018 (UTC)
Xaosflux I could rollback on your sandbox, but on Vera Gedroits the article where all this started from, I only have an option to undo. You will see I manually had to undo a whole bunch of changes because there was no way to rollback the lot of them. I now have a work around, Opening the last clean version and saving, but why I cannot just rollback the lot of them is not understandable to me. Usually I have an option to rollback or undo, on Gedroits, only undo appears. SusunW (talk) 20:28, 4 July 2018 (UTC)
@SusunW: the rollback link will only work if the "right side" version is the latest version. If you are comparing any other versions rollback is not an option. Can you go to the page you think rollback should work on, then copy the entire url from your address bar to here so we can see exactly what you are looking at? — xaosfluxTalk20:31, 4 July 2018 (UTC)
xaosflux I do not understand what you mean by right side version. I am not comparing any version, I am looking at the revision history, not the article. I linked above to the revision history so that you could see that there is no option to rollback. Or at least there isn't for me. What do you mean by the entire url? That isn't what I gave you above? SusunW (talk) 20:37, 4 July 2018 (UTC)
On that one line I see rollback on the 20 or so edits that appeared on 29 June, there was no option to rollback anything. I manually had to undo each one. I finally got frustrated trying to figure out which ones I had undone and which ones I hadn't and pulled up the last clean version and just manually corrected all the introduced errors by manually comparing the two versions. It took over an hour to fix what should have been the press of a button. I have now spent more than an hour trying to explain the problem to you, which I find very, very stressful. Our service is to provide articles for users to read. The technology piece should not be something that readers or writers struggle with. I am truly sorry that I cannot explain why this is important or why whatever happened should be evaluated. What caused it, if it will happen again, if it is fixed I do not know. What I do know is that I will not finish my article today. What I know is that I do not have the skill to explain it better than I have and I apologize for wasting your time, as you could have helped so many other people. SusunW (talk) 20:56, 4 July 2018 (UTC)
@SusunW:manually undo each edit? You could have simply reverted to a version without the issues. E.g. go to this version [46], click "edit this page" and then save it with whatever edit summary is appropriate. The reason you could not rollback is that SunnyBoi edited after the IP, and you can only rollback the most recent editor. Headbomb {t · c · p · b}21:00, 4 July 2018 (UTC)
Headbomb I know that now, but I did not know that then, so I went one at a time undoing each edit. Until Gerda told me to just open the last clean version and save it, it never occurred to me to do that. By that time, I had already manually undone them all retyping what was originally there. SusunW (talk) 21:06, 4 July 2018 (UTC)
Headbomb, however, thank you for identifying the problem. A slew of editors introduced errors to a GA. Rather than being able to quickly fix the problem rolling back all the errors introduced, the programming was such that only one user (the most recent) could be easily rectified. This seems to me to be a disconnect, there ought to be a way to eliminate multiple blocks of erroneous text. But it doesn't matter. I have a work around. Again, I am sorry for taking up so much time. I thank you all for your efforts to try to help. SusunW (talk) 21:22, 4 July 2018 (UTC)
If a series of the most recent edits are in error and you want to revert them to a previous version, go to the article history, click the left radio button next to the good version you want to go back to, click the right radio button next to the most recent version, then click "Compare selected revisions". Once you get the comparison screen, click the "undo" link next to the time stamp for the latest revision. Add an edit summary and save. – Jonesey95 (talk) 22:11, 4 July 2018 (UTC)
Viewing, editing and saving an old version in the page history is only three clicks. You have to know about it (or know another method) but I would oppose one-click rollback links at all versions to revert to them without giving an edit summary. There would be many misuses and accidental clicks. PrimeHunter (talk) 23:06, 4 July 2018 (UTC)
One difference between editing an old version and clicking "undo" on a diff is that the editors who made the edits you are undoing will be notified only in the latter case. One may view this notification as desirable or undesirable, depending on the circumstances. – Jonesey95 (talk) 23:25, 4 July 2018 (UTC)
WP:TWINKLE facilitates this to an extent. It works in the diff view, not on in the edit history (see [47]). Only admins have access to that functionality, for some reason. Presumably concerns about edit wars and the like. Headbomb {t · c · p · b}23:28, 4 July 2018 (UTC)
Why are page movers told to fix double redirects when the bot can do it?
I always assumed this was because asking editors to fix technical issues themselves was quicker and less disruptive than waiting for the bots, but I just moved a page and deliberately didn't fix the double redirects (I was performing a page split, and all of the double redirects were better targeted at the new article I was creating) and EmausBot (talk·contribs) got to the redirects and "fixed" them before I could even pop out the placeholder stub, only taking three minutes.[48][49][50]
I had always assumed the bots were slower on these things (they seem to take days to migrate interwiki links to wikidata), and thought for a moment that my edit conflict was with someone undoing my page move. Obviously I'm not complaining about EmausBot doing its job effectively, but if it's that effective wouldn't changing Please clean up after your move: [...]Check what links here to see whether the move has created any double redirects, and fix the most serious ones. A bot will fix the rest later on. to, say, taking this out of the bulleted list and adding an extra note You may also wish to fix the double redirects [with a link to the list], but you do not have to as a bot will fix them shortly.
Well, would you agree that setting them to wait at least ten minutes would be a good idea, if we are telling page movers that they have to check the redirects and fix the "serious ones" and that the bots will fix them "later"? Hijiri 88 (聖やや) 02:19, 30 June 2018 (UTC)
Presumably one that is linked to from a lot of articles, thus creating a whole bunch of broken wikilinks. I would have thought that if the bots get some double redirects and miss others, it would be the "serious" ones that they are most likely to get, and get the fastest, so they would be the ones that don't need to be manually fixed immediately. Hijiri 88 (聖やや) 02:25, 30 June 2018 (UTC)
From a bot perspective, e.g. how the bots are coded, an serious double redirect would be when the final redirect target is unclear. One of the most known examples of this would be the redirect loop, where Redirect A links to Redirect B, Redirect B links to Redirect C, which links back to Redirect A, thus creating a loop. The bots are capable of marking serious redirects for deletion, but whether the bot operator has configured it to do that, I do not know.--Snaevar (talk) 11:23, 30 June 2018 (UTC)
Another example would be self-loops, where a redirect redirects to itself (basically the same thing as an A->B->C->A loop except without the B and C involved. Side effect of WP:SWAP moves when the pages to be swapped are an article and its redirect, which is probably the most common type of SWAP-move. AddWittyNameHere (talk) 11:29, 1 July 2018 (UTC)
(edit conflict) Snaevar I don't think those are double (as opposed to triple, quadruple, etc.) redirects, though, and they can't be created by an individual page move. In fact I don't think the "loop" scenario can result from page moves at all, unless someone actively created a double redirect at some point and then the article was moved to a title that none of them redirected to, which seems like a somewhat unlikely scenario, and writing instructions that only need to be followed in very specific, rare circumstances doesn't seem like a good idea. Hijiri 88 (聖やや) 11:31, 1 July 2018 (UTC)
Redrose64 (talk·contribs) I was trying to fix a problem with the template in that it did not keep the same random number, I had thought that moving the page to a subpage and then calling it with a random number would work, alas, this did not work. I then moved it back to the original place.
I had thought that the change would be permanent and to keep edit histories properly in place, I moved the page (however, I now realise without ensuring that my idea would work). I reverted my mistakes and used the |same=yes parameter instead to achive my goal. I usually test using the sandbox, but this has just reaffirmed the need for testing first. Dreamy Jazztalk | contribs18:12, 1 July 2018 (UTC)
This bot has actually been failing (or running so slowly that it amounts to a failure). E.g., Wikipedia:Manual of Style/Biographies was RMed to Wikipedia:Manual of Style/Biography last week, and days later all the shortcuts and other redirs had not updated, so I had to do them all manually. Similarly, it used to be that if I moved a page (I'm a page-mover, and do a lot of that, including round-robins), it was often the case that the bot would fix double redirs before I even got around to it, and that was handy. Now, I have to do them all by hand. — SMcCandlish☏¢ 😼 01:02, 5 July 2018 (UTC)
Query help
Resolved
I need a little help developing an SQL query on Quarry.
If I could also get the Query to output the date that the NPR user right ('patroller') was granted, as well as the date of the last patrol completed, that would be ideal. — Insertcleverphrasehere(or here)05:43, 5 July 2018 (UTC)
quarry:query/28019, for the first two parts. It's... not elegant. And getting the date patroller was granted isn't going to be feasible by any method I can imagine: it's only stored in the enormous logging table, and which groups were added or removed are stored in its hard-to-parse log_params column. —Cryptic06:55, 5 July 2018 (UTC)
Sometimes, when I push the public changes button, to implement an edit, I get an 'edit conflict' notice. GoodDay (talk) 18:01, 1 July 2018 (UTC)
It happens sometimes when I accidentally push the button the second time (a short time after the first push) before the page reloads. Ruslik_Zero20:44, 1 July 2018 (UTC)
That wasn't it. But, I think I found the problem. It's in my mouse. I'm editing against myself. It's a glitch. GoodDay (talk) 20:19, 4 July 2018 (UTC)
@GoodDay: Your mouse is probably suffering from switch bounce. I have one that started doing this a couple of months ago, so I found that I was double-clicking when not intending to. Mice can be repaired, temporarily - but the bounce will return after a period, and it's much easier to just buy another. The one that I'm using at the moment cost GBP 1.00 --Redrose64 🌹 (talk) 09:15, 5 July 2018 (UTC)
References numbers
Numbered list for references when viewed desktop on a mobile device are partially hidden because of margin/padding settings malfunction. Only ones are visible completely, tens are half-visible, and hundreds etc. are below left content so are not visible (may be different for different devices but problem exists for sure). --Obsuser (talk) 05:42, 5 July 2018 (UTC)
I'm on mobile so cannot cope with screenshots. It is obvious that reference number i.e. 137 should be displayed as such and not as 37 or 7 (this glitch happens especially for numbers in right column[s] when references are displayed in two or more cols). Browser is Samsung internet and device Galaxy J3 2016. Obsuser (talk) 09:38, 5 July 2018 (UTC)
Samsung Internet is probably the issue (it's garbage), and I think the only reasonable way to fix this issue is to change your browser. --Izno (talk) 12:07, 5 July 2018 (UTC)
Seeking intrepid technical volunteers for a mission
I'm thinking about what to say, and I keep thinking of this World War II-era comic strip. A junior officer stands up in front of his combat unit and says "I need a volunteer what don't owe me no money for a little routine patrol."
It's not that bad (honest!), but I do have a kind of odd request: I need some tech-savvy people who are willing to fix some templates and HTML markup in articles at non-English Wikipedias.
Situation: HTML5 is coming to the last ~100 wikis next Thursday (5 July). Most wikis, including this one, are mostly ready. A few are not. Some of them have more than 10K mainspace errors. Some of these errors are even very easy to fix:
In many cases, the problem is in a template were originally copied from this wiki, and the changes have already been implemented here, so it's just a matter of copying the recent fixes over. An editor very kindly did this for train-related templates at the Chinese Wikipedia, and cleared up hundreds of errors on the spot.
In some cases, it's super-simple fixes, like the literally thousands of articles that have <small>...<small> when they ought to say <small>...</small>. You don't have to be able to read the local script; just search for unclosed small tags and add the slash to close the last one (example).
The wikis that I'm most worried about are: ptwiki, zhwiki, srwiki, arwiki, viwiki, and plwiki. Here's the list of problems:
The links take you to a list of just articles (e.g., not talk pages) that are affected. At some wikis, these errors affect a non-trivial fraction of all articles.
What I'd like: If you have fixed these errors here, please check one of these wikis, and see if you can help. If you maintain a favorite template (or set of templates) here, please check out the matching templates at other wikis. It is generally not necessary to speak the local language to fix up the HTML. I've used the correct HTML (like "<small>...</small>") as an edit summary, and nobody's objected yet. Many hands make light work, and one gnome really could single-handedly solve some of these problems. Please help. If you need help figuring out where to start, then leave a note at WT:Linter or ping me. Whatamidoing (WMF) (talk) 21:35, 26 June 2018 (UTC)
I am not volunteering for this but just suggesting that someone considers looking into some automated like perhaps AWB to help with this. Personally I have used AWB on the English Wikipedia to to find and remove cases where "<small>" and "</small>" are used so I imagine it that it might be helpful with this. --Emir of Wikipedia (talk) 21:40, 26 June 2018 (UTC)
The lists of templates on pt.WP look especially ripe for improvement. If someone can figure out how to fix these templates, it will probably reduce the article count significantly. I found one obvious fix, which probably fixed a couple dozen articles, but I am stumped on the rest. My gut feeling is that Template:Navbox on pt.WP may be the root cause of many of the errors. – Jonesey95 (talk) 05:34, 27 June 2018 (UTC)
I spent a while looking at a navbox (in my sandbox at ptwiki, if anyone wants to have a go at it – feel free to try out a few edits), and I've got no idea what's triggering the errors. Jonesey's gut feeling seems very plausible to me. Usually, the span tag problems are about the order that various elements are placed in (e.g., italics need to be on the outside of a language template), but I haven't figured these out. Whatamidoing (WMF) (talk) 06:53, 28 June 2018 (UTC)
FWIW, I have either personally fixed it or had others with rights fix them or left messages (like this one) on many 10s of wikis over the last 6 months. So, I think a majority of those 85 wikis should have been covered by this by now. SSastry (WMF) (talk) 09:21, 30 June 2018 (UTC)
Some of these multiple-unclosed-formatting-tags are really messed up! Nested <small>s with two missing </small> tags and I'm losing my mind.. - TNT💖09:55, 30 June 2018 (UTC)
My theory is this: people know that the '' markup both starts and ends some italic text, similarly with ''' for bold. They have the firm idea that these work like toggles, to switch between the ordinary and the modified. They then hear of <small> and assume that it is also a toggle, and that they should use <small> a second time to switch off small text. They may never have heard of end tags. --Redrose64 🌹 (talk) 10:34, 30 June 2018 (UTC)
Agreed - I'm not blaming anyone! {{small}} goes some way to make the tag easier to use, as most experienced editors are aware of how templates work, but I'm not sure how many projects have that template.. - TNT💖11:08, 30 June 2018 (UTC)
Some pages at this wiki use outdated HTML. This change may change the appearance of those pages. Special:LintErrors has a complete list of affected pages.
I recommend keeping the parser migration extension and preview functional for a month or so in case it helps editors fixing pages to see how it looked it before the switch. SSastry (WMF) (talk) 13:54, 5 July 2018 (UTC)
PS I also expect quite a few people coming in with broken user pages or stuff like that, as these were mostly skipped (in favor of fixing articles) when people were doing the cleanup. —TheDJ (talk • contribs) 09:46, 5 July 2018 (UTC)
In the 2018 "Tri-Nations Hockey Tournament" section, the first four calls of {{footballbox collapsible}} are behaving correctly — but for some reason, the final one instead turns into a text link to the template instead of a transclusion of the template, and then this problem carries through the entire rest of the page, so that even {{reflist}} links out instead of displaying any of the footnotes. And in addition, the page was uncategorized — but even the {{Uncategorized}} template was also linking out instead of displaying the maintenance template, thus forcing me to add the first semi-appropriate category I could think of to actually make it drop from the uncategorized pages list even though I don't really know what the most correct category for this page would really be.
I've looked thoroughly at the page, however, and cannot find any obvious indication of a coding error, such as a misplaced nowiki tag, that would cause this to happen.
Much thanks. I didn't even know that there was a limit, so I guess now I'll know if I ever see a situation like this again. Bearcat (talk) 14:51, 5 July 2018 (UTC)
Something has happened with the watchlist. There seems to be a line break after each bullet point, so the diff and hist links, and the pagename and all the rest appear on the next row instead of the same row, and as a result, the watchlist is twice as long. HandsomeFella (talk) 21:10, 28 June 2018 (UTC)
OK... everybody saying "yes, me too" seems to be using a Microsoft browser (Internet Explorer or Edge). Is anybody having this problem but not using a Microsoft browser? Is anybody using a Microsoft browser and not having this problem? --Redrose64 🌹 (talk) 08:35, 30 June 2018 (UTC)
I don't mean to be cheeky, but if you have deployed something, and it doesn't work, why don't you just back the change out, and try to find what's wrong in a test environment? I work in IT (though not on this platform), that's what I'd do if something similar happened to me. Also, is there a time plan? HandsomeFella (talk) 22:01, 1 July 2018 (UTC)
Anyone know where we can request that failed updates be backed out, and get an ETA? Or, if WMF has decided the MS products are to be unsupported or under-supported, where we can request that they explicitly recommend that MS users switch to Google products? --Hobbes Goodyear (talk) 22:12, 1 July 2018 (UTC)
That happens sometimes, depending on the severity of the issue. This issue doesn't seem to rise to that level of severity.
I'm not sure this is the same problem, although it seems likely to be related, but as of sometime late yesterday, my Watchlist no longer has bullet points for either seen or unseen changes, under Chrome (version 67.0.3396.62). They appear, very briefly, and within ~1 second vanish, never to return. With IE11, the extra line break also occurs while the bullet points are visible, but vanishes (along with the bullets) within 1-2 seconds. Squeamish Ossifrage (talk) 13:51, 29 June 2018 (UTC)
I'm using Firefox 60 and experience the same issue regarding watchlist bullets. I'm using the enhanced watchlist. Are you? --Izno (talk) 14:01, 29 June 2018 (UTC)
It did occur to me that it might be those. No, I haven't tested it yet because I wasn't sure how much effort I wanted to put into testing it. When I get a chance ~ --Izno (talk) 18:48, 29 June 2018 (UTC)
I'm also using Chrome (version 67 on Windows 10) and I also have this problem. Specifically whenever I look at my watchlist on my laptop, I don't see any dark bullets, only hollow ones, even if the "mark all changes as seen" message is still on the top, meaning that there are some changes I haven't seen. Everymorningtalk to me14:46, 30 June 2018 (UTC)
I was having various watchlist bullet problems regardless of the status of that toggle. However, as of today, things seem back to normal? Squeamish Ossifrage (talk) 13:36, 2 July 2018 (UTC)
Hi. I've had the auto-patrol user right for some time now, but new articles I've created today have gone through page curation (example). Obviously this creates an extra backlog on page curation, where there wasn't one before. Thanks. LugnutsFire Walk with Me13:18, 29 June 2018 (UTC)
- Yes, there does seem to be snafu. Not only did I come across one from Lugnuts, but also Magicpiano, and The Drover's Wife, both of which I believe have autopatrolled rights. The good news is, I checked about 20 of the other new creations from all 3 editors, and all were autopatrolled. Onel5969TT me13:29, 29 June 2018 (UTC)
So it sounds like there may be a feed/filter issue? Are you using Special:NewPagesFeed and expecting "patrolled" pages to be able to be filtered out (like how "reviewed" pages can be filtered out)? — xaosfluxTalk13:31, 29 June 2018 (UTC)
@Xaosflux: It's not an issue with the feed or mixed up terminology. Pages created by admins or users with the autopatrolled right are supposed to be marked as reviewed (in the Page curation log) automatically on creation. That appears to have been broken. For example, compare the page curation logs for this page I created a few days ago (empty because I'm an admin) and this page Victuallers created today (had to be manually marked as reviewed even though he's an admin). – Joe (talk) 14:08, 29 June 2018 (UTC)
That's different. I think we're getting patrolled and reviewed mixed up here. This is an issue with sysops/autopatrolled users having articles not marked as patrolled automatically, which sends them to the NPP queue. Natureium (talk) 14:05, 29 June 2018 (UTC)
@Joe Roe: so the summary of the problem is "Page creations by editors with autopatrolled access are no longer also be marked as reviewed" (and they WERE previously)? It doesn't look like the phabricator ticket @Stryn: referenced is for this specific case. Did someone already open one? — xaosfluxTalk14:34, 29 June 2018 (UTC)
Hi all -- I'm Marshall Miller; I'm a product manager at WMF working with the Community Tech team. Thanks for filing this bug. We've realized that this problem was accidentally caused by Community Tech's work on improvements to the New Pages Feed, and we're working on a fix now. I'm sorry about this -- it's definitely frustrating that extra pages are showing up in the feed unnecessarily. We definitely don't want to rush and potentially cause any other issues, so the team is currently writing some additional tests for the fix and will be doing code review. Because of that, it's looking like the fix can be deployed on Monday. I'll give another update here in a few hours. -- MMiller (WMF) (talk) 18:57, 29 June 2018 (UTC)
Hi all -- the team has developed a fix for the bug, and it has been code reviewed. They also wrote additional tests into the code to help ensure that the fix does its job, doesn't break other things, and will be harder to break in the future. The next step is to test the fix in a testing wiki before deploying, which we expect to do on Monday. Thank you for your patience, and please let me know if you have any questions or concerns. -- MMiller (WMF) (talk) 23:46, 29 June 2018 (UTC)
@MMiller (WMF): Thanks for the quick response to this. The timing is awkward, as we were very close to eliminating a two-year-old backlog before the sudden uptick in pages to review! But otherwise it's a relatively harmless bug. Will the fix on Monday retrospectively mark pages as patrolled that should have been? Or will it just fix autopatrolled from that point on? – Joe (talk) 12:16, 30 June 2018 (UTC)
I am seeing the same issue. Hopefully the fix will remove new articles from autoconfirmed users from the queue. My concern was about the queue size as well.–CaroleHenson (talk) 16:55, 30 June 2018 (UTC)
Hi all -- the bug fix was deployed by MusikAnimal a few minutes ago, so we expect that new pages created by autopatrolled users are no longer going into the queue for review. Additionally, a script was run to mass review the 1,867 pages that were created by autopatrolled users during the time that the bug was in the software. So at this time, we're expecting that everything is back in order, with existing pages in the right places, and new pages going to the right places. Please post here if you're still seeing anything different! Thank you for your patience with this as we put the fix in place. -- MMiller (WMF) (talk) 18:50, 2 July 2018 (UTC)
Yeah, I too have been getting notices that things like redirects I create (and I do a lot of that kind of gnoming) have been "reviewed". This means the reviewing system is being flooded by stuff it doesn't need to see from me and other affected parties, and I'm getting spammed with "reviewed" notices. This isn't even new; it's been happening to me for some time, though intermittently. — SMcCandlish☏¢ 😼 00:59, 5 July 2018 (UTC)
WikiMarkup color-shading is missing from a text editor using Chromium
After spending 10 minutes trying to figure out if it was a change I made, I'm convinced that something was altered in the text editor that removed all the colored formatting which specified the different markup in articles. These helpful colors are now all gone in edit mode. I suppose the one question I'm left with asks whether anyone agrees with me that there is a certain inefficiency to taking settings I've set for my own use, turning them off, and then leaving me for 10 minutes with the unshakable feeling that the entire problem was of my own making. So is this really a problem of my own making, or have I become completely delusional. My fish is ready to self-trout if the latter is the case. spintendo 13:29, 29 June 2018 (UTC)
Spintendo, in case you didn't see Izno's reply to you before I moved it: it is at the top of the section, directly under the Thursday's software release issues (1.32.0-wmf.10) heading. I carelessly moved it to there without noticing it was a reply specifically to what you wrote. (Izno approved the move, but I thought I should tell you if you missed it.) --Pipetricker (talk) 21:44, 29 June 2018 (UTC)
I thought it might be that too, but after re-configuring my settings half a dozen times trying every kind of combination I could think of, and ones I've never tried before, I still cant get the editor back to looking the way it did before whatever it was that happened, happened. Alas, in following the Kübler-Ross stages of grief, I've left behind the levels of denial, bargaining and blame. I'm transitioning now into level 5 - acceptance that I'll probably never see those editor settings and their beautiful colors again. Maybe if I was more of a yellow-appreciative person I'd get along better with the beta wikitext editor - but that color dominates that editor. Oh well, thank you everyone for your help! spintendo 10:00, 1 July 2018 (UTC)
Problems with the edit window when there is WikiMarkup color-shading
I wanted to report this but didn't have time. My problem is that all these colors and fonts in the edit window are distracting. Furthermore, when I was trying to edit using Microsoft Edge while signed in, the edit would end up in the wrong place and I'd have to fix it. Usually I would be copying and pasting information and it would end up at the start of the edit window rather than where I intended it to go.— Vchimpanzee • talk • contributions • 16:39, 29 June 2018 (UTC)
And I don't know what explains this diff. I blame the software but don't know what I did to get that result. Seeing as how I didn't make another edit to the article I have no way of knowing what I intended there. On the other hand, I might have used the edit window to move some text I wanted to be plain text, which whatever email address I was using would make a complete mess of.— Vchimpanzee • talk • contributions • 16:42, 29 June 2018 (UTC)
That's usually seen when there's a "loss of focus" (the cursor forgets where it's supposed to be) when you start typing. It's a known occasional problem in the 2017WTE, but it's not so common with other editing environments. What's your mw:editor? Whatamidoing (WMF) (talk) 16:53, 29 June 2018 (UTC)
By the way, using Microsoft Edge at home I'm not having problems. I don't usually use it for Wikipedia but it wouldn't allow me into two email addresses, so I used Chrome for those. Since I couldn't easily copy information that I was moving to those email addresses using the edit windows with Microsoft Edge, and since the site kept freezing, I eventually used Wikipedia, but not signed in, on Chrome and had no problems, or colors.— Vchimpanzee • talk • contributions • 16:58, 29 June 2018 (UTC)
Whatamidoing (WMF) I never had the problem of the cursor forgetting where it was supposed to be. I also had some trouble with copying and pasting but don't know how to describe that. I am having a new problem at home. The text is jumping up and down as I type, like there's an earthquake.— Vchimpanzee • talk • contributions • 16:58, 29 June 2018 (UTC)
Sorry, I didn't know what that was and forgot to ask. I clicked on that link and couldn't really tell. At a library yesterday, where I was having the focus problem, I was on a desktop, though I think the software is the same as what I use at home. I explained why I wasn't using Chrome. And when I did and wasn't signed in, everything looked normal. I've never used Visual Editor and I am on a desktop at home.— Vchimpanzee • talk • contributions • 20:50, 29 June 2018 (UTC)
Do you happen to have "GoogleTrans: open a translation popup for the selected text or the word under the cursor when pushing the shift button" enabled in Special:Preferences#mw-prefsection-gadgets? It caused one of the behaviors you're describing, but not the others (and I thought that it had been fixed since then).
Until I go to the library, I won't know. I'm not aware any of what you said is true there. At home, while signed in, I see what look like photos above the edit window. With private browsing, which I was told to use for reading newspapers, there are fewer of those and they look simpler, and there are words on the right, and everything in the edit window is black. The earthquake is still ... wait, it stopped while I was typing.— Vchimpanzee • talk • contributions • 21:29, 29 June 2018 (UTC)
At this library there is Windows 10 and I am using Internet Explorer 11. I'll check to see if it is happening with Chrome too. When I click the left mouse button if the cursor is inside the edit window, I always go to th top of the window, regardless of where I told the cursor I wanted to go. Using the arrow keys is just too frustrating.— Vchimpanzee • talk • contributions • 16:45, 2 July 2018 (UTC)
I couldn't get a clear answer for why I don't have the same problems at home with Edge that I do at that one library. I'm going to that library Thursday. One problem i did notice was that if I try to copy and paste and then move the cursor within the edit window at the same time, I get sent to the top of the edit window.— Vchimpanzee • talk • contributions • 16:43, 3 July 2018 (UTC)
The Wiktionary template I mentioned is here: Template:Wiktionary.
What it does is give some visual distinctiveness, attractiveness, and separateness to a link to an equivalent or strongly related Wiktionary article. A visitor will easily be able to see it, be more likely to expect it will be useful to them in that moment to click on it, and understand that the link is more related than usual to other links between Wikipedia/Wiktionary/wiki articles or the web generally. I think having the same thing between Wikipedia and OpenStreetMap wiki would be useful given that there are some articles of a geographical bent that cover the same ground on both wikis.
If this template already exists, I would like to learn about it so I can use it. If it does not exist, I will ask at Wikipedia:Requested_templates/Places_and_things (I am willing to learn how to craft templates and put the work in but I will need help, and if anyone here wants to assist, that would be great). Thanks!
@Vchimpanzee: Did not mean to misrepresent your role! But thanks again for pointing me here. @PrimeHunter: I did see the relation et al templates, thanks for letting me know about the wider category, however. The reason I see no problem with extending it beyond sister projects is that it is not an endorsement of a whole project, just a recommendation for a reader that they may find some additional or recontextualised information on (in this case) the linked OSMwiki page useful given that they are already reading about the topic. So it can even be evaluated on a case-by-case basis as needed to further the encyclopedic goal of WP. Also, OSM and Wikimedia do collaborate quite a bit already, given that both focus on community involvement (wiki-nature) and verifiability. Arlo James Barnes18:45, 5 July 2018 (UTC)
Kludginess in displaying pages and in the wikitext editor
Something weird is going on since the new parser was implemented, both when viewing pages and when editing in the wikitext editor. The window will often hang, and then the contents will shift a little (like it is being rejiggered on the backend or something) then settle, and then it does this again. This is extremely frustrating when it happens in the editing window. I use the most recent version of chrome on a mac desktop and use the default skin with no javascripts or anything. I tried it with the most recent version of Firefox and it replicated there. This is very frustrating. Jytdog (talk) 20:11, 5 July 2018 (UTC)
Probably unrelated to the new parser since the parser is not used for page views. There might be another change in the deployment today which is causing FOUC (or not-quite-styled content). (WP:ITSTHURSDAY) --Izno (talk) 20:29, 5 July 2018 (UTC)
It's never a good idea to install scripts that you know nothing about. You never know what it might do - good or bad. --Redrose64 🌹 (talk) 19:19, 5 July 2018 (UTC)
The answer seems to be, as far as I can tell from reading the code, nothing other than producing a broken link on category pages due to the script being massively out of date. {{3x|p}}ery (talk) 02:30, 6 July 2018 (UTC)
Wikimedia Maps problem
I've reported this on Phabricator (T198235), but since Kartographer is now basically unmaintained because Community Tech have moved onto something else, does anyone know why highway shields in the map in Kartographer and at https://maps.wikimedia.org consisting of numbers only are incorrectly sized? (Images are in the task description.) I'm noting this here because it should be relatively easy to fix for someone who can read and can edit the map stylesheets. Thanks, Jc86035 (talk) 15:44, 6 July 2018 (UTC)
Userpage artificially transcluded into inappropriate category
User:Derkommander0916 is being filed in Category:Templates for railway lines of Malaysia, by virtue of transcluding a Malaysian railway line template on the page. As always, userpages are not supposed to be categorized alongside content in mainspace categories, so this has to be removed — but I can't even find that category declaration in the template, but rather even there it seems to also be an artificial transclusion generated by yet another nested subtemplate I can't identify. Can somebody figure out where this category is coming from so that the userpage can be removed from it? Thanks. Bearcat (talk) 19:12, 5 July 2018 (UTC)
Okay, but I can't fix that — it seems to always autogenerate "Templates for railway lines of (Country)" for every country whose railway lines use a "railway-routemap"-calling template at all, so I can't remove it for Malaysia without completely blowing up the entire forest. Is there any other way to get the user page evicted? Bearcat (talk) 19:25, 5 July 2018 (UTC)
It needs to be templatespace, not main, because the categories are meant to hold templates — you depopulated the categories in the process, exactly as I feared I'd be doing. Bearcat (talk) 19:31, 5 July 2018 (UTC)
Since our last newsletter, the Structured Data team has moved into designing and building prototypes for various features. The use of multilingual captions in the UploadWizard and on the file page has been researched, designed, discussed, and built out for use. Behind the scenes, back-end work on search is taking place and designs are being drawn up for the front-end. There will soon be specifications published for the use of the first Wikidata property on Commons, "Depicts," and a prototype is to be released to go along with that.
The first discussion on copyright and licensing with Commons was held in March. This was a "high level" discussion, there will be a consultation later this summer about the deeper mapping of copyright and licensing in a structured way.
We are still welcoming (more) staff from GLAMs (Galleries, Libraries, Archives and Museums) to become part of our long-term focus group (phabricator task T174134). You will be kept in the loop of the project, and receive regular small surveys and requests for feedback. Get in touch with Sandra if you're interested - your input in helping to shape this project is highly valued!
Two research projects about Wikimedia Commons are currently ongoing, or in the process of being finished:
m:Research:Curation workflows on Wikimedia Commons—a project that seeks to understand the current workflows of Commons contributors who curate media (categorize it, delete it, link to it from other projects, etc.).
The newsletter omitted two interwiki prefixes, breaking the links on non-meta wikis as you might see above. Here are the correct links:
m:Research:Curation workflows on Wikimedia Commons—a project that seeks to understand the current workflows of Commons contributors who curate media (categorize it, delete it, link to it from other projects, etc.).
Hi, WikEd is still giving trouble, but of a different kind from a week or two ago. Then, it was inserting numerous blank lines, creating havoc with list formatting. Now, it closes things up but too vigorously; if one tries to insert blank lines, the result is often paired <div></div> tags instead.
This diff illustrates the thing that I mean. It is a new effect not seen until recently. Hope it can be fixed soon. All the best, Chiswick Chap (talk) 14:26, 16 June 2018 (UTC)
Firefox (most recent version), Win10 64 bit, Monobook. Problem seems to be related to find/replaces with WikiEd, but that could be a coincidence. Headbomb {t · c · p · b}01:16, 18 June 2018 (UTC)
This is still going on. The empty lines still happen, and the div tag seem to be inserted whenever you to a whitespace-related regex. This seems to be caused particularly when copy/pasting new lines. Possible an issue with end-of-line encoding. Headbomb {t · c · p · b}13:25, 6 July 2018 (UTC)
These kinds of issues aren't always an either-or situation; it's possible that it's a bad interaction between WikEd and Firefox, rather than just being one of them to blame. Personally, I'd recommend not using WikEd at all, because it seems to be poorly maintained. --Deskana (talk) 14:43, 7 July 2018 (UTC)
JavaScript page in error tracking category
Why do some js pages end up in an error tracking category such as Category:ParserFunction errors? An example is here. I asked the user about the issue here and mentioned that the js page seems to get parsed as if it were wikitext. That generates errors due to three comments which mention a template, for example {{Aired episodes}}. Viewing the HTML source for the js page shows the error: "Lua error in Module:Template_parameter_value at line 27: attempt to index a nil value" since the template has no parameters. Having the fake error in the tracking category is an irritation to someone who obsesses about cleaning errors but my question is how this happens. Why would template syntax in a js page get parsed with a resulting error category? I don't think this happens in a module. Johnuniq (talk) 09:31, 7 July 2018 (UTC)
js (and css) pages are parsed like wikitext when categories and link tables are made. The result is just ignored when the page is rendered since it automatically gets the page content model "JavaScript". It's deliberate and we use the link tables in some features. For example, speedy deletion nominations of js and css pages place the pages in the right admin-monitored categories even though the nomination box is not shown on the page. User:Anomie/linkclassifier.js asks to install with:
This means uses can be found with Special:WhatLinksHere/User:Anomie/linkclassifier.js. Many scripts do the same. The wikitext processing can be avoided in a js page by starting with a line saying // /* and ending with a line saying // */. Everything inside /* ... */ is a wikitext comment which is ignored in wikitext parsing. Lines starting with // are js comments so the lines but not the lines between them are ignored in JavaScript parsing. PrimeHunter (talk) 10:21, 7 July 2018 (UTC)
I mean // lines are ignored when the JavaScript runs in the account. // is not a wikitext comment so you have to use /* ... */ for that. But /* ... */ is also a JavaScript comment so you cannot place /* ... */ around the whole page. That would prevent the JavaScript from running. But if you start the page with // /* and end it with // */ as I said then the combination works (assuming there are no other /* ... */ in the page). Wikitext processing ignores // and the whole page is commented out. JavaScript running ignores everything after // on a line so // /* ... is a single-line comment and ignores that /* alone would have started a multi-line comment in JavaScript. PrimeHunter (talk) 11:38, 7 July 2018 (UTC)
Another way is to put // <nowiki> at the top and // </nowiki> at the bottom. Everything between the tags won't be processed as wikitext. This is probably more useful for actual scripts rather than for user's common.js or skin-specific js pages, where linkbacks are useful for finding who has installed a script. - Evad37[talk]11:54, 7 July 2018 (UTC)
I don't think that /* ... */ will work to suppress the parsing of templates and links; I'm pretty sure it needs to be the HTML comment tags <!-- ... -->. --Redrose64 🌹 (talk) 15:19, 7 July 2018 (UTC)
Right. I confused the comment tags. It's // <!-- on the first line of a js page and // --> on the last line if you don't want the page to be processed as wikitext when link tables are made. <!-- and --> are invalid JavaScript but that doesn't matter when they are in a JavaScript comment line. <nowiki>...</nowiki> also works. PrimeHunter (talk) 16:22, 7 July 2018 (UTC)
Whitespace at the end of an edit can be automatically removed on save. I don't know the details but the space was left there in a full page edit so it wasn't removed at the time. PrimeHunter (talk) 10:31, 7 July 2018 (UTC)
To editors PrimeHunter and NinjaRobotPirate: thank you for your help! No, I don't have a script that does that, and this is the first time I've ever seen this happen. If the software is automatically making edits while I edit a page, it makes me wonder what else it's doing. It's a bit unsettling to see a diff where there was an edit there that I didn't make. When I look at a diff made by another editor, I've always taken for granted that all the edits in that diff were made by that editor. Now I wonder! (???) Paine Ellsworthput'r there14:25, 7 July 2018 (UTC)
I created a testcase and couldn't replicate it. Assuming it's not caused by a user-script or copy-paste, it must be something in the MW software, intentional or bug, but anyway benign. -- GreenC14:41, 7 July 2018 (UTC)
@Paine Ellsworth and NinjaRobotPirate: - PrimeHunter is on the right lines here. When you edit a section, trailing whitespace is removed from the last line. This is an oversimplification: in more detail, what happens is that when the edit box is first loaded, trailing whitespace (spaces, tabs and newlines) is removed from the last line of text or other markup and replaced with a single newline. You then get the chance to start editing in that edit box. When you use the Publish changes button, trailing whitespace is again removed from the last line and replaced with a single newline (if it is the last section on the page) or with two newlines (if it is not). This has been normal behaviour for as long as I've been around (nine years and counting), evidence from 4 years ago. --Redrose64 🌹 (talk) 14:49, 7 July 2018 (UTC)
Thank you! I tried too and couldn't get it to happen. It does though, judging by Redrose64's sandbox case above. Maybe the software doesn't do it in userspace? Paine Ellsworthput'r there15:34, 7 July 2018 (UTC)
This behaviour is most obvious when you edit a section. It also happens when you edit a whole page, but it's rarely visible since trailing whitespace almost never occurs on the last line of a page. The only instances that I know of are from six or so years ago when somebody used a bot to create a number of redirects which ended with two newlines instead of one. The next edit to the redirect naturally removed the extra newline. --Redrose64 🌹 (talk) 16:22, 7 July 2018 (UTC)
As I said, "Whitespace at the end of an edit can be automatically removed on save". I should apparently have clarified that "the end" really did mean the end and not before section heading code in a full page edit. If you want to see the effect at the current version of User:GreenC/testcases/test then edit the lead section only with [53] and click "Show changes". The diff shows a space at the end of the edit will be removed. Don't save. Others may want to see it. I know four situations where save will not save what is actually in the edit area. 1) Whitespace removal at the end of the whole edit. 2) Signature conversion of three, four or five tildes. 3) Substitution with subst:. 4) The pipe trick on [[...|]]. I haven't tried to save a page above 2 MB but cutting that off may be a fifth case, and there may be more cases I don't know. PrimeHunter (talk) 16:48, 7 July 2018 (UTC)
Re-scheduled deployment of the New Filters on Watchlist
There was a recent announcement about the plans to graduate the New Filters for Edit Review out of beta for this Wiki. The deployment was stalled to fix the performance issue related to the change. The performance of the new interface has been improved significantly as an outcome of the work by the developers [54]. So, the deployment has been re-scheduled. The deployment is scheduled for this wiki on July 16th 2018.
{{GeoGroupTemplate}} is having issues once again, and like normal, the issues are related to the Google Map section. If you go to National Register of Historic Places listings in Westmoreland County, Pennsylvania and click the Google option, you get a 404 error, but if you click the OpenStreetMap option, it places all the coordinates on the map, just like normal. Any idea what's wrong? I've tried the Google link on several different pages, including user:nyttend/sandbox, where I added it two days ago (at which time the Google link was working fine); all pages yield the same good-in-OSM-bad-in-Google results, so it's not some weirdness with the Westmoreland page. Nyttend (talk) 23:14, 7 July 2018 (UTC)
If you attempt to {{ping}} more than 50 users in one post, you receive a system-generated message reading: "You tried to mention more than 50 users. All mentions above that limit were not sent." This implies that the first 50 were sent. However, this does not appear to have happened here—although information is incomplete, all indications are that none were sent. Thus the system-generated message is highly misleading, and in this case resulted in a potentially harmful 3-day delay in notification of previous participants.
The software needs to be changed to send the pings up to the limit as per the message, or to correct the message. My preference is the former. Equally important, the limit should be increased to something that accommodates reasonable legitimate usage, such as 100.
Can someone see if there are existing phab ticket(s) for both issues, or create same?
Finally, the doc for ping (Template:Reply to) is unclear as to whether the limit applies to a single use of the template or to the entire post. I thought it was the former, so I split the 56 users into two templates. Since I received the system-generated message, it appears it's the latter. That needs to be clarified, but that's something we can handle ourselves; I mention it only as a related issue in case anyone has comments. ―Mandruss☎22:25, 3 July 2018 (UTC)
50 is a MediaWiki limit for the whole edit no matter how the users are mentioned. It's controlled by $wgEchoMaxMentionsCount which is 50 for Wikimedia wikis. phab:T144614 ("Inform Flow users when they hit the flow mention limit") lead to gerrit:350887 where MediaWiki:Notification-header-mention-failure-too-many was changed. Before it said: "{{GENDER:$2|Your}} mentions were not sent because they exceeded the limit of $3." Now it says: "{{{GENDER:$2|You}} tried to mention more than $3 {{PLURAL:$3|user|users}}. All mentions above that limit were not sent." According to phab:T144614 the change was made because Flow (an alternative discussion software) does send the mentions below the limit. But it appears the same message is used without Flow where the mentions are not sent, leading to confusion. Flow has been uninstalled at the English Wikipedia so we could create a customized MediaWiki:Notification-header-mention-failure-too-many which ignores Flow and copies the original message. Flow might return at some time and other wikis are affected so somebody should probably file a Phabricator ticket about the issue.
I oppose raising the limit to 100 or sending the first 50 mentions. Users sometimes make huge accidental mentions by transcluding or archiving a page with many linked users, e.g. from old signatures. Mentions are only sent for signed edits but such edits are sometimes signed. The limit helps against meaningless mass mentions. There is rarely a good reason to ping more than 50. Make multiple edits in those cases. PrimeHunter (talk) 23:22, 3 July 2018 (UTC)
Well the one I linked above, for one. But fine, I'll be happy if (1) the message is corrected to reflect what actually happened, so editors know what action to take when they see it, and (2) the doc is made crystal clear that the limit applies to the entire post (it is not even close to that now). ―Mandruss☎23:41, 3 July 2018 (UTC)
Please note mentions have been known to be unreliable, and some editors opt out. If you really have an "important" message to get to many editors a MassMessage may be the better route as its delivery can be better confirmed. — xaosfluxTalk00:00, 4 July 2018 (UTC)
Requires a special user right, apparently, and more work than simple pings. According to Wikipedia:Mass message senders, there are 53 non-admin users who have the right. Clearly pings have a lot more community acceptance/uptake than mass messages, and anybody who opts out is choosing to be left out of mass notifications like the one I linked. ―Mandruss☎01:14, 4 July 2018 (UTC)
Template:Reply to/doc does currently say "Warning: If the total number of detected to-be-pinged users in an edit exceeds 50, no notifications will be delivered." I will add a sentence to clarify that "in an edit" means even spread among multiple templates. --Ahecht (TALK PAGE) 00:01, 4 July 2018 (UTC)
Mandruss, since Flow isn't relevant anymore, I can't see a point to keeping this text in the message. I've accordingly tweaked it: No notifications have been sent.Nyttend (talk) 23:08, 7 July 2018 (UTC)
– This page is for technical issues with what exists, not proposals for what doesn't exist. Not to say that this distinction is widely understood and observed. ―Mandruss☎00:13, 9 July 2018 (UTC)
License for templates?
Wikipedia and other wikis have lots of templates running under the MediaWiki software. Are these templates licensed under the same Creative Commons license as used by wiki page content by default? Or are they GPL'd like the MediaWiki software? SharkD Talk 06:39, 9 July 2018 (UTC)
Same license as every other page on wikipedia, unless otherwise indicated at the top of the page in comments or something. —TheDJ (talk • contribs) 07:31, 9 July 2018 (UTC)
Feature request: backlink hover from citations in Template:Sfn
In Template:sfn in body text one can hover over the reference, [1] {{sfn|Reid|2003|p=3}} and gain the information, "Reid 2003, p. 3." It would be correspondingly useful in the citations to be able to hover over caret in "1. ^ Reid 2003, p. 3." and gain the information, "At the time of the two world wars, Australia and the United Kingdom (UK) had a very close relationship. Australia was a self-governing dominion within the British Empire, and its foreign and defence policies were strongly influenced by those of the British Government. Most Australians were either descended from Britons or had been born in the UK, leading to a widespread perception that Britain was the "Mother Country"."
This feature is envisaged to improve review editing and editing around sourcing in general. It is also envisaged to help reader experience when reading for research purposes. It would cut a considerable time cost in reviewing which an appreciable benefit for the encyclopaedia.
The suggested rule for hover text is:
For a bloc of sfn type citations
Display the preceding body text back to:
The next bloc of sfn type citations, or
The paragraph break
Such that for "¶Foo. [1] Bar. [2(a)][3(b)]" in the citations hovering over 1 renders "Foo.", 2(a) renders "Bar.", and 3(b) renders "Bar."
Could other editors assist with their ideas of the usefulness of moving this forward, and if viewed as useful the manner of doing so? Fifelfoo (talk) 03:20, 8 July 2018 (UTC)
It probably won't be done. It's technically complex and it would be fairly difficult to automatically tell what text an inline citation is being used for. The people at the WMF are also likely to think this isn't very important, especially since you could always… click the caret, and would probably prefer to put their resources into other things (they barely put enough resources into developing software based on volunteer input as it is). Jc86035 (talk) 05:33, 8 July 2018 (UTC)
I think a gadget or another user script could probably make this work to some degree, but I otherwise agree that WMF would not spend time on this. --Izno (talk) 13:13, 9 July 2018 (UTC)
image widths that respond to page width
Is there a way to format a wide image that fits the image as a percentage of the page width or box width, so that it responds to screen width without overflowing or cropping the display?
X201, Upright scales the image as a proportion of default thumbnail size. I am looking for a way to scale as a proportion of page width or box width. Cheers, · · · Peter (Southwood)(talk): 09:41, 6 July 2018 (UTC)
Although this is possible in HTML with a little CSS, as in:
<imgsrc="Example.svg"style="width:50%;"/>
the MediaWiki software does not allow this. The main reason is that image scaling is done server-side, and our servers have no way of knowing how wide your device is. --Redrose64 🌹 (talk) 10:54, 6 July 2018 (UTC)
The software can find the viewport width of the device with CSS media queries, and respond accordingly. This functionality just isn't exposed to editors. TemplateStyles will change that though, and it's due to be enabled soon (phab:T197603), since this wiki was just switched from Tidy to RemexHTML. — AfroThundr (u · t · c)12:08, 6 July 2018 (UTC)
@Pbsouthwood: I'm guessing your question is related to the mainpage images at the wikimania wiki (context/examples always helps!). I think I've fixed them, so that they no longer cause horizontal scrollbars on small windows. I did so by adding an ID to the site's CSS for the mountain image, and an inline layout hack for the logo images. Cheers, Quiddity (talk) 21:01, 8 July 2018 (UTC)
Indirectly, I guess. That came up after the original issue with portals which use relatively wide images for various purposes, includng page banners. · · · Peter (Southwood)(talk): 05:56, 9 July 2018 (UTC)
Yesterday at ANI, I happened upon an edit where instead of pinging someone, a user accidentally transcluded an entire userpage onto the noticeboard. Searching the archives (at ANI and here) reveals that this is far from the first time this has happened. Is there someway we could try to make it a habit to include <noinclude> and similar code in userpages to prevent this from happening as often? Home Lander (talk) 19:37, 9 July 2018 (UTC)
@Xaosflux: Not particularly often, per se, but when it does happen, it tends to break up a noticeboard and can spawn all sorts of pings to users (particularly when lots of barnstars, etc, are on a userpage), who then generally end up here or somewhere else wondering why they were pinged about something that has nothing to do with them. An edit filter sounds like a great idea. Home Lander (talk) 19:48, 9 July 2018 (UTC)
The new version of MediaWiki will be on test wikis and MediaWiki.org from 5 June. It will be on non-Wikipedia wikis and some Wikipedias from 6 June. It will be on all wikis from 7 June (calendar).
You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 6 June at 15:00 (UTC). See how to join.
Fixed with this edit. Galobtter (talk · contribs) had put the 
Resolved
enable the extension at en.wiki.Thankfully,∯WBGconverse 13:38, 18 June 2018 (UTC)
You are invited to join the discussion at Wikipedia talk:TemplateStyles#RFC: Adopt as a guideline. - Evad37 [talk] 08:26, 22 May 2018 (UTC)
Thank you --Redrose64 🌹 (talk) 23:23, 14 June 2018 (UTC)
If I opt for "nothing" in my preferences, is there a way to load the enhanced editor via javascript? I suppose the alternative is to actually opt for the enhanced toolbar in the preferences and do 
(talk) 18:10, 26 June 2018 (UTC)
Fixed I split the page into Australia women's national field hockey team results (2010–14) and Australia women's national field hockey team results (2015–19), which has resolved the issue. As PrimeHunter said, the page hit the limit of how much code it can include from templates. --Ahecht (TALK
![[16]](https://i.imgur.com/jjUqRQt.png){kind=link}
![[17]](https://i.imgur.com/QUMLCFp.png){kind=link}
![[47]](https://i.gyazo.com/eb8aea81ef60dc1f25c8f7a7d13a6696.png){kind=link}
