Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia
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.
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


Weird ref, citation, white space interaction bug[edit]

Without the line feed the citation is messed up.



AManWithNoPlan (talk) 23:22, 30 September 2019 (UTC)

@AManWithNoPlan: Shouldn't it be:
I was under the impression we shouldn't be using wikimarkup inside CS1 parameters. --RexxS (talk) 23:56, 30 September 2019 (UTC)
Something is going wrong. People expect to be able to have quote marks and apostrophes . AManWithNoPlan (talk) 00:12, 1 October 2019 (UTC)
You have unbalanced markup. The parser doesn't know that you want an actual apostrophe. Use {{'}} for the apostrophe whenever you are writing the possessive of an italicized name, like this:[4]Jonesey95 (talk) 01:53, 1 October 2019 (UTC)
Jonesey is correct here. The other way to do it of course is to take the lone apostrophe and use the reference value for it instead. --Izno (talk) 02:05, 1 October 2019 (UTC)
Alas, Editor Jonesey95 is not correct here. The template {{'}} renders as this:
<span class="nowrap" style="padding-left:0.1em;">&#39;</span>
All of that styling is why that template is marked as not safe for COinS.
Trappist the monk (talk) 12:11, 1 October 2019 (UTC)
Rexx, generally. Some wikimarkup is supported in certain parameters. --Izno (talk) 02:06, 1 October 2019 (UTC)
Still odd that a line feed mattered. AManWithNoPlan (talk) 02:20, 1 October 2019 (UTC)
Just to prove that this isn't some artifact produced by Module:Citation/CS1, this <ref>''30 Rock'''s.</ref>[5] gives the same result. Here is the html from this page:
<li id="cite_note-5"><span class="mw-cite-backlink">'<i><a href="#cite_ref-5">^</a><b></b></i></span><i><b> <span class="reference-text"></span></b></i><b>30 Rock</b>s.</li>
And using &#39; <ref>''30 Rock''&#39;s.</ref>[6] and its html:
<li id="cite_note-6"><span class="mw-cite-backlink"><b><a href="#cite_ref-6">^</a></b></span> <span class="reference-text"><i>30 Rock</i>&#39;s.</span></li>
Trappist the monk (talk) 12:11, 1 October 2019 (UTC)
The reason the newline matters is because the Cite extension displays the reference wikitext by substituting it into MediaWiki:Cite references link one. The resulting wikitext resembles '''foo''' ''bar'''s that happens to be interpreted in an unexpected manner. Including the newline puts a newline in that wikitext, and since apostrophe markup only works within a single line there's no ambiguity. Fixes might include replacing the ''' in MediaWiki:Cite references link one with <b>...</b> or <strong>...</strong> or formatting the citation with <i>...</i> to avoid the misinterpretation of apostrophe-wikitext. In the former case MediaWiki:Cite references link many format might also want a similar edit. Anomie 12:32, 1 October 2019 (UTC)
So, ref-tags don’t work perfectly, but how to fix them is the question with some suggesting adapting cite templates to work around the bug In most cases. AManWithNoPlan (talk) 02:17, 7 October 2019 (UTC)


  1. '^ "30 Rocks".
  2. ^ "30 Rock's".
  3. ^ "30 Rock's".
  4. ^ "30 Rock's".
  5. '^ 30 Rocks.
  6. ^ 30 Rock's.

Possible interaction of spam blacklist and citation archival-url[edit]

Note: see prior discussion for additional context, about an url recently added to the WP:BLACKLIST.

Note: a parallel discussion is taking place at Help talk:Citation Style 1 about aspects relating more to the citation template aspects of this. Mathglot (talk) 02:48, 5 October 2019 (UTC)

JzG, I'm going through them, fixing them up. The fixes to the ones in citations are going smoothly. However, I triggered the filter, attempting to change the External link in Juliet Escoria from its current value, to the following value:

  • [ Interview with Catherine Faw Morris at ''Adult Magazine'']

Maybe the filter could be adjusted to excuse examples where it's embedded in a web archive url? Or should I code this valid archive link differently, so it can be saved? Mathglot (talk) 03:16, 3 October 2019 (UTC)

Hm, this time (at Azar Swan) I couldn't save the page after marking url-status usurped and adding this archive url:
  • |archive-url=
I ended up putting the archive-url in hidden text in order to be able to save it (rev 919328779), and it went through okay. The problem now, is that there is a live, blacklisted url in Citation 8 (this link is safe to click) in this article. This seems to be two problems, possibly interacting with each other:
  1. not sure how this got past the filter
  2. shouldn't |url-status=usurped have blocked display of this url, irrespective whether it is a spammy url or not?
Adding user Trappist the monk (talk · contribs) for comments on question 2 above. Mathglot (talk) 03:39, 3 October 2019 (UTC)
Aha, they are interacting. The doc for url-status says: "url-status: this optional parameter is ignored if archive-url is not set." SInce I had to put it in hidden text to successfully save because of the edit filter, that disables the effect of url-status. Now what? How do I fix this? Mathglot (talk) 03:47, 3 October 2019 (UTC)
I can envisage several possible solutions:
  • Move the url value out of the archive-url field and directly into the url field, but that might require some explanation in hidden text or something to prevent well-meaning editors from attempting to move it back to the archive-url field.
  • Leave the value in the archive-url field, and use the required url field to point to something else; perhaps the entry in the WP:BLACKLIST that covers it, or the discussion on the talk page about it. This seems more like a work-around, though.
  • Allow usurped for citation parameter url-status to block display of the spammy url in the url field, even with no archive-url
  • Add a new value for url-status that would block display, even with no archive-url.
Thoughts? Whatever the solution turns out to be, we should document it somewhere for users bumping up against this. Mathglot (talk) 04:14, 3 October 2019 (UTC)

Discussion moved here from prior location because it possibly affects more than one area.   Mathglot (talk) 04:24, 3 October 2019 (UTC)

I've fixed it in this case by url-encoding the archive url: Diff/919328779/919369896. That's probably the correct option in most cases, but I do think that if url-status is usurped or unfit, the original url should be hidden, whether archive-url is set or not. rchard2scout (talk) 10:38, 3 October 2019 (UTC)
|url-status= and its predecessor |dead-url= both require |archive-url=. It is a misuse of a template to set one and not the other. --Izno (talk) 15:09, 3 October 2019 (UTC)
Not quite true, I think. While Module:Citation/CS1 ignores |url-status= when |archive-url= is omitted or empty, that is not the same as a requirement; were it a requirement, then we'd have to invent a new error message for that case. As it is, a stand-alone |url-status= is just clutter which is a different kind of problem ...
I have been experimenting in Module:Citation/CS1/sandbox (not saved yet) looking at how to handle the various cases of a blacklisted url by percent-encoding the url in the archive-url as Editor Rchard2scout did with the example discussed here. I will discuss this at Help talk:Citation Style 1 when I have something to say.
Trappist the monk (talk) 15:47, 3 October 2019 (UTC)
@Rchard2scout:, In a technical WP:TPO violation, I've reversed the order of the revisions in your diff above. Previously, it showed your revision, still the latest/current, on the left side of the diff, and the earlier revision on the right. I assume this was not your intention. If it was, feel free to revert, but in that case, please add an explanatory note to make this clear. Thanks, Mathglot (talk) 22:29, 3 October 2019 (UTC)
Trappist the monk: Archive URLs are not exempt for spam blacklists. In fact it's a requirement archive URLs have the full target URL so that the spam blacklist can pick them up. Circumventing this process is a no-no. We've had RfCs about this before. There is also a MediaWiki policy about not using url-shortening services which is essentially what this becomes when hiding the real URL from the filters, because url-shortening allows spammers and malicious actors to insert bad things into Wikipedia. I've seen this many times using WaybackMedic, people use archive URLs to add stuff they shouldn't be. -- GreenC 19:09, 3 October 2019 (UTC)
I don't doubt you but, point me to an RFC that discusses this?
If archive-urls are required to hold the complete original url, shouldn't cs1|2 be checking that and be emitting an error message? Is this requirement publicly documented anywhere? Certainly, this requirement, if it is a requirement should be documented wherever |archive-url= is documented, shouldn't it?
Trappist the monk (talk) 19:18, 3 October 2019 (UTC) -- IAbot and WaybackMedic have been expanding to long form for years (where possible). IABot in particular is relentless and will get to all archive URLs eventually. CS1|2 could add a warning. Wayaback has no short-form option and WebCite is no longer taking new archives and all their URLs are long-form already (presumably). The providers with known short-form are webcite,,, freezepage, National Archives UK. Data at WP:WEBARCHIVES. -- GreenC 19:40, 3 October 2019 (UTC)
I don't read that RFC closure as a 'requirement' but the shortening point is taken, though I see this more as a possible masking than a shortening. I have rolled back the edit. Because there are bots that routinely lengthen short archive urls, and because editors at the RFC did not like the idea of an automated tool admonishing editors to use the long-form archive urls, I do not foresee adding that kind of error checking.
Trappist the monk (talk) 22:40, 3 October 2019 (UTC)

Can we back up and take a 40,000 foot view for a second, to get some perspective about the locus of the problem? I think this may help inform the discussion. I see what's going on here, as a conflict between two desirable features:

  • Support Verifiability, by exposing to readers the url of a source that supports an assertion in an article.
  • Prevent the user from being exposed to ill effects, by clicking on an url that may contain malware.

I think the statement of the issue we are facing here is, how do we do both of these at the same time, when an url used to support the article (and maybe still does, in an archived version) but has been usurped by malware? A couple of corollary questions to consider:

  1. Is it okay to reduce verifiaibility a little bit in this case, by suppressing display of the url (and archive url, if any) completely? I assume that the answer here is no, but perhaps not everyone agrees.
  2. Is it okay to display the spammy url, if it is not hyperlinked? I tend to think not, as it still seems to violate the spirit of the spam filter, even if it is unclickable.

Are there other functional aspects we haven't considered? Airing out what ought to happen, and getting agreement here first, will help keep the discussion about how to find a solution more on track. When discussing functionality, are there other stakeholders who ought to be looped in, here? Adding xaosflux. Mathglot (talk) 23:10, 3 October 2019 (UTC)

If all sites on the blacklist were indeed malware, there would be no issue; but most are merely spammy sites, while some have been blacklisted for other reasons. Link removal involves not just the loss of verifiability, but potentially the permanent loss of the information cited, contrary to our mission. What ought to happen is that each instance is checked, and either replaced or whitelisted. Doing so requires knowledge of the subject and the original link. Hawkeye7 (discuss) 23:29, 3 October 2019 (UTC)
@Hawkeye7:, That would seem to imply that we need to retain the information somewhere, of what kind of nasty the items on the blacklist actually are, so that they could possibly be handled differently. Is that what you meant? (At least, in an ideal world; whether it's practical/feasible/priority is a separate issue.) Mathglot (talk) 23:36, 3 October 2019 (UTC)
Yes, that is what I mean. It should be recorded somewhere. Hawkeye7 (discuss) 03:26, 4 October 2019 (UTC)

A solution is remove the offending URL but retain a {{citation}}. Blacklists don't prevent citing only linking. However if something is blacklisted it would be advisable to find an alternative source. -- GreenC 00:33, 4 October 2019 (UTC)

If a citation provides other means to verify the material, the simplest approach is not to include the url. The problem appears when online verification is the only available option. Again, the simpler approach would be for the editor to find a non-blacklisted mirror. If there no such mirrors, and the editor believes that the material can not be verified otherwise, then the pre-infected archive copy could be used, after some procedure as below:

1. Filtering should alert the editor that the url is blacklisted
2. The citation editor could submit the "clean" archived url for whitelisting, to whoever maintains such lists
3. The option |url-status=whitelisted should be inserted in the template to inform other editors that the particular archived url has been vetted, even if the current version is unsuitable.

It is a cumbersome approach, but I believe it is viable. (talk) 13:19, 4 October 2019 (UTC)

Hmm.. but we would still be providing a link to a blacklisted website (even if via an archive version). Sites are blacklisted for many reasons, vetting a URL can be a matter of opinion if it is safe/appropriate/clean etc.. requiring community consensus which gets messy to maintain. If the only concern is V, perhaps there can be an admin-maintained list that is not visible to non-admins and if a user wants to verify a URL they can contact an admin who can discretely provide the URL for V purposes only. There would be note in the citation where to request the URL. It might require the requesting user have a working email contact so not posted in the clear. -- GreenC 14:48, 4 October 2019 (UTC)
I don't think that such burden of verification should be placed on readers. A better option may be for the citing editor to re-archive the material @ Wikisource? An explanation of the material's origin, without any offensive links, could be included at Wikisource, not at the citation which would now be considered sanitized. (talk) 17:06, 4 October 2019 (UTC)
The burden is always on the reader to verify. This burden is actually less then going to the library and checking out a book. Wikisource is for previously published public domain documents, like books and speeches. Also copyright restrictions. -- GreenC 17:16, 4 October 2019 (UTC)

Just a heads-up that there is a parallel discussion taking place at Help talk:Citation Style 1 about aspects relating primarily to the citation template aspects of this, which may overlap in part some of the discussion above. Mathglot (talk) 02:52, 5 October 2019 (UTC)

There seems to be an issue that the values usurped and unfit for param |url-status are not well-defined; at least, not everyone appears to agree what they mean. As part of settling how to handle the part of the problem related to the spam blacklist as raised here, it seems to me that the definitions of usurped, unfit, and possibly other values need to be agreed upon as a prerequisite. If we're not all talking about the same thing, then discussions of edge cases like this one concerning the blacklist will get hopelessly tangled.
Probably the discussion of those definitions should be handled at the Help CS1 discussion; wider input and more eyeballs would be helpful there for this case, and even for the broader question of what those param values mean, exclusive of any blacklist complications. In particular: if you see a citation, including an url-status that says it is usurped, what do you think that means? What should the citation do with that? Please jump in at that discussion, if you feel you can help. Thanks, Mathglot (talk) 23:55, 9 October 2019 (UTC)

User contributions changes[edit]

I see some recent changes to Special:Contributions which make it much less useful for me. The search form is now hidden under a "Search for contributions" toggle, which means an extra click for me to change search settings, but I can live with that. However, when I use a CIDR range (needs to be enabled in Preferences/Gadgets), which I do many times a day to find edits by related IPs after I encounter anon vandalism (e.g. I search for, the list of IP addresses with edits loads above the list of recent edits. The list of addresses is often very large, and takes many seconds to load, and during this time if I scroll down to the list of recent edits (limited only to the most 50 recent edits by default), the loading list above keeps jumping the screen so I can't do anything useful. Until a couple of days ago, the list of recent edits was above the list of IP addresses, so I could ignore the loading of the latter. Is there a way to toggle off the list of IP addresses? There is a "toggle all" option, but that's not what I want; it shows edits sorted by IP address, but I want edits for the range of IP addresses sorted by date, as already appears at the bottom of the window. Alternatively, can I force the list of IP addresses to be a fixed size, rather than expanding as new addresses are found.-gadfium 20:53, 3 October 2019 (UTC)

WP:ITSTHURSDAY and the latest round of OOUI "improvements"..... but the gadget stuff comes from MediaWiki:Gadget-contribsrange.js which hasn't really been maintained in a while. This should be able to get pushed down if someone wants to dig in to it. — xaosflux Talk 21:32, 3 October 2019 (UTC)
Isn't the search by IP range gadget entirely obsolete now? * Pppery * it has begun... 21:45, 3 October 2019 (UTC)
@Pppery: the No per-IP sorting or date headings, or any bells and whistles. note on the top of that task description says it isn't really a full-replacement. — xaosflux Talk 22:23, 3 October 2019 (UTC)
But it does appear to offer what Gadfium was asking for, by simply not displaying any list of IP addresses. * Pppery * it has begun... 22:25, 3 October 2019 (UTC)
Thanks, turning off the gadget gives me exactly what I want. Thanks Pppery.-gadfium 22:33, 3 October 2019 (UTC)
By the way, you can force the search interface to be shown by inserting this into Special:MyPage/common.css:
/* Quick hack to force the Search tab on [[Special:Contribs]] open. Credit: Volker E. (WMF) & Stwalkerster - [[m:Special:Permalink/19434096#Reverting the new "collapsed search interface" on Special:Contribs|Tech]] */ 
.mw-special-Contributions { display: block !important; }
.mw-special-Contributions .oo-ui-fieldsetLayout-header { display: none !important; }
— regards, Revi 00:35, 4 October 2019 (UTC)
Thanks, that works for me, avoiding that extra click.
I'm most impressed with the speed and quality of the technical help I've been given here!-gadfium 03:05, 4 October 2019 (UTC)
So we're currently looking into additional changes from the feedback given here. One is implementing a “pin” to let the form stay expanded phab:T234569 (edited link; making above CSS hack obsolete), the second is a technical error, that affected the user autocomplete phab:T234510. Volker E. (WMF) (talk) 04:24, 4 October 2019 (UTC)
@Volker E. (WMF): That first ticket is unrelated. Can you double check your links? --Izno (talk) 11:30, 4 October 2019 (UTC)
I think he meant phab:T234569. – Ammarpad (talk) 11:40, 4 October 2019 (UTC)
Edited and fixed above, thanks @Izno: and @Ammarpad: Volker E. (WMF) (talk) 17:40, 4 October 2019 (UTC)
  • I have another bug related to these changes: at least on my system (Chrome 77.0.3865.90, Windows 10 v.who-knows) the shortened User: box is not long enough to display a full IPv6 address, which makes it very difficult to use. Can it be restored to its original length? Ivanvector (Talk/Edits) 14:07, 4 October 2019 (UTC)
    @Ivanvector: I've tried on monobook, vector, and timeless - for each a ipv6 address (38 characters) is only taking up about half the box for me - what skin are you using, and how may characters are you fitting in the input box? — xaosflux Talk 17:30, 4 October 2019 (UTC)
    I'm using vector, and was viewing the contributions page by clicking on an IP address so the box was pre-filled. When I click on this, I see "2601:681:8400:26A0:CD73:" and then the rest is cut off. Ivanvector (Talk/Edits) 18:10, 4 October 2019 (UTC)
    Oh also my Windows display settings were set to zoom 125%. If I set that back to 100%, I see ... the same thing, but smaller. Ivanvector (Talk/Edits) 18:13, 4 October 2019 (UTC)
    @Ivanvector: can you try in safemode to see if you still have this problem? I'm not having the problem as seen here: File:20191004-ooui-contrib-page.JPG. — xaosflux Talk 18:52, 4 October 2019 (UTC)
    @Xaosflux: yep, that worked, I see the same as you with safemode on. If I remove the &safemode=1 I get the short box again. Ivanvector (Talk/Edits) 18:59, 4 October 2019 (UTC)
    @Ivanvector: hmm - possibly one of your scripts or gadgets is in conflict, try turning off your manual implementation of MediaWiki:Gadget-markblocked.js in User:Ivanvector/vector.js? — xaosflux Talk 19:03, 4 October 2019 (UTC)
    It appears this is actually due to Enterprisey's delsort.js (imported under his previous username) ~ Amory (utc) 23:24, 4 October 2019 (UTC)
    Hmm. I don't have delsort installed but I still see that behavior. I'll look into it. Enterprisey (talk!) 05:42, 5 October 2019 (UTC)
    Enterprisey, it seems like the causative factor is mw.loader.load( 'mediawiki.ui.input'), specifically the input. ~ Amory (utc) 10:44, 5 October 2019 (UTC)
    @Enterprisey:, the rule .mw-ui-input-inline { display: inline-block; } added by User:Enterprisey/mw-ui-input.css (being used in cv-revdel and unblock-review scripts) is the culprit. SD0001 (talk) 11:12, 5 October 2019 (UTC)
    And yeah, mw.loader.load('mediawiki.ui.input') is also causing the same issue. Bizarre, since this one is WMF-sponsored. Ping Volker E. (WMF). SD0001 (talk) 11:25, 5 October 2019 (UTC)
    Ah. Fun. Well, Ivanvector, .mw-ui-input-inline { display: block; } in your common.css should work. Enterprisey (talk!) 01:44, 6 October 2019 (UTC)
    @SD0001: With the fix of phab:T234510 not only the autocomplete works again, the issues with user scripts should actually also disappear, as we've removed a leftover .mw-ui-input-inline class from this specific input. Rolling out this week, should be live on enwiki by Thursday. Volker E. (WMF) (talk) 01:40, 8 October 2019 (UTC)
    I filed a task for this one at phab:T234733. --Izno (talk) 22:10, 5 October 2019 (UTC)
  • I dislike the new change but anyway the pin thing would help a lot - No one wants to have to click to expand the box every time they want to search a users contribs, Would prefer if it was expanded by default tbh. –Davey2010Talk 17:23, 4 October 2019 (UTC)
    Depends how you edit. Nearly every time I load Special:Contributions, it's from a user-specific link, so I rarely use the box and thus love the space gains. ~ Amory (utc) 23:27, 4 October 2019 (UTC)

Notices vs Alerts[edit]

Mondays amirite

Why do we have distinct Alerts and Notices menus on the top line? They're both just, "things that need your attention", with no logical distinction that I can see of which things go in which menu. I'd rather save the screen real-estate and have them in a single menu. Perhaps there's a way to configure that which I haven't found yet?

Other minor point: is it just me, or does the Notices icon look more like a USB-B connector than a mailbox? -- RoySmith (talk) 15:33, 4 October 2019 (UTC)

What goes where is explained at Help:Notifications#Triggering_events. Basically, talk page messages, emails, mentions, and rights changes are alerts while thanks, reviews, and cross-wiki are notices. ~ Amory (utc) 16:34, 4 October 2019 (UTC)
I personally see a distinction. Alerts are for communication, or things that directly affect your work (such as when your edit was reverted, user rights changes, etc.). Notices are editors thanking you, adding links to pages you created -- things that are interesting but don't necessarily need any follow-up. I'm not aware of a way to configure what types of notifications go where, but you can disable some of them at Special:Preferences#mw-prefsection-echo. MusikAnimal talk 17:11, 4 October 2019 (UTC)
I've had a user script on the back burner for ages that combines the two. It's a bit tricky. (To everyone) feel free to poke me in a month or so if you really want this, since I'm a bit busy at the moment. Enterprisey (talk!) 06:23, 7 October 2019 (UTC)
does the Notices icon look more like a USB-B connector than a mailbox? lol, was that ever intended to look like a mailbox? SD0001 (talk) 18:19, 7 October 2019 (UTC)
It's an inbox, like people (used to?) have on their desks. ~ Amory (utc) 21:39, 7 October 2019 (UTC)
Um, yeah, I wrote mailbox but meant inbox. In any case, I still think it looks like a USB-B connector. It's amazing how we're using representations of physical objects that haven't existing in decades to represent things in user interfaces. An icon of a floppy disk for save? When's the last time anybody saw a real floppy disk? -- RoySmith (talk) 22:56, 8 October 2019 (UTC)
Today, in my desk drawer. Anyway, it's not a USB connector, it's a TV set. --Redrose64 🌹 (talk) 23:12, 8 October 2019 (UTC)
RoySmith, Off-topic for sure, but hilariously this weekend a family member needed to get photos off of a CD. It took 3 calls to find someone with an optical drive. Growing up we used audio tape cassettes in the C64 for data storage. I feel old now. SQLQuery me! 23:17, 8 October 2019 (UTC)
Yup. I had a TRS-80, with audio tape storage. And, I do still have a CD drive. I use it every once in a while to rip tracks off some old CDs to load up into iTunes. The kids at the gym are listening to who-knows-what, but I'm rocking to The Dead and CCR. -- RoySmith (talk) 23:47, 8 October 2019 (UTC)
It's also worth noting that the mobile site (and Minerva skin in general) has them merged into one bell icon. Pelagic (talk) 02:08, 11 October 2019 (UTC)

Tacky color scheme for old revisions[edit]

Take a look at the top of any old revision - think this was a WP:THURSDAY interface improvement - anyone else think the pink in yellow is tacky looking though? — xaosflux Talk 23:46, 4 October 2019 (UTC)

phab:T232415. The yellow is due to (now) using .warningbox while the red is because we use {{fmbox}} at MediaWiki:Revision-info. ~ Amory (utc) 00:09, 5 October 2019 (UTC)
We should remove the fmbox now. It would look better. – Ammarpad (talk) 00:15, 5 October 2019 (UTC)
Done by JJMC89. Still doesn't look great. I feel that the background colour ought to be red to draw attention to the fact that this isn't the current version of the page. SD0001 (talk) 11:29, 5 October 2019 (UTC)
MediaWiki:Revision-info-current also need attention.--Lam-ang (talk) 15:09, 5 October 2019 (UTC)
Did you mean Mediawiki:editingold? — xaosflux Talk 15:32, 5 October 2019 (UTC)
No. I took care of the one Lam-ang mentioned. Editingold doesn't currently cause me problems, but I'm using WTE2017. That said, it may in the future be one ofthe targets. --Izno (talk) 15:40, 5 October 2019 (UTC)
@Izno: this also gives pink-in-orange, however in visual editor the pink seems to be the only coloring (else it is just plain text on plain background) so it may be worth keeping - or perhaps changing to the same coloring as the orange.. — xaosflux Talk 15:44, 5 October 2019 (UTC)
Probably just means that VE hasn't been updated. Let's go ahead and remove editingold also. --Izno (talk) 15:49, 5 October 2019 (UTC)
I don't use VE but the pink isn't dark enough to get a person's attention.— Vchimpanzee • talk • contributions • 15:46, 7 October 2019 (UTC)

Page categorisation[edit]

Is there a problem with page categorisations as I have had no entries on my watchlist for the last couple of days yet there are new/removed entries in the category Category:CS1 errors: dates that should have appeared? Keith D (talk) 10:17, 5 October 2019 (UTC)

It works for me. Is "Hide categorization of pages" disabled at Special:Preferences#mw-prefsection-watchlist? Is Category:CS1 errors: dates on your watchlist? You have to watch the category page and not just the articles. PrimeHunter (talk) 12:17, 5 October 2019 (UTC)
No it is not disabled and the category is on the watchlist. It is also not hidden on the selection screen for the watchlist. It was OK until about Thursday when it stopped giving the category changes. Keith D (talk) 18:19, 5 October 2019 (UTC)
I'm not sure what you mean by "not disabled" but the option "Hide categorization of pages" should be disabled, i.e. have no check mark. It's enabled by default. PrimeHunter (talk) 19:40, 5 October 2019 (UTC)
There is no check mark in the box. Keith D (talk) 20:25, 5 October 2019 (UTC)
Do you see categorizations at [1]? I see many when watching Category:CS1 errors: dates. Try to remove and readd the category to the watchlist. Do other categories like Category:Candidates for speedy deletion‎ fail to produce results? PrimeHunter (talk) 09:05, 6 October 2019 (UTC)
Yes I can see the categorisations using the link that you specified. It is all categorisations that I am missing from my normal watchlist entries such as Category:Start-Class Yorkshire articles‎. Keith D (talk) 18:31, 6 October 2019 (UTC)
Many thanks for the help I have just spotted what the problem is with the link you gave. I appear to have only got the (Main) namespace selected, for some reason, rather than All which it usually is. Back to normal now. Keith D (talk) 18:58, 6 October 2019 (UTC)

Transclusion count[edit]

I'm sure it's been asked before, but I can't find it: is there an easier way to count the transclusions of a template than using the "what links here" page and counting how many pages? Circéus (talk) 02:05, 6 October 2019 (UTC)

There is a "Transclusion count" link in the "External tools" section of Special:WhatLinksHere when given a template as an argument. * Pppery * it has begun... 02:19, 6 October 2019 (UTC)
You can also add this script mw.loader.load('//'); which lets you count without leaving "what links here" page and is more flexible with namespaces, etc. SD0001 (talk) 05:14, 6 October 2019 (UTC)
You can also use Help:Searching#hastemplate: and see the reported number of search results. It can be combined with other search strings and search options, e.g. the namespace (only mainspace by default). PrimeHunter (talk) 08:47, 6 October 2019 (UTC)
Such searches are particularly useful because you can search for uses of the template with a particular parameter (e.g. here.   Jts1882 | talk  09:28, 6 October 2019 (UTC)
(You don't need to place the spaces internal to the metacharacters you have; this is also correct. --Izno (talk) 13:57, 6 October 2019 (UTC))
For templates with over 2,000 transclusions, there are weekly lists generated at Special:PrefixIndex/Module:Transclusion_count/data/. --Ahecht (TALK
) 18:04, 6 October 2019 (UTC)
Related thread at Template talk:High-use#Switch to automated transclusion count. --Redrose64 🌹 (talk) 22:49, 6 October 2019 (UTC)


Please see the idea discussed at Template talk:CodeBox#External links. I *think* it's about code, and then giving an external link to show what it does, but I'm not entirely sure. This might be good, or there might be an even better way to accomplish the desired goal. WhatamIdoing (talk) 00:01, 7 October 2019 (UTC)

I think the issue here is more about policy. Runnable code snippets are popular on many Q&A, how-to and programming sites; but Wikipedia is not a how-to website. Also when you combine that with the external link issues, for instance questions about the site itself (, and the fact that this will have to be embedded in the middle of articles; it will become clear this is something unlikely to be allowed on Wikipedia. But creating the template is one thing; starting to use on articles (with or without consensus) is another thing. Currently its only use on mainspace is on Lua (programming language) and it was added by the author. – Ammarpad (talk) 06:06, 7 October 2019 (UTC)
I've reverted my change, due to general consensus appearing to be against it, and potentially it being against some rule I haven't heard of/noticed yet (Would appreciate pointers to what I violated, I realise now that I violated WP:NOTHOWTO and WP:ELNO. MoonyTheDwarf (Braden N.) (talk) 12:47, 7 October 2019 (UTC)

VE cut & paste[edit]

doesn't see to be working. Is this affecting anyone else? ——SerialNumber54129 11:57, 7 October 2019 (UTC)

It's a part of many issues: phab:T234489. – Ammarpad (talk) 12:15, 7 October 2019 (UTC)
Ah, thanks very much Ammarpad, well that's too rich for me. Any idea, though, how long that kind of thing takes to sort out? (It's just that I've read the phab ticket but I'd have more luck with Cantonese!) Thanks again, ——SerialNumber54129 12:22, 7 October 2019 (UTC)
@Serial Number 54129: The short version is it looks like a fix was uploaded yesterday by @DChan (WMF): that's currently awaiting review. Hopefully they can shine some light on how long these things usually take to go live. Sam Walton (talk) 12:30, 7 October 2019 (UTC)
The task was triaged with the highest priority tag, so one can assume it will not take long to get fixed, all other things being equal. – Ammarpad (talk) 12:38, 7 October 2019 (UTC)
Thanks very much Sam Walton and Ammarpad, for the update, and a big Thank You to all the technical folk on this board who enable content creation by doing what they do and also take the time to explain things to plebs like me! Cheers! :) ——SerialNumber54129 12:44, 7 October 2019 (UTC)

Is this the same issue that messes up the ref numbering in VE? When I test-edit articles in VE, almost all of them have the refs in the ref section with a higher number than in the article, making it hard to see which ref belongs with which number of course... Here the refs in the ref section are numbered 17 to 27, here 4 to 10, here 4 to 15, here 5 to 89; here the only reference is numbered "6"! Fram (talk) 12:45, 7 October 2019 (UTC)

I don't believe so, that looks to be T95176. Sam Walton (talk) 12:50, 7 October 2019 (UTC)
Thanks. Ouch, that's a task from 2015... Fram (talk) 14:04, 7 October 2019 (UTC)

{coord} location doesn't match Google Map location[edit]

This may be a known problem or a non-problem but, having noticed it, I thought I would mention it here.

Compare this Google Maps location with the 5°08′33″N 125°58′35″E / 5.1424303°N 125.9764215°E / 5.1424303; 125.9764215 location from {{coord}} and GeoHack->Google Maps. Maybe it's a rounding error or a cockpit problem on my part. Wtmitchell (talk) (earlier Boracay Bill) 14:23, 7 October 2019 (UTC)

@Wtmitchell: in your first example you seem to be using a "named location" on ("Miangas") not only the geo-coordinates like this - does that give you the result you are looking for? — xaosflux Talk 14:58, 7 October 2019 (UTC)
Specifying the named location appears to drop a pin on the named location while centering the map on the coordinates (at least approximately). For a more extreme example, try 125.1424303,125.9764215, which uses the named location of "Miangas" but coordinates much farther away. The coordinates of Miangas appear to be closer to 5°33′19″N 126°35′07″E / 5.5554°N 126.5854°E / 5.5554; 126.5854. – Jonesey95 (talk) 16:05, 7 October 2019 (UTC)
@Xaosflux: it's not odd, it's expected: consider that a URL goes into the value of a href="..." attribute of an <a> tag, any unencoded quotes will terminate that value. Try percent-encoding it, like this, where %C2%B0→°, %27→' and %22→". --Redrose64 🌹 (talk) 20:43, 7 October 2019 (UTC)
@Redrose64: yea not really 'odd' but it is phab:T17661. — xaosflux Talk 20:55, 7 October 2019 (UTC)

Tech News: 2019-41[edit]

15:34, 7 October 2019 (UTC)

Search function has a URL with "cirrus"[edit]

Is this explained anywhere? — Vchimpanzee • talk • contributions • 15:44, 7 October 2019 (UTC)

@Vchimpanzee: see more at mw:Help:CirrusSearch. — xaosflux Talk 15:58, 7 October 2019 (UTC)
Thanks.— Vchimpanzee • talk • contributions • 16:02, 7 October 2019 (UTC)

Page views data prior to February 2008[edit]

I am working on a research project related to the traffic of Wikipedia platform. Could you please help me to find the page views data of the early days of Wikipedia? Ideally, I would like to find 2001-February 2008. I understand that the metrics were different from the current metrics. — Preceding unsigned comment added by Vika-Wiki (talkcontribs) 03:59, 8 October 2019 (UTC)

@Vika-Wiki: These dumps go back to December 2007, but there was not much pageview data before then. I believe there was page view data in the early days of Wikipedia but I have no idea how to get at it without maybe downloading old database dumps. Graham87 05:18, 9 October 2019 (UTC)

Reply link script[edit]

I am having problems with Enterprisey's reply link script. Please see Wikipedia:Help_desk#Reply_link_script and User talk:Þjarkur/sandbox for more info about the problem. I tried reaching to Enterprisey, but he didn't get back to me. It doesn't seem to work on some Wikipedia forums such as the WP:HD and WP:ANI and also my talk page. I get the error message "There was an error while replying! Please leave a note at the script's talk page with any errors in the browser console, if possible.". I tried replying at this page and I have no issues replying there. I am currently using a modified script at User:Þjarkur/reply-link.js Can you figure out what is going on there and how to fix these errors so that the script works on every Wikipedia page? Interstellarity (talk) 18:02, 8 October 2019 (UTC)

(edit conflict) For an explanation, Interstellarity is having some problems with reply-link but only with replying to certain posts. I could identify one error where it was not possible to reply to me due to the Unicode character in my username which was giving a "Failed to find a matching comment in the Parsoid DOM". Interstellarity says they still get an error from reply-link, but only on some pages including WP:ANI. My guess is that Parsoid has changed the markup it returns a little bit. Interstellarity, can you verify that the error you get is the same Parsoid DOM error as before? – Thjarkur (talk) 18:01, 8 October 2019 (UTC)
I just got an edit conflict. I have provided more info. Do you any more info regarding this post? Interstellarity (talk) 18:06, 8 October 2019 (UTC)
Yes, do you still get the same Parsoid DOM error or is there another console error message? – Thjarkur (talk) 18:08, 8 October 2019 (UTC)
Þjarkur, I got it to work at WP:VPT and WP:HD, but not my user talk page. Yes, I do get the error message you are talking about. Interstellarity (talk) 18:11, 8 October 2019 (UTC)
Any help would be appreciated. Interstellarity (talk) 19:58, 8 October 2019 (UTC)
Most people are frequently experiencing errors with reply-link, not just you. Alas, for now the only option is to manually edit the page whenever it doesn't work. It's an extremely complicated script and would need quite a bit of coding and testing by Enterprisey (or someone else) to run reliably across all pages. SD0001 (talk) 06:25, 9 October 2019 (UTC)
For me, it seems to work at both [ANI and at HD. Any specific comments you tried replying to where it didn't work? SD0001 (talk) 06:59, 9 October 2019 (UTC)
SD0001, Replying in both of those places worked for me too. It doesn't seem to work when replying to someone on my talk page. Interstellarity (talk) 10:50, 9 October 2019 (UTC)
One thing that I've noticed is that the generated edit summary sometimes implies that a user is replying to themselves (example). --Redrose64 🌹 (talk) 13:29, 9 October 2019 (UTC)
Redrose64, The edit summary isn't the problem. It is the functionality of the script that's the problem. Interstellarity (talk) 21:50, 9 October 2019 (UTC)

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)

Remove the merge template[edit]

Please remove the Merger notice on {{Infobox Company}}. It is irritating to see it appearing on top of articles. If it cannot be removed, then please put a noinclude around it. Users need to read the caution notice before slapping notices on highly visible templates. (talk) 10:07, 9 October 2019 (UTC)

This is not a technical issue, please follow up at Template talk:Infobox company. — xaosflux Talk 10:31, 9 October 2019 (UTC)
I really feel {{template for discussion}} should be wrapped in {{if preview}}. These notices are fairly confusing and sit prominently at the top of articles. – Thjarkur (talk) 10:45, 9 October 2019 (UTC)
TFD notices are generally reasonable. I've not really understood the complaints yet. --Izno (talk) 00:11, 10 October 2019 (UTC)

Wikipedia talk:Tags#Editor privacy[edit]

Unresolved: Phabricator ticket opened by xaosflux (thank you!). –xenotalk 15:58, 9 October 2019 (UTC)

I'm concerned that some of the tags added to edits (presumably for debugging reasons) are violating the privacy of editors by disclosing the type or software characteristics of devices they are using to contribute. Please see Wikipedia talk:Tags#Editor privacy. –xenotalk 13:35, 9 October 2019 (UTC)

I'm unhappy with this practice too. Thanks for raising this, xeno. ↠Pine () 18:54, 9 October 2019 (UTC)

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

{{PAGESINCATEGORY:Articles with redirect hatnotes needing review|pages}} is showing a higher count (17) 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, {{PAGESINCATEGORY}} 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)

Newly deprecated cite parameters used by reFill[edit]

A previous message was left at User talk:Zhaofeng Li/reFill, but Zhaofeng Li does not appear to have been active on WP since July.

So |deadurl= and |dead-url= have been deprecated in {{cite web}} and its variants, in favor of |url-status=. However, I notice reFill 2, and probably regular reFill, are still generating |dead-url=, which in turn now generates an error message and adds the page to the maintenance category Category:CS1_errors: deprecated parameters. The operators of InternetArchiveBot and GreenC bot have made the fix there, is there anyone who can update reFill accordingly?. The particulars of the cite template update that applies here are listed at the maintenance category page (and also at Template:Cite_web#What's_new), but note that the "yes" or "no" values also need to be changed to "live", "dead", "unfit", or "usurped", as necessary. Thanks.— TAnthonyTalk 19:56, 9 October 2019 (UTC)

@TAnthony: This was reported at GitHub 3 days ago [4]. A look through User talk:Zhaofeng Li/reFill suggests bug reports to reFill have gone unresolved for at least the past 6 months, and many reports prior going back years unresolved. Zhaofeng Li reports they are "semi-retired" from Wikipedia as of July. It might be the tool lacks a maintainer and is running without an operator. If this is the case it might be reported to Wikipedia:Bots/Noticeboard and see what they say. It's a little different since it is a user-triggered tool with full oversight of edits by end user and might not be under the same rules as a bot, but IMO it should be. -- GreenC 21:16, 9 October 2019 (UTC)
Hi GreenC. You are correct in your observations about refill. On the other hand it should be noted that the tool was updated to "refill 2" sometime earlier this year. Also two or three days ago it was down for several hours and since it came back it is running much slower than it was previously. This makes me think someone is tinkering with it somewhere but I have no idea how to find out who or where this is happening. Is there any chance that something being done at another wiki is affecting things here? If anyone else knows what is going on please add that info here to help us understand what is happening. MarnetteD|Talk 21:44, 9 October 2019 (UTC)
MarnetteD, I'm looking through the source files on Toolforge where it runs (both versions) and see timestamps to a few files from around February 2019, most much older. Not unusual for outages due to hosting problems on Toolforge. I found a source file where |deadurl= is mentioned, looks like an easy fix, but can't modify it due to file permissions. For the record it is Toolforge: /data/project/refill/versions/stable/src/Reflinks/CitationGenerators/CiteTemplateGenerator.php -- GreenC 23:46, 9 October 2019 (UTC)
Thanks for the info GreenC. February sounds right for the change to "2". MarnetteD|Talk 01:00, 10 October 2019 (UTC)

Extreme difficulty loading pages[edit]

I'm using YouTube and Google no problems in Taipei, Taiwan. But when I try to load Wikimedia project pages, the page loads partially and then stops. If I refresh the page five to fifteen times, I can eventually make the full page load up. What is happening here? I can't get Phabricator to send a confirmation email to my email inbox, otherwise I wouldn't be asking here. Geographyinitiative (talk) 00:15, 10 October 2019 (UTC)

This problem has been going on since yesterday night (Oct 9 my time). Also, when I just made an edit, I got the message "Some parts of the edit form did not reach the servers; double-check that your edits are intact and try again." What is happening here? So bizarre! Geographyinitiative (talk) 00:31, 10 October 2019 (UTC)
The problem is ongoing. Again, I can use other websites normally, but Wikipedia pages require several refreshes. As I am writing this, the page is not fully displayed. Geographyinitiative (talk) 03:36, 10 October 2019 (UTC)
I'm not sure about having the same problem, but in my case it was browser dependent. IE had a problem and Chrome had not. FredTC (talk) 03:48, 10 October 2019 (UTC)
Good advice. I switched between browsers and the problem is basically gone (or at least greatly reduced). Geographyinitiative (talk) 04:00, 10 October 2019 (UTC)
I may have spoken too soon- the problem is still there in the second browser, but not as bad. What could explain this? ([5]). --Geographyinitiative (talk) 04:18, 10 October 2019 (UTC)])Geographyinitiative (talk) 04:14, 10 October 2019 (UTC)
Well, back at my laptop, I experience no more problems. So I think I had a different problem that occured at the same time your problems started. I guess at wikimedia they were experimenting with browser dependent code. --FredTC (talk) 07:26, 10 October 2019 (UTC)
I had problems with pages not rendering at all (think the message was something unexpected went wrong) on two different iPads (iOS 9 and 11) but not on iPhone with iOS 12. Also errors in the Wikipedia app. Wednesday night Australia-east time, so would have been about midday UTC 9 Oct. Pelagic (talk) 22:46, 10 October 2019 (UTC)
I want to report that I am no longer having any problems in any browser. The situation got better and better over the course of the day yesterday and now my loading times have returned to normal. Geographyinitiative (talk) 01:33, 11 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)

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.[6] 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)

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

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)

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)

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)

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)

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)

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.[8] PrimeHunter (talk) 22:43, 14 October 2019 (UTC)