Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia
  (Redirected from Wikipedia:VPT)
Jump to navigation Jump to search
  Policy   Technical   Proposals   Idea lab   Miscellaneous  
The technical section of the village pump is used to discuss technical issues about Wikipedia. Bug reports and feature requests should be made in Phabricator (see how to report a bug). Bugs with security implications should be reported differently (see how to report security bugs).

Newcomers to the technical village pump are encouraged to read these guidelines prior to posting here. If you want to report a JavaScript error, please follow this guideline. Questions about MediaWiki in general should be posted at the MediaWiki support desk.

Frequently asked questions (FAQ) (see also: Wikipedia:FAQ/Technical)
Click "[show]" next to each point to see more details.
If something looks wrong, purge the server's cache, then bypass your browser's cache.
This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown.
Font size changed unexpectedly?
You may have accidentally changed the font size on your browser for a particular website by pressing a shortcut key or scrollwheel without realising it. Try resetting the zoom with Ctrl+0 (typing the digit zero while holding down the control key) or adjusting the zoom with Ctrl++ or Ctrl+-. Alternatively, look for the View option on your browser's menu and reset it to 100%.
No, we will not use JavaScript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See bug 1864. There is an accesskey property on it (default to accesskey="f" in English), and for logged in users there is a gadget available in your preferences.
No, we will not add a spell-checker, or spell-checking bot.
You can use a web browser such as Firefox, which has a spell checker.
If you have problems making your fancy signature work, check Wikipedia:How to fix your signature.
If you changed to another skin and cannot change back, use this link.
Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem.
If an image thumbnail is not showing, try purging its image description page.
If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear.
Numbers listed in parentheses in the "Recent changes" section, on history pages and in your watchlist are the number of added or removed bytes.
For server or network status, please see Public Website Health Status for Wikimedia Foundation - Core services.
Questions and suggestions related to the portal should go to Meta.
« Older discussions, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166


RfC: Enabling TemplateStyles

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


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.


  • mw:Template:Stylish (css)
  • mw:Template:ResponsiveAmboxExample (css)


  • Support. Jc86035 (talk) 12:28, 18 May 2018 (UTC)
  • Yesss Galobtter (pingó mió) 16:00, 18 May 2018 (UTC)
  • 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)
  • 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)
  • 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)
  • Maybe? I'd like to use an actual use / example before deciding. Headbomb {t · c · p · b} 22:34, 18 May 2018 (UTC)
    • @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)
      • So basically, this can't (at least straightforwardly) change say an existing string to a different string, but would rather apply things like font changes, width changes, and other CSS type of changes on a per-template basis? I think we still ought to have some restrictions on that (Evad37's restrictions/best practices below seem very reasonable) especially for accessibility reasons, but I don't why what that couldn't be rolled out now (i.e. support), with the understanding that people using this are careful/use WP:COMMONSENSE. Headbomb {t · c · p · b} 11:43, 19 May 2018 (UTC)
  • Conditional support, if we get some sort of guidelines and/or best-practices in place first. Stuff like "only style the template's output", "avoid using !important", "use selectors and class names that are highly likely to be unique to that template (i.e. myTemplate-row rather than row)", "only images which don't require attribution can be used as background images". - Evad37 [talk] 02:01, 19 May 2018 (UTC)
  • Support I've been waiting a long time for this. This will allow us to fix a lot of templates for mobile, and also to reduce the size of the HTML we produce by getting rid of duplicated inline CSS. — Mr. Stradivarius ♪ talk ♪ 07:38, 19 May 2018 (UTC)
  • Sure, seems useful. I'd worry about abuse and keeping track of it all — it seems like the potential for pages could be huge — and would definitely support some level of baseline protection status (probably AC default, elevate to TE if heavily used). Basically, if TheDJ and Stradivarius think it'd be good, it's probably good. ~ Amory (utc) 11:58, 19 May 2018 (UTC)
  • 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)
  • Support It looks like it would be useful. Guidance will be developed in the usual way. There may be occasional misuses but they will be reversible. I assume changes will show up on watchlists in the usual way? · · · Peter (Southwood) (talk): 08:29, 22 May 2018 (UTC)
  • Support Not having any useful way to code responsively (or even use CSS correctly) is a real pain, it's like trying to build a car with no wheels and the wrong chassis, and it makes everything on wikipedia look like it's from the early 2000's. Because it is. This would be so helpful. JLJ001 (talk) 17:19, 24 May 2018 (UTC) SOCKSTRIKE. Primefac (talk) 18:37, 31 May 2018 (UTC)
  • Support As long as we have guidelines in place to control how this is used. We don't want editors going wild with this. — AfroThundr (tc) 07:48, 27 May 2018 (UTC)
  • Conditional support, per Evad37. I was going to saying something like this myself (and I think I did in a previous round), but Evad37's got the gist of that minor issue. I fully support going forward with this feature implementation, it just can't be dumped on the community without pre-addressing the potential problem points.  — SMcCandlish ¢ 😼  04:24, 2 June 2018 (UTC)
  • Support, it's high time! – Uanfala (talk) 10:42, 9 June 2018 (UTC)

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)

Hmm, people who make use of it should I hope make sure their styling does not affect the rest of the page/other templates but only the target template. People who vandalize can perfectly well cover screen-fuls of page with image vandalism so not going to dramatically up the possibilities of vandalism Galobtter (pingó mió) 16:00, 18 May 2018 (UTC)
Correct, but if that becomes unmanageable, we could elevate edit permissions to templateeditor or something. the benefits will outweigh the negatives. Besides. postion:absolute bothers me on half the user pages and that seems perfectly acceptable to the community. —TheDJ (talkcontribs) 17:37, 18 May 2018 (UTC)
+1 for banning position:absolute and other crimes against design. :P Richard0612 17:50, 18 May 2018 (UTC)
@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)
@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)
It seems I left my irony–sarcasm meter off. Jc86035 (talk) 18:07, 18 May 2018 (UTC)
Easily done, no harm! :) Richard0612 18:10, 18 May 2018 (UTC)

So for this custom CSS, which namespace would it be hosted in? Would users be restricted from editing these CSS pages (e.g. limiting these pages to administrators/template-editors only)? epicgenius (talk) 21:19, 18 May 2018 (UTC)

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

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)

  • 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)
    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)
    @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)
    Yes. You should be able to test on testwiki. — JJMC89(T·C) 00:39, 20 May 2018 (UTC)
    Saw it there, sample for anyone watching at testwiki:Template:-/test.css. — xaosflux Talk 01:10, 20 May 2018 (UTC)

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)

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)
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)
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)
Or just create a category akin to Category:Templates using under-protected Lua modules. {{3x|p}}ery (talk) 03:47, 20 May 2018 (UTC)
If a template is unprotected, presumably its css page would also be unprotected. What would there be to prevent a rule being maliciously added to that css page? For example, one having a selector that is not specific to the template's code, but perhaps matches some other part of a page - maybe as broad as
body { /* ... */ }
- this could potentially compromise all pages using that template. --Redrose64 🌹 (talk) 09:51, 20 May 2018 (UTC)
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)
It says "Styles included by a template can currently affect content on the page outside of the content generated by that template" which is what I am worried about. --Redrose64 🌹 (talk) 20:06, 20 May 2018 (UTC)
Oh that's true, absolutely. If there's (e.g.) a div on the page that the CSS selects, it'll be affected. But the styles couldn't affect the body or any other elements of the interface. Then again, if a vandal could edit the CSS to cause chaos, they could edit the template itself to cause chaos. Hence the logic that the CSS should have the same level of protection as its parent template. Richard0612 20:20, 20 May 2018 (UTC)

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)

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)

Change coming to MonoBook skin for mobile users


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

Cool deal :-) ~Oshwah~(talk) (contribs) 06:13, 31 May 2018 (UTC)
  • Well the usual question, how does one get the previous layout back as the default on the "Desktop version" without having to set the desktop setting every time in the mobile browser? —Mr. Matté (Talk/Contrib) 20:36, 31 May 2018 (UTC)
  • This is horrible. And it's impossible to get the good layout on an iPad. In Safari, "Request Desktop Site" takes me to the mobile site. I then either request it again or scroll down and select "Desktop", and I'm back where I started. It doesn't work in Chrome either. The ability to permanently opt out of this is desperately needed. MANdARAX  XAЯAbИAM 21:51, 31 May 2018 (UTC)
  • I would have to agree. If I wanted nesting menus, I would just use a desktop program. I'm trained on using Monobook on all of my devices, no matter how kludgy it might be on an iPhone screen. The icons are too random and so tiny as to be useless to contextualize the menu option beneath it; if I'm keeping this I'd like the option to use text titles. I'm annoyed enough with the WP app wanting to grab anything I surf to, and this doesn't help mobile browsing/editing. Nate (chatter) 22:18, 31 May 2018 (UTC)
  • Is this what's screwed up the screen when I request the desktop site on mobile? I now get some horrible and meaningless icons at the top of the screen. Please stop "improving" things by making them worse. DuncanHill (talk) 22:51, 31 May 2018 (UTC)
Chiming in as the developer who approved the relevant patchsets and who has been working closely with Isarra on this...
First of all, thank you for providing feedback! Given that a lot of volunteer time and effort has been put into testing this change and ironing out bugs, it's surprising to see that some persistent bugs are still present — and I'm hoping you can help us squash those bugs for once and for all!
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 devices are ubiquitous these days. The MonoBook skin was written originally in 2004, back when almost nobody had heard the words "responsive web design"; if MonoBook were written today, it would naturally feature responsiveness since in 2018 — and, frankly, for many years before, responsiveness has been a de facto standard for most web sites out there; MediaWiki has and still is lagging behind, partially because Wikipedia and other Wikimedia sites (Wiktionary, Wikivoyage, etc.) use the MobileFrontend extension to serve a rather different view to users of mobile devices. --Jack Phoenix (Contact) 00:49, 1 June 2018 (UTC)
Samsung Galaxy J3 SM-J320FN, Android 5.1.1, Chrome 66.0.3359.158 (32 bit), screen 360x640. I have lost the talk/edit/history etc tabs at the top of the page, they have been replaced by illegible and meaningless icons. I can't see an option on the upload wizard for Wikipedia screenshots. DuncanHill (talk) 01:26, 1 June 2018 (UTC)
I think I managed to work out the upload. DuncanHill (talk) 01:40, 1 June 2018 (UTC)
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)
They take up more space than the text, and are not by any means as readily understandable. One of the reasons I like monobook is because the tabs are so much clearer to me than on the other skins. They also make me have to click twice for some functions that I only had to click once for before. Also, PLEASE DO NOT PING OR @ ME. Getting rid of the notification on the new display is a pig. And more, it makes the desktop display on a mobile much more like the mobile site display, which is exactly what I'm trying to avoid. It makes articles take more scrolling to get through, contents lists take up the whole damn width of the screen, pictures take up the whole width. It's nasty. DuncanHill (talk) 02:59, 1 June 2018 (UTC)
Yes, exactly this. I would imagine that if someone is deliberately using the desktop view on mobile devices, he or she probably is used to the desktop view and wants it to look exactly the same on all devices. Responsive web design is exactly the opposite of what such users want. They like one view and don't want it to change, and they would like to keep using it everywhere. And at least my personal opinion places no weight on "lagging behind" when the desktop view has already been very optimised for editing; if we change it, it should be because something actually is broken, not to keep up with the Joneses. It strikes me that these efforts would be better spent on the mobile view, where they would be aimed at a public that actually wants this. A pertinent question might be if anyone on WP actually asked for this, or if it was simply imposed because some higher-ups from the WMF decided we had to keep up with the Joneses (never mind that the Joneses are doing something completely different and have completely different needs). An even more pertinent question might be if anyone actually realised the counterproductiveness of applying responsive web design to the desktop view on mobile devices. Double sharp (talk) 03:32, 1 June 2018 (UTC)
Something I've forgotten to add is that editing on the desktop view even on a mobile device allows you to do layout fixes even when not on a desktop, with the desktop view as the showcase one as it ought to be (there you have the biggest screen and the most complete experience, after all; it's quite difficult to research and edit on a smartphone simultaneously due to the amount of tab-swapping needed, so while it could be done, I do most of my large edits on the desktop). On the mobile view and this responsive quasi-mobile view, this can't be checked because pictures take up the whole width and override any chosen settings (never mind the mistakes that sometimes result when this is done, like unscrollable images that spill off the screen). Double sharp (talk) 06:13, 1 June 2018 (UTC)
I see, from Isarra's comment further down, that (to quote her) "the WMF was actually against this, as they feared pretty much precisely this reaction, which just goes to show that they have learned from previous incidents". I find this quite heartening and agree with her that it shows they've learned. I also see the link below showing where this was previously discussed, albeit without much publicity. Nevertheless, I still wonder if anybody along the lines realised the counterproductiveness of this, because the only people who are likely to see this are the people who are likely not to want it. Double sharp (talk) 10:37, 2 June 2018 (UTC)
@Jack Phoenix and Isarra: Please provide a way to permanently revert/disable this feature; as a screen reader user, I have no interest in it and never will (not to mention that it disables the access keys). I receive it in desktop view on my 15.6-inch laptop (!), a 2012 HP Pavilion dv6 Notebook PC running Windows 10 with a screen resolution of 1366×768 (the maximum) in IE11 when the window is restored (but not when it is maximised, and not at all in FF57). IE11 is easiest to use here for various screen-reader-related reasons, and Edge is not an option. Graham87 01:37, 1 June 2018 (UTC)
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)
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)
@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)
There was a separate change to the jump links this week: phab:T195256. I haven't investigated yet whether that could be related, but just mentioning it for completeness. Legoktm (talk) 05:49, 1 June 2018 (UTC)
@Graham To disable the jump-to links, use .mw-jump-link{display: none;}. Notice the class name containing "link". The explicit disabling of accessibility links (in addition to being visually hidden by default) is not something MonoBook offered officially before, but I hope this snippet helps you to keep disabling it. Krinkle (talk) 20:42, 1 June 2018 (UTC)
@Krinkle: Thanks, but I already have that code in my monobook.css and it doesn't work. Graham87 03:30, 2 June 2018 (UTC)
@Graham: That's unfortunate. Which browser and operating system are you experiencing this on? I have tried myself with MonoBook in IE 11 on Windows 8, and also in Chrome and Firefox on macOS. Without the change to monobook.css it is visually hidden but becomes visible when tabbed to. With the change to monobook.css it is always hidden and not part of the accessibility tree and tab sequence. I have also tried adding the rest of your monobook.css customisations and are still not able to reproduce the issue. --Krinkle (talk) 21:05, 2 June 2018 (UTC)
@Krinkle: Hmmm, that's really weird! I get it in all combinations of JAWS/NVDA, the two most popular Windows screen readers, with IE11/FF60 unnder Windows 10. Could be a screen reader thing. After a couple of days of having it like this, I find it doesn't bother me anywhere near as much as the (now-reverted) responsive skin changes, however. Graham87 02:13, 3 June 2018 (UTC)
I now have to have my zoom size at 150% (instead of 175%) to maintain my previous layout. TBH, I wish ya'll would leave things alone. GoodDay (talk) 01:59, 1 June 2018 (UTC)
Here we go again. Did anyone actually ask for this? Selecting "Desktop view" on my phone does absolutely nothing to get rid of this. I'd like a way to have all the main functions (main/talk/edit/watch/history/move) back in their tabs in one click. If I want any of them on my smartphone, I just zoom in on them and then tap the screen, not try to interpret tiny icons. Double sharp (talk) 02:40, 1 June 2018 (UTC)
Don't know if this is related, but it seems to have just started together with this: the multiple images at my talk page won't fit on my mobile screen anymore and won't allow me to scroll to see the parts cut off. Samsung Galaxy Core Prime (SM-G360G), Android 5.1.1, 534×320 (landscape, although the same problem occurs in portrait), Samsung Browser 3.3 on Android (Lollipop). Double sharp (talk) 03:32, 1 June 2018 (UTC)
I logged in this evening and found myself looking at whatever this mobile skin is. Except I am definitely not using a mobile device. Please fix immediately. Thank you.
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)
  • My devices are an iPhone 7+ and the iPad Pro 10.5" running the most current Safari version (under a beta; I'm on 11.4 public beta 2). 1920x1080 on the iPhone, 2224x1668 on the iPad. It isn't as bad on the iPhone (though again I'd love a text labels icon over the pinpoint-sized icons), but I use the iPad because it renders a page how it should on a desktop. I don't need it to render the 'mobile version' on that device. Nate (chatter) 03:19, 1 June 2018 (UTC)
  • How do we get the hell rid of this? I don't use Monobook for "responsive design", I use it for a familiar workflow that's now entirely broken. Please either revert this change, Isarra and MZMcBride, or at very least provide an opt out (that isn't "fiddle with your phone settings.") This is the same kind of tone deaf "You'll love it once it's rammed down your throat hard enough!" that WMF likes to pull every so often. Seraphimblade Talk to me 04:57, 1 June 2018 (UTC)
    • 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)
  • What the flying fuck, please get rid of this abomination on mobile NOW. If I ask for the desktop version while I'm on my phone, that's because I want the goddamn desktop version, not a crapfest of unusability buried 20,000 leagues deep under barely legible icons that convey little to no information.Headbomb {t · c · p · b} 08:48, 1 June 2018 (UTC)
Oh god, this affects the desktop view on desktops as well if you aren't in full screen mode. Revert this abomination ASAP please! Headbomb {t · c · p · b} 08:55, 1 June 2018 (UTC)
  • As so many others have said: How the hell do I get rid of this? The icons are invisible because I work with images off, and the useful text links are at the bottom of the page, which can be a long way down. If you wanted to create a new 'responsive' skin, that's what you should have done, not broken Monobook. BlackcurrantTea (talk) 09:55, 1 June 2018 (UTC)
    @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)
  • 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)
Would it be all right if I sorted the responses here into... general buckets of what they are/are discussing? It would make it much easier for me to respond to stuff, pull out actionable items, etc. Also maybe help figure out what we should do with this moving forward, and such. -— Isarra 11:02, 1 June 2018 (UTC)
  • (ec) I'm sorry, but I am another person who thinks this change was very much for the worse, and it is impossible to get the old look back for me (iPhone 6s, Safari). Apart from the fact that the new design is considerably less useful for me than the old one which worked really well for me personally (so yes, why not create a new skin for people who do not like the old version, and allow those of us who to like it to keep using it?), I now can't see e.g. the full "Open for discussion" table at Wikipedia:Requests for adminship without flipping the phone into landscape mode, which I usually prefer not to do. This is certainly not intended behaviour. (By "can't see" I mean that it is too wide for the screen and the leftmost part of the table is cut off, so on my screen it starts with the "Support" column.) And that's in the desktop version on the mobile, not the mobile version, so I can't in fact "return" to the desktop version and fix it in that manner. --bonadea contributions talk 11:07, 1 June 2018 (UTC)


I'll try to address specific concerns here. If I've missed something, please feel free to add an item, or comment on anything here already. (Responses to specific things above also coming shortly, but I'd prefer if further issues etc are added below, as this will make them much easier to keep track of and address.) -— Isarra 12:12, 1 June 2018 (UTC)

On second thought, I can't follow the source of the above at all. I've tried to add all issues below. -— Isarra 13:56, 1 June 2018 (UTC)

Who asked for this?

Third-party MediaWiki sites, primarily. There is a serious lack of mobile support in the skins currently shipped with MediaWiki, and MobileFrontend often does not entirely meet their needs either. Making more of the available skins themselves responsive is a good step toward supporting their need for a mobile-friendly site for visitors.
I did enquire what people thought of this change here in april once I had the basic prototype, but no issues were raised and nobody objected at the time. -— Isarra 12:12, 1 June 2018 (UTC)

Opt-out methods not working

Mobile browsers have a browser option to request the desktop site - this works in firefox, but due to bugs in the browsers themselves, apparently not so much in safari and chrome.
There is a link in the page footer for 'Mobile view' or 'Desktop view' - this is a part of MobileFrontend, and has nothing to do with this change.
No way to opt-out on desktop - there may be browser extensions for this? I'm not sure. This is, frankly, a very unusual request. (If all else fails it might be doable to add a user preference, though? But that's apt to be very messy source-side, as mw isn't exactly built for these kinds of options either.) -— Isarra 12:12, 1 June 2018 (UTC)
Is this a response to me? If you thought I wanted the ability to opt out of seeing the Mobile/Desktop view links, then you've misunderstood me. (If not, then I guess I've misunderstood you, but that's the only thing I can think of that would qualify as a "very unusual request".) I mentioned the Desktop link because Legoktm said that one could opt out of the new layout by requesting the desktop site, and I wanted to point out that it didn't work no matter how I attempted to get the desktop view. What I wanted the ability to opt out of is the same thing everybody else here is talking about. MANdARAX  XAЯAbИAM 06:16, 2 June 2018 (UTC)
If a change is known not to work on common browsers, maybe don't introduce it? Or only introduce it on a new skin that people can choose to use if they want to. DuncanHill (talk) 12:29, 1 June 2018 (UTC)
But the new look is what is visible on the mobile after requesting the desktop site (Safari). It's the mobile version of the desktop site that has changed; the en.m.wikipedia version is the same from what I can tell (I always scroll down and click "Desktop" whenever I am redirected to the mobile site so don't have that much experience with what it is supposed to look like, exactly). --bonadea contributions talk 12:42, 1 June 2018 (UTC)
A bit clearer of an explanation for people: The new design doesn't actually switch on "desktop" versus "mobile", it switches on the effective viewport width being greater than or less than 850 pixels. On (some) mobile browsers, the browser's "Request Desktop Site" option forces the minimum viewport width to a value larger than 850px which is why it functions to bypass the new responsiveness in Monobook. Anomie 13:18, 1 June 2018 (UTC)
And the toggle on the bottom of the page is for MobileFrontend, which turns MF specifically on/off, regardless of viewport. We really need to make this less confusing, but for now that's how it is. -— Isarra 13:27, 1 June 2018 (UTC)

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)
@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)
@Graham87: Okay, thanks - can you try a hard refresh and let me know if that fixes it? -— Isarra 20:12, 1 June 2018 (UTC)
@Isarra: Nope, it doesn't. Graham87 03:34, 2 June 2018 (UTC)
Also, this is probably obvious but I'll say it anyway ... the access keys for the hidden elements don't work when they're hidden (by design). Having to unhide them first kinda defeats the purpose of the access keys as a quick navigation tool. Graham87 03:47, 2 June 2018 (UTC)
@Graham87: The problem here is I can't replicate this elsewhere, and if the mobile hiding is the problem, then none of them should be working, including talk, history, etc. Based on what this change actually does, the page-related access keys should either all work or none, so if some still work and others don't, this suggests that this may indeed be caused by something else entirely. (The other change? What was the other change?)
We're reverting this for now, but... agh. (Also, in general, are you saying that display: none on a parent disables accesskeys in general in screen readers? Because if so I may have a few other skins that definitely need fixing... )
Also thank you, seriously, for your specific feedback and bearing with us on this. Very helpful. -— Isarra 08:52, 2 June 2018 (UTC)
@Isarra: I can't replicate this problem here anymore (obviously), but I can replicate it on your prototype with the latest stable versions of both JAWS and NVDA, the two most popular Windows screen readers, in both IE and Firefox (again with the latest stable versions ... I had to hugely increase the zoom for the elements to be hidden there). Not sure if this was clear enough before (perhaps it wasn't!), but this is only a problem for me when the elements are hidden; they work fine otherwise. Maybe it's a display:none thing ... who knows? Graham87 09:50, 2 June 2018 (UTC)
@Graham87: Ah, thanks! That actually helps clarify a lot. Now I get what you're saying, and... yeah, this will definitely be fixed. -— Isarra 21:49, 2 June 2018 (UTC)

Uses icons instead of text for tab labels

Filed as phab:T196190. Legoktm (talk) 19:29, 1 June 2018 (UTC)
This is necessary because there are an arbitrary number of tabs with fairly arbitrary content across languages. The only way to make them fit on a set size is to set their size as well, and the only way to do that is to remove the text and replace it. The reason why they would now appear bigger is because they also have extra padding so they're easier to hit with random body parts that do not have the precision of a mouse pointer.
  • We cannot simply have them as text that wraps and moves the rest of the page content down because they are technically after the page content in the DOM.
  • A fallback for something to appear when the icons are disabled should be added. The problem is I'm not sure how to do that. Any ideas? This is important for a lot of things, frankly, not just (mobile) MonoBook. -— Isarra 12:12, 1 June 2018 (UTC)
The icons are not necessary, the tabs worked perfectly well before. Just bin this change. DuncanHill (talk) 12:29, 1 June 2018 (UTC)

Hides navigation and requires extra steps to find/use it

General workflow changes are to be expected when using different kinds of devices. However they should not be so significant, so if anyone running into issues here can describe exactly what you would do before, and then compare to after, that would be quite useful to improve the situation. -— Isarra 12:12, 1 June 2018 (UTC)
Well, before I would just do what I would do on my pc, all the tabs etc were in exactly the same place and looked exactly the same. I can't give you any screenshots because my Tardis is broken. Now, I have to work out what the icons mean, work out where some of them are hiding as they don't all show at once (see screenshot above), and I can't dismiss notifications without navigating away from the page I am on. DuncanHill (talk) 12:29, 1 June 2018 (UTC)
I know this is a long shot, but could I ask you to please try to bear with it for few of days, see what you think after you've had a chance to get more used to it, and then let me know what problems/things are still being specifically annoying at that point? I know this kind of came out of the blue, and I'm sorry about that, but Wikimedia's update deployments are a little... strange compared to how the sites I usually work with are (third-party mw sites tend to have actual versioning, as opposed to rolling-release updates), and I'm apparently still not very good at handling it appropriately. -— Isarra 13:27, 1 June 2018 (UTC)
I don't want to use it at all, certainly not get used to it. It's grim for reading, and awful for editing. Telling people to "get used to it" is not helpful. DuncanHill (talk) 15:01, 1 June 2018 (UTC)

WMF shoving things down users' throats

The WMF was actually against this, as they feared pretty much precisely this reaction, which just goes to show that they have learned from previous incidents. This, on the other hand, is a volunteer-driven initiative targeted more toward the needs of third-party MediaWiki users, with the understanding that nobody objected when I asked about it here earlier, so it was probably fine. -— Isarra 12:12, 1 June 2018 (UTC)
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)
What's more public than VPT? -— Isarra 13:27, 1 June 2018 (UTC)
I'd expect suggested changes that are expected to affect a large majority of the Wikipedia community to be at least publicised by a watchlist notice and/or a link at Wikipedia:Centralised discussion. I'm not so tech-savvy that VPT is somewhere I go often; I mostly go here if something's not showing up right, whether because of recent changes or because the stuff on my .js and .css pages (all written by others) are not working properly. I'd expect this to be true of quite a few other Wikipedians. Double sharp (talk) 14:48, 1 June 2018 (UTC)
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)
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)
What's more public than VPT? – I also do not think VPT is sufficiently "public". I'm a frequent editor but don't read VPT unless I'm following a discussion about a problem after it occurs. I'm only here now because I noticed the change to the skin and saw the watchlist notification. Mitch Ames (talk) 14:03, 8 June 2018 (UTC)
The WMF was actually against this apparently not against it enough to block promoting it to production... — xaosflux Talk 01:34, 4 June 2018 (UTC)

'Notifications' is just a link to Special:Notifications instead of a flyout with the actual notifications displayed

I have noooo idea what to do about this. Apparently Special:Notifications just doesn't entirely work, but we also can't use the usual echo flyouts on mobile because OOUI doesn't support mobile either. Um. -— Isarra 13:27, 1 June 2018 (UTC)

Previewing/fixing formatting problems for desktop/mobile from either device

This is a longstanding issue that's been brought up time and again - that mobile and desktop render differently, and people need to be able to preview changes on either regardless of which they're actually editing from. Having skins that responsively support both should improve the situation in that you can focus on the content itself more than the formatting, but... hmm, not sure if this helps, since indeed it does seem to kill the ability to zoom out and crap on a phone. -— Isarra 13:56, 1 June 2018 (UTC)
Wait, nevermind, that's what the 'Request desktop site' thing is for. Actual problem is that it only seems to entirely work in firefox. -— Isarra 13:58, 1 June 2018 (UTC)

Should have a tablet/small-desktop view

I think a tablet/small-desktop view, which hides the sidebar but still shows labels for the tabs, would be a good idea. I find this works quite well in Timeless. Why give users a phone experience if they're on a mid-to-large sized device or small desktop screen? - Evad37 [talk] 14:43, 1 June 2018 (UTC)
@Evad37: Main reason was because I didn't want to figure out how to make collapsible tabs because vector's implementation scares me and just making the cutoff wider sort of avoided the problem, but since people seem to feel a lot more strongly about this than expected, yeah. This seems definitely in order. -— Isarra 20:18, 1 June 2018 (UTC)

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)

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)
  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)
  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)
  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)
  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)
  6. Basically what DuncanHill said. Double sharp (talk) 14:43, 1 June 2018 (UTC)
  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)
  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)
  9. Revert, or restore the original version and have them separate. Preferably immediately. —Xezbeth (talk) 20:50, 1 June 2018 (UTC)
  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)
  11. Change things back to the way they were. GoodDay (talk) 22:15, 1 June 2018 (UTC)
  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)
  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)
  14. Ugg why oh why is this on by default for desktop?! pull this change back. — xaosflux Talk 03:49, 2 June 2018 (UTC)
  15. I agree with pretty much everything everybody above said. MANdARAX  XAЯAbИAM 06:20, 2 June 2018 (UTC)
  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)
  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)
  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)
  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)
  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)
  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)
  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)
  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)

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)

See also this XKCD comic. This is 2018, responsive web design should be the standard, not an opt-in. If we do end up forking monobook, the old (non-responsive) version should be called something else (perhaps "throwback") and responsive monobook shipped along with MediaWiki to third parties. For folks that want to opt-out of responsive design, they would then be free to switch the skin to the forked version in their preferences. It is going to be impossible to please everyone, but we must be forward thinking in terms of the MediaWiki software design, and a small but vocal minority of those who would rather be stuck in 1999 cannot hamper progress. This is not to say the current iteration of responsive monobook is perfect, and if you have found issues which hamper your experience with the skin beyond "I don't like it because it's different", then please let us know about it. These are the things that need to be discovered and addressed in order to make the skin work great in mobile as well as desktop. Unfortunately, it's difficult to uncover all of these issues beforehand given the various workflows that people have, so if you bear with us during this teething process and offer constructive feedback and criticism, the skin will come out better for it :). Unfortunately, forking monobook into a throwback version is not free; it adds maintenance burden to the WMF as they now have one additional skin to test against and ensure it remains up-to-date and secure. Ideally, those who detest responsive monobook can figure out what real issues they have with it (versus feelings or knee-jerk reactions against change) and report them so they can be looked into and resolved, and we end up with responsive monobook as the only monobook at the end of the process. --Skizzerz (talk) 20:16, 1 June 2018 (UTC)
There have been plenty of valid issues given. Your response is patronising and dismissive of the real problems listed above. It makes Wikipedia harder to use. It's not a "knee jerk reaction" to object to a degradation of service and function. DuncanHill (talk) 20:31, 1 June 2018 (UTC) More - To dismiss the complaints as a case of "I don't like it because it's different" shews that you either haven't read the problems above, or you simply do not care about user experience. I am appalled at your comment. You should not be involved in dealing with volunteers if that is your attitude to us. DuncanHill (talk) 20:34, 1 June 2018 (UTC)
I am a professional software developer. If I responded to client complaints about a UI change as Skizzerz did above, I would be promptly out of a job, and rightly so. (Hint.) I fully agree with DuncanHill here. This sort of major UI change should never be imposed with little or now warning except oin an opt-in basis, particualry when doing it instead as a new varient skin would apparently have been simple. DES (talk)DESiegel Contribs 22:44, 1 June 2018 (UTC)
@Skizzerz: Here's the issue with the "responsive" skin: it's responsive. This is a negative-value feature and no amount of "fixes" and "improvements" will ever change that. People who use monobook, as opposed to say vector, use monobook because it's the power editor skin. All the features we want are exposed there, directly. Not buried in 482 layers of unrecognizable icons spread over 47 submenus. Headbomb {t · c · p · b} 22:58, 1 June 2018 (UTC)
@Skizzerz: I will echo DESiegel's comment that if I treated the users of my software in the dismissive and sarcastic way that you've done here, I would swiftly be out of a job (and yes, I do it professionally too, and have for over a decade now). Rather, I treat those users as valued partners, since at the end of the day, the software I write means nothing at all if the people who use it cannot get done with it what they want to get done. I do understand that you feel attached to what you've written, but your dismissive citation of an xkcd cartoon (and by the way, I have read xkcd every Monday, Wednesday, and Friday morning for years now, and yes I saw that one) as some kind of justification doesn't say much for you. Yes, all changes break something, but that doesn't mean all changes that break something are by definition good ones. I would challenge you to specifically refute what I've asked here, to put "Monobook" and "Monobook Mobile" as separate skins. I can see no downside to that, aside from perhaps as you said some additional maintenance costs, but well, you made these changes, so if the additional maintenance isn't worth it, revert them back. When a substantial proportion of your users wants the "classic" or "legacy" functionality, you do need to maintain that until and unless you convince them that what's newer really is better. Seraphimblade Talk to me 00:23, 2 June 2018 (UTC)
@Skizzerz: Question: is there any argument at all for responsive web design for WP besides "it's 2018 and all the cool kids are doing it?" Surely we should at least ask ourselves why the cool kids are doing it and if their situation is applicable to ours. I rather find that no, it really isn't. The simple fact of the matter is that contributing seriously to Wikipedia is quite different from contributing seriously to a lot of other sites: you can't just write what you think, because that is going be non-neutral original research. Being a serious WP editor is not that easy and you will end up using pretty much all the sidebar and header tools all the time, and I do not think that any change that hides them is an improvement. If anything I think it would make it more difficult for readers to become editors (and that is already difficult enough as it stands). Double sharp (talk) 03:27, 2 June 2018 (UTC)
Going to try to respond to all of the above in one go (if you couldn't tell, I don't visit here much).
@DuncanHill: I am not trying to be dismissive of any of the issues already raised which are actually issues, of which there are quite a few in the sections above. This kind of feedback is very valuable and I encourage people to keep raising these sorts of issues. For example, from the feedback above it's pretty clear that the iconography could probably use more work to be clearer, the breakpoints could be re-evaluated so that it breaks only on lower resolutions (perhaps with the introduction of a tablet-friendly view so it doesn't go straight from desktop to phone), the thing with screen readers and access keys not working is a major issue, the orange is odd/confusing, and so on. All of these are valid issues, and if people see more things like that, they should by all means report them. The types of feedback that is not useful or at all helpful is neatly encapsulated in Headbomb's comment above. That type of feedback is entirely useless and pointless, and would be promptly ignored if I was in charge of the project (I'm not; I just happen to be friends with Isarra -- I haven't contributed anything to the project itself as of yet). You don't like it because it's different? Keep it to yourself, we don't need to hear it. You don't like it because there are actual issues that impact its usability or aesthetics? Let us know so we can work with you to address them.
@Double sharp: The applicability of responsive design stems from the increasingly larger percentage of users who browse Wikipedia with their mobile devices as days go by. The existing mobile site (MobileFrontend) largely goes about solving the issue in the wrong manner. By having an entirely separate mobile skin, features which editors or power users may need are simply nonexistent, whereas if we made a desktop skin responsive those features would still be present (albeit perhaps behind a menu in order to ensure the content is given top priority for screen real estate). As an example, the MobileFrontend skin makes it impossible to view the diffs between non-adjacent revisions, so if one user makes 5 edits in a row you cannot easily see the full diff combining those 5 edits. However, in a responsive skin, those features would still be present in some fashion as the same skin is serving both mobile devices and desktop users. For things such as checking up on vandalism on the go, these sorts of features are invaluable even though they don't impact the vast majority of users (hence why MobileFrontend doesn't support them).
@Seraphimblade: It is not my decision to introduce this as a second variant of the skin. Should that discussion come up, I will fight as hard as I can to make responsive monobook the default one, and have the non-responsive one introduced as a separate skin that people can switch to if they absolutely hate the new monobook. Your "substantial proportion" is less than a fraction of a percent of all users of monobook across all wikis, and English Wikipedia's community does not and should not have any say over what MediaWiki as a whole serves to 3rd party users. We ship monobook along with the tarball, so forcing those 3rd party users who have been asking for responsive skins for years to go out and download one separately instead of bundling it and automatically upgrading their wikis to use it once we do ship it is only doing them a massive disservice. The English Wikipedia's community does and should have absolute say over what happens to English Wikipedia itself, so if the community really wants the skin to be forked, that will be a decision the WMF will need to weigh and perhaps implement. I think that decision is premature, however. Once the bulk of issues mentioned in the above sections are ironed out, that is the time to evaluate what the community really thinks about it. Causing riots due to an alpha-quality responsive skin is incredibly short-sighted. Now, you may have questions as to why an alpha-quality skin was deployed to English Wikipedia, and well, so do I. This probably should have been deployed to the test Wikipedia for a month or two to gather this sort of feedback rather than abruptly and without much advance warning deploying it to a production wiki.
@Lots of people: I'm a professional developer too. I'm not posting in a professional capacity. You are not my clients, I am not representing anyone but myself with my comment, and I am not being paid to sit here and type these words. I'm a volunteer who happens to have opinions on software design, and saw a colleague (who is also a volunteer) being raked over the coals by negative responses which had no business being that negative. So, I jumped in with a somewhat snarky comment asking for people to state the actual issues they have (for the actual issues which exist, of which there are many), and for people who just want everything to stay the same for 20 years without any attempts at improvement to either go away or stop being curmudgeons and offer constructive feedback instead so that we can move forwards as a platform and as a community. If you want my respect, start respecting the efforts of other volunteers, and work with them instead of attacking them. --Skizzerz (talk) 18:26, 2 June 2018 (UTC)
@Skizzerz: In order to work on the layout of WP articles, and ensure that they look good on desktop as well as on mobile, we need a mobile view that matches the desktop view in this respect, instead of one that (like the current one) makes all images take the entire screen width. We also really don't have enough room on mobile to have all the tabs, sidebar links, and top links without making the text a lot smaller, but these need to be directly accessible to be really useful. But once we keep those the same as the desktop view, don't we essentially have the desktop view already? Even just adding references on a smartphone is time-consuming and pretty painful already, and we don't need to make things even more painful by requiring more clicks and possible loading time at each step along the way to doing small edits that are still practical on smartphone. Double sharp (talk) 16:02, 5 June 2018 (UTC)

Oddly enough, one gets the previous display restored via reducing 'font size' to 150%. But, I'm used to having my fonts at 175% GoodDay (talk) 11:55, 2 June 2018 (UTC)

@Skizzerz: Re:"Keep it to yourself, we don't need to hear it." This change was forced upon on me/us, with no way to opt out, so yes, you/the devs do need to hear it. More importantly, this change needs to be reverted, and promptly so. Which apparently it was.Headbomb {t · c · p · b} 18:32, 2 June 2018 (UTC)

Skizzerz (talk · contribs · deleted contribs · logs · edit filter log · block user · block log) "You don't like it because it's different? Keep it to yourself, we don't need to hear it. You don't like it because there are actual issues that impact its usability or aesthetics? Let us know so we can work with you to address them." I have been telling you actual issues that affect its usability and its aesthetics. I am a vastly more active editor on Wikipedia than you are, so I think I have rather more right than you, who hadn't edited here in over 6 years before your patronising post above, to say that something degrades usability, and I think you would do well to defer to people who actually edit this Wikipedia on such issues. If you want our respect Skizzerz try being a productive editor rather than someone who just turns up to be snide and ignore genuine issues. DuncanHill (talk) 18:48, 2 June 2018 (UTC)
(edit conflict) @Headbomb: There was a way to opt out: it was the "request desktop site" feature of your mobile browser. This apparently didn't work on iOS (and also impacted actual desktop users who didn't fullscreen their browsers), so reverting seems a sensible course of action while those issues as well as the other issues raised above are addressed. As I mentioned in my reply above, I don't think this should have been deployed here as-is, rather it should have been on test Wikipedia for a couple of months to gather this sort of feedback in a non-production environment. The skin will continue to be worked on and these issues addressed, and hopefully the deployment process for it next time will be more sensible and with more advanced notice. To come back to what you were actually responding to, a good feedback would be "The opt out isn't working" or "I don't see a way to opt out" or "It's showing the phone version when I'm on my desktop with the browser window still large but not full-screen" rather than peppering it with swears, calling it an abomination, and other inflammatory remarks. @Duncan: Wikipedia is not the world, and is not the only wiki running the MediaWiki software. We are both volunteers, you have exactly zero more and zero less rights than I do. I honestly do not care one whit about Wikipedia, as my focus areas are more towards supporting 3rd party MediaWiki instances, and I have made numerous contributions in that area, just as you have made numerous contributions here because presumably you care about Wikipedia and this is one of your focus areas. The size of my e-penis edit count compared to yours here has absolutely no bearing on the validity of all of the above statements I made. I was not accusing you of not pointing out issues in a constructive manner; my initial comment did not name any names or call anyone out. My follow-up to you specifically in fact noted that a lot of the issues that you and others raised were in fact "valid issues" according to my original comment, to make it clear that I was not flippantly discarding everything said in the above sections. I am not "ignoring" genuine issues. I was asking everyone to have less grar and derogatory comments so that the genuine issues could stand out so they can be addressed. --Skizzerz (talk) 18:58, 2 June 2018 (UTC)
No, "request desktop site" was not a way to opt out of this. This affected the desktop versions as well, both when seen from a phone, or from a desktop. Headbomb {t · c · p · b} 19:00, 2 June 2018 (UTC)
Holy hell, this guy doesn't even have 25 edits on Wikipedia this is how he talks to power users? Headbomb {t · c · p · b} 18:54, 2 June 2018 (UTC)
@Skizzerz:You certainly shouldn't dismiss the concerns of people who do a lot of editing and who have told you that these changes make editing harder when you do not have any real experience to base your dismissal on. If you are telling the truth when you say you don't care about Wikipedia then you really shouldn't be diving into discussions like this, especially when you mischaracterise the contributions of others and fail to respond to genuine concerns. DuncanHill (talk) 19:08, 2 June 2018 (UTC)
I’d appreciate if we could stick to the problems instead of discussing the people. —TheDJ (talkcontribs) 19:57, 2 June 2018 (UTC)
We were doing that until Skizzerz turned up with his dismissive and patronising posts. DuncanHill (talk) 22:07, 2 June 2018 (UTC)

I am finding it difficult to understand why this has been a problem for third party users. If they don't like the non-responsiveness of monobook then they don't have to install it on their system. After all, monobook has not been the default skin here for many years; it is not essential for third parties. If they are asking for a monobook-like skin that is responsive, then as several editors have already suggested, develop a new skin that does that for them. Don't mess with the skin the grognards are using. By definition, they won't like it. SpinningSpark 15:44, 8 June 2018 (UTC)

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)

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)
Thank you thank you thank you. Please do not revert back - please. --bonadea contributions talk 07:50, 2 June 2018 (UTC)
Please do revert back, and then implement this properly: As an opt-in change for those who want it, not a forced change for those who do not. Seraphimblade Talk to me 10:00, 2 June 2018 (UTC)
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)
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)
At that time I hadn't tried to see how much work it would be to support both. It turned out to be reasonably possible to add in a user preference to control the responsiveness. In general we try and avoid adding in new preferences/conditionals like this, but I think we'll be able to deal with the extra maintenance burden in the future. Legoktm (talk) 08:51, 7 June 2018 (UTC)
And apparently phab contributors think they don't need any community consensus to push this on us (having removed a community consensus project tag)? It is bad enough when staff push an unwanted change, now we have to fight with volunteers too? — xaosflux Talk 17:38, 2 June 2018 (UTC)
Well that's correct...ish. Generally, individual technical changes don't go through any form of community consensus review, and on the scale of things, this was only supposed to affect people who use the MonoBook skin on mobile devices, which is a pretty small set of people. But that didn't work out as planned due to the mobile breakpoint triggering for people with high zoom levels on laptop/desktop devices, and that we only started announcing and socializing the change a bit too late. Legoktm (talk) 08:42, 7 June 2018 (UTC)
What does "socializing the change" mean? DuncanHill (talk) 20:04, 7 June 2018 (UTC)
Because of my background I could understand this to mean: developing/documenting a capability, providing tech support, and publicizing the 'how to do it' to a community. --Ancheta Wis   (talk | contribs) 20:07, 7 June 2018 (UTC)

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)

GoodDay, I think we're going to need more information. Which page? What web browser and operating system? How big is your screen? What does it look like when it's out of whack? Whatamidoing (WMF) (talk) 23:01, 31 May 2018 (UTC)
(edit conflict) "out of wack" is very vague for something depending on your skin, browser, window size, the specific page and other factors. Above 150% is a lot and it does not surprise me if something displays poorly. PrimeHunter (talk) 23:01, 31 May 2018 (UTC)
It just doesn't display the same, anymore. I can't explain it without showing what it looks like, which I can't do. An example: the 'Search' box, should be on the left of the screen, but instead is at the top. GoodDay (talk) 23:27, 31 May 2018 (UTC)
If your search box is usually on the left then you don't have the default Vector skin at Special:Preferences#mw-prefsection-rendering. I guess you have MonoBook and are seeing an effect of the new responsive MonoBook feature in the previous section. It will vary when it happens for different users. You can maybe also get it to happen at 100% or less by narrowing the browser window. PrimeHunter (talk) 00:41, 1 June 2018 (UTC)
Vector default, seems to be the closet to what I previous had. GoodDay (talk) 01:23, 1 June 2018 (UTC)
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)
This is connected to what's being discussed in the preceding discussion. GoodDay (talk) 22:12, 1 June 2018 (UTC)
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)

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)

Why it opt-out instead of opt-in? DuncanHill (talk) 10:29, 7 June 2018 (UTC)
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)
Do you have suggestions on where else this should be announced? Relatively speaking, this change should not affect that many users... Legoktm (talk) 19:05, 7 June 2018 (UTC)
MediaWiki:Watchlist-messages and MediaWiki:Sitenotice spring immediately to mind. WP:AN is also a good place to announce changes which are likely to confuse editors. VP:T isn't quite a disused lavatory with a sign on the door saying "Beware of the Leopard", but it's not Trafalgar Square either. Why is it opt-out instead of opt-in? DuncanHill (talk) 19:47, 7 June 2018 (UTC)
@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)
Done. Why is it opt-out instead of opt-in? DuncanHill (talk) 20:02, 7 June 2018 (UTC)
Yes, why is it opt-out instead of opt-in? Since this is for Monobook rather than Vector, the people who are going to see it are mostly power editors, who will largely have no use for it. Double sharp (talk) 23:20, 7 June 2018 (UTC)
I suppose a more flexible question here would be, is the opting default something that can be configured per project? — xaosflux Talk 00:00, 8 June 2018 (UTC)
Opt-out or opt-in makes very little difference to individual users in the end, save that if it's opt-in, very few people will choose to opt-in since they won't even know it's an option (how often to you check your preferences to see if something new is out there). I don't care which of the two is chosen by whomever, for whatever reason, as long as those who don't want it don't have it forced on them. Headbomb {t · c · p · b} 01:25, 8 June 2018 (UTC)
Yes, but if it's opt-out, I imagine people will also not know for the most part how to opt out in the absence of a wider announcement than VPT, for exactly the same reason. DuncanHill's edit request at Mediawiki talk:Watchlist-messages will of course lead to a wide announcement, so this is likely to be less of a problem now. I nevertheless wonder how strong the correlation will be between high mainspace activity and opting out. Double sharp (talk) 05:03, 8 June 2018 (UTC)

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)

@AKlapper (WMF): Did the job queue die? :D --Izno (talk) 15:27, 8 June 2018 (UTC)
@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 [email protected] (or maybe meta:Tech but that looks pretty dead)? Thanks! --AKlapper (WMF) (talk) 16:27, 8 June 2018 (UTC)
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)
@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)

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)

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

- under a question the Russian categories (was born in the territory of Ukraine, built in Ukraine and Russia) What sense Soviet to duplicate as Russian?. It is wrong when the Ukrainians who were born in the Russian empire, turn automatically in Russians / Russians of category have written down because all sources are Russians.

I have given it as an example, have met recently. And when the Ukrainian is written down as Russian, it is possible to meet not once. Or Crimean Bridge (Crimea) - the Crimea the disputed territory of Ukraine and Russia. In the table in the right top corner where "locale" is written only Russia, there is no Ukraine. This violation of a neutrality and short information that to mislead the reader. --Bohdan Bondar (talk) 21:47, 9 June 2018 (UTC)

According to Ukraine: "While Russia and ten other UN member states recognize Crimea as part of the Russian Federation, Ukraine continues to claim Crimea as an integral part of its territory, supported by most foreign governments and United Nations General Assembly Resolution 68/262." As such, I agree with you that the English Wikipedia should recognize Crimea as part of Ukraine and things like infoboxes (such as the "locale" field in the infobox of Crimean Bridge (Crimea)) should say Ukraine. However, this is not the right forum it is for technical matters such as computer software. This could be a large and contentious issue akin to the great Talk:Gdansk/Vote of 2005. -- GreenC 13:58, 11 June 2018 (UTC)

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

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

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)
@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)
@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 A couple of days ago these menus had the same content.
Problem #1 seems to suggest that at the same time, a couple of days ago, the logged-in cookie started to be created non-persistent (has no expiration date specified) on the phone, and automatically goes away when the browser tab closes. But that's just the symptom; I can't debug cookies on this phone. David Brooks (talk) 03:00, 11 June 2018 (UTC)
ETA overnight- I guess that, although I don't use Monobook so assumed its mobile skin change was not related, the mere fact of tinkering with the mobile interface could have caused some collateral damage? David Brooks (talk) 12:45, 11 June 2018 (UTC)
@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)
Hey there @DavidBrooks: @DaneGeld:! Could I please ask for which user agent your mobile device has? provides an easy way to copy and paste. Jdlrobson (talk) 20:14, 11 June 2018 (UTC)
@Jdlrobson: Mozilla/5.0 (Mobile; Windows Phone 8.1; Android 4.0; ARM; Trident/7.0; Touch; rv:11.0; IEMobile/11.0; NOKIA; 909) like iPhone OS 7_0_3 Mac OS X AppleWebKit/537 (KHTML, like Gecko) Mobile Safari/537. I never looked at that before; must be pretty confusing. Again, this is Windows Phone 8.1, which of course is no longer supported by MS. David Brooks (talk)
In this context, I should probably point out what I mentioned above: the "keep me logged in" checkbox is also now missing, which probably explains the cookie non-persistence. David Brooks (talk) 15:02, 12 June 2018 (UTC)
Right, so it looks like we dropped JS support for this browser so Nearby is not going to work thus hidden. I think we can restore the watchlist link and display a checkbox to allow you to keep logged in on mobile. We have tasks for both and will hopefully get those addressed soonish Jdlrobson (talk) 18:39, 12 June 2018 (UTC)
Thank you for looking into it! David Brooks (talk) 22:27, 12 June 2018 (UTC)
In case anyone else comes across this thread, I just discovered UC Browser (from Alibaba) which still works. Maybe I'm the last WinPho 8.1 user on the planet to know about it. Although it doesn't display the checkbox, it does persist login, and it does show the missing menu options. Each user will have to decide whether this is worth the reported privacy/security flaws. David Brooks (talk) 12:15, 17 June 2018 (UTC)

Confirm watch/unwatch


I have "Add direct unwatch/watch markers (×/+) to watched pages with changes" ticked in Preferences→Watchlist. Clicking the x used to quietly remove the page from my watchlist. For the last few days, it has instead taken me to a confirmation screen, which I find less convenient. Has anything changed? Is there a way to restore the previous functionality? Thanks, Certes (talk) 19:56, 10 June 2018 (UTC)

It's now mysteriously working again. It seems to work intermittently. I'm using Firefox 60.0.1 on Ubuntu with the default skin. Certes (talk) 23:15, 10 June 2018 (UTC)
Certes This sometimes happens to me as well — it seems to occur when the watchlist isn't fully loaded, either because I clicked too soon or the browser/interwebs crapped out. I've (largely) trained myself to deal with the former. ~ Amory (utc) 00:59, 11 June 2018 (UTC)
Thanks. I've had short outages this week on my normally reliable connection, so that's probably the cause. Certes (talk) 09:59, 11 June 2018 (UTC)
Yes, you need to wait for all the JavaScript to finish. Which on occasion, is never. --Redrose64 🌹 (talk) 19:22, 11 June 2018 (UTC)

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)

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)

Font size in "Search Wikipedia" box


A few weeks ago the font size in this box (on Vector it's located at the upper right side) suddenly shrank to what appears to be about 8-point. I poked around in the Village pump archive (the CSS documentation, & what Help pages I could find) to figure out where I could make it larger & easier for my eyes but failed to find the correct discussion. Anyone know what parameter needs to be changed to increase the font size for this field? -- llywrch (talk) 18:31, 11 June 2018 (UTC)

I don't know why it changed for you but try this in your CSS to override whatever changed it:
#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)
That did it. Thanks. -- llywrch (talk) 20:59, 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)

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

Tech News: 2018-24

21:55, 11 June 2018 (UTC)

Update on page issues on mobile web

CKoerner (WMF) (talk) 20:58, 12 June 2018 (UTC)

Why can't the time in the footer identify the time zone?

I'm not sure what controls the standard footer text at the bottom of articles and pages such as this one. At the moment it reads:

This page was last edited on 12 June 2018, at 20:58.

A reader wrote to Wikimedia to ask which time zone is associated with the time. While veteran editors, especially those who have customized their preferences to select a time zone will know the answer (UTC, unless you specify a different one) why couldn't we include the time zone in the standard message. It doesn't seem to be a space issue, and most of our readers are unlikely to know that UTC is the default.

What's the harm in changing it to read:

This page was last edited on 12 June 2018, at 20:58 UTC.


This page was last edited on 12 June 2018, at 20:58 (UTC). --S Philbrick(Talk) 21:46, 12 June 2018 (UTC

I think that's a very good idea. DuncanHill (talk) 21:59, 12 June 2018 (UTC)
The text is made by MediaWiki:Lastmodifiedat. There is an old suggestion by Jason Quinn at MediaWiki talk:Lastmodifiedat#add " (UTC)" string? The message is called with a time in the default time zone of the wiki (UTC) for unregistered users, and in the time zone at Special:Preferences#mw-prefsection-rendering for registered users. But the message is not told which time zone it is called with, or whether the user is unregistered. I guess we could use <span class="anonymous-show"> UTC</span> to only show " UTC" to unregistered users. PrimeHunter (talk) 22:21, 12 June 2018 (UTC)
Putting UTC in parenthesis would be preferable to not doing so, in order to be consistent with the format used in discussion timestamps. --Redrose64 🌹 (talk) 22:48, 12 June 2018 (UTC)
I've just found that for a few weeks in 2009, we did indeed emit a hardcoded " (UTC)" that was appended to the passed-in time. Admins might like to look at this. --Redrose64 🌹 (talk) 22:52, 12 June 2018 (UTC)
As I suspected, it is moderately complicated. But following up on Primehunter's suggestion, oen can argue that if you affirmatively chose a time zone, you know which one you chose, and if you didn't, you can, so showing (UTC) to unregistered users would always be accurate, and would clarify the time zone for the readers most likely not to know the answer.--S Philbrick(Talk) 00:05, 13 June 2018 (UTC)
This seems useful enough if there are no technical issues with implementation. · · · Peter (Southwood) (talk): 06:24, 13 June 2018 (UTC)
The suggested solution would send <span class="anonymous-show"> UTC</span> to everybody and rely on the browser to hide "UTC" for registered users. If CSS for anonymous-show fails to load from MediaWiki:Group-user.css then registered users will also see "UTC". Pages are occasionally displayed with no or broken CSS but I guess this willl be rare and it's not a serious problem if a few users see "UTC" on a non-UTC time on a page which may look broken. PrimeHunter (talk) 09:55, 15 June 2018 (UTC)
Here is the active code if people want to try viewing it in different circumstances: " UTC". PrimeHunter (talk) 09:59, 15 June 2018 (UTC)
Please can we use <span class="anonymous-show"> (UTC)</span> for consistency with other timestamps? --Redrose64 🌹 (talk) 10:11, 15 June 2018 (UTC)
I support that. 12:00<span class="anonymous-show"> (UTC)</span>. produces "12:00 (UTC)." which renders as "12:00 ." with a space for me in Firefox (not caused by the added parentheses). We could say 12:00<span class="anonymous-show">&nbsp;(UTC)</span>. instead. This produces "12:00 (UTC)." which renders as "12:00." for me with no space. PrimeHunter (talk) 10:47, 15 June 2018 (UTC)

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)

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)
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)
Portal:Cornwall/box-footer only called {{Box-footer}}. I have called it directly instead.[6] I think Pbsouthwood should have done that before deleting the page. PrimeHunter (talk) 13:42, 13 June 2018 (UTC)
Thanks, that's fixed the overlaps and straggling, but one still cannot edit the noticeboards, and there are no edit links for any of the sections. DuncanHill (talk) 13:47, 13 June 2018 (UTC)
The edit links in the boxes have been restored with [7]. I guess it's intentional that there are no section edit links. PrimeHunter (talk) 14:03, 13 June 2018 (UTC)
Thanks all for the quick responses and action :) Not sure about the lack of section edit links, but still a great improvement. DuncanHill (talk) 14:10, 13 June 2018 (UTC)
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)
At the time I deleted it, it had had no content (blank page) for a while, and was on a long list of unused portal subpages for deletion. There were probably no direct links to it, but we have found that some templates and modules are calling subpages of pages where they are transcluded, which can be relatively tricky to track down. If this happens again, please report on the WikiProject:Portals talk page, as there are a few of us who now know how to deal with this problem.
DuncanHill, I don't think the members of Wikipedia:WikiProject Portals were expecting portal boxes to be transcluded into WikiProject pages, though as far as I am concerned it is a reasonable thing to do. If you are maintaining Portal:Cornwall as part of WikiProject Cormwall, please let the portal project know how you prefer to manage it, so we can try to avoid any further problems. Cheers, · · · Peter (Southwood) (talk): 15:12, 13 June 2018 (UTC)
The new articles, articles needing attention, etc, boxes are Wikiproject material that the portal uses, not portal boxes that the wikiproject uses. I also had to fix a link here where a redirect was deleted without incoming links being corrected. DuncanHill (talk) 15:22, 13 June 2018 (UTC)
DuncanHill, Fair enough, they are conceptually project pages which use portal components, which is probably why people were not expecting this kind of side-effect. I cannot speak with certainty for the people who listed the portal subpage for deletion, but I would not have guessed that it was transcluded into a project page through a series of about two templates and a Lua module. It happened, and the important thing is whether it has been fixed. We will try to look out for similar side effects, but often the only way to find them is when they happen. Cheers, · · · Peter (Southwood) (talk): 03:24, 14 June 2018 (UTC)
I agree.    — The Transhumanist   21:32, 15 June 2018 (UTC)

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)

Syntax highlighting will no longer turn off / Forced into 2017 Editor

I just hit the edit button and my editor has gone nuts. There is syntax highlighting; Headers now have increased font size etc. Essentially my 2010 editor has been forced to the 2017 editor even though I have not enabled it. This screws up my entire work flow and prevents me from using my browser based snippet program. I have looked through Preferences to find a way to turn it off but have found nothing. Is there a way to get the old, simple wikitext editor back? The new features are neat but neat is only good if it does not break stuff. Jbh Talk 23:57, 13 June 2018 (UTC)

@Jbhunley: There should be a pencil icon in your editing toolbar, last button before the "Advanced" menu. This will toggle syntax highlighting. Does that work for you? MusikAnimal talk 00:01, 14 June 2018 (UTC)
Sorry, you said you were forced into the 2017 editor, too. That should be in your beta preferences. Uncheck "New wikitext mode". No idea how you got forced into this, though MusikAnimal talk 00:06, 14 June 2018 (UTC)
(edit conflict)}Yes! I do not know whether to feel relieved or stupid. Thank you! I was fearing I would have to go back to writing WikiText by hand…
I assumed it was the 2017 editor since the highlighting scheme looked like the one I saw in the 2017 editor rather than what I remembered the 2010 highlighting to look like ie actually changing the font size and face rather than just different colors. The 2017 version was not toggled in Beta so I thought a new default setting had been pushed out. I was, in fact, still in the 2010 editor. Jbh Talk 00:12, 14 June 2018 (UTC)
Not just you — that pencil thing is new, when did that get added? Nice feature, but wish it wasn't on by default. Was editing a .js page so couldn't turn it off. ~ Amory (utc) 01:13, 14 June 2018 (UTC)
It is has been available as a beta feature for a while, and today it was graduated out of beta. However it definitely shouldn't have turned itself on. I logged into a few alternate test accounts, where I had never used syntax highlighting, and it was not turned on. So not everyone is affected, it seems. At any rate, you can turn it off, and if you do so it should stay that way. Note the JavaScript/CSS syntax highlighting is a different feature that has been around for quite some time. You can also turn that off, though -- click on the "<>" button at the far left of the editing toolbar. MusikAnimal talk 03:00, 14 June 2018 (UTC)
Can somebody please update meta:Community Tech/Wikitext editor syntax highlighting. It claims it is still a beta feature and may be released in July or August. PrimeHunter (talk) 08:45, 14 June 2018 (UTC)
The pencil has been there all along? Didn't notice it. And perhaps it was a "if you've ever turned it on" thing? At any rate, it colors nowiki on js pages, that's how I saw it. As a public service announcement, if anyone uses User:ערן/autocomplete.js, it breaks on this. ~ Amory (utc) 10:31, 14 June 2018 (UTC)
Regarding autocomplete, I may try to adapt it to syntax highlight once phab:T170001 is fixed - but I prefer to not invest time on fixing it as the infrastructure may rewritten (with or without CodeMirror) to properly support all languages. Eran (talk) 17:53, 14 June 2018 (UTC)
And of course the pencil icon isn't there at all if the toolbar is turned off in Preferences, Editing.
If I was inclined to give the syntax highlighting a try, is there a documented way of configuring it?
Mitch Ames (talk) 13:33, 14 June 2018 (UTC)
No, the pencil icon hasn't been there all along. It has been if you had "syntax highlighting" turned on in your beta preferences. Now it is out of beta so everyone gets the pencil. @Amorymeltzer: When you edit a JS page, like User:Amorymeltzer/dashes.js, you see the new syntax highlighting? It has occurred to me that to have the (preexisting) JS/CSS editor, you need "Enable enhanced editing toolbar" turned on in your preferences. I'm guessing you do not. Indeed JS pages don't seem to work well with the new syntax highlighting, because it's not wikitext. I think we can disable this feature on JS/CSS/JSON pages, if you think that's a good idea? (by the way, I definitely recommend the "enhanced editing toolbar" when editing JS!!).

@Mitch Ames: Indeed there is no pencil icon if the toolbar is turned off (because there's nowhere to put it). We could use a link in the sidebar, maybe, but the old toolbar-less editor is going to be phased out anyway, as I understand. MusikAnimal talk 15:55, 14 June 2018 (UTC)

"That pencil icon" has been in the corner of the toolbar for several years, and it switches you to the visual editor. "That highlighter pen icon" just arrived, and it toggles syntax highlighting. It appears that the complaints that the highlighter marker looks too much like the editing pencil are being collected at phab:T174145. Whatamidoing (WMF) (talk) 16:30, 14 June 2018 (UTC)
You are right, thanks for clarifying. I didn't even notice the pencil on the right! I assume we were all talking about the highlighter, though, which indeed looks an awful lot like a pencil. MusikAnimal talk 17:21, 14 June 2018 (UTC)
@MusikAnimal and Whatamidoing (WMF): Yes, indeed, the highlighter. I use the old toolbar, as I only really use it for citation stuff anyway (hence, I only see one "pencil" since visual editor isn't an option) and the highlighter button shows up there. It's not a huge deal, but regardless of toolbar used, this new highlighter button doesn't show up in user js pages. That's good, but when using the old toolbar, js pages mirror the last used highlighting state, and you can't turn it off there since there's no button (or toolbar); you have to go to another page, click edit, turn it off, then reload your js page. With the enhanced toolbar, this isn't an issue. I can file a phab, since that's almost certainly not expected behavior. MediaWiki js pages also show the highlighting, but they also show the old toolbar, so it's reparable. Also, holy shit, thank you, enhanced toolbar for js is amazing! ~ Amory (utc) 17:41, 14 June 2018 (UTC)
  • I personally feel it shouldn't have been graduated from beta just yet. There are still some serious performance issues that I am noticing, especially when I'm on my phone. The syntax highlighter, especially on larger bodies of wikitext, take up to 2 seconds to process sometimes and in doing so blocks key inputs to the text area. If you type regularly, the key inputs queue up and so you sit there waiting for the syntax highlighter to re-process every key stroke. This is even more noticeable on my phone, and as a result auto-correct really messes up my text in those instances. I would like to see the syntax highlighter implement a waiting period before processing. Say like 1.5 seconds after the last keystroke, it should process what's in the textarea, and go to sleep while the user is actively typing. Development IDEs do this already.—CYBERPOWER (Around) 12:40, 14 June 2018 (UTC)
    Concur. I regularly use charinsert for wiki markup, most often to create <code><nowiki></nowiki></code>, two clicks which should leave the cursor inside the <nowiki></nowiki>. But, with the highlighter enabled, the cursor is always moved to the start of the line. The new functionality should not break the old tried and true.
    Trappist the monk (talk) 14:50, 14 June 2018 (UTC)
    I think that is what breaks ProKeys as well. It can not find the current cursor position when the macro proscessing is invoked so it can not tell if the preceding text has a snippet associated with it or where to insert the text if there is one. A brief delay before processing might fix that. It would be nice to be able to use syntax highlighting. The new version is quite nice. Jbh Talk 15:20, 14 June 2018 (UTC)
    @Cyberpower678: I'm not sure what IDE you're referring to, but I assume one that is not within the browser? The syntax highlighting uses a JavaScript library called CodeMirror. This is the same library that GitHub's editor uses, for instance, and also the web inspector that comes with Chrome. The nature of the implementation means very large bodies of content, or a slower devices (like some smartphones), will have a noticeable performance impact. Despite these issues, the time had come that we at least let people decide if they want to use it, and switch it on/off as desired.

    @Trappist the monk and Jbhunley: Your issues with Charinsert and ProKeys sound fixable. I managed to get User:MusikAnimal/responseHelper (which also does cursor placements) to work with the syntax highlighting, maybe I can make the same fix to those scripts. I will look into it! MusikAnimal talk 16:20, 14 June 2018 (UTC)

    If it would be possible that would be great. Thank you for looking into it! Jbh Talk 16:53, 14 June 2018 (UTC)
    @MusikAnimal: When I referred to an IDE, I meant any IDE in general such as PyCharm or PhpStorm. When you make modifications to large chunks of code there, it will generally wait until you have finished typing before processing the text and update the highlighting. What I'm asking for is that this JS do the same. As it stands right now it updates after every keystroke and that produces a major slowdown as the text gets larger, even on a computer. It should be possible to insert a sleep timer that gets reset on every key stroke, and when the timer elapses it updates the highlighting. That would add a major performance improvement, not to mention reduce CPU usage as I am currently observing mine spike to 20% as I type in this window.—CYBERPOWER (Chat) 17:00, 14 June 2018 (UTC)
    I don't know, all of that logic is part of the CodeMirror library. In general we haven't had to many complaints about performance, except on large pages. Your IDE is compiled to assembly and runs directly on your operating system. It will always be faster than your browser (certainly your phone!), which has to interpret the JavaScript. I've actually never used an IDE that doesn't highlight on every keystroke, but I digress. Hopefully we're still looking at a net positive of the syntax highlighting feature being available. All I can recommend is to turn it off if you're experiencing problems. Sorry! MusikAnimal talk 17:21, 14 June 2018 (UTC)
    @MusikAnimal: Then what about giving users the option to have the highlighter not kick in if it takes to long per run, or if the page size exceeds a certain limit?—CYBERPOWER (Chat) 17:31, 14 June 2018 (UTC)
    Interesting idea! Yes I think that is certainly possible. My suggestion would be to make a documented way of configuring this in your Special:MyPage/common.js, such as CodeMirror.maxPageSize = 100000; or something. I don't think we'd want to expose this in the interface, or add more preferences. An initial timeout (takes too long to load) is probably something it should do automatically, and perhaps could be disabled in your user JS (e.g. CodeMirror.timeout = false). Would you mind creating a Phabricator task? MusikAnimal talk 17:36, 14 June 2018 (UTC)

@MusikAnimal: you mentioned above that the WikiText editor is now using CodeMirror. Is that just for syntax highlighting or the editor in general? Is it possible to load CodeMirror alternate keymap files i.e keymap/vim.js? Jbh Talk 20:33, 14 June 2018 (UTC)

Just for syntax highlighting, but that effectively takes over the editor itself. I am not aware of how to load alternate keymaps in CodeMirror, but sounds like it's worth exploring! By the way, the bug with cursor placement is filed at phab:T197263 and we are looking into it. MusikAnimal talk 20:39, 14 June 2018 (UTC)
Yep... Being able to hack the WikiText editor via exposed CodeMirror configuration would be great but that capability seems to go in the opposite direction of what the push to Visual Editor indicates (more technical rather than less). It is a nice wish though.
Thank you for looking into the cirsor issue. Jbh Talk 20:09, 15 June 2018 (UTC)

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)

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

Thanks notifications vanished

At the top, between the links to my user and user talk pages, there are the "bell" and "TV set" icons. The latter has the figure "2" superimposed, implying that I have two unread thanks notifications, but when I click it, I get "There are no notifications." Not even a list of old thanks, which is what I got before today. Clicking the bell icon lists all the old mentions, reverts etc. Is something broken in the thanks system? Oh, it's Thursday - of course it's broken. How silly of me. --Redrose64 🌹 (talk) 20:12, 14 June 2018 (UTC)

Mine seem to be working normally. Have you checked your settings at Special:Preferences#mw-prefsection-echo? DuncanHill (talk) 20:15, 14 June 2018 (UTC)
Something is broken: I click on mine and get the "Our servers are currently under maintenance or experiencing a technical problem." page "PHP fatal error: Class undefined: PageTriageMarkAsReviewedPresentationModel" --Masem (t) 20:16, 14 June 2018 (UTC)
Mine is not working either, the bubble shows up with the number of notifications but when I click on it it says there are none. Home Lander (talk) 20:22, 14 June 2018 (UTC)
Oh dear. Not sure about notifications issue, but the "PageTriage" bug should be fixed within an hour or two. Sorry! MusikAnimal talk 20:41, 14 June 2018 (UTC)
@MusikAnimal: I thanked you for the above post; it might duplicate the issue on your end. Home Lander (talk) 20:53, 14 June 2018 (UTC)
I'm having the same issue. Bringing down the dropdown shows "You have no notifications", but if I click the "All Notifications" button I can see the thanks message at Special:Notifications. --Ahecht (TALK
) 20:54, 14 June 2018 (UTC)

@Redrose64 and Masem: and everyone else... Is it working for you now? MusikAnimal talk 21:45, 14 June 2018 (UTC)

Yes, seems fixed. --Masem (t) 21:50, 14 June 2018 (UTC)
Yes, Face-smile.svg Thank you --Redrose64 🌹 (talk) 23:23, 14 June 2018 (UTC)
Ditto, working here as well. Home Lander (talk) 00:33, 15 June 2018 (UTC)
For the record, MaxSem is the one to thank for fixing it. I get credit for breaking it =p MusikAnimal talk 15:34, 15 June 2018 (UTC)

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)

MZMcBride, how often will the database report be updated? Is there a tracking strategy? NotARabbit (talk) 05:15, 15 June 2018 (UTC)
Currently the report is updated manually. It could be automated in the future. The tracking strategy is basically the use of the "R from" templates and their associated categories. For example, once a page is marked as a misspelling and gets categorized in Category:Redirects from misspellings, it will no longer appear in future versions of the report. --MZMcBride (talk) 14:59, 15 June 2018 (UTC)
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)
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)
Yes, potentially. :-) --MZMcBride (talk) 14:59, 15 June 2018 (UTC)

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)

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)

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)

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 [8] then you currently get June 4 to June 13. PrimeHunter (talk) 09:20, 15 June 2018 (UTC)
Yes PrimeHunter is correct. My guess is if you check back tomorrow, the data will be there. I have no idea how this works (it happens in the Analytics cluster), but some articles may have data for today/yesterday, others not. I've briefly documented this at [9] MusikAnimal talk 15:32, 15 June 2018 (UTC)
It still hasn't updated for the 14th but has for yesterday, I think there is a problem here. The C of E God Save the Queen! (talk) 06:56, 16 June 2018 (UTC)
There is, or at least there was a problem. No data for 14 June. Lofhi (talk) 13:35, 16 June 2018 (UTC)
Is there likely to be a backfill process so that the 14th will show up relatively soon, or is it likely to be missing forever (or an extended time)? I have some automation that is blocked waiting for the data for the 14th at the moment, and want to know if I should just tell it the 14th is never coming and to skip it, or to just hang on a bit longer expecting it will show up within a few days at the latest... — Preceding unsigned comment added by Abulsme (talkcontribs) 16:46, 16 June 2018 (UTC)
(The C of E here). It's still not showing the stats for the day and I don't have much trust in the alternative view counters. Do we have an explanation for this and can the stats be retrieved? The Royal C (talk) 13:07, 17 June 2018 (UTC)
I've filed a task for this at phab:T197542. My assumption is the "job" failed to run, and they can simply re-run it to populate the data, but don't quote me. MusikAnimal talk 15:04, 17 June 2018 (UTC)

Visual Editor for Talk pages, Discussion pages, etc

How long do we have to wait for this? Who are the people who are reposible for the API of Wikipedia? :) Shevonsilva (talk) 17:17, 15 June 2018 (UTC)

This is somewhere in the realm of "nope" and "never" because of how talk pages work. Might be something to add to WP:PERENNIAL at this point. --Izno (talk) 18:17, 15 June 2018 (UTC)
Oh dear dear, that might not be too complex. Developers/Software engineers have only to add some special icons for additional functions, and, in mobile version there is already a kind of GUI interface with a textbox. May I know who are the developers of wikipedia and how it works and how can I contact them for this? :) Thanks. Shevonsilva (talk) 20:44, 15 June 2018 (UTC)
No, it is definitely too complex. If you are sincerely interested in submitting a task, which is 100% likely to be declined, contact information can be found at Help:Bug reports. --Izno (talk) 21:05, 15 June 2018 (UTC)
Thanks for the link. Why do you think it is complex? :) We have to allocate new functions to new toolbar bottons and can directly use the existing API through inheritance and polymorphism. This cannot be a big task as I believe. Shevonsilva (talk) 06:35, 16 June 2018 (UTC)
The phab linked here helpfully quotes/links mw:Help:VisualEditor/FAQ, which, near the bottom, answers your questions. In short, The visual editor is designed to edit content, plain pages of text and Talk pages aren't content. ~ Amory (utc) 00:42, 16 June 2018 (UTC)
Thanks, yes, as we have similar text content (in talk pages and discussions) with additional functionalites, we can simply extend the interface for other text contents as simply we can re-use the API and add new functionalities for this. :) Shevonsilva (talk) 06:35, 16 June 2018 (UTC)
If you think that it's simple, then you try to do it; and on no account may you break existing functionality (broadly construed). It will also be your responsibility to explain why you have done this against consensus. --Redrose64 🌹 (talk) 09:01, 16 June 2018 (UTC)
Thanks, yes. I have to properly analyse the set of new sub-features. Will see how it goes. :) Shevonsilva (talk) 17:25, 16 June 2018 (UTC)

@Shevonsilva: I'm definitely of the opinion that the current setup of talk pages is not very good, and I think it's great that you want to help with that! The problem is, talk and discussion pages have a large array of disparate functions, and designing a solution for all of them simultaneously is very hard. The visual editor is designed to edit content pages, and modifying it so that it serves the two totally different needs will end up meaning it serves neither of the functions well. To be totally honest, I think your efforts would be better focused in a different space; if you're interested in MediaWiki development, then more help is always welcome, and I can absolutely point you to places where you could help out. --Deskana (WMF) (talk) 23:00, 16 June 2018 (UTC)

Little blue arrows in diffs

I this diff I notice a little blue arrow next to Charlie Waite. Is this new? DuncanHill (talk) 19:24, 15 June 2018 (UTC)

Yes, see m:Tech/News/2018/22#Changes later this week Nthep (talk) 19:36, 15 June 2018 (UTC)
Thank you, looks helpful. DuncanHill (talk) 19:39, 15 June 2018 (UTC)

Minor bug in text message for pending changes

When looking at an article with unreviewed pending changes (for example: List of video game developers), the message on top says:

The latest accepted revision was accepted on 9 June 2018. There are template/file revisions awaiting review.

The "template/file revisions" part doesn't fit for an article. Not really a big issue, but the message text should be fixed/tweaked. I am a pending changes reviewer using Vector skin, and have clicked a "Pending changes" tab on top of the article to see the above message. If i remember correctly, the message was different a few days ago and probably has changed recently. GermanJoe (talk) 21:05, 15 June 2018 (UTC)

It has been reviewed now but I saw your quote before the review. Mediawiki used MediaWiki:Revreview-newest-basic-i instead of MediaWiki:Revreview-newest-basic. I don't know why. The edit pending review was [10] which added a link in a table cell. All eight pages currently at Special:PendingChanges use MediaWiki:Revreview-newest-basic without -i, e.g. Jordan Belfort. translatewiki:MediaWiki:Revreview-newest-basic-i/qqq says about the -i message: 'Shown when viewing the latest version of a "checked" page with only template or file changes pending review'. translatewiki:MediaWiki:Revreview-newest-basic/qqq without -i says: 'Shown when viewing a the latest version of a "checked" page with pending changes.' PrimeHunter (talk) 21:29, 15 June 2018 (UTC)
I examined the 20 pages currently at Special:PendingChanges. 19 of them used MediaWiki:Revreview-newest-basic. The last correctly used MediaWiki:Revreview-newest-basic-i for this edit which only makes changes to a template call. Maybe the software mistook the originally reported edit [11] for a template change due to the similar pipe syntax in templates and tables. Another thing is that the default MediaWiki:Revreview-newest-basic-i/qqx says "Template/file changes" while our customized MediaWiki:Revreview-newest-basic-i says "template/file revisions". The latter sounds like edits to a template page and not like changes to a template call in an article. I suggest we say "template/file changes" like the default. PrimeHunter (talk) 09:46, 16 June 2018 (UTC)
Agree. "Changes" would be slightly clearer in this context, when the message is supposed to refer to template and file changes within an article. Thank you for looking into this. GermanJoe (talk) 10:17, 16 June 2018 (UTC)

Cross Lang Conflicts

Dear techy Wikipedians,

I am I am experimenting with using programming way to find cross-language fact conflicts in large scale. Here is a small sample of data I was able to produce for now. I like to ask for some early feedback. Do you think these data would be useful, if yes, can you think of any usecase? If not, what other information can I include to make it more useful?

Please leave comments here.

For now I plan to produce EN v FR, EN v DE. I post related data to the related Wikipedias too.

  • fr:Utilisateur:Xinbenlv/Exemples_de_conflits_croisés
  • de:Benutzer:Xinbenlv/Beispiele_für_Langanguage-Konflikte

Xinbenlv (talk) 22:43, 15 June 2018 (UTC)

The sample data.
  • EN v FR: birthdays
FirstSource FirstLang FirstValue SecondValue SecondLang SecondSource en 1980-08-23 1980-08-22 fr en 1966-05-20 1966-11-14 fr en 1967-08-07 1967-08-09 fr en 1980-10-31 1982-02-07 fr en 1962-02-05 1962-03-24 fr en 1942-11-09 1942-12-06 fr en 1988-02-19 1988-02-18 fr en 1880-02-14 1880-02-17 fr en 1962-08-10 1962-04-10 fr en 1950-08-27 1951-08-27 fr en 1994-03-12 1994-02-09 fr en 1968-09-20 1969-09-20 fr en 1993-07-31 1993-01-31 fr en 1964-03-03 1964-03-04 fr en 1983-07-26 1983-07-20 fr en 1925-06-18 1925-06-08 fr en 1897-03-31 1887-03-31 fr en 1996-04-16 1995-04-16 fr en 1954-08-19 1956-08-19 fr en 1934-04-13 1933-04-13 fr
  • EN v DE birthdays
URL1 code1 birthday1(geburtstag


birthday(geburtstag2) code2 URL2 en 1979-08-23 1979-08-29 de en 1992-09-17 1995-09-17 de en 1917-01-30 1917-06-30 de en 1993-03-15 1993-05-13 de en 1983-12-18 1983-02-16 de en 1945-03-28 1948-03-28 de en 1984-04-11 1980-11-04 de en 1966-03-22 1966-03-02 de en 1995-02-09 1993-12-23 de en 1943-01-17 1943-01-27 de en 1893-06-26 1895-06-26 de en 1928-06-21 1928-01-21 de en 1947-03-02 1947-03-03 de en 1984-08-07 1984-07-08 de en 1983-08-23 1983-08-02 de en 1930-10-21 1930-11-21 de en 1975-06-11 1975-06-14 de en 1985-02-23 1985-02-25 de en 1963-06-04 1963-01-04 de en 1896-03-02 1895-03-02 de
This looks like it can be really useful for fixing Wikidata errors. How do you extract the information? Can you show us the code? Roger (Dodger67) (talk) 23:11, 15 June 2018 (UTC)
Hi @Dodger67, Thanks for your encouragement. On a high-level, the steps are: (1) extract facts from a Wikipedia Article. (2) compare the information that should have a unique value (e.g. a personal can only be born once) across languages. (3)turn this comparison into a Map-Reduce-like large scale pipeline. (4) filter the conflicting data with constraints. Not all technologies I used are open-sourced yet, so I still need sometime to get the code to a status of release-able. Other comments, thoughts? I wonder if people will also think it helpful to fix facts on Wikipedia, too? Xinbenlv (talk) 23:31, 15 June 2018 (UTC)
Seeking more comments Xinbenlv (talk) 01:58, 17 June 2018 (UTC)
Xinbenlv, have you asked over at d:Wikidata:Project chat? I think this would be very useful to Wikidata editors (probably much more than Wikipedia editors), as information is routinely imported from smaller projects like the Russian Wikipedia, which might not have data as good as the English Wikipedia's. There are also probably more editors who are used to querying databases, and there are some tools (with a GUI) which I think can import entire infoboxes from groups of articles. Jc86035 (talk) 09:05, 17 June 2018 (UTC)
@Jc86035, sounds good, I haven't but will do! thanks! ! Xinbenlv (talk) 15:48, 17 June 2018 (UTC)

Underlines not being removed when linking to an anchor using built-in feature

Not really an actual problem, but just trying to figure out why. Internal links look like this: [[User talk:Amaury#Discussion Archives|My Archives]] However, if I use the built-in link feature to make that a link semi-automatically, the underlines aren't removed for some reason: [[User_talk:Amaury#Discussion_Archives|My Archives]]. Why are the underlines not being removed? Here's a quick step-by-step. [12] and [13]. Clicking Internal Link does not remove the underlines. Amaury (talk | contribs) 01:06, 16 June 2018 (UTC)

The images are from a feature on the chain icon in the default toolbar. I never use it but the url to page name conversion seems very limited. It cannot handle percent encoded url's like 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 PrimeHunter (talk) 09:58, 16 June 2018 (UTC)

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

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)

What editor are you using? 2017 Wikitext editor? Visual Editor? Another? --Izno (talk) 13:31, 16 June 2018 (UTC)
Dunno, Izno. Looking at my preferences, I have "Always give me the source editor" checked, and "New WikiText Mode" checked on the Beta Features tab. --ColinFine (talk) 23:14, 16 June 2018 (UTC)
Okay, you're using the 2017 wikitext editor. I see this behavior also in Firefox (have for a while) and it probably deserves a task in Phabricator. I don't see one there. I think we need figure out the exacts of when it happens still. --Izno (talk) 13:04, 17 June 2018 (UTC)

WikEd now inserts div tags all over

Hi, WikEd is still giving trouble, but of a different kind from a week or two ago. Then, it was inserting numerous blank lines, creating havoc with list formatting. Now, it closes things up but too vigorously; if one tries to insert blank lines, the result is often paired <div></div> tags instead. This diff illustrates the thing that I mean. It is a new effect not seen until recently. Hope it can be fixed soon. All the best, Chiswick Chap (talk) 14:26, 16 June 2018 (UTC)

This is very annoying indeed. Headbomb {t · c · p · b} 14:39, 16 June 2018 (UTC)
I can't seem to replicate this - does it happen when inserting blank lines under any circumstances? ƒirefly ( t · c · who? ) 22:27, 16 June 2018 (UTC)
What browsers, browser version, operating systems, and skins are ya'll using? --Izno (talk) 12:53, 17 June 2018 (UTC)
Firefox (most recent version), Win10 64 bit, Monobook. Problem seems to be related to find/replaces with WikiEd, but that could be a coincidence. Headbomb {t · c · p · b} 01:16, 18 June 2018 (UTC)

br after template

Using a template inside an article sometimes the next line goes to a new paragraph. It like there is a <br>. Any solution. Xaris333 (talk) 16:02, 16 June 2018 (UTC)

That is usually because the template has a newline at the end of the output. The solution is to remove the newline from the template, e.g. by starting a noinclude part on the same line as the last template output, but you didn't name any template so we cannot examine your situation. PrimeHunter (talk) 18:59, 16 June 2018 (UTC)
@Xaris333: Or even an article where it is happening. Examples almost always help on VPT. --Redrose64 🌹 (talk) 21:45, 16 June 2018 (UTC)
Problem solved. Thanks. Xaris333 (talk) 16:56, 17 June 2018 (UTC)

Tool for mass redirects?

Based on Wikipedia:Articles for deletion/WNG560, I want to redirect a couple hundred articles to NOAA Weather Radio. I did the first batch by opening a bunch of browser tabs and having a copy-pasting. That got old fast. I could write something that goes through the API to automate this, but that's almost more effort than it's worth (and would probably require bot approval). Is there some existing tool to automate the rest of these? -- RoySmith (talk) 22:02, 16 June 2018 (UTC)

  • WP:AWB? Galobtter (pingó mió) 22:05, 16 June 2018 (UTC)
  • AWB is absolutely the way to go - ping me if you want a hand with doing them. ƒirefly ( t · c · who? ) 22:16, 16 June 2018 (UTC)
  • Ah, cool. Yeah, that looks like exactly what I need, thanks. RTFM-ing now. -- RoySmith (talk) 22:20, 16 June 2018 (UTC)
    • Oh, wait. Runs on windows only? Really??? That's like a non-starter for me. -- RoySmith (talk) 22:28, 16 June 2018 (UTC)
      • You can use WP:JWB Galobtter (pingó mió) 22:30, 16 June 2018 (UTC)
        • OK, that's working fine (once I figured out I needed the "s" regex flag). Thanks again. -- RoySmith (talk) 23:11, 16 June 2018 (UTC)

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)

@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)
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)
The task to watch is phab:T194588. --Izno (talk) 13:09, 17 June 2018 (UTC)
Ah, much obliged! I figured someone must have gotten there ahead of me. Snow let's rap 21:26, 17 June 2018 (UTC)

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

-- (talk) 22:12, 17 June 2018 (UTC)

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

No indentation in this line

  • 1 asterisk
            • 5 asterisks
1 colon
5 colons
20 colons

Image upright went wrong

Pls see fluorine & talk. My "upright" (image) went wrong, but i am mobile now so cannot revert myself. -DePiep (talk) 22:41, 17 June 2018 (UTC)

I have reverted your edit.[14] Wikipedia:Extended image syntax#Using "upright" says: "The upright option works in combination with the thumbnail or thumb option". PrimeHunter (talk) 22:49, 17 June 2018 (UTC)
ok. -DePiep (talk) 23:21, 17 June 2018 (UTC)
Retrieved from ""
This content was retrieved from Wikipedia :
This page is based on the copyrighted Wikipedia article "Wikipedia:Village pump (technical)"; it is used under the Creative Commons Attribution-ShareAlike 3.0 Unported License (CC-BY-SA). You may redistribute it, verbatim or modified, providing that you comply with the terms of the CC-BY-SA