Wikipedia:Village pump (technical)

 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.
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.
For server or network status, please see Wikimedia Metrics.
« Archives, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176


The website disappears for seconds then appears whenever I enter a page or refresh a page[edit]

So when I refresh or enter any Wikipedia page. The page appears then suddenly everything disappear for few seconds and then it appears. Anyone having the same issue? I am using mobile version.--SharabSalam (talk) 19:48, 8 October 2019 (UTC)

This is actually very annoying in large articles or pages like this.--SharabSalam (talk) 19:50, 8 October 2019 (UTC)
what mobile device and browser? My iPhone safari seems slightly problematic with newest OS. AManWithNoPlan (talk) 22:44, 8 October 2019 (UTC)
It happens in my laptop as well, when I switch to mobile version. I am using google chrome in both my mobile and my laptop.--SharabSalam (talk) 03:30, 9 October 2019 (UTC)
Is this § Mobile glitch on page load?  Nixinova  T  C  00:47, 12 October 2019 (UTC)
Nixinova, yes.--SharabSalam (talk) 21:03, 12 October 2019 (UTC)

Is there a way to force a purge of PAGESINCATEGORY ?[edit]

{} is showing a higher count (2) than the actual number of pages in the category. Is there a way to force a purge of this counter to get it synched with the actual count again? wbm1058 (talk) 18:56, 9 October 2019 (UTC)

Pretty sure there are archived threads on this, also phab tickets. It's why the word "approximately" was added to the message "The following 200 pages are in this category, out of approximately 9,999 total". In short: it's a bug, they know, they've not fixed it yet. --Redrose64 🌹 (talk) 19:20, 9 October 2019 (UTC)
Oh, I see: Wikipedia:Village pump (technical)/Archive 46 § Incorrect counts from PAGESINCATEGORY function. (September 2008) – wbm1058 (talk) 19:42, 9 October 2019 (UTC)
But T15683, {} sometimes returns a negative number, was closed in May 2008 after r34870, "if the number of pages (or subcats or media files) is negative on initialization, we just do a recount."
More recently, T16237, PAGESINCATEGORY should differentiate between pages and subcategories, was closed in 2012 after this update.
Added PAGESINCATEGORY: magic word in April 2008.
My phabricator search isn't finding any open bug report for the issue reported on Village Pump in September 2008. Is it possible that a formal bug report was never submitted for this? wbm1058 (talk) 11:26, 10 October 2019 (UTC)
@Wbm1058: to your specific question, it looks like phab:T85696, for the general problem it appears to have all rolled up in to phab:T221795. — xaosflux Talk 11:43, 10 October 2019 (UTC)
So, having been annoyed by this for over a month, and losing my patience in waiting for a better fix, I tried deleting and restoring the category, and, voila, the count was refreshed to the correct number! wbm1058 (talk) 02:48, 18 October 2019 (UTC)

Preserving my anonymity when not logged in[edit]

I have a question about how best to preserve my anonymity when not logged in. I have one solution in mind that would require IA help. But before I try WP:IANB, I thought I'd air the issue here first, to see if there may be a better/easier solution.

My goal is to avoid inavertently making changes when when not logged in, so I don't out my IP if I save something with a recognizable pattern. I imagine that one approach, is to somehow warn myself before hitting "Publish". I've taken a sort of mirror-image approach to this, via a change to my common.css, which turns my "Publish" button green when logged in, as suggested at the Help Desk in 2012. This doesn't warn me when I'm not logged in, but it (hopefully) will get me used to a green Publish button, so that when I'm not logged in and don't see it, my spidey sense will tingle. Only, I have a crappy spidey sense, so I don't think that will work. (At that same discussion, someone pointed to a "MediaWiki: Prevent anon editing script" that apparently works with Firefox—not my habitual browser—but in any case, that link is now dead.)

The idea I had for the solution, is to copy the code I have in my common.css, to [[User:<my-actual-ip-address>/common.css]], and change the color of the Publish button to red (and maybe also add a CSS ::before selector to generate added text "Are you sure?" right before the button as well). So, I was going to request an IA to add the common.css for me (after passing the IP via email, and checking with a CU, if necessary, to verify it's me). But that's rather costly in limited human resources, and it occurs to me that there might be an easier or better way. Is there? Mathglot (talk) 01:16, 10 October 2019 (UTC)

Not an answer to your specific question, but you might be interested in m:IP Editing: Privacy Enhancement and Abuse Mitigation. -- RoySmith (talk) 01:21, 10 October 2019 (UTC)
Being able to run scripts for the next user of any IP address you use would be a disaster waiting to happen. For this reason you need to be logged in to run customisations in your userspace on Wikipedia. The solution would be to host the CSS in your browser - there are probably many extensions/plugins/browsers capable of doing that. I personally use the green button thing, as well as some other UI changes when I'm logged in, and I find it actually kinda works. -- zzuuzz (talk) 01:22, 10 October 2019 (UTC)
This. Assuming you usually use the same browser, you can do tons of stuff, the page source has information such as the logged in user information - if it is not there you could just remove the button with local javascript. — xaosflux Talk 01:36, 10 October 2019 (UTC)
Custom JS and CSS are loaded only for logged-in editors. Any code in the js/css subpage of an IP address won't work. The solution to your problem, as mentioned above, is to deploy custom JS/CSS through your browser. SD0001 (talk) 07:01, 10 October 2019 (UTC)
@Mathglot: Your mirror-image approach is the "right" way to do this. It's what I do and while it might take a little bit, once you adjust, seeing a different color will be quite jarring. There are other things you can tweak too, for an even greater difference, and that's not even counting using a different skin or noticing your gadgets aren't loading. ~ Amory (utc) 09:56, 10 October 2019 (UTC)
The dead script link is mirrored at with source code at You can ask for help at Wikipedia:Reference desk/Computing if you name your browser. PrimeHunter (talk) 12:10, 10 October 2019 (UTC)

The only good thing about them changing the default skin from monobook to vector is that I immediately notice when I'm not logged in. ―cobaltcigs 06:56, 18 October 2019 (UTC)

Template "Whos Who" not working[edit]

Template:Who's Who has stopped generating the correct links, at least when the type = was is selected, returning a 404 error. DuncanHill (talk) 20:25, 10 October 2019 (UTC)

I have fixed it by simply ignoring type = was.[1] I couldn't make any save of the template, not even a null edit, until I removed transclusion of the documentation. All attempts failed with "Syntax error in JSON (help)". I never learned TemplateData syntax so I'm not trying to fix Template:Who's Who/doc. PrimeHunter (talk) 22:22, 10 October 2019 (UTC)
Thanks, the template hadn't been changed since it was working. DuncanHill (talk) 22:32, 10 October 2019 (UTC)
TemplateData needs to be in valid JSON format. When there are single braces { ... } these indicate an object, which is a comma-separated list of zero or more name:value pairs; there should not be a comma after the last pair. This edit by Snaevar (talk · contribs) fixed it. --Redrose64 🌹 (talk) 22:49, 10 October 2019 (UTC)
Yeah, that's a wonderful trap awaiting template editors: "Syntax error in JSON" when trying to edit a template, and the JSON programming code is in the (unprotected) documentation. I dropped a note at a MediaWiki talk page, but it might be worth a phab bug report. – Jonesey95 (talk) 23:02, 10 October 2019 (UTC)
Based on a search "Syntax error in JSON" intitle:doc we have at least 68 such traps lying around. I was unable to save a null edit on any of the tested corresponding templates, e.g. Template:Douban/doc. Maybe we should add a tracking category to MediaWiki:Templatedata-invalid-parse. PrimeHunter (talk) 00:57, 11 October 2019 (UTC)
AFAICT, the problem here is explained in T214984, which basically says that the old parser, HHVM, used to (mistakenly) allow saving of some buggy JSON, and the new parser, PHP7, does not. I think this means that if you try to edit a buggy page, the new parser will complain. The solution, I think, is to edit the /doc subtemplate, copy and paste the TemplateData code into JSONlint, fix it, and paste it back into the /doc subtemplate. Then you'll be able to edit the template. There may be a simpler way, and what I know about all of this couldn't fill a thimble, so feel free to correct/strikeout/trout anything I got wrong.
And yes, please add a tracking category that will appear in the list at Special:TrackingCategories. Thanks. – Jonesey95 (talk) 02:06, 11 October 2019 (UTC)
Special:TrackingCategories lists tracking categories which are part of MediaWiki itself. A wiki cannot add new categories there. We can make subcategories like Category:Templates with TemplateData errors in Category:Wikipedia template cleanup or the large Category:Tracking categories. But it appears that HHVM use is ending and Rchard2scout has already fixed most doc pages in my search so maybe there will soon be no need for tracking this issue. PrimeHunter (talk) 09:38, 11 October 2019 (UTC)
Yeah, I saw this discussion, and thought I'd just clean it all up. Sometimes a bit of honest gnoming is the easiest solution. Most of them were commas after last items (which aren't allowed, which I think is a stupid requirement of the JSON standard), and some newlines which had to be converted to \n. PrimeHunter's search now turns up zero results, and I expect in the future it will be practically impossible to make new mistakes, given almost everyone is probably being moved over to the new editors/parsers. rchard2scout (talk) 10:07, 11 October 2019 (UTC)
I have linked Category:Tracking categories in MediaWiki:Trackingcategories-summary which is displayed at top of Special:TrackingCategories. PrimeHunter (talk) 09:49, 11 October 2019 (UTC)

Problem using JSON with <mapframe>[edit]

There is a problem using json data with <mapframe>, which now generates the error "<mapframe>: Couldn't parse JSON: Control character error, possibly incorrectly encoded". It seems to be a change in how control characters are handled. I fixed the map at List of state highways in Kerala by replacing linefeeds with "\n" (this edit). This is unsatisfactory as it makes it very difficult to understand the query. Any ideas what changed and how to fix it or where to report it?   Jts1882 | talk  09:21, 12 October 2019 (UTC)

@Jts1882: This is related to #Template "Whos Who" not working above. --Redrose64 🌹 (talk) 12:50, 12 October 2019 (UTC)
Ah, T214984 mentioned above explains the problem. This change to the JSON parsing affects a large number of pages using JSON data with maps. Is it possible that there could be a general fix through <mapframe> or will all the pages have to be fixed individually? I'm thinking it will have to be the latter.   Jts1882 | talk  13:17, 12 October 2019 (UTC)
It looks like there are roughly 86 of these in article and template space. – Jonesey95 (talk) 14:23, 12 October 2019 (UTC)
Here's one way to fix the problem, but Jts1882 is correct that it makes the query a lot less easy to read. Is there a better way? Wikicode can use HTML comments to format long lines to make them more readable; I don't know if there is a way in JSON to achieve a similar effect. – Jonesey95 (talk) 14:50, 12 October 2019 (UTC)
JSON doesn't have comments. 77 of those 86 may be sorted by fixing Template:Kerala State Highways Network. --Redrose64 🌹 (talk) 15:26, 12 October 2019 (UTC)
I've fixed that one with "\n" additions, but it doesn't clear 77 instances. A number of them use map data pages such as Wikipedia:Map data/Australian LGAs/Tasmania/Central Highlands and have additional linefeeds at the beginning and end, plus a comma at the end. I've fixed some of them.   Jts1882 | talk  17:07, 12 October 2019 (UTC)

───────────────────────── Side note: There's some explanation about JSON in templates at mw:Topic:V6u2mpy11qiu9705, if anyone wants background information. Whatamidoing (WMF) (talk) 20:59, 18 October 2019 (UTC)

Page file size graph[edit]

Is there a tool that graphs the change to a page's file size over time? ―Mandruss  21:35, 10 October 2019 (UTC)

Rough draft user script here: User:Cobaltcigs/HistoryGraph.js
  • Example output: screenshot
  • Activate by calling AddGraphLink(); function after pageload.
  • Adds a link called "Show graph" (see cursor arrow location) to action=history pages.
  • Depicts (in a popup div) whatever series of revisions is currently visible on said history page.
  • Has, therefore, a hard maximum of 5000.
  • Requires a browser capable of rendering an <svg> element defined within the html document. I don't have a list of these, but I'm guessing that means not Internet Explorer.
cobaltcigs 10:12, 11 October 2019 (UTC)
@Cobaltcigs: Thanks for the effort! I don't know how to get more than 500 on a history page. Even if I did, 5,000 wouldn't be enough for my immediate need, which is to show fluctuation over a period of several years at a high-activity article. ―Mandruss  17:13, 11 October 2019 (UTC)
@Mandruss: There is also a chart showing yearly granularity at E.g. see the orange line at [2]. MusikAnimal talk 17:26, 11 October 2019 (UTC)
@MusikAnimal: Thanks. That looks like what is available via the "Page statistics" link on the history page. I need at least month granularity. ―Mandruss  17:41, 11 October 2019 (UTC)
@Mandruss: A history page typically shows 50 revisions, but can show anything from 1 to 5,000 revisions (if they exist). The links for 20, 50, 100, 250, 500 are merely samples of what's possible - to show any other amount, click any of those links (20 is best because the subsequent fetch and display is quickest), then go to your browser's address bar where you should find that the right-hand end of the displayed URL now looks something like this: &offset=&limit=20&action=history. Alter the value following limit= to any positive integer between 1 and 5000 inclusive and then press ↵ Enter. When doing this, make sure that you don't remove any ampersands by mistake; and don't use a comma in values 1000 up. --Redrose64 🌹 (talk) 20:58, 11 October 2019 (UTC)
Thanks, I'll try to remember that. It may come in handy, but as I said above it's no help in this case. ―Mandruss  21:00, 11 October 2019 (UTC)
@Cobaltcigs: Upon reflection, I guess I could make do with multiple 5000-revision graphs. The real problem is that (I'm guessing here) your X axis is scaled to revisions instead of time; i.e., the X-distance between consecutive revisions is the same whether they are a minute or a day apart. I'd need that fixed at a minimum, and it would then be extremely useful to have single-letter month labels on the X axis (JFMAMJJASONDJFMAMJJASOND...), with the year shown vertically below the J for each January (or horizontally below each JFMA). If any of this is more than you feel like taking on, I completely understand. ―Mandruss  21:52, 11 October 2019 (UTC)

So I'm re-learning how to use the API, which would allow getting the entire history through several incremental requests (to wit, 500 per). Above assumption is correct and the timestamps are not currently even looked at. Parsing these and converting to a floating point number is trivial. The hard part is deciding how to handle the inherent problem of scaling by time, which is that the ratio of revisions to amount of time represented by a pixel of screen width (let's call that, roughly, "edits per day") will vary drastically from one page to the next, or even between different eras of the same page. Depending on density, the graph's general appearance could vary from sand dunes, to a liar's polygraph, to calligraphy. So some sampling/averaging strategy might be needed to reduce noise (i.e. avoid trying to show several size values at the same x position). An onscreen interface to tweak the settings of same might also be helpful. ―cobaltcigs 13:11, 12 October 2019 (UTC)

@Cobaltcigs: My strategy, were I working on the platform where I have competence, would be to plot the file sizes at 12:01 am on the first day of each month (UTC). You'll rarely have a revision at that time, but that file size will be shown in the last revision before that time. In other words you're not plotting all revisions, but only one per month – so density is not a factor. ―Mandruss  19:44, 12 October 2019 (UTC)
Assuming the risk that any given page had blanking or crapflooding vandalism at the end of one month (that went unreverted until the beginning of the next month) is low enough to be acceptable, then yes, that would be easier. ―cobaltcigs 07:23, 14 October 2019 (UTC)
That would be ok with me. So you think you can do this? Any time frame? ―Mandruss  14:08, 14 October 2019 (UTC)
Alternatively, you could plot the average size for each month. You decide which is better, I'm ambivalent. ―Mandruss  15:08, 14 October 2019 (UTC)


  • Screenshot
  • Singly grabs last revision before YYYY-MM-01T00:00:00Z of every month, from the API.
  • No longer connected to the history tab, is now a separate tab with its own "fake" action.
  • Takes about 10 seconds per year on my system.
  • Expands off the right side of the screen when graphing older pages.
  • Has month/year labels, positioning of which is a bit dodgy. Added longer vertical line to January for clarity.

cobaltcigs 10:27, 16 October 2019 (UTC)

@Cobaltcigs: That looks pretty good. How about some extra guidance on installation and, if not self-explanatory, usage. ―Mandruss  06:37, 17 October 2019 (UTC)
So you should be able to importScript('User:Cobaltcigs/HistoryGraph.js');, then see a "graph" tab, right after the history tab of any page that has an edit history (i.e. neither a "Special:" page nor a red link). See red arrow in same-as-above screenshot (which uses "monobook" skin).
Note: Based on suspicion that you may instead be using the "vector" skin, I tested it there too. To my surprise it seems to function the same, except the "graph" link becomes hidden in a drop-down menu under a tab titled "More" rather than appearing as a separate tab. I have no idea why that is, or how to correct it. (I also noticed the "move" link is hidden in the same place, which seems like it would suck—glad I don't use vector.) All other skins remain untested at this time.
In any case after you find this link and click on it, navigating to a url with the fake &action=graph, the content area should begin populating with a list of timestamps to show API loading progress. This may take a few minutes on very old pages. After loading these, the fully rendered graph should appear in the same place. You may then have to scroll to the right to see the whole thing.
Note: I'm not aware of any way to activate rsvg on the server side to produce a PNG thumbnail from an arbitrary string of SVG/XML text (or from anything not uploaded in the File: namespace). Also (at least in my browser) right-clicking on the graph (an embedded SVG element) does not offer a "Save as..." option to download the SVG. So if that's what you actually want to do, it may require adding a "download" button using one of these techniques (which doesn't seem very difficult).
cobaltcigs 07:46, 17 October 2019 (UTC)
@Cobaltcigs: Presently in vector, the menu does appear after the History button if you've a wide-enough monitor, but it looks oddly disfigured. You should use the code mw.util.addPortletLink('p-cactions', `/w/index.php?title=$&action=graph`, 'Graph', 'ca-graph') to place the menu button. Apart from being a one-liner rather than 10 lines, this will also correctly place the menu across all skins (which is inside the "more" dropdown for vector - i think that's ok as vector users are used to seeing custom script buttons in the more dropdown).
Also it looks like the script sending the api calls only after the previous one's response has been received, rather than send them parallely, making it quite slow for articles with long histories (eg. try it on the article History). SD0001 (talk) 08:32, 17 October 2019 (UTC)
Thank you for the feedback. I'll go ahead and use the addPortletLink function which I was unaware of.
As for the API requests, I did it that way to ensure they're all received and pushed into the array in a predictable order. If they're all sent at the same time, I'd probably have to switch to some key-value mapping like sz[`$-$`] = parseInt(ms[1]); (which I know how to do), then convert this object into an array of sizes sorted by said YYYY-MM keys (which I also how to do), but only do this after determining that the last response is complete (which I really don't know how to do in a parallel-thread situation).
Also the number of months to go back is not known in advance. It only quits after finding a beginning-of-month timestamp with zero preceding edits. I suppose I could try looking forward from an impossibly early (pre-Wikipedia) timestamp to determine first edit date, then simultaneously fetch 1 edit backward from the first of every month between that date and the present. Seems like that approach would reveal an expected key/value count (of the object above) to determine completion of the last request. But from what code in what thread? Should it just keep checking back at an arbitrary setInterval()?
cobaltcigs 09:08, 17 October 2019 (UTC)
@Cobaltcigs: Ok, it's working. Yes, I'm Vector skin. AFAIK that's still the default skin so it's going to be the most commonly used by far. I'm happy with Vector.
I do need a way to capture the graph so I can share it in a discussion. For my immediate purpose I can just take a screenshot of the right end of the graph, showing May 2014 through present. Whether that will be adequate for future needs by me and others, I don't know. I don't care to attempt one of those techniques that don't seem very difficult (to you).
That means the Y axis is not on screen, so it would be great to have it repeated on the right side. ―Mandruss  09:30, 17 October 2019 (UTC)

I've added the download button. SVG file should appear in your browser's download folder with a title like HistoryGraph-$.svg. Converting to other formats is left as an exercise. GIMP is recommendable. ―cobaltcigs 10:14, 17 October 2019 (UTC)

Read only maintenance window planned for ENWP at 14th Nov 05:00 AM UTC[edit]

See ↠Pine () 22:43, 10 October 2019 (UTC)

@Pine: see also MediaWiki_talk:Sitenotice#Banner_for_read-only_-_Thu_14th_November_from_05:00_to_05:30_AM_UTC where we declined a "banner" - as far as a WLN, short read only periods happen periodically and we don't normally post them. In this case, phab:T234801 also says that while it could be 30 mins, they are only expecting "1-2 minutes" of interruption. — xaosflux Talk 23:10, 10 October 2019 (UTC)
@Xaosflux: let's have the discussion about notifications at the Watchlist-messages talk page so that we don't have the same discussion in two places. Thanks, ↠Pine () 06:47, 11 October 2019 (UTC)

Announcement: script-installer now an actual gadget[edit]

The User:Enterprisey/script-installer provides one-click installation and management of user scripts without editing common.js. I just moved it out of the "testing and development" gadget section, so it's ready for broader use. You can find it at the bottom of the "Editing" section at Preferences → Gadgets. This is exciting because common.js (and telling non-technical people to write javascript) can now be completely avoided. (I've had it as a gadget since March, but only in the testing and development section, and completely unannounced - 482 people managed to find and install it anyway.) Enterprisey (talk!) 00:29, 11 October 2019 (UTC)

@Enterprisey: at the very least this should have a link to a more thorough description of what this gadget does. If the main page is User:Enterprisey/script-installer - this should probably be moved to a Wikipedia: page, as "gadgets" are community maintained. — xaosflux Talk 01:21, 11 October 2019 (UTC)`
Good idea. I added a link. I was going to move the documentation page to WP:Script Installer, but right now it looks like that name is occupied by the documentation for Gary's "Script Installer" script, which I actually didn't know about until just now. We could convert that page to a disambiguation (mine, Equazcion's, Gary's, and other installer scripts that might be out there), I guess? Enterprisey (talk!) 01:55, 11 October 2019 (UTC)
@Enterprisey: Wikipedia:Script-installer maybe? And then just put a {{for}} or something on them? — xaosflux Talk 03:03, 11 October 2019 (UTC)
@Enterprisey: I don't think there's any need to move the documentation to the project space. What needs changing is the "Skin support" and "browser support" fields in the infobox. Pretty sure the script works properly on chrome and other browsers. As for skins, there are a few issues: (i) in the modern skin, background color is same as the text color - making the "Install | Manage user scripts" buttons invisible, (ii) in timeless, the cursor doesn't become a pointer when hovering over the buttons, (iii) in cologneblue, the buttons don't work at all. SD0001 (talk) 06:46, 11 October 2019 (UTC)
Should all be fixed now. Thanks for the bug reports! Enterprisey (talk!) 00:05, 12 October 2019 (UTC)
Also, regarding the duplicate version at User:Enterprisey/script-installer.js, would it be a bad idea to replace its contents with something along the lines of
mw.loader.using( [ 'user.options', 'mediawiki.api' ] ).then( { if ( !mw.user.options.get( 'gadget-script-installer' ) ) { new mw.Api().saveOption( 'gadget-script-installer', '1' ); } } ); 
migrating all current script users to the gadget version? I think this is desirable because gadgets are cached and minimised and hence load faster. SD0001 (talk) 07:11, 11 October 2019 (UTC)


User:Jackmcbarn/advancedtemplatesandbox.js is a useful userscript used to extend Extension:TemplateSandbox to all spaces. However, it does not look like it is still maintained and Jackmcbarn appears to be inactive. For one, I had trouble using the userscript installer on it. I did get it to work finally. My question: is there an alternative? Is anyone willing to copy it and maintain it? I don't have the technical skills. --- Coffeeandcrumbs 01:11, 11 October 2019 (UTC)

Coffeeandcrumbs, are there any specific issues with the script that need fixing? Galobtter (pingó mió) 05:34, 11 October 2019 (UTC)
It's only some 20 lines of javascript (though exceptionally useful!), and doesn't need any maintenance in particular. I do have a copy of it at User:SD0001/sandbox4.js that adds an extra feature - on sandboxes, the page name is pre-filled with the template name ("/sandbox" of the current page name being stripped). SD0001 (talk) 06:38, 11 October 2019 (UTC)
@SD0001: That is exactly the feature I was going to request. Installed. Thank you! You should add it to WP:USLIST. --- Coffeeandcrumbs 08:22, 11 October 2019 (UTC)

Mobile glitch on page load[edit]

Wikipedia glitch 20191012.png

When a page fully loads on the mobile Wikipedia, the top bar temporarily (~<1sec) becomes the height of the screen and the Wikipedia logo goes down to the bottom of the screen (see image).  Nixinova  T  C  00:43, 12 October 2019 (UTC)

See phab:T235092. – Ammarpad (talk) 06:01, 12 October 2019 (UTC)
  • This has been going on for a lot of time. I already stopped using my mobile when editting.--SharabSalam (talk) 21:04, 12 October 2019 (UTC)

Missing section edit links[edit]

Why don't I see any section edit links at Template:Talk archive navigation/doc? As a control case, page Template:Talk header/doc appears with section edit links as expected. Possibly relevant:

Looking at the page source for section Usage in each case, I see this:

<h3><span class="mw-headline" id="Usage">Usage</span></h3>


<h2><span class="mw-headline" id="Usage">Usage</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/w/index.php?title=Template:Talk_header/doc&action=edit&section=1" title="Edit section: Usage">edit</a><span class="mw-editsection-bracket">]</span></span></h2>

respectively. Is this because someone went straight to H3, skipping level 2 headers in the doc? Why should that suppress edit links, even if it is an unrecommended habit per MOS:SECTIONS? Mathglot (talk) 22:38, 12 October 2019 (UTC)

@Mathglot: Template:Talk archive navigation/doc transcludes {{Talk archive navigation}} in the "Optional parameters" section. That template adds a __NOEDITSECTION__, presumably to discourage inexperienced editors from replying to archived messages. Suffusion of Yellow (talk) 22:44, 12 October 2019 (UTC)
To amplify: heading levels (n.b. not header levels) have nothing to do with it. In the rare cases that a page has no section edit links and nothing is using or transcluding __NOEDITSECTION__, it usually comes down to bad Wikimarkup - such as a pair of opening braces that are not followed by a valid template name, and are also not balanced until much later in the page. --Redrose64 🌹 (talk) 23:24, 12 October 2019 (UTC)
Thanks, @Suffusion of Yellow and Redrose64: In that case, shouldn't the __NOEDITSECTION__ be enclosed inside <includeonly>...</includeonly>? Mathglot (talk) 23:58, 12 October 2019 (UTC)
That wouldn't matter. The template is transcluded in the documentation so it would still run code in <includeonly>...</includeonly>. There are other ways to avoid activating __NOEDITSECTION__ but it's hardly worth it for a single doc page. PrimeHunter (talk) 00:06, 13 October 2019 (UTC)
K, thanks. This page just stuck out, because I hadn't seen that behavior before. Am willing to let it drop here. Thanks again, for all the responses! Mathglot (talk) 00:14, 13 October 2019 (UTC)

Final thought: kind of unrelated—I think—but since we're all here: shouldn't all those H3 headings at Template:Talk archive navigation/doc be H2's instead? Mathglot (talk) 20:48, 13 October 2019 (UTC)

Some of them, yes. --Redrose64 🌹 (talk) 21:49, 13 October 2019 (UTC)
I'm also missing section edit links on Portal talk:Australia; there may be a transcluded __NOEDITSECTION__ but it's not obvious. Certes (talk) 10:58, 17 October 2019 (UTC)
I found the right place with Special:ExpandTemplates and removed __NOEDITSECTION__ from the output with {{replace}}.[3] PrimeHunter (talk) 11:25, 17 October 2019 (UTC)

Why are unpatrolled Wikidata changes rendered immediately at Wikipedia?[edit]

There is currently a discussion going on at Wikidata that folks here may be interested in commenting on. In brief: a vandal's change to the "description" field at the Wikidata Gay (Q592) item showed up immediately as the "short description" at the top of Wikipedia's Gay article.

Although it affects Wikipedia, the locus of the problem appears to be Wikidata, so the discussion is being hosted there. Your feedback would be appreciated at WD:CHAT. Thanks, Mathglot (talk) 01:15, 13 October 2019 (UTC)

It's for precisely this sort of problem that we've gone to the trouble of setting up WP:WikiProject Short descriptions and are working on supplying 2 million articles with local short descriptions. The locus of this particular problem is not at Wikidata. It's at Gay where someone on a mission decided to remove the local short description "Term for person with same-gender attraction" and left the article open to display vandalism from Wikidata, which inevitably happened soon after. --RexxS (talk) 02:56, 13 October 2019 (UTC)
RexxS, If that is truly the reason that the WikiProject was set up, then I have to say I am stunned. It sounds like you are saying, "Since Wikidata can't be trusted, we're creating millions of entries on Wikipedia in order to override it." Or am I misreading you? I had assumed that the reason for WP:WPSHORTDESC was to supply descriptions until Wikidata, which is a smaller group, could catch up. Was I wrong about that?
Secondly, I can assure you that the editor who removed the local short description at Gay is not "someone with a mission", and certainly did not remove the value in order to leave the article open to vandalism, but to allow it to default to a value judged better at the time. User:Crossroads is a respected editor who is HERE for no other reason than to improve the encyclopedia, as evidenced by his numerous improvements at articles and his cogent and informed reasoning at Talk pages.
As far as where the locus of the problem resides, if our trust level of Wikidata is such that we are overriding its data through great effort at Wikipedia, that means the problem resides with Wikidata, especially if it's true that fields are "inevitably" vandalized there. The fact that we are fixing the problem here, is equivalent to stopping the importation of faulty car parts from a bad supplier; we may have fixed it, but the problem is not on our side. If this is what's happening here, then one solution would be to shut down importation of Wikidata short description until it is judged to be reliable enough. Are we to the point where that is a discussion that needs to be aired? Mathglot (talk) 18:24, 13 October 2019 (UTC) updated to redact double quotes (even though the strike is too low); by Mathglot (talk) 20:37, 13 October 2019 (UTC)
The WikiProject was created after the close of Wikipedia:Village_pump_(proposals)/Archive_145#RfC:_Populating_article_descriptions_magic_word. There is already a consensus to eventually shut down the use of Wikidata for short descriptions, but the WMF won't allow it until there are enough local short descriptions. Galobtter (pingó mió) 18:48, 13 October 2019 (UTC)
@Mathglot: No, what I'm saying is that "Since the description field on Wikidata has no means of being sourced, it is unverifiable and therefore directly contradicts WP:5P2: All articles must strive for verifiable accuracy, citing reliable, authoritative sources." Nobody here asked the WMF to force the contents of Wikidata description fields into English Wikipedia's articles, and despite a strong consensus against them, the WMF team refused to turn them off. The compromise that was hashed out was that we were given a new "magic word" that allowed us to use local descriptions instead of those drawn from Wikidata; and that the Wikidata feed would be turned off when 2,000,000 articles had local short descriptions. That's why we have the WikiProject. We are actually creating descriptions for articles that are locally editable, subject to our anti-vandalism patrols, and governed by the English Wikipedia's sourcing policies, in particular BLP. Those descriptions could be exported to Wikidata, of course, but I'm not sure of their value there, since each language has its own description and (unlike most other parts of Wikidata) they are not intrinsically useful to other projects.
As for Crossroads, an edit summary of Wikidata description is more accurate. "Gay" is used far more for men than for women; and homosexuality is most often referred to in RS as same-sex attraction and not same-gender attraction. While our article lead on Homosexuality allows for both, it puts "sex" first. certainly had the appearance to me of someone trying to make a point through original research - YMMV. The effect, of course, was the same whatever the intent: it opened up our article for vandalism from Wikidata and left it so that editors had no indication that they had to go to another project to fix it. If you think that my use of "inevitably" deserves scare quotes, then perhaps looking at the edit history of gay (Q592) might persuade you otherwise.
"if our trust level of Wikidata is such that we are overriding its data through great effort at Wikipedia, that means the problem resides with Wikidata" That's an incorrect inference. The problem resides with a WMF development team who unilaterally decided that it was okay to import unsourceable information into the English Wikipedia against the advice of enwiki editors. A better analogy for us fixing the problem locally would be the situation where we are importing faulty car parts from an otherwise good supplier; we say we don't want any more faulty ones; but the importer keeps sending them and we are forced to keep using them until we can make them ourselves locally. Whose side is the problem on now?
Look, I know I'm coming across as exasperated, but that's what I am. I've been wrestling with this problem since it was first proposed, and I've explained what will go wrong a hundred times, and I'm sick of saying "I told you so" after the event. For others who still aren't familiar with the issues, please read at least some of the discussions linked from Wikipedia:WikiProject Short descriptions#History 2. Then if you want to criticise me for being annoyed, I'll be happier to accept it. Cheers --RexxS (talk) 20:21, 13 October 2019 (UTC)
No, I don't want to criticize you, on the contrary, I want to thank you for taking the time to give such an informative background, for something you've obviously had to say more than once before. I'm just sorry you're frustrated. (I know what that feels like, in a completely different corner of the encyclopedia; happy to discuss that over on my Talk page.) I also appreciate your extending the analogy in order to give me a better view of what's going on. I'm going to have a look at some links to try and get up to speed, and then try to help out on the project a bit, as I'm able, to try to get you to 2M. For what it's worth, my entry point to this whole issue was also from 5P2, when I realized what was going on at Gay and that we had no control over the reliability of such data; so you might say I got here by the side door. Thanks again for your feedback, and your work on the project. Mathglot (talk) 20:32, 13 October 2019 (UTC) P.S. Those were intended as real quotes, not scare quotes, sorry. Mathglot (talk) 20:37, 13 October 2019 (UTC)
I appreciate Mathglot's explanation of what I did. I'd also like to point out that the shortdesc I removed (undid, actually) had been up for less than 1 hour. It was not some long standing thing. And the meaning of that shortdesc was significantly different, as I explained. I don't think I'm expected to cite a bunch of sources in a shortdesc or edit summary. Rather, the shortdesc should be based on the sourced content in the article, which the one I removed certainly was not. -Crossroads- (talk) 21:00, 13 October 2019 (UTC)
One thing I think I've learned from this, is that in cases where the Wikidata description at a given point in time happens to be better than the content given in the {{short desc}} template on a Wikipedia article, rather than simply remove the template from the article and let the text from Wikidata be imported by default, instead, we should copy and paste the value from Wikidata into the template. That way, if the Wikidata item is vandalized later, we've already preserved the good value in the template, and the vandalized value won't be displayed. Adding Crossroads. Mathglot (talk) 22:02, 13 October 2019 (UTC)
I was thinking the same thing. -Crossroads- (talk) 23:37, 13 October 2019 (UTC)
I know the whole short descriptions stuff has already been exhaustively discussed, but is there an equivalent to our ClueBot NG over at Wikidata? I feel like the Wikidata change that Mathglot showed would've been caught by it. Enterprisey (talk!) 20:11, 13 October 2019 (UTC)
Enterprisey: Wikidata uses ORES to flag edits. ORES did flag the change Mathglot found.(lookup) Whether they have an bot using that information, I do not know. In addition, their main extension, Wikibase, blocks edits on statements which are not used as the community intended. Wikidata has of course also common anti-vandalism extensions like AbuseFilter, etc.--Snaevar (talk) 00:56, 15 October 2019 (UTC)

Actually, one other thought, RexxS, inspired by your comment,

I've been wrestling with this problem since it was first proposed, and I've explained what will go wrong a hundred times... please read at least some of the discussions linked from <link>...

A situation like this is tailor-made for exposition in an essay. Have you considered writing one? Make a distillation of all your best arguments from your hundred explanations, and lay it all out in one place. Those past discussions about the topic that aren't already wikilinked in the essay body, you can throw into the See also section. Then, when the 101st person (me?) comments or asks about it, point them at the essay. Sounds like you'd have plenty of company to help write it. Willing to start one? Sure seems like there's a need, and that others would find it useful to enlist in their discussions, as well. Mathglot (talk) 21:54, 13 October 2019 (UTC)

How does Module:Labelled list hatnote convert number sign hash marks to section symbols?[edit]

{{see also}} is mostly the Lua code at Module:Labelled list hatnote. Where and how does it change wikilinks to specific sections like Article#Section into Article § Section? EllenCT (talk) 00:46, 13 October 2019 (UTC)

The magic happens in Module:Hatnote, specifically in the "Format link" section. See also {{Format link}} if you're just looking for a way to make that link formatting yourself. – Jonesey95 (talk) 00:59, 13 October 2019 (UTC)

Ewwww. More importantly, why does it do this and how do you make it not? ―cobaltcigs 16:42, 14 October 2019 (UTC)

You shouldn't. Why it does it is because # isn't understood as an indicator of a section IRL. §, the section sign, is. We even have a template for that. Nardog (talk) 16:52, 14 October 2019 (UTC)
The scope of such understanding is, roughly, lawbooks vs. the entire internet. But I'd be okay with this, given a software change that makes '§' (a) an illegal title character, and (b) interchangeable with '#'—in exactly the same way all space characters exist as aesthetically favorable alternatives to '_' in links. This way linking to [[List of Foo§Bar]] would produce <a href="/en/List_of_Foo#Bar" title="List of Foo">List of Foo§Bar</a> and pasting a title with '§' into the address bar would behave exactly like that title existed as a section redirect. Then we'd all be happy. But pretending on such a broad scale that this equivalence exists when it doesn't is a WP:PLA violation. ―cobaltcigs 15:02, 17 October 2019 (UTC)

Generating a gallery from a pool[edit]

I'd like to set up a gallery where the gallery itself shows fifteen images randomly drawn from a pool of perhaps fifty or sixty images, and each time the page is refreshed or purged, the gallery resets with a new set of fifteen images from that pool. Is that possible? bd2412 T 02:30, 13 October 2019 (UTC)

@BD2412: Yes, an expansion to Module:Carousel (which returns a single image from a pool) should be able to meet your needs if you're happy to purge the page to get the new gallery. Unfortunately, Scribunto-based solutions don't refresh on a reload because of caching. You may be able to do better using client-side JavaScript, but it's doubtful whether you'll get agreement to implement JavaScript that purges a page without having to click okay on a popup. This is to prevent vandals loading the servers by repeatedly requesting a page reload at high speeds. --RexxS (talk) 03:18, 13 October 2019 (UTC)
Interesting - thanks. bd2412 T 03:25, 13 October 2019 (UTC)

Image creates strange blank space[edit]

Could you have a look at Lou Andreas-Salomé#Death? The image on the right creates a strange blank space. Thank you very much, --Epìdosis 12:05, 13 October 2019 (UTC)

I have shifted the image to the spot before the maintenance tag, this looks better. SD0001 (talk) 12:47, 13 October 2019 (UTC)

It's 2019, why is unicode still so hard?[edit]

In Milutin Babović-Telegraph, the references are rendering as blobs of hex escape junk. If I copy-paste reference #3 into my sandbox, it renders properly in cyrillic characters. What's the issue here? -- RoySmith (talk) 15:34, 13 October 2019 (UTC)

Ugh, I think I copies the wrong example. -- RoySmith (talk) 15:47, 13 October 2019 (UTC)
@RoySmith: are you referring to the bare url references? They are displaying exactly they way they were input, as bare urls. If you want to show a title, use a citation template and the title parameter. — xaosflux Talk 16:58, 13 October 2019 (UTC)
@RoySmith: see and percent-encoding. TL;DR: URLs are written in US-ASCII by design. Incnis Mrsi (talk) 18:31, 13 October 2019 (UTC)

This is a comedy of errors. First, I was trying to use reFill to expand those bare references, and it wasn't doing anything with them. But, now I just tried that again, and it successfully converted the references. And, in the process of debugging why reFill wasn't doing anything, I managed to accidentally copy the wrong reference into my sandbox for testing, and failed to notice that. -- RoySmith (talk) 19:27, 13 October 2019 (UTC)

Who do we approach to delete search suggestions in Special:Log?[edit]

Hi all,

Recently, I wanted to see the Special Log of a fellow administrator (I'm deliberately not naming them). And when I clicked on their name in the "Performer" field, the search suggestions that sprung up were abusive. How does one get that removed? Thanks, Lourdes 10:59, 14 October 2019 (UTC)

Either the abusively named accounts need to be renamed, or there is some form of suppression that can be placed on them. I think the latter is preferred. –xenotalk 11:45, 14 October 2019 (UTC)
I guess such accounts are reported to the stewards (privately) for global lock and suppression. This will remove them from the logs. SD0001 (talk) 12:03, 14 October 2019 (UTC)
I once submitted an oversight request (Ticket#2019042710003636) about this. The response was The content in question is under discussion by the Oversight team, and we will get back to you with our decision after we agree upon the appropriate course of action under the oversight policy <>. I'm not sure we can do anything about that, but something should certainly be done about it -- RoySmith (talk) 12:21, 14 October 2019 (UTC)
Since all user accounts are now global, I don't think enwiki oversighters can do anything about this. But I'm guessing that stewards can rename the account, and then suppress the log action of the rename. So that the abusive name is completely gone from public records. SD0001 (talk) 13:15, 14 October 2019 (UTC)
I actually think they have a button that will do it all without the renaming. @Ajraddatz and MBisanz: jog my memory? –xenotalk 13:32, 14 October 2019 (UTC)
Yes, stewards can suppress the account globally. It will remove all instances of the username, except where it has been manually written by someone else or auto-populated by rollback or undo actions. It will hide the abusive names from search results as well. -- Ajraddatz (talk) 14:55, 14 October 2019 (UTC)
Likewise, local oversighters can take care of it here, but if we think it warrants suppression we'll just contact the stewards anyway to take care of things globally, so, you know, two birds one stone and all that. I believe renamers would specifically not rename such an account, as oversight/steward tools are built for the purpose and would be desired regardless, so creating a bunch of log entries across several wikis would be counterproductive. ~ Amory (utc) 01:31, 15 October 2019 (UTC)
This is not an isolated phenomenon. Typing in the name of any number of regular names who have been around a while, it often pulls up such abusively named accounts. It's been that way for years on the ones I know about, and nothing has been done. Who knows how many there are out there like that. Maybe oversighters should have a system to get rid of these, without having to be notified one by one. — Maile (talk) 01:43, 15 October 2019 (UTC)
Well, a lot has/is being done. There have been about 30 global suppressions of such names within the last week. But we do not have the capacity to go and find all of them ourselves, so we rely on reports for anything that is missed. -- Ajraddatz (talk) 22:53, 15 October 2019 (UTC)

Where is the article I created?[edit]

This is the problem edit. It is a copy and paste merge. I thought in order to make the move happen, the title of my article would change in order to preserve the history. I probably wrote the entire article so if that's the case it's not a real problem.— Vchimpanzee • talk • contributions • 21:29, 14 October 2019 (UTC)

Several moves have caused some confusing logs. The page you merged content from currently has its page history at McNeely–Strachan House. You were the only contributor. PrimeHunter (talk) 22:36, 14 October 2019 (UTC)
Thanks. I didn't think about that.— Vchimpanzee • talk • contributions • 14:49, 15 October 2019 (UTC)
I just thought of something. It's too late to do anything now, but what I had expected that a move would take place that would change the name of the article in my edit summary in the above edit. No, wait, that only happens in my contributions, where it says what article I edited.— Vchimpanzee • talk • contributions • 16:35, 15 October 2019 (UTC)
Here is my solution. That should clear things up for anyone who is confused.— Vchimpanzee • talk • contributions • 16:40, 15 October 2019 (UTC)

Article seems corrupted[edit]

I don't know whether someone might be able to take a look at Talk:Marathon_world_record_progression#Sections_are_displaying_in_the_wrong_order? The article seems somehow corrupted, but I don't know whether the issue will get any attention there. 2A00:23C5:4B91:AB00:6CCD:D471:9CF7:2B7F (talk) 22:14, 14 October 2019 (UTC)

If tables are displayed later then it's usually because the table end |} is missing. I have added it.[4] PrimeHunter (talk) 22:43, 14 October 2019 (UTC)
@PrimeHunter:. Thank you, that's fixed it! 2A00:23C5:4B91:AB00:FCD5:6B0E:A54A:8E8E (talk) 23:07, 15 October 2019 (UTC)

Tech News: 2019-42[edit]

23:32, 14 October 2019 (UTC)

How to find HTML markup[edit]

The dBase article has a hat stating there is HTML markup that should be removed. It's a long article, is there an easy way to find it all? Maury Markowitz (talk) 13:55, 15 October 2019 (UTC)

I think this edit took care of them. DMacks (talk) 14:07, 15 October 2019 (UTC)

Edit watchlist page groups[edit]

The Edit watchlist used to be organized in groups with their own titles in MonoBook. Now they are all in one group. I noticed 'Hide categorization of pages' in preferences, but unchecking that did nothing. I would like them to be separate again. Smarkflea (talk) 15:59, 15 October 2019 (UTC)

This is phab:T235137. --Izno (talk) 16:07, 15 October 2019 (UTC)

Tools for removing non-section redirects in templates?[edit]

Is there a tool that would help with removing redirects in templates? For example Template:Aboriginal peoples of the Northern Territory still has over a dozen.Naraht (talk) 07:08, 16 October 2019 (UTC)

@Naraht: I added the following to my Special:MyPage/common.css, which makes it easier to identify redirects so that I can manually resolve them:
.mw-redirect { background: url( center right no-repeat; padding-right: 13px; } 
It will make redirect links look like thisInsert redirect.png. --Ahecht (TALK
) 19:46, 16 October 2019 (UTC)
I use similar CSS, .navbox .mw-redirect, .vertical-navbox .mw-redirect { font-style: italic; color: red; }, which makes redirects stand out as italic and red. --Izno (talk) 23:45, 16 October 2019 (UTC)
For this I've found using a background-color works better. Seems like italic red would be barely distinguishable from an actual red link (referring, perhaps, to a film title) which may appear elsewhere in the same navbox. Another option would be keeping the link text blue but adding a differently colored underline like .mw-redirect { border-bottom: 1px solid red; }. ―cobaltcigs 08:25, 17 October 2019 (UTC)

I think by "removing redirects" the OP probably means:

While editing the template, click some button to replace each redirect link with a link to its target (unless said target contains #, which would suggest the redirect may someday become a separate article)

You'd need javascript with some API calls to determine these things. The suggested CSS would only alert you, prior to editing, that redirects are present (which the OP already realizes). ―cobaltcigs 06:12, 17 October 2019 (UTC)

cobaltcigs, Izno that is a good restatement. I'd be just fine with an external tool as well, but AutoWikiBrowser doesn't appear to be that tool.Naraht (talk) 08:12, 17 October 2019 (UTC)

New gadget proposal for undoing edit from mobile diffs[edit]

It has been proposed that a new gadget be installed that allows editors to revert edits from mobile diffs (Special:MobileDiff). See the discussion at Wikipedia_talk:Gadget#proposal_for_undo_gadget. Thanks, SD0001 (talk) 08:15, 16 October 2019 (UTC)

404 at wmflabs edits by user[edit]

I'm getting 404 when clicking the Find edits by user link on the History page of articles. I.e., Mathglot (talk) 10:57, 16 October 2019 (UTC)

@Σ: maintains that tool. Σ, is it coming back? If not we can just remove that from the history legend. — xaosflux Talk 11:36, 16 October 2019 (UTC)
You can use User:Ale jrb/Scripts/userhist.js for finding edits by user on a page. SD0001 (talk) 14:14, 16 October 2019 (UTC)
There is also XTools Top Edits. I have changed the link in Histlegend to point there, until Sigma's tool is restored. MusikAnimal talk 15:32, 16 October 2019 (UTC)
Odd, because I'd restarted it just a few days ago. But I restarted it again and it is now up and running again. Σσς(Sigma) 04:23, 18 October 2019 (UTC)
@Xaosflux, Mathglot, and MusikAnimal:Σσς(Sigma) 04:24, 18 October 2019 (UTC)
Thanks all! Mathglot (talk) 08:33, 18 October 2019 (UTC)


I have been using Wiki-Map to locate articles to add to categories but after I click "Show Map" and it starts showing the places I get "This page didn't load Google Maps correctly. See the JavaScript console for technical details.". This appeared to be something that started happening in 2016 when Google reduced its free maps or something but with Wiki-Map this didn't happen until a few weeks ago (although I've only been using it a few months). Crouch, Swale (talk) 16:30, 16 October 2019 (UTC)

Crouch, Swale, That site isn't hosted on Wikimedia servers, so you'll have to contact them directly using the link at the bottom of the page. There are almost certainly other tools that serve a similar function, such as toolforge:wikishootme. --AntiCompositeNumber (talk) 13:04, 17 October 2019 (UTC)
Thanks, I'll use that then especially given that is looks like it has more features. Crouch, Swale (talk) 13:09, 17 October 2019 (UTC)

WMF sites down[edit]

Did anybody get a 503 backend Fetch error upon trying to access any Wikimedia site, in the past few minutes? WBGconverse 17:32, 16 October 2019 (UTC)

  • No issues from Colombo or London. Cheers, Rehman 17:34, 16 October 2019 (UTC)
Winged Blades of Godric, it is likely. WMF Ops is aware and working on it. --AntiCompositeNumber (talk) 17:36, 16 October 2019 (UTC)

Editing News #2 – Mobile editing and talk pages – October 2019[edit]

Read this in another languageSubscription list for this multilingual newsletter

Inside this newsletter, the Editing team talks about their work on the mobile visual editor, on the new talk pages project, and at Wikimania 2019.


What talk page interactions do you remember? Is it a story about how someone helped you to learn something new? Is it a story about how someone helped you get involved in a group? Something else? Whatever your story is, we want to hear it!

Please tell us a story about how you used a talk page. Please share a link to a memorable discussion, or describe it on the talk page for this project. The team would value your examples. These examples will help everyone develop a shared understanding of what this project should support and encourage.

Talk Pages[edit]

The Talk Pages Consultation was a global consultation to define better tools for wiki communication. From February through June 2019, more than 500 volunteers on 20 wikis, across 15 languages and multiple projects, came together with members of the Foundation to create a product direction for a set of discussion tools. The Phase 2 Report of the Talk Page Consultation was published in August. It summarizes the product direction the team has started to work on, which you can read more about here: Talk Page Project project page.

The team needs and wants your help at this early stage. They are starting to develop the first idea. Please add your name to the "Getting involved" section of the project page, if you would like to hear about opportunities to participate.

Mobile visual editor[edit]

The Editing team is trying to make it simpler to edit on mobile devices. The team is changing the visual editor on mobile. If you have something to say about editing on a mobile device, please leave a message at Talk:VisualEditor on mobile.

Edit Cards[edit]

What happens when you click on a link. The new Edit Card is bigger and has more options for editing links.


The editing toolbar is changing in the mobile visual editor. The old system had two different toolbars. Now, all the buttons are together. Tell the team what you think about the new toolbar.
  • In September, the Editing team updated the mobile visual editor's editing toolbar. Anyone could see these changes in the mobile visual editor.
    • One toolbar: All of the editing tools are located in one toolbar. Previously, the toolbar changed when you clicked on different things.
    • New navigation: The buttons for moving forward and backward in the edit flow have changed.
    • Seamless switching: an improved workflow for switching between the visual and wikitext modes.
  • Feedback: You can try the refreshed toolbar by opening the mobile VisualEditor on a smartphone. Please post your feedback on the Toolbar feedback talk page.


The Editing Team attended Wikimania 2019 in Sweden. They led a session on the mobile visual editor and a session on the new talk pages project. They tested two new features in the mobile visual editor with contributors. You can read more about what the team did and learned in the team's report on Wikimania 2019.

Looking ahead[edit]

  • Talk Pages Project: The team is thinking about the first set of proposed changes. The team will be working with a few communities to pilot those changes. The best way to stay informed is by adding your username to the list on the project page: Getting involved.
  • Testing the mobile visual editor as the default: The Editing team plans to post results before the end of the calendar year. The best way to stay informed is by adding the project page to your watchlist: VisualEditor as mobile default project page.
  • Measuring the impact of Edit Cards: The Editing team hopes to share results in November. This study asks whether the project helped editors add links and citations. The best way to stay informed is by adding the project page to your watchlist: Edit Cards project page.

PPelberg (WMF) (talk) & Whatamidoing (WMF) (talk) 16:51, 17 October 2019 (UTC)

User script for watching pages temporarily[edit]

New user scripts are not usually announced here but I think this one is sort of epic. Seeing that watchlist expiry was #7 on last year's Community Tech wishlist, I have recently created a new user script that enables watching pages temporarily - see User:SD0001/T-Watch. Being a user script, of course, the implementation is quite different than how the WMF is going to implement it. But until such a feature becomes a part of core MediaWiki - which I guess is going to take quite a while, I think this script would be useful. Any feedback is welcome. Enjoy! SD0001 (talk) 18:16, 17 October 2019 (UTC)

Now updated to provide elegant menus for vector and monobook skins, to avoid the watch links from cluttering the "more" dropdown (in vector) or the p-cactions toolbar (in monobook). SD0001 (talk) 12:06, 18 October 2019 (UTC)
Interesting, I'll definitely give this a go and let you know of anything odd. Nosebagbear (talk) 13:31, 18 October 2019 (UTC)

Thumbnails in Category[edit]

Why does Category:Copy to Wikimedia Commons reviewed by a human show image file thumbnails if I edit and preview it, but not if I just access it normally? -- Begoon 02:58, 18 October 2019 (UTC)

It contains {{file category}}, which contains (as a default setting) the __NOGALLERY__ directive, which is ignored on category preview, which has been known about since the feature was first added in 2006. ―cobaltcigs 03:11, 18 October 2019 (UTC)
cobaltcigs, thank you. I added a |showthumbs= to {{file category}} to allow overriding that default, and it works now. Cheers. -- Begoon 03:28, 18 October 2019 (UTC)

It looks like that template is supposed to infer whether to show/hide galleries based on the {{}} parameter, so you'll want to be mindful of image copyright status when overriding. But in this particular case (where humans have deemed the files suitable to copy to commons), free=yes seems like a reasonable presumption. Simply using that would have the same effect. ―cobaltcigs 04:27, 18 October 2019 (UTC)

A fair point, but I think it should be ok here for the reasons you say. You can trust me to be over-elaborate when solving a problem, but I think I'll leave the parameter there anyway as doing no real harm. Thanks. -- Begoon 05:08, 18 October 2019 (UTC)
Although, on second thoughts, I've rolled back the changes, because once I got to browsing that category there are quite a few "questionable" images in it, where I'm not convinced the "free" licensing is completely solid. The "human" reviews seem quite a bit less thorough than I would have hoped. I can always take advantage of the "preview" quirk and use it that way if I want to. Face-smile.svg -- Begoon 05:40, 18 October 2019 (UTC)

pct |sigfig=[edit]

I found no way I could input the output of Template:Pct into Template:Sigfig, so asked in Template talk:Percentage to add |sigfig= as an option, as it currently already exists in Template:Convert. What's the best way to go about this? Guarapiranga (talk) 21:59, 18 October 2019 (UTC)

"Editor Interaction Analyzer" is down[edit]

Editor Interaction Analyzer🔖--Moxy 🍁 04:47, 19 October 2019 (UTC)