Wikipedia:Village pump (technical)/Archive 166

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search

Searching logs

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)Reply[reply]

Special:Log needs an exact page name. Administrators can search a string in the title of deleted pages at Special:Undelete. I see: Liquid Glass Nanotech (not an exact match but shows up), Novotech, Novotech (Australia) Pty Limited, Novotech Australia Pty Limited, Novotech Clinical Research, Novotechip. PrimeHunter (talk) 22:31, 3 June 2018 (UTC)Reply[reply]
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)Reply[reply]
A search of Special:Log search at phab: finds many similar requests, e.g. phab:T120764 which lists some of the others. PrimeHunter (talk) 23:20, 3 June 2018 (UTC)Reply[reply]
I see. Thanks. Jytdog (talk) 23:27, 3 June 2018 (UTC)Reply[reply]
This can be done through Quarry, e.g. quarry:query/27387. It's relatively slow - that query took about two minutes. If you run your own (terse instructions here), be aware that log_title uses underscores instead of spaces, and doesn't include the page's namespace. —Cryptic 23:34, 3 June 2018 (UTC)Reply[reply]

Jarry's Template transclusion count missing!

On Special:WhatLinksHere there used to be a link to Jarry's template transclusion counter when you searched for a template, but now it's gone! Does anyone know why, or how I can get it back, or who I have to stab in the kidneys for taking it away in the first place? Primefac (talk) 12:25, 30 May 2018 (UTC) (please ping on reply)Reply[reply]

@Primefac: Per this, for some reason MediaWiki:Linkshere-2 is used instead of MediaWiki:Linkshere. Copying the code of the latter to the former I think should fix it, though why that change was made I have no idea; doesn't seem to have anything to do with the phab task Galobtter (pingó mió) 13:06, 30 May 2018 (UTC)Reply[reply]
(edit conflict) Mediawiki has changed WhatLinksHere from using MediaWiki:Linkshere to using the new MediaWiki:Linkshere-2. The former was customized at the English Wikipedia. The new MediaWiki message is called with the wikilinked page name instead of just the page name. What an annoying and pointless change but we should be able to work around it. I will post to MediaWiki talk:Linkshere#New message name. PrimeHunter (talk) 13:11, 30 May 2018 (UTC)Reply[reply]
@PrimeHunter: It's absolutely not pointless; it allows a full-URL link with redirect=no to be passed in when viewing WhatLinksHere for a redirect page. See phab:rMWac187d902f235cd6e523fff30b2bcb4765e3e75b. It is apparently going to go into the next issue of Tech News. — This, that and the other (talk) 16:16, 31 May 2018 (UTC)Reply[reply]
Heh, I see you commented at phab:T189860 already. — This, that and the other (talk) 16:18, 31 May 2018 (UTC)Reply[reply]
Something else has happened to Special:WhatLinksHere. If you looked at this for a non-existent page, such as Special:WhatLinksHere/Template:WikiProjectBannerShelll, the line "The following pages link to ..." used to have a boldfaced redlink, but now it's a boldfaced bluelink, thus giving the misleading impression that the page exists, when in fact it does not. It means that I'm slowed down when processing Wikipedia:Database reports/Broken WikiProject templates. --Redrose64 🌹 (talk) 16:04, 1 June 2018 (UTC)Reply[reply]
Why is the 'what redirects here' functionality removed? Please restore that! Headbomb {t · c · p · b} 19:11, 1 June 2018 (UTC)Reply[reply]
Blue instead of red link was reported in phab:T195933. A fix should be on the way. Restoration of "Show redirects only" should also be on the way. We made the link at the English Wikipedia in MediaWiki:Linkshere but it uses a MediaWiki feature which was changed in phab:T189860. PrimeHunter (talk) 19:46, 1 June 2018 (UTC)Reply[reply]
Thanks all - I was just about to raise these issues myself. Lugnuts Fire Walk with Me 08:24, 3 June 2018 (UTC)Reply[reply]

Missing functionality

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)Reply[reply]

@John Cline: I moved your post to the existing section. PrimeHunter (talk) 23:23, 3 June 2018 (UTC)Reply[reply]

What links here redirects

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)Reply[reply]

Mobile view

Is there any particular reason why mobile view is the default view for tablets? 78.16.209.113 (talk) 19:30, 4 June 2018 (UTC)Reply[reply]

Tech News: 2018-23

21:54, 4 June 2018 (UTC)

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)Reply[reply]

{{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)Reply[reply]

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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
@John Cline: Please give examples of pages that would benefit by being listed twice in the same category. --Redrose64 🌹 (talk) 07:14, 4 June 2018 (UTC)Reply[reply]
I am literally on my way out the door; almost late, as it is. Off the cuff, John F. Kennedy and Bruno Mars, I'd say. Cheers.--John Cline (talk) 11:42, 4 June 2018 (UTC)Reply[reply]
Which category should list these people twice? --Redrose64 🌹 (talk) 22:38, 4 June 2018 (UTC)Reply[reply]

Beginning of text too close to the top of the page

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)Reply[reply]

I agree! It looks crowded and confusing. NotARabbit (talk) 17:55, 4 June 2018 (UTC)Reply[reply]
Yeah, there is a small problem there. I left a comment at the ticket that I suspect introduced the problem. —TheDJ (talkcontribs) 20:15, 4 June 2018 (UTC)Reply[reply]
See also MediaWiki talk:Gadget-metadata.js#spacing. --Redrose64 🌹 (talk) 22:42, 4 June 2018 (UTC)Reply[reply]

Deformed pie chart

pie chart at the top of Irreligion in the United Kingdom

Does the pie chart at the top of Irreligion in the United Kingdom look deformed to anyone else, or is it just me? DuncanHill (talk) 02:12, 4 June 2018 (UTC)Reply[reply]

Deformed how? It looks correct to me. Chris857 (talk) 03:23, 4 June 2018 (UTC)Reply[reply]
Me too. {{pie chart}} looks like it invokes some serious black magic, though. What browser/version/os/etc? Do the examples at {{pie chart}} and/or {{Graph:PieChart}} look ok? —Cryptic 03:29, 4 June 2018 (UTC)Reply[reply]
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)Reply[reply]
Yeah, it looks slightly taller than wider. Mainly though it is horrifyingly rasterized.. Galobtter (pingó mió) 08:40, 4 June 2018 (UTC)Reply[reply]

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)Reply[reply]

Yes, that is caused by "Use a black background with green text" (example) at Special:Preferences#mw-prefsection-gadgets. {{Pie chart}} uses background-color and the gadget changes background colors. Many things will work poorly with the gadget but you can try posting to MediaWiki talk:Gadget-Blackskin.css. PrimeHunter (talk) 12:32, 4 June 2018 (UTC)Reply[reply]
Interestingly, the example at {{Graph:PieChart}} shews the pie chart correctly, but the text in the key is black, so invisible on a black background. DuncanHill (talk) 13:07, 4 June 2018 (UTC)Reply[reply]
{{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)Reply[reply]
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. — Dispenser 04:14, 5 June 2018 (UTC)Reply[reply]

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)Reply[reply]

You can do that with the API example in sandbox. You might have to do some batching if you want to fetch that many entries though. —TheDJ (talkcontribs) 09:39, 5 June 2018 (UTC)Reply[reply]

Broken IPA templates

{{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)Reply[reply]

 Fixed with this edit. Galobtter (talk · contribs) had put the {{Template for discussion/dated}} outside the <noinclude>...</noinclude>. --Redrose64 🌹 (talk) 16:15, 5 June 2018 (UTC)Reply[reply]

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.

The New Filters introduce an easier yet more powerful user interface to Watchlist as well as a whole list of filters and other tools that make reviewing edits more efficient, including live page updating, user-defined highlighting,the ability to create special-purpose filter sets and save them for re-use and (on wikis with ORES enabled) predictive filters powered by machine learning. If you’re not familiar with the New Filters, please give them a try on Watchlist by activating the New Filters beta feature. In particular, it would be very helpful if you can test the new functionality with your local gadgets and configurations. The documentation pages provide guidance on how to use the many new tools you’ll discover.

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 wrong 16:23, 5 June 2018 (UTC)Reply[reply]

CSD backlog?

CAT:CSD is reporting a backlog even though there are less than 50 items in the cat. — RHaworth (talk · contribs) 12:05, 22 May 2018 (UTC)Reply[reply]

I think the template counts sub-categories as well, so the items might be there only. Regards SoWhy 12:30, 22 May 2018 (UTC)Reply[reply]
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 (11 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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
Only became noticeable this week: {{PAGESINCATEGORY|Candidates for speedy deletion}} currently showing 11, hugely in excess of the actual number: Noyster (talk), 19:19, 24 May 2018 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]

PAGESINCAT miscounting

Category:Candidates for speedy deletion appears to have approximately 110 members, not 11 as {{PAGESINCAT:Candidates for speedy deletion}} claims. What is going on there? Template:CSD summary and other admin backlog templates try to use this number. —Kusma (t·c) 09:02, 29 May 2018 (UTC)Reply[reply]

See #CSD backlog?. --Edgars2007 (talk/contribs) 09:11, 29 May 2018 (UTC)Reply[reply]

Incomplete lines underneath headings

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)Reply[reply]

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)Reply[reply]
”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 (talkcontribs) 03:48, 5 June 2018 (UTC)Reply[reply]
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)Reply[reply]
@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 (talkcontribs) 18:36, 5 June 2018 (UTC)Reply[reply]
@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)Reply[reply]
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. —Cryptic 22:24, 5 June 2018 (UTC)Reply[reply]
@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)Reply[reply]

Is the beta wikitext editor abandoned?

I am using the beta source editor.

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)Reply[reply]

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)Reply[reply]
@Goldenshimmer: What web browser and operating system do you use? --Izno (talk) 22:23, 4 June 2018 (UTC)Reply[reply]
Izno Mozilla Firefox 60 in Gentoo GNU/Linux. —{{u|Goldenshimmer}}|✝️|they/their|😹|T/C|☮️|John 15:12|🍂 22:29, 4 June 2018 (UTC)Reply[reply]
I took a picture of it
Screenshot 2018.06.03 14.59.00 cropped
. —{{u|Goldenshimmer}}|✝️|they/their|😹|T/C|☮️|John 15:12|🍂 22:52, 4 June 2018 (UTC)Reply[reply]
Can you give me the URL that's in that screenshot? It appears to begin https://en.wikipedia.org/w/index.php?title=Tods_shoes#/e but I'm not sure what follows. Whatamidoing (WMF) (talk) 00:44, 5 June 2018 (UTC)Reply[reply]
Whatamidoing_(WMF): I think it was https://en.wikipedia.org/w/index.php?title=Tods_shoes#/editor/0. I just made a similar page, which exhibited a similar button deficit in the editor while creating, and the URL for that was https://en.wikipedia.org/w/index.php?title=Tods_Shoes#/editor/0. —{{u|Goldenshimmer}}|✝️|they/their|😹|T/C|☮️|John 15:12|🍂 00:55, 5 June 2018 (UTC)Reply[reply]
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.
Can you please confirm that Special:Preferences#mw-prefsection-betafeatures says that you have the "New wikitext mode" enabled, and tell me what Special:Preferences#mw-prefsection-editing says about the visual editor and its "Editing mode" (e.g., one tab or two)? Also, have you tried this in a different web browser or kind of computer? Whatamidoing (WMF) (talk) 02:03, 5 June 2018 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]
Oops, it only fixed the missing-buttons issue. The loading issue is still there. Sorry. (Also, after saving an edit, the Edit link goes to https://en.wikipedia.org/w/index.php?title=Special:Badtitle/dummy_title_for_API_calls_set_in_api.php&action=edit&section=40 which shows an error.) —{{u|Goldenshimmer}}|✝️|they/their|😹|T/C|☮️|John 15:12|🍂 19:32, 5 June 2018 (UTC)Reply[reply]
I'm not sure what's going on, so I filed a bug report so the VisualEditor devs can look at it. Whatamidoing (WMF) (talk) 03:51, 6 June 2018 (UTC)Reply[reply]
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)Reply[reply]

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)Reply[reply]

They're already in Category:Pages with script errors. Is there any reason to put them in a less-specific category? Anomie 01:24, 6 June 2018 (UTC)Reply[reply]
No Anomie, there would be no reason for that. It turns out that the pages in Category:Pages with script errors are the antithesis of pages meant for populating the Wikipedia category. Thank you for your response.--John Cline (talk) 09:46, 6 June 2018 (UTC)Reply[reply]

Copyvio tool broken

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."

I tried it on another article as well, and got the same error. Natureium (talk) 15:29, 6 June 2018 (UTC)Reply[reply]

I noticed this too, when I went to work at around 14:30 UTC, but it's back up now. The best place to post for this tool is at the maintainer's talk page (User talk:The Earwig). — Ninja Diannaa (Talk) 16:56, 6 June 2018 (UTC)Reply[reply]
Thanks. Natureium (talk) 17:54, 6 June 2018 (UTC)Reply[reply]
All of Toolforge and VPS was rebooted yesterday around this time. Everything should be back up now MusikAnimal talk 15:22, 7 June 2018 (UTC)Reply[reply]

Module:EditAtWikidata needs a small tweak

If you use {{EditAtWikidata|qid=Q1}}, you get Edit this at Wikidata. If you inspect the link, you see that it links to https://www.wikidata.org/wiki/Q1# rather than https://www.wikidata.org/wiki/Q1 . That should be fixed if possible. Headbomb {t · c · p · b} 00:46, 7 June 2018 (UTC)Reply[reply]

Why is this a problem? {{3x|p}}ery (talk) 01:05, 7 June 2018 (UTC)Reply[reply]
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)Reply[reply]
I edited the module as requested. It should be ok but please check! Johnuniq (talk) 07:46, 7 June 2018 (UTC)Reply[reply]
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)Reply[reply]

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•C 17:20, 7 June 2018 (UTC)Reply[reply]

I am not sure that this will make sense. 6210 is a very large number of possible passwords. Ruslik_Zero 17:31, 7 June 2018 (UTC)Reply[reply]

Messaging users of a particular skin

Is it possible for Wikipedia to target messages at users of a particular skin? DuncanHill (talk) 11:06, 7 June 2018 (UTC)Reply[reply]

@DuncanHill: No. User preferences, including skin, are considered private data, so are not exposed. Jdforrester (WMF) (talk) 18:28, 7 June 2018 (UTC)Reply[reply]
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. — xaosflux Talk 19:42, 7 June 2018 (UTC)Reply[reply]

Weird behaviour at Afd

FR30799386's screenshot

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)Reply[reply]

@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)Reply[reply]
It's on every discussion page. Natureium (talk) 19:51, 5 June 2018 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
Fair enough. Natureium (talk) 23:18, 5 June 2018 (UTC)Reply[reply]
I tried MinervaNeue (if that's the skin in question) on desktop and mobile (FF and Chrome) and I don't see any issue either here, or at Wikipedia:Articles_for_deletion/Daniel_Carver_(3rd_nomination). @FR30799386: would you have a specific page where the issue shows up? Headbomb {t · c · p · b} 20:08, 5 June 2018 (UTC)Reply[reply]
Headbomb-Here is a screenshot...Parts of the text have been chopped off etc. Hope you can help out — FR+ 04:34, 6 June 2018 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
Headbomb, Redrose64:Repinging — FR+ 07:32, 6 June 2018 (UTC)Reply[reply]
What happens if you look at say, Quark. Is the infobox all messed up? Headbomb {t · c · p · b} 08:00, 6 June 2018 (UTC)Reply[reply]
Nope. It is perfectly okay. — FR+ 08:38, 6 June 2018 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]
"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 nowTheDJ (talkcontribs) 05:16, 7 June 2018 (UTC)Reply[reply]
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)Reply[reply]
I cannot help here then. If someone has too much time on their hands they can write a bot and figure it out. —TheDJ (talkcontribs) 19:59, 7 June 2018 (UTC)Reply[reply]

502 Bad gateway for GUC

I'm getting error 502 "Bad gateway" for wmflabs Global User Contributions. Mathglot (talk) 20:26, 6 June 2018 (UTC)Reply[reply]

It's about https://lists.wikimedia.org/pipermail/cloud-announce/2018-June/000054.html, reported at least on phab:T196568. Stryn (talk) 20:54, 6 June 2018 (UTC)Reply[reply]
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)Reply[reply]

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)Reply[reply]

 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? — xaosflux Talk 13:47, 8 June 2018 (UTC)Reply[reply]
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. — xaosflux Talk 13:51, 8 June 2018 (UTC)Reply[reply]
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)Reply[reply]

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)Reply[reply]

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)Reply[reply]
There is no redlink. DuncanHill (talk) 22:43, 7 June 2018 (UTC)Reply[reply]
When I search "hflegicljic", I see:
Search Results
[Search bar]
Content pages: [Multimedia] [Everything] [Advanced]
You may create the page "Hflegicljic".
There were no results matching the query.
When I search "magical of solomon," it's the same deal, except there's results. Ian.thomson (talk) 23:21, 7 June 2018 (UTC)Reply[reply]
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)Reply[reply]
@DuncanHill: With default settings you should still get a red link for salted titles like Roland Baines without quotation marks. What is your skin at Special:Preferences#mw-prefsection-rendering and what is your language at Special:Preferences#mw-prefsection-personal? If you have set the language to British English or Canadian English then you don't get a red link for salted titles but the top of Special:Preferences should give a general warning with MediaWiki:Preferences-summary/en-gb or MediaWiki:Preferences-summary/en-ca, linking to Help:Preferences#Internationalisation. I have tried to suggest a stronger warning in the MediaWiki messages but some users object to indicating that British or Canadian English is a bad choice for interface language. If you have it and decide to keep it then please always mention it when you report issues with interface messages. You should also have mentioned your search term from the start. PrimeHunter (talk) 07:51, 8 June 2018 (UTC)Reply[reply]
Also, what is your setting at Preferences → Search? There are four options here; I use "Classic prefix search". --Redrose64 🌹 (talk) 13:40, 8 June 2018 (UTC)Reply[reply]
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)Reply[reply]

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)Reply[reply]

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)Reply[reply]
Ugh, missed that of course. Thanks for the pointer. –Deacon Vorbis (carbon • videos) 18:13, 8 June 2018 (UTC)Reply[reply]

#ifeq around template:shortcut???

In Wikipedia:Deletion review/Purpose, we've got the following blob of template gunk:

{{#ifeq:{{{shortcut|yes}}}|no||{{shortcut|WP:DRVPURPOSE}}}}

What's the purpose of the #ifeq conditional here? What does this do that plain old:

{{shortcut|WP:DRVPURPOSE}}

wouldn't do with less obfuscation? -- RoySmith (talk) 20:47, 8 June 2018 (UTC)Reply[reply]

@RoySmith: The page is also transcluded at Wikipedia:Closing discussions#Challenging a deletion, where the shortcut is not needed. -- John of Reading (talk) 20:52, 8 June 2018 (UTC)Reply[reply]
Hmmm, I'm still not getting how this is parsed. Looking at Help:Conditional expressions#Using #ifeq, I get as far as:
  • string 1 is "{{{shortcut|yes}}}"
  • string 2 is "no"
  • value if identical is the empty string
  • 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)Reply[reply]
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}}. —Cryptic 21:21, 8 June 2018 (UTC)Reply[reply]
(edit conflict) shortcut is the name of an optional parameter when Wikipedia:Deletion review/Purpose is transcluded. Wikipedia:Closing discussions#Challenging a deletion transcludes it with {{Wikipedia:Deletion review/Purpose|shortcut=no}}. A template (or any other transcluded page) references parameters with triple curly braces like {{{shortcut}}}, or {{{shortcut|X}}} to specify the value X if the shortcut parameter is missing or empty. But if you want to learn template code then please try Help:Template before asking further questions. See e.g. Help:Template#Handling parameters. Wikipedia:Help desk or Wikipedia:Teahouse are better places to ask questions about template coding. PrimeHunter (talk) 21:29, 8 June 2018 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]

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://en.wikipedia.org/..., 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.

Please {{Ping}} me to discuss. --Thnidu (talk) 15:27, 9 June 2018 (UTC)Reply[reply]

@Thnidu: The image is at Commons:Template:Potd/2018-06-03 and the "falls" caption is at Commons:Template:Potd/2018-06-03 (en). I don't know how the mobile apps/view work. Did the mobile view claim that it was today's POTD? -- John of Reading (talk) 15:47, 9 June 2018 (UTC)Reply[reply]
@John of Reading: I believe I first ran into it at commons: Template:Potd/2018-06-03 (en). — Ah, I see the problem now. It is the Picture of the Day for that date on Commons, not on WP. Sorry to have bothered you. --Thnidu (talk) 16:20, 9 June 2018 (UTC)Reply[reply]

Help with Archive navigation

I am trying to set up the archive navigation and it's counting the header User:Tyw7/Archiveheader as an archive. How to avoid this?

See User talk:Tyw7/Archive 3 for an example. --Tyw7  (🗣️ Talk to me • ✍️ Contributions) 18:12, 9 June 2018 (UTC)Reply[reply]

@Tyw7: {{Archive nav}} expects to be passed the number of the archive on which it is being used; if the number is missing, it defaults to 5 for demonstration purposes. I've added code to User:Tyw7/Archiveheader to extract the archive number from the archive page name. -- John of Reading (talk) 18:39, 9 June 2018 (UTC)Reply[reply]
Thanks. That seem to work. --Tyw7  (🗣️ Talk to me • ✍️ Contributions) 18:45, 9 June 2018 (UTC)Reply[reply]

Job queue

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)Reply[reply]

@AKlapper (WMF): Did the job queue die? :D --Izno (talk) 15:27, 8 June 2018 (UTC)Reply[reply]
@Izno: It's not that I run the job queue or can travel back three months in time, sorry. :) You could ask in #wikimedia-tech connect or on wikitech-l@ (or maybe meta:Tech but that looks pretty dead)? Thanks! --AKlapper (WMF) (talk) 16:27, 8 June 2018 (UTC)Reply[reply]
It probably has to do with the transition to a new job queue backend, it seems they didn't implement the reporting yet so the existing interfaces don't report jobs that are in the new queue. Anomie 21:42, 8 June 2018 (UTC)Reply[reply]
@Anomie: When I went to Special:Statistics and clicked the link for the job queue, that also reported 0. Is that the same API? --Izno (talk) 13:23, 10 June 2018 (UTC)Reply[reply]

Change coming to MonoBook skin for mobile users

Hi,

(Unfortunately, my note missed Tech News by a few hours, so I'm posting a special notice here as a heads up, in addition to my wikitech-ambassadors email, and the post here a month ago.)

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).

Thanks! Legoktm (talk) 06:08, 31 May 2018 (UTC)Reply[reply]

Cool deal :-) ~Oshwah~(talk) (contribs) 06:13, 31 May 2018 (UTC)Reply[reply]
  • 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)Reply[reply]
  • 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ИAM 21:51, 31 May 2018 (UTC)Reply[reply]
  • 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)Reply[reply]
  • 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)Reply[reply]
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!
Can you tell us the following things:
  • The name of your device (e.g. Lenovo ThinkPad X230 laptop, iPad Pro 2nd generation, 12.9" screen, etc.)
    • 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.
  • The operating system (OS) of the device
  • The screen resolution of the device
    • 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
    • Internet Explorer, Firefox, Google Chrome, Safari, Firefox for Android (also known as Fennec) and Chromium are some examples of popular web browsers.
    • 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)Reply[reply]
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)Reply[reply]
I think I managed to work out the upload. DuncanHill (talk) 01:40, 1 June 2018 (UTC)Reply[reply]
Horrible icons instead of words
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
@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. Graham87 01:37, 1 June 2018 (UTC)Reply[reply]
Also, how do I disable the jump-to-navigation/search links now? Putting .mw-jump-link{display: none;} in my monobook.css doesn't do it. Graham87 02:01, 1 June 2018 (UTC)Reply[reply]
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?
Your CSS also looks fine to me. --MZMcBride (talk) 02:56, 1 June 2018 (UTC)Reply[reply]
@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. Graham87 03:36, 1 June 2018 (UTC)Reply[reply]
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)Reply[reply]
@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)Reply[reply]
@Krinkle: Thanks, but I already have that code in my monobook.css and it doesn't work. Graham87 03:30, 2 June 2018 (UTC)Reply[reply]
@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)Reply[reply]
@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. Graham87 02:13, 3 June 2018 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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.
Lenovo ThinkCentre 700 desktop PC
Linux Mint 18.1 Cinnamon
1600x900 (zoom at 150%)
Firefox 60.0.1
The problem is on every page.
Sephiroth9611 (talk) 02:42, 1 June 2018 (UTC)Reply[reply]
  • 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)Reply[reply]
  • 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. Seraphimblade Talk to me 04:57, 1 June 2018 (UTC)Reply[reply]
    • What has this got to do with WMF? By the sounds of it, this was an initiative entirely of volunteer developers. — This, that and the other (talk) 09:20, 1 June 2018 (UTC)Reply[reply]
  • 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)Reply[reply]
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)Reply[reply]
  • 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)Reply[reply]
    @BlackcurrantTea: how are you disabling images in your browser? When I tested with images disabled in Firefox, the icons still showed up. Legoktm (talk) 07:49, 2 June 2018 (UTC)Reply[reply]
  • 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, please leave it reverted. BlackcurrantTea (talk) 08:37, 2 June 2018 (UTC)Reply[reply]
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)Reply[reply]
  • (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. --bonadea contributions talk 11:07, 1 June 2018 (UTC)Reply[reply]

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)Reply[reply]

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)Reply[reply]

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)Reply[reply]

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)Reply[reply]
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ИAM 06:16, 2 June 2018 (UTC)Reply[reply]
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)Reply[reply]
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). --bonadea contributions talk 12:42, 1 June 2018 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]

Issues with screen readers etc

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)Reply[reply]
@Isarra: The article/talk access keys don't work; the "edit this page" link (and it turns out all the others!) work fine. Graham87 16:50, 1 June 2018 (UTC)Reply[reply]
@Graham87: Okay, thanks - can you try a hard refresh and let me know if that fixes it? -— Isarra 20:12, 1 June 2018 (UTC)Reply[reply]
@Isarra: Nope, it doesn't. Graham87 03:34, 2 June 2018 (UTC)Reply[reply]
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. Graham87 03:47, 2 June 2018 (UTC)Reply[reply]
@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)Reply[reply]
@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? Graham87 09:50, 2 June 2018 (UTC)Reply[reply]
@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)Reply[reply]

Uses icons instead of text for tab labels

Filed as phab:T196190. Legoktm (talk) 19:29, 1 June 2018 (UTC)Reply[reply]
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)Reply[reply]
The icons are not necessary, the tabs worked perfectly well before. Just bin this change. DuncanHill (talk) 12:29, 1 June 2018 (UTC)Reply[reply]

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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]

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)Reply[reply]
This might not have been the best place to ask. Next time try somewhere a little more public. DuncanHill (talk) 12:23, 1 June 2018 (UTC)Reply[reply]
What's more public than VPT? -— Isarra 13:27, 1 June 2018 (UTC)Reply[reply]
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)Reply[reply]
Quite so, I only come here when things don't work as expected, or I am baffled by something. DuncanHill (talk) 14:55, 1 June 2018 (UTC)Reply[reply]
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. Seraphimblade Talk to me 17:23, 1 June 2018 (UTC)Reply[reply]
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)Reply[reply]
The WMF was actually against this apparently not against it enough to block promoting it to production... — xaosflux Talk 01:34, 4 June 2018 (UTC)Reply[reply]

'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)Reply[reply]

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)Reply[reply]
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)Reply[reply]

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)Reply[reply]
@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)Reply[reply]

Not a problem, just an observation

I saw something about this on the Help Desk, and wanted to comment that when I start a new talk page topic, the line for the heading turns blue.— Vchimpanzee • talk • contributions • 20:59, 6 June 2018 (UTC)Reply[reply]

I don't like it

Everyone who doesn't like this change please sign here.

  1. It is kind of dumb. -— Isarra 12:12, 1 June 2018 (UTC)Reply[reply]
  2. 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)Reply[reply]
  3. Please get rid of it, or move it to a separate skin, or something. It really impairs functionality on the mobile. --bonadea contributions talk 12:45, 1 June 2018 (UTC)Reply[reply]
  4. 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)Reply[reply]
  5. 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)Reply[reply]
  6. Basically what DuncanHill said. Double sharp (talk) 14:43, 1 June 2018 (UTC)Reply[reply]
  7. 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)Reply[reply]
  8. 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. Graham87 16:50, 1 June 2018 (UTC)Reply[reply]
  9. Revert, or restore the original version and have them separate. Preferably immediately. —Xezbeth (talk) 20:50, 1 June 2018 (UTC)Reply[reply]
  10. 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)Reply[reply]
  11. Change things back to the way they were. GoodDay (talk) 22:15, 1 June 2018 (UTC)Reply[reply]
  12. This hasn't affected me, yet, and i don't want it to. Make it opt-in only. DES (talk)DESiegel Contribs 22:45, 1 June 2018 (UTC)Reply[reply]
  13. 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)Reply[reply]
  14. Ugg why oh why is this on by default for desktop?! pull this change back. — xaosflux Talk 03:49, 2 June 2018 (UTC)Reply[reply]
  15. I agree with pretty much everything everybody above said. MANdARAX  XAЯAbИAM 06:20, 2 June 2018 (UTC)Reply[reply]
  16. 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)Reply[reply]
  17. 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)Reply[reply]
  18. 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)Reply[reply]
  19. 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)Reply[reply]
  20. There's no need to dick around with Monobook for this. Make it a new skin. Seraphimblade Talk to me 07:04, 3 June 2018 (UTC)Reply[reply]
  21. 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. SpinningSpark 15:36, 8 June 2018 (UTC)Reply[reply]
  22. 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ölf 15:51, 8 June 2018 (UTC)Reply[reply]
  23. 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)Reply[reply]

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? Seraphimblade Talk to me 17:19, 1 June 2018 (UTC)Reply[reply]

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)Reply[reply]
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)Reply[reply]
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 Contribs 22:44, 1 June 2018 (UTC)Reply[reply]
@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)Reply[reply]
@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. Seraphimblade Talk to me 00:23, 2 June 2018 (UTC)Reply[reply]
@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)Reply[reply]
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)Reply[reply]
@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)Reply[reply]

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)Reply[reply]

@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)Reply[reply]

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)Reply[reply]
(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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
@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)Reply[reply]
I’d appreciate if we could stick to the problems instead of discussing the people. —TheDJ (talkcontribs) 19:57, 2 June 2018 (UTC)Reply[reply]
We were doing that until Skizzerz turned up with his dismissive and patronising posts. DuncanHill (talk) 22:07, 2 June 2018 (UTC)Reply[reply]

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. SpinningSpark 15:44, 8 June 2018 (UTC)Reply[reply]

Revert this

T196212 I've created a request to revert this change in phab:T196212. Feel free to subscribe and continue to comment on it. — xaosflux Talk 03:55, 2 June 2018 (UTC)Reply[reply]

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)Reply[reply]
Thank you thank you thank you. Please do not revert back - please. --bonadea contributions talk 07:50, 2 June 2018 (UTC)Reply[reply]
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. Seraphimblade Talk to me 10:00, 2 June 2018 (UTC)Reply[reply]
Right, as an opt-in change it would be excellent. Just not this forced change for those who are hindered rather than helped by it. --bonadea contributions talk 10:17, 2 June 2018 (UTC)Reply[reply]
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. Seraphimblade Talk to me 10:42, 2 June 2018 (UTC)Reply[reply]
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)Reply[reply]
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? — xaosflux Talk 17:38, 2 June 2018 (UTC)Reply[reply]
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)Reply[reply]
What does "socializing the change" mean? DuncanHill (talk) 20:04, 7 June 2018 (UTC)Reply[reply]
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)Reply[reply]

Wikipedia's font size.

Wikipedia's page display appear to go out of wack, when one has it set at above 150% font size. GoodDay (talk) 22:13, 31 May 2018 (UTC)Reply[reply]

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)Reply[reply]
(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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
Vector default, seems to be the closet to what I previous had. GoodDay (talk) 01:23, 1 June 2018 (UTC)Reply[reply]
Would you consider trying to upload Wikipedia:Screenshots of Wikipedia? Or turn on an e-mail address for a few minutes and send me a note? I can reply, and then you could e-mail the screenshot to me. Whatamidoing (WMF) (talk) 18:25, 1 June 2018 (UTC)Reply[reply]
This is connected to what's being discussed in the preceding discussion. GoodDay (talk) 22:12, 1 June 2018 (UTC)Reply[reply]
I've had the same problem, with the same solution. Reducing the font size restores normalcy. Bus stop (talk) 07:00, 2 June 2018 (UTC)Reply[reply]

Update, and opt-out details

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)Reply[reply]

Why it opt-out instead of opt-in? DuncanHill (talk) 10:29, 7 June 2018 (UTC)Reply[reply]
And, as noted above, this is not a widely-read noticeboard. Will there be wider publicity for this? DuncanHill (talk) 10:34, 7 June 2018 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]
@DuncanHill: we are usually much more liberal with watchlist messaging then sitenotices, drop an edit request at MediaWiki talk:Watchlist-messages for discussion, if it gets support (or lacks opposition) we can spin it up pretty easily. — xaosflux Talk 19:50, 7 June 2018 (UTC)Reply[reply]
Done. Why is it opt-out instead of opt-in? DuncanHill (talk) 20:02, 7 June 2018 (UTC)Reply[reply]
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)Reply[reply]
I suppose a more flexible question here would be, is the opting default something that can be configured per project? — xaosflux Talk 00:00, 8 June 2018 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]

Need help with complex template formatting

Template:Lynching in the United States, section “Victims”. Can it be made collapsible (3 different bars) without destroying the structure? Thanks. The Teahouse referred me here. deisenbe (talk) 20:18, 10 June 2018 (UTC)Reply[reply]

There is no standard way to do this. However you can use {{Navbox with collapsible groups}} to combine several navboxes like in {{Universe_navboxes}}. Ruslik_Zero 08:17, 11 June 2018 (UTC)Reply[reply]

Problems of articles about Ukraine

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.


For example this architect https://en.wikipedia.org/wiki/Talk:Alexey_Dushkin

- 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)Reply[reply]

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. -- GreenC 13:58, 11 June 2018 (UTC)Reply[reply]

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)Reply[reply]

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)Reply[reply]
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 (utc) 00:59, 11 June 2018 (UTC)Reply[reply]
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)Reply[reply]
Yes, you need to wait for all the JavaScript to finish. Which on occasion, is never. --Redrose64 🌹 (talk) 19:22, 11 June 2018 (UTC)Reply[reply]

Font size in "Search Wikipedia" box

Resolved

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)Reply[reply]

I don't know why it changed for you but try this in your CSS to override whatever changed it:
#searchform {font-size: 16px;}
It works when previewing if you want to easily experiment with different sizes. PrimeHunter (talk) 18:45, 11 June 2018 (UTC)Reply[reply]
That did it. Thanks. -- llywrch (talk) 20:59, 11 June 2018 (UTC)Reply[reply]

Tech News: 2018-24

21:55, 11 June 2018 (UTC)

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.

Example: "CS1 errors: dates‎ (2 C, 28,984 P)". – Jonesey95 (talk) 21:25, 11 June 2018 (UTC)Reply[reply]

It sounds like the same issue as #CSD backlog? with work at phab:T195397. PrimeHunter (talk) 08:27, 12 June 2018 (UTC)Reply[reply]

Update on page issues on mobile web

CKoerner (WMF) (talk) 20:58, 12 June 2018 (UTC)Reply[reply]

hide watch list message cookies disappearing

Hi, see discussion at MediaWiki_talk:Watchlist-messages#dismissed_messages_keep_appearing_again if you have any feedback about problems with your watchlist cookies not working. — xaosflux Talk 17:45, 13 June 2018 (UTC)Reply[reply]

Read-only for 30 minutes on July 18 06:00 UTC

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.

If everything goes well, this should just take a few minutes, but prepare for 30 minutes to be on the safe side. /Johan (WMF) (talk) 14:29, 14 June 2018 (UTC)Reply[reply]

You can read more in the tasks linked to from phab:T197134. /Johan (WMF) (talk) 14:34, 14 June 2018 (UTC)Reply[reply]

Template problem buried somewhere

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)Reply[reply]

NEVER MIND! I finally thought to try null edits on all the pages, and poof, they’re fine. Sigh. NotARabbit (talk) 06:45, 15 June 2018 (UTC)Reply[reply]

Potentially untagged misspellings report

Hi! Potentially untagged misspellings (configuration) is a newish database report that lists potentially untagged misspellings. For example, Angolan War of Independance is currently not tagged with {{R from misspelling}} and it should be.

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)Reply[reply]

MZMcBride, how often will the database report be updated? Is there a tracking strategy? NotARabbit (talk) 05:15, 15 June 2018 (UTC)Reply[reply]
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)Reply[reply]
I started tracking my edits at the talk page, as well as posting a couple of notes. It’s a slow process! NotARabbit (talk) 06:34, 15 June 2018 (UTC)Reply[reply]
There is a list in machine-readable format at Wikipedia:AutoWikiBrowser/Typos. I wonder if these should be the same list? :) --Izno (talk) 12:12, 15 June 2018 (UTC)Reply[reply]
Yes, potentially. :-) --MZMcBride (talk) 14:59, 15 June 2018 (UTC)Reply[reply]

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)Reply[reply]

Wikiproject front page displaying bizarrely

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)Reply[reply]

I see a bunch of redlinks to Portal:Cornwall/box-footer on that page. Was it important? Chris857 (talk) 13:34, 13 June 2018 (UTC)Reply[reply]
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)Reply[reply]
Portal:Cornwall/box-footer only called {{Box-footer}}. I have called it directly instead.[14] I think Pbsouthwood should have done that before deleting the page. PrimeHunter (talk) 13:42, 13 June 2018 (UTC)Reply[reply]
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)Reply[reply]
The edit links in the boxes have been restored with [15]. I guess it's intentional that there are no section edit links. PrimeHunter (talk) 14:03, 13 June 2018 (UTC)Reply[reply]
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)Reply[reply]
Adding |EDIT=yes to Portal:Cornwall/box-header should give section edit links if the project wants it. PrimeHunter (talk) 14:18, 13 June 2018 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
I agree.    — The Transhumanist   21:32, 15 June 2018 (UTC)Reply[reply]

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)Reply[reply]

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://en.wikipedia.org/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://en.wikipedia.org/wiki/. PrimeHunter (talk) 09:58, 16 June 2018 (UTC)Reply[reply]

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)Reply[reply]

Mobile site broke on Windows Phone

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:

  1. 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.
  2. 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.

Was the mobile site upgraded recently, and has anyone else tried it on WinPho? David Brooks (talk) 00:31, 10 June 2018 (UTC)Reply[reply]

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|Geld 00:44, 10 June 2018 (UTC)Reply[reply]
@DaneGeld: @DavidBrooks: could this be related to Wikipedia:Village_pump_(technical)#Change_coming_to_MonoBook_skin_for_mobile_users? DuncanHill (talk) 13:30, 10 June 2018 (UTC)Reply[reply]
@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)Reply[reply]
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)Reply[reply]
@DavidBrooks: @DaneGeld: I'm not aware of any changes to the mobile site that would cause this, but I don't know everything. :) I've created a phabricator task to have the engineers take a look. CKoerner (WMF) (talk) 12:53, 11 June 2018 (UTC)Reply[reply]
Hey there @DavidBrooks: @DaneGeld:! Could I please ask for which user agent your mobile device has? http://www.whatsmyua.info/ provides an easy way to copy and paste. Jdlrobson (talk) 20:14, 11 June 2018 (UTC)Reply[reply]
@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)Reply[reply]
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)Reply[reply]
Thank you for looking into it! David Brooks (talk) 22:27, 12 June 2018 (UTC)Reply[reply]
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)Reply[reply]

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)Reply[reply]

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)Reply[reply]
@Xaris333: Or even an article where it is happening. Examples almost always help on VPT. --Redrose64 🌹 (talk) 21:45, 16 June 2018 (UTC)Reply[reply]
Problem solved. Thanks. Xaris333 (talk) 16:56, 17 June 2018 (UTC)Reply[reply]

Pending changes reviews and edit summaries

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? Snow let's rap 22:39, 16 June 2018 (UTC)Reply[reply]

@Snow Rise: Maybe I'm not understanding quite what you're describing, but I just reverted my own pending change using Twinkle and was able to type a long edit summary. Is that a work-around? Home Lander (talk) 01:24, 17 June 2018 (UTC)Reply[reply]
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. Snow let's rap 02:41, 17 June 2018 (UTC)Reply[reply]
The task to watch is phab:T194588. --Izno (talk) 13:09, 17 June 2018 (UTC)Reply[reply]
Ah, much obliged! I figured someone must have gotten there ahead of me. Snow let's rap 21:26, 17 June 2018 (UTC)Reply[reply]


RfC: Enabling TemplateStyles

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.
There is a clear consensus to checkY enable the extension at en.wiki.Thankfully,WBGconverse 13:38, 18 June 2018 (UTC)Reply[reply]

Should Extension:TemplateStyles (help) be enabled on the English Wikipedia as soon as technically possible? Jc86035 (talk) 12:28, 18 May 2018 (UTC)Reply[reply]

Background

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.

Examples

Survey

  • Support. Jc86035 (talk) 12:28, 18 May 2018 (UTC)Reply[reply]
  • Yesss Galobtter (pingó mió) 16:00, 18 May 2018 (UTC)Reply[reply]
  • Yes please. I have lots of templates that i could fix if only I had these capabilities. —TheDJ (talkcontribs) 17:37, 18 May 2018 (UTC)Reply[reply]
  • Support - I can think of excellent use cases for this - making templates responsive with media queries is the first one that comes to mind. Richard0612 17:48, 18 May 2018 (UTC)Reply[reply]
  • 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)Reply[reply]
  • Maybe? I'd like to use an actual use / example before deciding. Headbomb {t · c · p · b} 22:34, 18 May 2018 (UTC)Reply[reply]
    • @Headbomb: A small example can be seen at mw:Template:ResponsiveAmboxExample, the image gets hidden if your browser window is narrow enough. Think of doing something similar with navboxes so the mobile site can stop hiding them. Anomie 07:46, 19 May 2018 (UTC)Reply[reply]
      • 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)Reply[reply]
  • 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)Reply[reply]
  • 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)Reply[reply]
  • 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 (utc) 11:58, 19 May 2018 (UTC)Reply[reply]
  • Support This sounds great. I was concerned about mal-use but the measures in place look well thought-out. Cesdeva (talk) 07:23, 22 May 2018 (UTC)Reply[reply]
  • 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)Reply[reply]
  • 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)Reply[reply]
  • 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 (tc) 07:48, 27 May 2018 (UTC)Reply[reply]
  • 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)Reply[reply]
  • Support, it's high time! – Uanfala (talk) 10:42, 9 June 2018 (UTC)Reply[reply]

Discussion (TemplateStyles)

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)Reply[reply]

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)Reply[reply]
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 (talkcontribs) 17:37, 18 May 2018 (UTC)Reply[reply]
+1 for banning position:absolute and other crimes against design. :P Richard0612 17:50, 18 May 2018 (UTC)Reply[reply]
@Richard0612: I think a blanket ban on position:absolute wouldn't be very practical, since there are e.g. 26 Lua modules which use it for largely legitimate purposes such as overlaying images. Jc86035 (talk) 17:57, 18 May 2018 (UTC)Reply[reply]
@Jc86035: I was being entirely flippant with my comment - of course it does have sensible uses (image overlays, charts, etc.) and shouldn't be banned. I've just seen a lot of user-space z-order abominations (not that I like CSS much as a technology anyway, but it's the best we have). Richard0612 18:05, 18 May 2018 (UTC)Reply[reply]
It seems I left my irony–sarcasm meter off. Jc86035 (talk) 18:07, 18 May 2018 (UTC)Reply[reply]
Easily done, no harm! :) Richard0612 18:10, 18 May 2018 (UTC)Reply[reply]

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)Reply[reply]

It would be in the Template: namespace, and protection could be applied as needed. High-exposure pages will inevitably be TE-protected. Richard0612 21:30, 18 May 2018 (UTC)Reply[reply]
Thanks. epicgenius (talk) 22:30, 18 May 2018 (UTC)Reply[reply]

I started a draft guideline page at Wikipedia:TemplateStyles; it could do with some expansion and/or discussion - Evad37 [talk] 02:48, 19 May 2018 (UTC)Reply[reply]

  • 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. — xaosflux Talk 21:51, 19 May 2018 (UTC)Reply[reply]
    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)Reply[reply]
    @JJMC89: perhaps that is a side affect of having that extension installed...currently template subpages ending in .css are in model wikitext (e.g. Template:X1/style.css). — xaosflux Talk 23:37, 19 May 2018 (UTC)Reply[reply]
    Yes. You should be able to test on testwiki. — JJMC89(T·C) 00:39, 20 May 2018 (UTC)Reply[reply]
    Saw it there, sample for anyone watching at testwiki:Template:-/test.css. — xaosflux Talk 01:10, 20 May 2018 (UTC)Reply[reply]

If allowed - default protection?

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? — xaosflux Talk 21:47, 19 May 2018 (UTC)Reply[reply]

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 (utc) 01:02, 20 May 2018 (UTC)Reply[reply]
Why should the styles of a template be harder to edit that the template itself. {{3x|p}}ery (talk) 01:04, 20 May 2018 (UTC)Reply[reply]
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)Reply[reply]
Or just create a category akin to Category:Templates using under-protected Lua modules. {{3x|p}}ery (talk) 03:47, 20 May 2018 (UTC)Reply[reply]
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
body { /* ... */ }
- this could potentially compromise all pages using that template. --Redrose64 🌹 (talk) 09:51, 20 May 2018 (UTC)Reply[reply]
The styles are scoped to prevent that kind of thing - basically you can't mess with anything that isn't contained in an element with the class .mw-parser-output. There's still potential for abuse, don't get me wrong, but it's not that bad. Richard0612 10:33, 20 May 2018 (UTC)Reply[reply]
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)Reply[reply]
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. Richard0612 20:20, 20 May 2018 (UTC)Reply[reply]

Discussion at Wikipedia talk:TemplateStyles#RFC: Adopt as a guideline

 You are invited to join the discussion at Wikipedia talk:TemplateStyles#RFC: Adopt as a guideline. - Evad37 [talk] 08:26, 22 May 2018 (UTC)Reply[reply]

Deployment of TemplateStyles

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)Reply[reply]

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.

Vocea României Junior (season 2)

Hello, can someone edit this page? I tried my best, but it isn't complete. --Monsterofain (talk) 14:10, 18 June 2018 (UTC)Reply[reply]

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)Reply[reply]

Indenting ":" doesn't work to right of image: should it?

Please see this edit.

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.)

--76.69.118.94 (talk) 22:12, 17 June 2018 (UTC)Reply[reply]

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)Reply[reply]
20 colons (before image)
Image with |thumb|left

No indentation in this line

  • 1 asterisk
            • 5 asterisks
1 colon
5 colons
20 colons
@76.69.118.94 and PrimeHunter: You can fix this by surrounding the text with <div class="flowlist">...</div>. See Special:Diff/846413082 for an example. --Ahecht (TALK
PAGE
) 16:32, 18 June 2018 (UTC)Reply[reply]

Editor not redirecting to a display URL after completing

[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://en.wikipedia.org/wiki/Wikipedia:Teahouse?action=edit#Disputed_text

I'm using Firefox, but I'm pretty sure I saw this in Opera recently as well. --ColinFine (talk) 10:35, 16 June 2018 (UTC)Reply[reply]

What editor are you using? 2017 Wikitext editor? Visual Editor? Another? --Izno (talk) 13:31, 16 June 2018 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]
@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)Reply[reply]
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)Reply[reply]
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://en.wikipedia.org/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)Reply[reply]
I've just opened one. Jc86035 (talk) 16:37, 18 June 2018 (UTC)Reply[reply]

Pageview data missing for June 14

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)Reply[reply]

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)Reply[reply]
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] MusikAnimal talk 15:32, 15 June 2018 (UTC)Reply