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, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177


Google Code-In will soon take place again! Mentor tasks to help new contributors![edit]

Hi everybody! Google Code-in (GCI) will soon take place again - a seven week long contest for 13-17 year old students to contribute to free software projects. Tasks should take an experienced contributor about two or three hours and can be of the categories Code, Documentation/Training, Outreach/Research, Quality Assurance, and User Interface/Design. Do you have any Lua, template, gadget/script or similar task that would benefit your wiki? Or maybe some of your tools need better documentation? If so, and you can imagine enjoying mentoring such a task to help a new contributor, please check out mw:Google Code-in/2019 and become a mentor. If you have any questions, feel free to ask at our talk page. Many thanks in advance! --Martin Urbanec 07:28, 5 November 2019 (UTC)

The tasks for "Google Code in" are listed on phab:project/view/4241/.--Snaevar (talk) 10:09, 9 November 2019 (UTC)

Bot to replace highjacked links[edit]

Is there a bot to disable hijacked links in refs/ELs that may now be unfit/malicious? At Wikipedia:Teahouse#Hijacked site with possible malware, Lyndaship has reported that has moved to, and the new host may be malicious (certainly misleading). The layout of the new site has changed, so it's not an easy replace of the hostname (though maybe editors could help construct a translation table?). Meanwhile, disabling the links would probably be reader-friendly. Is there a bot or some other means to handle this? —[AlanM1(talk)]— 23:07, 5 November 2019 (UTC)

@GreenC: poke. --Izno (talk) 01:11, 6 November 2019 (UTC)
@AlanM1: Agree on malicious domain: it is a sketchy domain. Normally would set the domain to Blacklisted in the IABot interface and run IABot and archive them all (since we don't know the new URLs second option is archive). But they will also require adding |url-status=usurped, to suppress displaying the malware link, which is custom coding. WaybackMedic can do it. Post/move this request to WP:URLREQ. Might also edit filter request. -- GreenC 01:44, 6 November 2019 (UTC)
@GreenC: Thanks for the quick response. I'll explore a little more to find out whether a translation table is reasonable before continuing. —[AlanM1(talk)]— 01:55, 6 November 2019 (UTC)
(Moved to and resolved.) —[AlanM1(talk)]— 23:23, 8 November 2019 (UTC)
@AlanM1: A few years back I used AWB and some manual editing to replace all references to the now defunct to instead use {{cite ship register}} or {{ship register}}. This way, now only could I make them all point to the new address, but should the linking scheme change again in the future, only those two templates need to be updated. Both templates already have been changed to point to the new address, so the best long-term solution would probably be to switch over to the template instead of just marking as usurped. --Ahecht (TALK
) 21:23, 11 November 2019 (UTC)
Thats a great little tool which I was unaware of. All the clydesite links are now sorted but I don't think this template would have been of benefit in this instance as the vessel id numbers also changed when the domain changed Lyndaship (talk) 07:03, 12 November 2019 (UTC)

Webcitation redux[edit]


There was a proposal to deprecate webcitation, since it had stopped accepting new pages to archive.

Although is no longer accepting new pages, it continues to serve pages archived in the past.

However Citation_bot is breaking those working links to the archives. It seems to me this is not what was agreed to in the proposal. I thought a bot was going to (1) search out all links to pages archived by; (2) determine if the page was also archived at; (3) if the page in question was also archived at, or, if still live, whether it could be archived at, then replace the url with an url.

I don't see anything in the proposal that authorized breaking working urls to archived pages.

I thought if there was no replacement at a better archive the working urls to the archive would be left, as is.

I went to User_talk:Citation_bot/Archive_18#WebCite_query_strings. Near as I can understand GreenC justifies this excision of working archive links because he or she has found vandals, or naive but misguided good faith contributors, have used links to webcitation so they could serve references to pages at sites we had decided to blacklist.

  1. But couldn't a vandal use this technique with links to, just as easily?
  2. This wasn't what was agreed to at the proposal, which only took place a month or so prior to the second discussion.

Webcitation was the first archive server I discovered, and I used it exclusively, for years, until I discovered So, prior to this bot breaking links to it, there may have been as many as a thousand perfectly valid instances where I used it, that still pointed to it. This represented a meaningful investment of my valuable time. So, I am not happy that this bot was authorized to break those links. Of course I would have to live with that unhappiness, if a central discussion authorized this. It does not seem that this was the case.

I sure hope citationbot was replacing those links with links, when this was possible.

A complicating factor is that webcitation offered users a choice - the archive-url it returned could either be a short, but obfuscated unique link, or it could return a longer, non-opaque link, that encoded the original pages url into it, just as does. It seems to me that GreenC's justification that vandals could hide bogus improper links in archive-url fields would only be true for those short, obfuscated links.

Well, I never used the short, obfuscated links webcitation offered. I only rarely came across anyone else using them.

I'd like a status report - has this bot broken every single working link to a webcitation archive? If not I suggest the bot should have this feature disabled, immediately.

If possible, I'd like to see a bot go through all the edits where citationbot broke perfectly valid, working links to the long, non-obfuscated webcitation archives, and restore those that weren't updated with a link to Geo Swan (talk) 19:10, 7 November 2019 (UTC)

Geo Swan, you could report this to Citation bot but AFAIK it no longer messes with Webcite links. @AManWithNoPlan:. Also you are misunderstanding the discussion at User_talk:Citation_bot/Archive_18#WebCite_query_strings I was not "justifying the excision of working archive links". -- GreenC 03:04, 8 November 2019 (UTC)
citation bot broke nothing. All it did was remove a human readable comment from the url. It was never actually used by webcitation. It turns out there are supposedly bots that add these and verify them, and they exist solely so people using Wikipedia can see what the archive is. AManWithNoPlan (talk) 03:30, 8 November 2019 (UTC)
webcitation links contain a time stamp and nothing else. Deep in their archive they simply never archived two pages at exactly the same moment. Very simple and yet very stupid. AManWithNoPlan (talk) 03:33, 8 November 2019 (UTC)

  • So, I got my knickers in a knot over something cosmetic... I'd still say the removal was a lapse from the principle "if it ain't broke, don't fix it..."
  • Thanks to everyone who responded. Geo Swan (talk) 03:38, 8 November 2019 (UTC)

Problems with separators and semicolons on RecentChanges, Watchlist, History and Contributions[edit]

  • Update: many of these appear to be realted, see phab:T233649 for the master ticket. — xaosflux Talk 01:44, 8 November 2019 (UTC)

What's with the semicolons in the watchlist?[edit]

I just noticed today that titles of pages in my watchlist end with a semicolon. I'm a big fan of semicolons, used correctly; this one, I have to say, just looks weird. When did it start, and what was the rationale? --Trovatore (talk) 20:45, 7 November 2019 (UTC)

WP:ITSTHURSDAY - seems to be:
.mw-title::after {
    content: ';\00a0';
code with a bug? Will open a phab ticket. — xaosflux Talk 20:48, 7 November 2019 (UTC)
phab:T237685 opened. — xaosflux Talk 20:52, 7 November 2019 (UTC)
Thanks! --Trovatore (talk) 20:53, 7 November 2019 (UTC)
@Jdlrobson: can you take a look at that ticket? — xaosflux Talk 21:48, 7 November 2019 (UTC)
very curious about this one - I'm a fan of consistency where ever possible and I'm not sure why the semicolon wouldnt appear here but would appear on history. What is the problem it is solving on history but not solving on watchlist? Jdlrobson (talk) 01:39, 8 November 2019 (UTC)

Missing separator[edit]

Resolved: Unable to duplicate this part - possibly related to other sections. — xaosflux Talk 01:22, 8 November 2019 (UTC)

On a perhaps related note, a few minutes ago I lost the space between page title and revision time, e.g.

m Meteotsunami‎22:37 . . (-35‎) . . ‎LizardJr8 ( talk | contribs )

Note the missing space between "Meteotsunami" and "22:37". DaßWölf 22:54, 7 November 2019 (UTC)

@Daß Wölf: is that on the watchlist? What interface language are you using, what skin are you using? Do you have any special watchlist settings enabled? — xaosflux Talk 00:49, 8 November 2019 (UTC)
@Xaosflux: yes, it's the watchlist, forgot to write that. Vector skin, JavaScript watchlist. Of all the settings that look like they might have impact, the ones I have enabled are unread changes in bold, and the subtle update marker. DaßWölf 01:04, 8 November 2019 (UTC)
Actually, it seems to have gone away. Now for the separator I have a semicolon and a space (e.g. "Meteotsunami; 22:37". I don't remember if the semicolon was there before. DaßWölf 01:05, 8 November 2019 (UTC)
@Daß Wölf: thanks, I hadn't been able to break it like you did - was going nuts :D The semicolon appears to be new (and unwanted), from the parent section of this above. — xaosflux Talk 01:10, 8 November 2019 (UTC)

Bad semicolon in history[edit]

@Xaosflux: Again unrelated, I just went to thank you for this edit and a new semicolon has popped up in the article history: "(cur | prev ) ¤ ¤ ; 01:10, 8 November 2019‎" - bolded for clarity. Now that one I'm sure wasn't there! DaßWölf 01:13, 8 November 2019 (UTC)
@Daß Wölf: phab:T237705 is open for the bad semicolon here. — xaosflux Talk 01:21, 8 November 2019 (UTC)
Yep, that's what I see too, thanks. DaßWölf 01:35, 8 November 2019 (UTC)
Note, in come cases a double set of bad leading semicolons are also appearing, updated the phab ticket. — xaosflux Talk 03:54, 8 November 2019 (UTC)
Xaosflux, I see a double set when I do an RD1 — I dropped a note at the ticket S Philbrick(Talk) 14:37, 8 November 2019 (UTC)
Semicolon before timestamp of edits in "View history"

The lines for each edit at any page when viewing under "View history" start with a semicolon (;). Is this intentional or a mistake? 37KZ (talk) 15:32, 8 November 2019 (UTC)

@37KZ: see above. — xaosflux Talk 15:49, 8 November 2019 (UTC)

Missing separators in page history[edit]

Resolved: This issue is no longer presenting. — xaosflux Talk 03:53, 8 November 2019 (UTC)
Parenthesis and pipe characters have disappeared in the page history for me (image). &safemode=1 did not solve the problem, suggesting it's not a problem with my scripts. —k6ka 🍁 (Talk · Contributions) 01:19, 8 November 2019 (UTC)
@K6ka: could you trying clearing you local cache and trying again? (I can't duplicate this one). — xaosflux Talk 01:27, 8 November 2019 (UTC)
@Xaosflux: The issue seems to have fixed itself (or someone fixed it behind the scenes) and I'm not getting this problem anymore. —k6ka 🍁 (Talk · Contributions) 03:48, 8 November 2019 (UTC)

Temporary CSS fix[edit]

At the moment, I get the stray semicolon before the date in Special:Contribs results. I resolved it with the following in my common.css:

.mw-changeslist-date::before {

The debugger said the content was ';\u00a0' (semicolon followed by a non-breaking space), which was then prefixed to the timestamp, after the bullet. Should I leave the \u00a0 there? It looks fine to me without it. —[AlanM1(talk)]— 03:21, 8 November 2019 (UTC)

@AlanM1: shouldn't hurt anything, keep an eye on the master phab ticket, they may fix all of this for you sooner than later. — xaosflux Talk 03:24, 8 November 2019 (UTC)

Semicolons on Contributions pages[edit]

I have noticed that the entries on Contributions pages (Special:Contributions) begin with a semicolon for each entry. Please fix this. —Etewilak (talk) 08:18, 8 November 2019 (UTC)

Probably T233649? --rchard2scout (talk) 11:08, 8 November 2019 (UTC)
Same for "View history" on individual pages. 37KZ (talk) 15:57, 8 November 2019 (UTC)
37KZ, There could be a reason for this, perhaps? It could be using the same coding for other pages, which have information which precede the current diff. Doug Mehus (talk) 16:37, 8 November 2019 (UTC)

Semi-colons before timestamps in Special:Contributions[edit]

I just noticed that, as of today, there's semi-colons before the time stamps of edits when you look at a user's contributions. I don't remember this being the case before today and I don't remember there being an announcement of this happening. Is this a glitch or an intended feature? Narutolovehinata5 tccsdnew 02:04, 11 November 2019 (UTC)

  • +1 ... Just came by to talk about these semicolons. What is happening??? Steel1943 (talk) 20:27, 11 November 2019 (UTC)
  • Yeah why is this still a problem? (talk) 12:31, 12 November 2019 (UTC)

Contributions have a semicolon[edit]

To the left of each edit. I don't think that was true before.— Vchimpanzee • talk • contributions • 22:00, 12 November 2019 (UTC)

See above. Headbomb {t · c · p · b} 22:07, 12 November 2019 (UTC)
Thanks.— Vchimpanzee • talk • contributions • 22:24, 12 November 2019 (UTC)

Make Reply-to a Gadget[edit]

Proposal: Make the popular Reply-to script a gadget, with special credit and attribution to User:Enterprisey for his coding of the script.

Rationale: The current Reply-to script is headily used, but suffers from intermittent and frequent errors depending on the page you're replying to another editor.

Hat tip: Evad37 to based on this similar proposal, and to Steel1943. --Doug Mehus (talk) 01:51, 8 November 2019 (UTC)

  • @Dmehus: are you referring to reply-link? If so, not only has the author said it is stilll being tested and debugged. Bugs are still present. but you also mentioned that it has problems. We shouldn't be forking this to a public gadget if it is known to be problematic. — xaosflux Talk 01:53, 8 November 2019 (UTC)
Xaosflux Yes, I meant Reply-link. Thanks. But, my understanding is that being a gadget, it will be hard-coded into the MediaWiki software, no? Also, I assume Wikimedia Foundation has full-time employed software engineers who could work out any kinks? --Doug Mehus (talk) 02:16, 8 November 2019 (UTC)
@Dmehus: nope, a "gadget" is just a community-managed script. You are probably thinking of an extension (an add-on piece of server software). You can track the (slow) progress on that at phab:T207567. — xaosflux Talk 02:28, 8 November 2019 (UTC)
@Xaosflux: Ah, that makes sense, and thanks for pointing out that link for me! Glad to see it's "in the works"—albeit slowly. In that case, I wonder if XFDCloser/DiscussionCloser could be made into Extensions? Also, re: "gadgets," what's the point in having a community-managed script versus the way it is now (one or more editors/administrators maintain the script)? Doug Mehus (talk) 02:31, 8 November 2019 (UTC)
@Dmehus: the primary benefit is for users, they can enable or disable gadgets very easily in Special:Preferences#mw-prefsection-gadgets instead of mucking about in .js/.css files. They are generally considered "safe" as only interface-administrators may make changes to them. (Anyone can request changes of course). — xaosflux Talk 03:09, 8 November 2019 (UTC)
Xaosflux, Ah, yes, I knew that, too! Like Twinkle...that makes sense. Thanks. Doug Mehus (talk) 03:18, 8 November 2019 (UTC)

Read only maintenance window planned for ENWP at 14th Nov 05:00 AM UTC (one week away)[edit]

A reminder this is one week away, see --JCrespo (WMF) (talk) 09:22, 8 November 2019 (UTC)

Thanks log not included in "All public logs"?[edit]

Consider these two log searches:

Why is the "thanks" entry not shown in the "all" search? Which part of "all" did I not understand? -- RoySmith (talk) 13:56, 8 November 2019 (UTC)

@RoySmith: it is available from that page, see example here. The instructions for that page say "This is a combined display of all logs except the patrol, review, tag and thanks logs", but you can turn them on where it says "Show additional logs". — xaosflux Talk 14:14, 8 November 2019 (UTC)
Funny story, I once almost desysopped someone because of this. (their hidden “thank” was keeping them from inactivity). –xenotalk 14:16, 8 November 2019 (UTC)
(edit conflict) The logs under "Show additional logs" are omitted if you only select "All public logs" so the name is a little misleading. It's determined by MediaWiki:All-logs-page but that message is shown both in the drop-down and heading of Special:Log so it's problematic to change it. If we for example said "All public logs (except additional logs)" then the heading would be false when additional logs have been selected. Special:Log displays MediaWiki:Alllogstext which has been customized by the English Wikipedia to include: "This is a combined display of all logs except the patrol, review, tag and thanks logs". This has the same issue of still displaying when some or all of those additional logs are selected. PrimeHunter (talk) 14:26, 8 November 2019 (UTC)
Ugh, what a disastrously bad UX. In the most central place, with a box around it to draw your attention, it says, "All". Then, in other places, where you might not think to look, it says, "well, except for these things..." Thanks for explaining it. I've opened T237729. -- RoySmith (talk) 14:31, 8 November 2019 (UTC)

Watchlist - Are you sure[edit]

Starting yesterday a new inconvenience seems to have been added to the watchlist process. Previously, I could click on the white (blue bordered) star and it would simply add the article to my watchlist. If I want to remove it, I click the blue star and it toggles back to white. Pretty simple. Now, for the last two articles I have added I get asked an obnoxious "are you sure?" question. I watch over fifteen thousand articles built up over a dozen years. I use this process constantly. I watch, I check, I respond when necessary to protect content. I spend far too much time doing this. I do not need to wait for an additional page load on each article I add to my watchlist, it answers; another page load and yet another 2 page loads to use the back button go back to where I was. It interrupts the flow of reading. How do we turn this unnecessary and obnoxious process off, permanently? Trackinfo (talk) 20:15, 8 November 2019 (UTC)

Additionally, and I only suggest it because the timing matches with the above inclusion, I am now unable to preview forward to see what edits have been made to the articles that show up in my watchlist. Again it was a function I had to sign up for that worked well for, oh, maybe a decade. By being unable to preview the edit, I must open each article I suspect might be a bad change. This greatly slows my ability to watch. Why has this disappeared? Trackinfo (talk) 20:22, 8 November 2019 (UTC)

@Trackinfo: are you using the mobile app, mobile site, or the full website? Which skin are you using? Do you have javascript disabled on your browser? — xaosflux Talk 21:06, 8 November 2019 (UTC)
I am on Safari on a Mac; essentially the same browser (updated) I have been using for a dozen years. I believe javascript is active and necessary for some of the editing features I have been signed up for. No changes on my side. All these things failing at the same time indicates to me that someone else did a system wide update that screwed things up. That's what I am trying to head off. Trackinfo (talk) 03:18, 9 November 2019 (UTC)
An additional feature is also failing. The notifications section, normally (over the last year or so) would show me some activity that name dropped me. Today I received three, I assume from this case. The Notifications bubble no longer appears, instead it opens up as a new page, that does not resolve. All I get below the wikipedia header is a header saying "Notifications" and an animation suggesting something is loading. It never loads. Trackinfo (talk) 03:25, 9 November 2019 (UTC)
Sounds like a javascript error somewhere, possibly in a userscript or gadget. Try opening your browser's console and let us know if there's any errors (in red). Also try adding ?safemode=1 to end of the web address (which disables all userscripts/gadgets) and see if the issues are still present. the wub "?!" 10:29, 9 November 2019 (UTC)
I have occasionally been afflicted by the "are you sure" malarkey, and the notifications opening as a new page. I think I enquired about the watchlist thing a while ago, but can't be sure offhand. I've rather assumed both were down to either a slow connexion at my end, or some sort of burp at the Wikimedia end. Monobook, Edge, Win10. DuncanHill (talk) 01:33, 11 November 2019 (UTC)

Global watchlist - Update 2[edit]

Question about MediaWiki interface timestamp format[edit]

Is there a MediaWiki: meta page that formats the structure of the use of "~~~~~" (e.g., displaying 02:55, 9 November 2019 (UTC) as 2019-11-09T02:55Z, etc)?  Nixinova TC   02:55, 9 November 2019 (UTC)

No. mw:Help:Signatures says: "timestamps are currently formatted by default and saved according to the default locale conventions (language, script, date and time format) used on each wiki". This data is given in configuration files for the wiki and not editable wiki pages like the MediaWiki namespace. But the default user part excluding timestamp (made with three ~~~) is determined by MediaWiki:Signature and MediaWiki:Signature-anon. PrimeHunter (talk) 12:19, 9 November 2019 (UTC)
On muh localhost wiki, I tried editing MediaWiki:Datedefault to various values based on reading mw:Manual:Date formatting, but none seemed to have any effect. Not sure why.
What definitely does work is editing ./languages/messages/MessagesEn.php and changing this line
$defaultDateFormat = 'dmy or mdy';
$defaultDateFormat = 'ISO 8601';
However this format is pre-defined to include the seconds and exclude the final Z. So if you want it to look exactly like the example you gave, you'd also need to find these two lines in the same file (not actually adjacent):
	'ISO 8601 time' => 'xnH:xni:xns',
	'ISO 8601 both' => 'xnY-xnm-xnd"T"xnH:xni:xns',
and change them to
	'ISO 8601 time' => 'xnH:xni"Z"',
	'ISO 8601 both' => 'xnY-xnm-xnd"T"xnH:xni"Z"',
Alternatively, you could add the Z and still keep the seconds, for the sake of "true ISO 8601" completeness.
Note that in addition to the users' signatures, this also affects log/history/contribs/etc. views.
Unfortunately attempting to set any of these things in LocalSettings.php did not seem to have any effect either.
You could probably create your own language (or "variant"?) as a way to avoid having these tweaks overwritten by updates, then choose that language instead of "en" in LocalSettings.php. Doing that may or may not require duplicating a bunch of other files as well (did not attempt). ―cobaltcigs 12:59, 9 November 2019 (UTC)
If you click Edit or View source on a MediaWiki message in the English Wikipedia then you get a link to which usually says what the message is for. MediaWiki:Datedefault gives which says: 'Used as checkbox label in user preferences, Prefs-rendering ("Appearance") tab. This message indicates Prefs-dateformat ("Date format") is default (= not specified).' So it merely displays the text "No preference" under "Date format" at Special:Preferences#mw-prefsection-rendering. uselang=qqx confirms the message is displayed there. PrimeHunter (talk) 21:41, 9 November 2019 (UTC)

Wikitable header centering: desktop vs mobile[edit]

I noticed wikitables set with a global alignment in style will show headers centralised on desktop and according to that global alignment on mobile. Is that how it's meant to be? Guarapiranga (talk) 07:27, 9 November 2019 (UTC)

Guarapiranga, pls give examples. It helps avoid ambiguity. —TheDJ (talkcontribs) 15:22, 9 November 2019 (UTC)

IP range edits[edit]

Resolved: The OOUI monster changed the controls around. — xaosflux Talk 05:21, 10 November 2019 (UTC)

There used to be tools that allowed the edits in an IP range to be viewed, but I can no longer find them and/or they no longer exist. I know that a CIDR range can be entered in the special:contributions page, but it is fairly useless as it can't be limited to recent contributions or a date range. One has to wade through thousands of irrelevant edits from decades ago. Is there anything better on WMF Labs nowadays? SpinningSpark 18:35, 9 November 2019 (UTC)

@Spinningspark: you should be able to use multiple filters at Special:Contributions, here is an example with a CIDR range and a date filter. Is that what you are having trouble with? — xaosflux Talk 19:22, 9 November 2019 (UTC)
That's perfect, I was just too stupid to work it out for myself. Is putting the dates directly in the url the only way to do this? SpinningSpark 20:57, 9 November 2019 (UTC)
@Spinningspark: From/to dates among other filters are available in the "Search for contributions" panel at the top of Special:Contribs. MusikAnimal talk 21:59, 9 November 2019 (UTC)
Ah right, I see. You can only get that from a clean form. Getting to it from a user's contributions, the settings fields aren't displayed. SpinningSpark 22:49, 9 November 2019 (UTC)
@Spinningspark: you should be able to, at the top of that page there is a collapsed "Search for contributions" control that you can open and change the filters. — xaosflux Talk 00:02, 10 November 2019 (UTC)
D'oh! SpinningSpark 01:12, 10 November 2019 (UTC)

Unable to view diffs of deleted pages[edit]

Apologies if this is the wrong location to report...but lately I've been having issues with viewing the diffs of deleted pages and was wondering if it was just me. When I try to click on a diff of a page that's been deleted, I'm met with "Internal error: Fatal exception of type "InvalidArgumentException" ", but strangely, when I click on the time and date of the revision I want to see as opposed to the diff button, I can view it just fine. So, for example, I can't see [1], but I can see [2]. A minor inconvenience, but annoying nonetheless. Also I can still see diffs that have been revision deleted as normal. Anyone know of an easy fix? Sro23 (talk) 19:09, 9 November 2019 (UTC)

@Sro23: it's broken, just confirmed on testwiki too. Will open a phab ticket. — xaosflux Talk 19:13, 9 November 2019 (UTC)
@Sro23: phab:T237824 has been created. — xaosflux Talk 19:17, 9 November 2019 (UTC)
Upmerged to phab:T237709. — xaosflux Talk 21:24, 9 November 2019 (UTC)
Good to see that I'm not the only one who is having this problem and that there are alternative ways to view deleted edits. Liz Read! Talk! 15:56, 15 November 2019 (UTC)

breaking edit??[edit]

Can anyone tell me what happened here? I only touched the part after the '=' at website in that edit, using the regular old-fashioned wikitext editor. The save however resulted in some spaces to be replaced by .. spaces, or tabs? --Dirk Beetstra T C 05:12, 10 November 2019 (UTC)

The breaking character is still in another parameter, it breaks the parameter name resulting for 'website' in a edit-mode warning that 'website' is not a recognised parameter. --Dirk Beetstra T C 05:21, 10 November 2019 (UTC)

@Beetstra: an "edit-mode warning"? In the wikitext editor? What is making this warning, what does it say? (Or is this a template in preview mode outputing to the preview?) — xaosflux Talk 05:23, 10 November 2019 (UTC)
@Xaosflux: Template is throwing the error that the parameter is unknown. Apologies for the unclarity. --Dirk Beetstra T C 05:29, 10 November 2019 (UTC)
@Beetstra: Revision 925449023 was just before your second edit. It contains no non-breaking spaces. Revision 925449055 (your firstsecond edit) contains three U+00A0 non-breaking spaces. They are where an asterisk is used in the following:
| website * * = {{facebook|stephenwesleymusic}}
| imagesize * =
No idea how they got there, but I've seen it before. Johnuniq (talk) 06:03, 10 November 2019 (UTC)
Johnuniq, yes, those nbsp's are the problem. I for sure did not put them there, they magically appeared and 'broke' the infobox. I know that 'French spacing' is converted, is that here converted wrongly? Dirk Beetstra T C 06:44, 10 November 2019 (UTC)
@Beetstra: I've remembered one place I saw it before. Did you copy the wikitext into a gmail edit window and then copied it out from there and back into the wikitext edit window? If so, that is a gmail feature. Johnuniq (talk) 07:15, 10 November 2019 (UTC)
Johnuniq, Nope, I copied the template from the external links section, then in the next edit I edited 'top' and replaced the content after the '=' with the material from my clipboard and hit saved the edit. I did not touch the material before the '=' on website, and not the next line. I then noticed on the page that my pasted facebook did not appear in the box and tried to figure out what went wrong. That is where the next edit window showed the template error that 'website' was not a recognised parameter. Dirk Beetstra T C 07:31, 10 November 2019 (UTC)
Hmm, if you used an Apple device the gmail issue might have been a red herring. Otherwise, all we can say is that something is doing the change whereas, for example, I often copy/paste wikitext but have never had that problem. Johnuniq (talk) 08:38, 10 November 2019 (UTC)
Johnuniq, I'm on Windows/Chrome. Somehow I think it is not related to the copy/paste but due to the some cleanup in the wikicode that malfunctions. Dirk Beetstra T C 09:59, 10 November 2019 (UTC)
I've been back through the last year's archives of this page and have found two related threads: Wikipedia:Village pump (technical)/Archive 173#Typing consecutive spaces in the Wikipedia iOS app editor causes NBSPs, which can break templates, and Wikipedia:Village pump (technical)/Archive 174#Taxobox questions. It seems to be browser/device dependent. --Redrose64 🌹 (talk) 16:02, 10 November 2019 (UTC)

Post-expand include size[edit]

Seeking a better understanding of post-expand include size. Reading the description, this data structure doesn't appear to be synonymous with HTML page. Is there an available picture of an example of it? And, is there an easy way to determine the size of the HTML page? ―Mandruss  16:03, 10 November 2019 (UTC)

I am not sure what you are asking, but you can use Special:ExpandTemplates to see the post-expand output of any wikitext, which is different from the HTML output - it's just wikitext with all templates expanded recursively and parser functions replaced with their output. The post-expand limit is applied to the length of the expanded wikitext. An easy way to determine the size of the html page? Not that it's relevant per above, but you can right click, click view page source, and get the character count using any software that has a character counter in it, like Word. SD0001 (talk) 19:30, 10 November 2019 (UTC)
The output of all templates, modules and parser functions called during the processing of a template can contribute to the post-expand include size so it's often larger than the final output. Click "Parser profiling data" at the bottom of a preview to see the post-expand include size. It's 39 bytes for {{green|Hello}} because {{green}} does not call anything. It just outputs 39 bytes. {{ISO 639 name|en}} only produces 7 bytes "English" but the post-expand include size is 28 bytes because {{ISO 639 name}} makes its own calls. "English" is output four times during processing: By {{ISO 639 name en}}, #ifexist, #if, and finally {{ISO 639 name}}. A template with no output could break the 2MB limit if it calls other templates with large output without passing that output to the original caller. PrimeHunter (talk) 00:18, 11 November 2019 (UTC)
See the examples of pages with a problem at Category:Pages where template include size is exceeded or the API list of articles. Taking List of political ideologies as an example, view that article then view the HTML source (Ctrl-U on some browsers). Search the HTML source for "NewPP" to see "Post‐expand include size: 2097066/2097152 bytes". In megabytes, that is saying that 2 MB of wikitext was included (transcluded) in the page from the expansion of templates. As an example, pasting {{green|Hello}} into Special:ExpandTemplates shows it generates <span style="color:green;">Hello</span> which is 39 bytes. In other words, using that example, the template would count as 39 bytes for the 2 MB limit. Johnuniq (talk) 21:28, 10 November 2019 (UTC)
Ok, thanks. Is there an easy way to determine the size of the HTML page (in bytes)? ―Mandruss  03:40, 11 November 2019 (UTC)
No, because it differs for every reader. The preferences (skin, etc.) of Logged-in users make a difference to what is displayed, and hence the output HTML. Even for logged-out users, the "You have a new message" orange box may appear or be absent. --Redrose64 🌹 (talk) 09:21, 11 November 2019 (UTC)
Good point. Now I wonder what the cached version of an article looks like. I had assumed it was the final HTML, but that can't be the case – unless all of that "customization" happens on the client side after download. ―Mandruss  09:52, 11 November 2019 (UTC)
Cached versions of articles look like this - the output of the MediaWiki parser, which is same across all skins - all user customisations are applied over this client side, via CSS or javascript. SD0001 (talk) 12:35, 11 November 2019 (UTC)

Link error in warning template[edit]

Template:Uw-coi-warn contains the string "You can post such a mandatory disclosure to your user page at [[{{SAFESUBST:<noinclude />BASEPAGENAME}}]]." There is an error here; this generates a mainspace article instead of the correct userpage, visible at [3] as an example. I'd correct it myself, but I fear mucking up the template in the process. Can a willing someone make the necessary change? Home Lander (talk) 20:12, 10 November 2019 (UTC)

@Home Lander: Fixed by using SUBJECTPAGENAME instead. -- John of Reading (talk) 21:14, 10 November 2019 (UTC)

Deleting ancient redirects from moves and attribution[edit]

In the early days of wikipedia, moving a page didn't leave any trace in the history of the page moved, only in the redirect that was left behind. And if at some point that redirect gets deleted for some reason, then there won't be any record of that move anywhere. Is that bad? Are we required to preserve some sort of information about the past names of articles for attribution? Are there any technical considerations that could be relevant? – Uanfala (talk) 00:43, 11 November 2019 (UTC)

Generally old redirects should just be left alone unless there's a really good reason to delete them. Partly for attribution issues but also due to link rot. As for what was done historically, I believe history merges were more common to preserve history. If you must delete an old redirect with history, you should request one of those so history is retained. Wug·a·po·des​ 00:49, 11 November 2019 (UTC)
True, but if the only thing remaining in the edit history of the redirect is that it is the previous name of the article, I don't think that alone needs to be preserved. If the redirect is deleted, then there is nothing to attribute. bd2412 T 00:53, 11 November 2019 (UTC)
If we needed to find out all the past names of a page, there ought to be a way. Possibly very tedious. EdJohnston (talk) 02:27, 11 November 2019 (UTC)
Page moves are recorded in the page's edit history, although the text has changed over the years. --Redrose64 🌹 (talk) 09:24, 11 November 2019 (UTC)
Prior to the roll out of MediaWiki 1.5 in June 2005, they were not recorded in the history of the page moved. – Uanfala (talk) 12:52, 11 November 2019 (UTC)
And in the earliest days of Wikipedia, there was no page move. You had to create a new page with cut-and-paste. PrimeHunter (talk) 20:02, 11 November 2019 (UTC)

Chrome - userscript problem[edit]

I have a long-standing íssue with my script on Windows Chrome.  (Admin only) script User:Beetstra/Gadget-Spam-blacklist-Handler.js fails in line 730: 'text.value += '\n' + append;' to update the actual text in the edit box, not adding the required content in 'append'. When looking at the value of text.value in debug mode, it is actually there (it is also in document.editform.wpTextbox1.value; text = document.editform.wpTextbox1), but it is not displayed in the edit box. The update of the summary field (document.editform.wpSummary.value) does get updated (I see it in the summary box), the correct material is collected, and the script does continue as expected (but when saving, the content is not changed). The problem is not there on Internet Explorer 11, the problem is not there in Chrome on my iPad. Someone has any clues? --Dirk Beetstra T C 11:04, 11 November 2019 (UTC)

Disable syntax highlighting - apparently highlighting "disables" use of this textbox (it's greyed in code Inspector [F12 FF]). If you switch that off, it will be "enabled" again. MarMi wiki (talk) 13:01, 11 November 2019 (UTC)
MarMi wiki thanks!. Funny, so .. is there then another box that is 'enabled'? (and funny that only Chrome understands that). Dirk Beetstra T C 13:03, 11 November 2019 (UTC)
MarMi wiki, did you mean User:Remember_the_dot/Syntax_highlighter? That one is turned off for me. Dirk Beetstra T C 13:10, 11 November 2019 (UTC)
I meant the default highlighter (CodeMirror) (the pencil icon, ~7th button from the left on the toolbar).
Under FF with enabled highlighting the script will not work either (I checked it with the above code snippets in Console). When in highlight mode, the text is stored in multiple div/span tags - each line (until enter) is in its own div. MarMi wiki (talk) 13:39, 11 November 2019 (UTC)
@MarMi wiki: yay, that worked. Rather annoying (I find it rather handy), but well, at least I can get the script to work. Thanks! --Dirk Beetstra T C 13:47, 11 November 2019 (UTC)
@Beetstra: You could also try to disable highlighting in the script (
//code to check if highlighting is enabled
$( '#wpTextbox1' ).data( 'wikiEditor-context' ).modules.toolbar.$toolbar.find( '#mw-editbutton-codemirror > a' )[0].click()
//change value
$( '#wpTextbox1' ).data( 'wikiEditor-context' ).modules.toolbar.$toolbar.find( '#mw-editbutton-codemirror > a' )[0].click()
MarMi wiki (talk) 15:07, 11 November 2019 (UTC)
MarMi wiki, not very elegant, but I could give it a try (though I am afraid it will turn it on when it is already turned off ..). Dirk Beetstra T C 06:11, 12 November 2019 (UTC)
@Beetstra: The api to modify the textarea is jQuery.textSelection. It exists specifically to avoid this issue of keeping multiple editors of the textarea in sync with eachother. —TheDJ (talkcontribs) 14:50, 12 November 2019 (UTC)
And it's even described on Wikipedia:User_scripts/Guide#Text_manipulation and Wikipedia:User_scripts/Techniques#Automatic_edits. I think it should be mentioned also on the WikiEditor and CodeMirror extensions pages (for example with a link: "visit here if you want to develop a JS script").
So for this case it would be:
var text = $textbox.textSelection( 'getContents')
$textbox.textSelection( 'setContents', text+'\n test')
// Above will scroll the text to the top (at least it does that when syntax highlighting is on),
// if you want to scroll back, you need to remember caret position:

// Put this line before 'setContents'
var pos = $textbox.textSelection( 'getCaretPosition')
// Put this line after 'setContents'
$textbox.textSelection( 'setSelection', pos)
--MarMi wiki (talk) 15:43, 12 November 2019 (UTC)
TheDJ, this script was ported, I did not write it from scratch, so I never saw that. I will try to incorporate this. Thanks! Dirk Beetstra T C 05:26, 14 November 2019 (UTC)

Tech News: 2019-46[edit]

22:02, 11 November 2019 (UTC)

Development environment for this wiki (take 2)[edit]

If I make a (Vagrant or Docker or VirtualBox) development for this wiki, would you be interested in including

  • 1. all gadgets or only some (if so then which)
  • 2. all extensions or only some (if so then which)
  • 3. all content or only some (if so then what part)
  • 4. all settings or only some (if so then which ones)

Also what extensions, or improvements to existing extensions, would you like to see developed if someone volunteers to do it. Is there a wish list.

Thanks, --Gryllida (talk) 05:10, 12 November 2019 (UTC)

There's plenty of wishes at meta:Community Wishlist Survey 2019/Results (and from previous years) - Evad37 [talk] 10:45, 12 November 2019 (UTC)
All extensions and settings should be there. Since gadgets can be installed trivially by editing pages on-wiki, there would not be much point in adding them. Regarding the content -- it wouldn't be possible to include 50 million pages, right? A sample, of say 100 pages from each namespace would be okay. SD0001 (talk) 11:41, 13 November 2019 (UTC)

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

This is a reminder. See for more information.

Due to daylight saving time, the time window has been changed from 05:00 UTC to 06:00 UTC.

Trizek (WMF) (talk) 09:43, 13 November 2019 (UTC)

JS to change contribs link[edit]

A user posted a question at the teahouse about how to set the contribs list to filter out edits to his user page. I didn't see a way to set the default options for the Special:Contribs page or any params to that Special page other than the username. So, I gave them an alternate link with a "long-form" URL with the params set up to filter out User namespace contribs. I'd like to be able to modify that Contribs link at the top of the page to use this URL instead of the plain Special:Contribs. This seems to work, but I'd appreciate knowing if there's an easier/better way (I'm a developer, but a total novice in this environment). The code I added to my common.js is:

$(document).ready(function() {
	var s = document.getElementById("pt-mycontris").firstChild.href;
	document.getElementById("pt-mycontris").firstChild.href =
		+ s.substr(s.lastIndexOf('/') + 1)
		+ "&namespace=2&wpfilters%5B%5D=nsInvert&title=Special%3AContributions";

(I actually already had a ready() function and added to it.) Thanks. —[AlanM1(talk)]— 11:03, 13 November 2019 (UTC)

$('#pt-mycontris a')[0].href += '?namespace=2&wpfilters%5B%5D=nsInvert'; inside the ready() does the same thing. SD0001 (talk) 11:34, 13 November 2019 (UTC)
Excellent, thanks! Do other Special pages work the same way (allowing tacking the raw URL parms on the end of one of the supported parms)? Is it documented somewhere what's available? —[AlanM1(talk)]— 12:12, 13 November 2019 (UTC)
Most special pages have one primary parameter, which for contributions is the username, so links of the form /wiki/Special:Contributions/username?...other...params... are the same as /w/index.php?title=Special:Contributions&...other...params . Similarly for WhatLinksHere, the primary parameter is the page name, and for PrefixIndex the prefix. SD0001 (talk) 15:04, 13 November 2019 (UTC)

Watchlist diff placement[edit]

Previously on my watchlist (and Special:RecentChanges, and possibly elsewhere I haven't noticed yet), the (diff|hist) link was previously immediately after the bullet point, to the left of the page and user information. It's now as of yesterday moved to the right of the page title. Is there a way I can move it back? Nikkimaria (talk) 03:07, 14 November 2019 (UTC)

I still see the (diff | hist) immediately after the bullet, both on watchlist and on RC. SD0001 (talk) 08:18, 14 November 2019 (UTC)
Did you accidentally turn on "group results by page"? Possibly unexpectedly by merely following a link? Anomie 12:25, 14 November 2019 (UTC)
Apparently yes, thanks. Nikkimaria (talk) 12:45, 14 November 2019 (UTC)



{{subst:PAGENAME}} makes the actual page name appear in the source edit instead of {{PAGENAME}}. How do I do the same for the page name minus the last letter, which is, as far as I know, written {{#invoke:string|sub|s={{PAGENAME}}|i=1|j=-2}}? Is it possible to subst: a module invoke?Jonteemil (talk) 03:13, 14 November 2019 (UTC)

Modules can be substituted in the same way as templates. {{subst:#invoke:string|sub|s={{subst:PAGENAME}}|i=1|j=-2}} should work * Pppery * it has begun... 03:20, 14 November 2019 (UTC)
@Pppery: It worked, thanks!Jonteemil (talk) 03:35, 14 November 2019 (UTC)

Prosesize as gadget[edit]

Hello, I've rewritten User:Dr pda/prosesize.js to be more modern and maintainable at User:Galobtter/scripts/prosesize.js. Most of the changes are internal, with the main user-facing changes are to remove the arbitrary disabling of the script on certain skins (e.g timeless) when the script works just fine on all desktop skins and a fixing of a bug in the calculation of reference text size. As prosesize is a very widely used user script (>2000 uses [4]), it seems an ideal candidate to become a gadget. If this becomes a gadget, I also propose replacing the content of User:Dr pda/prosesize.js to be mw.loader.load( ['ext.gadget.prosesize'] ), i.e to load the gadget directly so the old code no longer needs to be maintained. Galobtter (pingó mió) 07:31, 14 November 2019 (UTC)

If this becomes a gadget, I'd instead suggest changing User:Dr pda/prosesize.js to: if ( mw.user.options.get('gadget-prosesize') === null ) new mw.Api().saveOption('gadget-prosesize', '1'); instead, so that the gadget gets enabled directly rather than get loaded via the user js page; and Special:GadgetUsage would also show an accurate number of usages. SD0001 (talk) 08:07, 14 November 2019 (UTC)
That seems reasonable. Galobtter (pingó mió) 18:00, 14 November 2019 (UTC)
There is a typo at <small><i>(See <a href="//">here</a> for details.)<i></small>; should be a closing </i> there. Also, color me salty about mw.notify( 'Prosesize does not work with the Visual Editor.' );, but can't do anything about that on my part. --Izno (talk) 23:23, 14 November 2019 (UTC)
Thanks, fixed. Word count should at least be workable with VE (html size cannot be due to the differing html used by VE and the regular editor); it is my intention to get prosesize working with VE eventually but the last time I tried to deal with anything VE it went badly so I'll need to find the time to do it properly. Galobtter (pingó mió) 05:52, 15 November 2019 (UTC)
Highlighting in the new script seems busted. Also, there's a (somehow blue) link to Wikipedia:Prosesize, which is obviously wrong/missing something. Headbomb {t · c · p · b} 23:35, 14 November 2019 (UTC)
Headbomb, oops, the code for loading the css was broken. I haven't created the page yet, but Wikipedia:Prosesize would be the page describing the gadget. Galobtter (pingó mió) 05:47, 15 November 2019 (UTC)
@Galobtter: working now, thanks. Headbomb {t · c · p · b} 05:50, 15 November 2019 (UTC)

Too often I get this "Edit conflict: Talk - Someone else has changed this page since you started editing it, resulting in an edit conflict."[edit]

Whenever I help out editing an article or talk page, I nearly always get this notification "Edit conflict: Talk - Someone else has changed this page since you started editing it, resulting in an edit conflict." I've learned to live with it and work around it:

  1. copy/pasting my text and then hit the blue "Publish changes" button a second time; sometimes it then publishes my text;
  2. if it doesn't, I have my text in the copy/paste memory of my computer and can again paste my text and then hit the blue "Publish changes" button a 3rd time and then mostly my changes are finally in the article or talk page.

Anybody know's what's going on? Is it because I have too many observations and reversed edits by moderators? I really study the reasons in case my additions are not accepted, at times I don't agree and I find the - how are these wikipedians called - I think "arbiters" - extremely blunt - especially when I've put 10 minutes to an hour of editing and documenting an article or clearly stated I wanted to start an article and need to park it somewhere to continue it later because my kids of wife walks in and need my attention. Anyway - thy. --SvenAERTS (talk) 08:27, 14 November 2019 (UTC)

It often happens to me when I've spent time making a single substantial edit while other editors are making many small edits. So, where possible, the solution is to reduce the size of your edits: work by making many small edits rather than a few longer ones, then you're less likely to be interrupted in this way. Where this isn't possible, you just have to get round it as you say you do. Peter coxhead (talk) 10:16, 14 November 2019 (UTC)
What's happening is described at Help:Edit conflict. If you're planning on making a long edit, make a small edit first to add the {{inuse}} tag to the top of the page. Don't forget to remove it afterwards, though. Yunshui  10:30, 14 November 2019 (UTC)
@SvenAERTS: This edit suggests that you clicked Publish changes twice, perhaps inadvertently - I have a mouse that sometimes double-clicks when I intended a single click, because of contact bounce. --Redrose64 🌹 (talk) 21:21, 15 November 2019 (UTC)

Email this user[edit]

Is it possible to have "email this user" enabled on some projects but not on others? For example, to have it enabled here on en-wiki but off on Meta? Thanks, DuncanHill (talk) 11:03, 14 November 2019 (UTC)

If you want to remove the link from your own interface when you view a userspace page then you can add this to the local Special:MyPage/common.css:
#t-emailuser {display: none;}
If you want to disallow others to mail you then disable "Allow other users to email me" at the local Special:Preferences. This will remove the link for them. PrimeHunter (talk) 11:36, 14 November 2019 (UTC)
Thanks, it's the latter I was looking for. DuncanHill (talk) 11:40, 14 November 2019 (UTC)
Even better, it allows me to block specific users, which is probably better for my purposes at the moment. Thanks again, DuncanHill (talk) 11:42, 14 November 2019 (UTC)

Unbulleted lists in infoboxes[edit]

At Money (That's What I Want) the infobox's "Label" field is formatted as a horizontal list, exactly as though it used {{hlist}}, except that on mobile it's missing any demarcation at all between items. But it actually uses {{unbulleted list}}, which is supposed to format as a vertical unbulleted list. Compare the same infobox's "writer" field, which uses {{hlist}}. I have never seen this behaviour before and I am surprised to find a vertical list template formatting horizontally. It makes no difference if I replace it with {{plainlist}}. Is this an intentional change? It's certainly not wanted and neither is it documented anywhere I can see. Hairy Dude (talk) 00:20, 15 November 2019 (UTC)

Well it appears this particular infobox template ({{Infobox song}}) imposes the plainlist class. Perhaps that's what causes this strange behaviour? Hairy Dude (talk) 00:30, 15 November 2019 (UTC)

Some wikipedia articles lack all standard formatting[edit]

I've noticed recently that a number of WP articles -- for example, My Grandfather's Clock -- appear without any of the standardized formatting when accessed. Is this a deliberate deprecation of these articles, or are some wiki scripts not working? Clevelander96 (talk) 00:53, 15 November 2019 (UTC)

What do you mean by standardized formatting? --Izno (talk) 02:04, 15 November 2019 (UTC)
It looks normal to me. Try to bypass your cache, e.g. Ctrl+F5 in many Windows browsers. F5 alone does less and probably isn't enough for you. PrimeHunter (talk) 12:05, 15 November 2019 (UTC)
This sounds like Clevelander96 is experiencing an intermittent problem whereby their browser is unable to apply all of the intended styling to a Wikipedia page. Common effects include: content of top bar and sidebar appears as plain bulleted lists below the page content; all text is in browser's default serif font; images and other boxes appear inline instead of being floated to one side. There are a number of reasons that this happens, including: missing or corrupt style sheets; missing or corrupt JavaScript. The root causes may be: problems with the servers; problems with the browser itself; problems anywhere in between. The usual fixes are: (i) WP:BYPASS; (ii) wait a bit; (iii) WP:BYPASS again. --Redrose64 🌹 (talk) 21:16, 15 November 2019 (UTC)
I'm having the same trouble as Clevelander96, and have had this problem before. At that time it was recommended that I bypass and purge, both of which I did to no avail; the problem though resolved itself about a week later. Is there any third thought as to what might remedy this? — Fourthords | =Λ= | 23:04, 16 November 2019 (UTC)

How can I make a template return a table?[edit]

I must've tried all possible permutations, and also searched all around WP, to no avail. What am I doing wrong here? — Preceding unsigned comment added by Guarapiranga (talkcontribs) 01:25, 15 November 2019 (UTC)

 Sorted Thanks, PrimeHunter. Guarapiranga (talk) 02:09, 15 November 2019 (UTC)
(edit conflict) {{crlf}} just makes the html code <br/>. I made actual newlines so table code starts on a new line.[5] Some templates get around such MediaWiki requirements by outputting tables with html syntax: Help:Table#Other table syntax. PrimeHunter (talk) 02:10, 15 November 2019 (UTC)

Watchlist in the advanced mode[edit]

when I open the watchlist using the advanced mode in my phone, it takes 30-45 seconds for the filters box to appear. If I clicked on anything in the watchlist at that time I end up clicking on something else because when the filters box appear the whole list go down few centimetres. It's really annoying and I sometimes accidentally click on rollback.--SharabSalam (talk) 16:29, 15 November 2019 (UTC)

SharabSalam, either get a faster phone, or use the hide option in the topright of the filters and dont use them, or disable the entire feature in your preferences. —TheDJ (talkcontribs) 16:41, 15 November 2019 (UTC)
Since the watchlist got changed in the advanced mode (approximately 3 weeks ago) I stopped using the advanced mode but Wikipedia keeps asking me to try the advanced mode until one time I accidentally clicked on something and it changed to the advanced mode. I like the advanced mode but the watchlist has become so annoying. Anyway, I am just going to stop using the advanced mode I am already pissed off, I reverted someone comment in the talk page and then self-reverted and he sent me a warning.--SharabSalam (talk) 16:50, 15 November 2019 (UTC)

Searching Contribution history[edit]

Is there a way to show user contributions based on a keyword search of the edit summary? Would like to find all edits by User:GreenC bot that contain an edit summary of Add {{Cleanup bare URLs}} like this edit. Particularly interested in the size of the edit - GreenC bot had a rare bug and hunting for a large increase in article size, with these edits, going back to May. -- GreenC 22:26, 15 November 2019 (UTC)

Not through the Wikipedia interface. quarry:query/40110. Looks like you're after Special:Diff/915911382, Special:Diff/915552147, Special:Diff/911767914, and Special:Diff/909834784. —Cryptic 22:54, 15 November 2019 (UTC)
For the more general case, there's the edit summary search tool, linked from users' contribution pages. I don't think it works in this specific case though. Graham87 06:59, 16 November 2019 (UTC)
In the old days, like until three weeks ago, you would go to the user's contribs page and append ?limit=5000 to the URL, then use your browser's "Find" feature (often Ctrl+F). Since they busted it right down to 500 max, it now takes ten times as long to do the same thing. --Redrose64 🌹 (talk) 10:08, 16 November 2019 (UTC)
See phab:T234450 and feel free to comment there. — xaosflux Talk 14:40, 16 November 2019 (UTC)

Referencing queries[edit]

Firstly a specific problem. I have a very untidy External links reference * Paintings by William Oliver Williams at Art UK. On 30 October OxonAlex tidied a similar reference up by removing 2 spaces (it was something about getting everything on the same line). Could you indicate what he did?

Another query is that the scanning of books is becoming more common so that you get a reference that is a combination of a web and book source. You initially will use the web template but may also need to give details of the book (such as page numbers) that would be obtained using the book template in combination with the web site details. An example (probably done inadequately by me) is, [1]

Editors have kindly helped me out eg. improving this 'Oliver, William. "Royal Academy entries". Exhibitors at the RA' to this [2]

However, I can't rely on this help and need to do things for myself. Is there a standard procedure recommended? I presume there is not a template for these 'combination' sources? BFP1 (talk) 16:46, 16 November 2019 (UTC)


  1. ^ Ledger, Tanya. "A Study of the Arundel Society !848-1897. PhD thesis (!978) pp 45-50". University of Oxford, UK. Retrieved 16 November 2019.
  2. ^ Graves, Algernon (1906). The Royal Academy of Arts: A Complete Dictionary of Contributors and their Work from its Foundation in 1769 to 1904. London: H. Graves and co. p. 12 – via the Internet Archive.
In future, please don't place your "references" inside ref tags on talk pages. Just link to them. Bearcat (talk) 16:50, 16 November 2019 (UTC)
You can use {{cite thesis}} for a thesis and {{cite book}} for a book. Examples are given there; you can copy and adapt them for your use. The documentation is long, but it explains how to use each parameter. {{cite web}} is generally for sources that are available only on the web. – Jonesey95 (talk) 17:17, 16 November 2019 (UTC)

Categories on archived talk page[edit]

Talk:Albert Cashier/Archive 2 is inappropriately appearing in 12 articlespace categories that it's not supposed to be in. I'm able to determine that it relates to the "Implementing the RFC/Comparisons" section, which contains several instances of direct transclusion of the article side by side with a proposed rewrite — but unfortunately, I don't know how to fix it without breaking the entire section in the process, and the page can't just stay in articlespace categories. Can somebody figure out how to get the page out of the categories? Thanks. Bearcat (talk) 16:49, 16 November 2019 (UTC)

It seems a poor idea to transclude whole articles on talk pages and the drafts are deleted so the comparisons don't work but I have used {{Suppress categories}} instead of removing the transclusions.[6] PrimeHunter (talk) 17:10, 16 November 2019 (UTC)

Pageview Statistics for Bible[edit]

I posted this concern at the Help Desk, and was advised to come here.

I have been looking at page viewing statistics for some articles, and I would like to know if someone with knowledge could review the statistics for Bible. On 5 March 2019, it was 4326. Starting on 6 March 2019, I see 55,573 pageviews. By the way, that was Ash Wednesday. On 15 April 2019, I see 284,992 pageviews. That wasn't Easter, by the way. Easter was 21 April 2019, and was 256,054 pageviews. The pageview metrics drop off in May 2019, but then fluctuate between thousands of pageviews and hundreds of thousands of pageviews. How confident can we be that there really is a weirdly fluctuating demand for viewing of the Bible article? Comments?

User:Maproom said that they did not find the values after 5 March to be plausible.
I posted: Thank you, User:Maproom. Is there a trouble ticketing system, such as Phabricator, for reporting the issue? Robert McClenon (talk) 17:27, 13 November 2019 (UTC)
I could make some sort of philosophical joke about a use-mention distinction or the difference between the symbol and the thing symbolized, except that on a given day, the number of readers who read the Bible is not in the hundreds of thousands, but the hundreds of millions.
In the year 2018, the daily viewing metrics are: 3800 average daily pageviews , and I find them consistent with other commonly read articles.
In the year 2017, we see an average of 4177 daily pageviews, and I believe that.

I pinged a few other editors, and got a response from User:BrownHairedGirl.

Another editor at Help Desk commented: Comparison with other pages showing the view counter wasn't just broken or had changed. Don't see any major news coverage relating to the Bible spanning March/April 2019.

User:BrownHairedGirl wrote: Looks to me like there is something v weird going on with the 2019 figures.

I suggest raising this at WP:VPT, where there seems to be lots of knowledgeable technie people who in my experience respond quickly and helpfully to a well-constructed query on even obscure issues

I don't find the numbers beginning on 5 March 2019 to be plausible. They are anywhere from one to two orders of magnitude higher than previously, and higher than what I see for other reasonably well-viewed articles. Is there a trouble ticketing system that editors can use? Comments? Assistance? Robert McClenon (talk) 18:04, 16 November 2019 (UTC)

@MusikAnimal: poke --Izno (talk) 20:46, 16 November 2019 (UTC)
See toolforge:pageviews/faq/#anomaly. Comparing desktop and mobile-web, it's likely there was some sort of automated false traffic from March to May 2019. I'm not sure about the recent spike in mobile-web pageviews. If something really bizarre is going on you can always file a task on Phabricator, but I think the comparisons here offer the confirmation we need. The private data is also purged after 90 days so I don't think we could give any concrete explanations of the March-May spike. When in doubt, I usually refer to the mobile-app figures, which don't experience the same kind of anomalies and hence can help confirm if fluctuations in traffic are authentic. The parent task to improve bot detection is tracked at phab:T138207. Hope this helps, MusikAnimal talk 21:49, 16 November 2019 (UTC)

self-sufficient unlinked DAB page entries[edit]

Just now, editing Tashi delek#Origin and meaning, I noticed that the link on the word "Tashi" is orange, i.e., a link to a DAB page. Tashi redirects to Tashi (disambiguation), but the meaning intended here is that of the word "tashi" itself, which is defined on the first line of the page:

Tashi (Tibetan: བཀྲ་ཤིས་, Wylie: bkra-shis, ZYPY: zhaxi, Lhasa dialect: [ʈáɕiʔ]), also spelled trashi, is a Tibetan word meaning "good fortune" or "auspiciousness". Tashi or trashi may refer to:

I added {{anchor|word}} to the beginning of the line and changed the link in Tashi delek to [[Tashi#word|Tashi]], but it didn't help; see the diff.

Is there any solution for this problem? The link should not be flagged in orange as a DAB link, because it links specifically to the one entry on the page that does not lead to another page but contains the relevant content. Please {{Ping}} me to discuss. --Thnidu (talk) 19:17, 16 November 2019 (UTC)

Maybe link the word to Wiktionary instead, since all you want is a definition. (Although it looks like someone will need to create that page at Wiktionary first.) – Jonesey95 (talk) 20:30, 16 November 2019 (UTC)
@Thnidu: It's only orange because you enabled a script, probably "Display links to disambiguation pages in orange" at Special:Preferences#mw-prefsection-gadgets. Normal readers don't see the color. If the disambiguation page is intentionally linked then the link should go via the redirect Tashi (disambiguation) per WP:INTDAB. This will also remove the orange. But the intention of the link here is not what disambiguation pages are for. PrimeHunter (talk) 21:00, 16 November 2019 (UTC)

What would cause the enwp UI to disappear?[edit]


For reasons beyond my understanding, random pages are rendering for me without the enwp UI, even when other pages are fine. Does anybody have an idea as to what's happening? I'm using Safari 13.0.3 on macOS 10.15.1 on a MacBookAir6,1. Thanks! (I had a similar problem that I asked about here, but it eventually resolved itself.) — Fourthords | =Λ= | 21:49, 16 November 2019 (UTC)

@Fourthords: see my reply at #Some wikipedia articles lack all standard formatting. --Redrose64 🌹 (talk) 22:44, 16 November 2019 (UTC)
Thanks, I'll reply up there. — Fourthords | =Λ= | 23:01, 16 November 2019 (UTC)