Wikipedia:Village pump (technical)

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

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

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

Multiple DISPLAYTITLEs on a page

Pls see ISmart Shankar. The {{Infobox film}} causes title to render in italics. But it is also desired that first letter should be in lowercase. Adding {{DISPLAYTITLE:<i>iSmart Shankar<i>}} anywhere on the page after infobox film (otherwise it gets overridden) does the trick. But it leaves behind an ugly red warning message on the page about the overriding DISPLAYTITLEs. Any way to suppress that? SD0001 (talk) 10:37, 1 June 2019 (UTC)

Is it right now? I think |italic title=no in the infobox was the trick, then {{DISPLAYTITLE:<i>iSmart Shankar<i>}} seems to work ok at the top. -- Begoon 10:49, 1 June 2019 (UTC)
@SD0001 and Begoon: Why do people keep asking this when the answer is right there to be seen? Specifically, in the documentation for {{Infobox film}}, there is a box beginning "This infobox should italicize the article title automatically". --Redrose64 🌹 (talk) 21:24, 1 June 2019 (UTC)
Redrose64, I don't understand your point. The OP knew that - he said "the {{Infobox film}} causes title to render in italics." - but it uses DISPLAYTITLE to accomplish that, and when the OP tried to also use DISPLAYTITLE to have a lowercase initial 'i', there was a 'clash' of two DISPLAYTITLEs and the software threw an error. The only thing the OP could have found out "right there in the documentation" was that the thing to do here was to use |italic title=no to turn off the behaviour, and it's not unreasonable that they missed that, or, indeed, failed to consider it as a somewhat counter-intuitive 'workaround' solution - since turning off italic display wasn't their intention. I genuinely don't see the need for your exasperation. -- Begoon 22:31, 1 June 2019 (UTC)
If Infobox film wants to mess with the display title, it should include more parameters for formatting it. — xaosflux Talk 22:34, 1 June 2019 (UTC)
I don't disagree with that, but glancing at the source I think it might be the underlying Infobox template/module that actually makes the italic title when Infobox film requests it - maybe it doesn't actually use {{DISPLAYTITLE}} or the magic word per se, but whatever it does clashes with subsequent use of it and throws the ugly red error/warning the OP describes (even though it still "works" in the sense that the displayed title is changed) - I've seen it cause confusion before, which was the only reason I knew about |italic title=no to disable the behaviour, without trawling the doc pages. -- Begoon 22:40, 1 June 2019 (UTC)
Thanks Begoon for sorting it out. I feel that such warnings should only be shown on preview, as readers clearly shouldn't be worried by it. Someone should file a phab ticket on this. SD0001 (talk) 05:33, 2 June 2019 (UTC)
Well, not everybody previews (they should, but they don't), and on this occasion the 'warning' was annoying because the intended result was obtained, so it seemed spurious. That doesn't mean that sometimes, in another situation, the 'warning' isn't potentially invoked because the rendering has failed to work as intended. I agree it's annoying and messy, though - perhaps, as Xaosflux suggests there are ways to improve the template in this respect - one that springs to mind is some sort of 'DISPLAYTITLE override' parameter, where you can just plug in whatever you want the infobox to do to the title rather than its default of solely italicising - but even that would rely on users knowing that the option existed, and might, I guess, 'encourage' some 'unfortunate looking experiments' with titles - which could, I suppose, be a good argument against doing it that way... Since the use-case here - having a lowercase initial character - is actually the most common reason I can think of to 'override' the current simple italic behaviour, maybe just providing a parameter for that would solve most 'issues'? -- Begoon 05:42, 2 June 2019 (UTC)
The warning is made by MediaWiki:Duplicate-displaytitle. I have added [1] a help link and mentioned [2] the probably most common solution there: "Many infoboxes have the option |italic title = no or |italic_title = no to omit an automatic display title." The reported example was [3]. PrimeHunter (talk) 08:38, 2 June 2019 (UTC)
Just as an amusing postscript, several days after this issue had been 'fixed' by adding |italic title=no to {{Infobox film}}, it was 'broken' again when someone added {{Infobox album}} as a second infobox, for the soundtrack. This needed an additional |italic_title=no (with the underscore) in the second infobox to 'fix' which I spotted on my watchlist, but only a day later, despite the 'enhanced' warning and several intervening edits... -- Begoon 10:12, 9 June 2019 (UTC)
MediaWiki:Duplicate-displaytitle adds Category:Pages with DISPLAYTITLE conflicts. It has no articles currently so I guess somebody is checking the category periodically and fixing articles. It gets at least one page view every few days.[4] PrimeHunter (talk) 09:10, 11 June 2019 (UTC)


Considering the above template, can anybody provide any further assistance with this issue? Thanks in advance. Greetings--Hildeoc (talk) 20:20, 4 June 2019 (UTC)

You asked that question again a fortnight later. You did not respond to the reply that you got. Why? Why have you not asked your question at the template's talk page as was suggested in the helpdesk posting that you linked?
— (talk) 20:45, 4 June 2019 (UTC)
@: I'm sorry – you're definitely right. I just thought I wouldn't get an answer if I asked on the template talk. But now I'll try in a sec. Best wishes--Hildeoc (talk) 21:39, 8 June 2019 (UTC)
Now done.--Hildeoc (talk) 21:42, 8 June 2019 (UTC)

Editing formatting bar break code

Currently, when editing the source text (i.e. not the visual editor), under the "advanced" formatting tab there is a button to insert a line break, which inserts the code <br>. As discussed at WP:LINEBREAK, this can break several of the available syntax highlighters for wikicode in the editing view (mis-highlighting all text in the page after the occurrence of that tag), and so should be avoided. Is it possible to change the interface so it inserts <br /> instead? (I apologize if I'm not using the right vocuablary.) (talk) 21:00, 4 June 2019 (UTC)

, if a syntaxhighlighter cannot handle a simple br tag, it's broken and shouldn't be used. —TheDJ (talk • contribs) 23:13, 4 June 2019 (UTC)
@TheDJ: Okay, new topic: The built-in Wikipedia syntax highlighter available through the user preferences/gadgets menu is broken and shouldn't be used.
If <br /> is the recommended output, why stick with the less-preferred one? (talk) 23:40, 4 June 2019 (UTC)
Gadgets are not official. They are maintained entirely by volunteers. --Izno (talk) 00:05, 5 June 2019 (UTC)
This is a long-standing known issue with the syntax highlighter, and there are periodic fruitless arguments about it on this page. Since the MW parser outputs <br />, and that form allows the syntax highlighter to help editors find and fix other syntax problems, it seems to me that the least bad option is to insert <br /> as the preferred option. I can find only one Phabricator task that relates to br tags and syntax highlighting (linked at the right side of this section), but I'm pretty sure I have seen others. – Jonesey95 (talk) 08:30, 5 June 2019 (UTC)
The button used to insert <br />, but this was changed by TheDJ in T150172. Perhelion argued at the time that <br /> should be replaced because HTML5 prefers <br>. However, <br /> is valid HTML5, and the MediaWiki parser will convert <br> to <br />. From what I can see, there's two options: go full-on <br>, which includes changing the parser, fixing the syntax highlighters, and changing the advice on WP:LINEBREAK, or go full-on <br />, which only needs a revert of that change by TheDJ. I'm in favour of the latter. Opinions? (also pinging , who commented on that phab task.) rchard2scout (talk) 11:01, 5 June 2019 (UTC)
Rchard2scout It just doesn't matter that much, unless you are the type of person that cares about adding or removing spaces between heading syntax and the heading content... Fruitless arguments indeed. Harmonisation of the wikicode is NOT needed here and a waste of editor time. Tools should be able to handle both, both are allowed wikicode, both are allowed in html5, one is better xml, the other better html5. I personally don't see the need for either wikEd or Remember theDots syntaxhighligh lib. Neither are used by more than a couple of people in the grant scope of things. And confusing users with documentation on details of line break syntax.. really.. who reads that and comes away with any level of understanding ?? A line break is <br> done. —TheDJ (talk • contribs) 13:26, 5 June 2019 (UTC)
Interesting support, with details, for <br> from a dev: diff "...<br> is valid wikitext...". I support that view—simple is good and changing wikitext to insert a space and a slash is pointless and confusing for onlookers. Johnuniq (talk) 00:25, 6 June 2019 (UTC)
Alright, TheDJ's arguments and Tim Starling's explanation have me convinced. One interesting quote from that reply by Tim: RemexHtml "will initially output "<br />" for compatibility with parser tests", which means it could be changed in the future, and we really shouldn't base our decisions about wikitext on the HTML output it generates. Let's not fix things that ain't broken, and those who care about syntax highlighting gadgets should fix their syntax highlighting gadgets. rchard2scout (talk) 19:08, 6 June 2019 (UTC)

Just so you know, the space in <br /> is entirely optional (personally I think <br/> looks better without the space). <br> without the slash is in no way "better" HTML5. The main reason why I don't want to support <br> in the syntax highlighter is because it's confusing to have some tags be automatically closing while other tags like <references/> require the slash. Also, I don't want to have to maintain an ever-growing list of automatically-closing tags. —Remember the dot (talk) 00:34, 9 June 2019 (UTC)

In HTML, the only valid self-closing tags are the void elements, and in fact any self-closed tag in the list of all valid HTML tags not present in the list of void elements is an error (e.g. <span/>). So, you probably should also not support the invalid HTML (except where appearing inside of e.g. <pre>). In the list there, only a couple of those appear as wikitext (though <source> has different semantics in wikitext). That list basically hasn't changed since HTML 4. So...
As for confusion, there's nothing you can do about that--some tags will be self-closing in some situations, and we've introduced a few others to wikitext (e.g. <section> for section transclusion), and some tags will never be self-closing, as is the case for that vast majority of the HTML tags you can write in wikitext (<code>, <div>... and just about every other). What's actually confusing is when a maintained gadget breaks on valid wikitext and then we get discussions like this one.... --Izno (talk) 02:29, 9 June 2019 (UTC)
Sure there's something we can do about that: Deprecate the use of <br> without the slash (maybe show a warning if the non-slashed version is used) and stop considering it "valid" wikitext. It's just not a popular solution because people insist that requiring the slash on tags like <references/> and <section/> but not on <br> and <hr> is somehow more straightforward. —Remember the dot (talk) 06:41, 9 June 2019 (UTC)
The reason it's unpopular is because it's valid HTML, which enjoys a consensus your gadget does not. Right now both of the WMF-sanctioned highlighters (one in the 2017 WTE and the other in the 2010) work just fine (if more-simply in other aspects). A whitelist/blacklist on your part is not hard to maintain once initially implemented and could even be maintained by another editor if you are disinterested. --Izno (talk) 15:50, 9 June 2019 (UTC)
HTML5 made everything "valid", including <p> and <div> tags without accompanying </p> and </div>. This syntax cannot be supported in the syntax highlighter without major detriment to its performance. Nevertheless, you are welcome to get permission to move mw:User:Remember the dot/Syntax highlighter and mw:User:Remember the dot/Syntax highlighter.js out of the User namespace, edit them based on community consensus, update mw:MediaWiki:Gadget-DotsSyntaxHighlighter.js to match, and continue to maintain the shared fork by adding new translations etc. If you implement automatically-closing tags nicely--with a voidTags config parameter analogous to nowikiTags and sourceTags--I won't revert it. Considering how strongly people seem to feel about this, I'm surprised that no one has done that already. —Remember the dot (talk) 20:36, 9 June 2019 (UTC)
No, the </p> tag has never been required until recently (it wasn't mentioned in HTML 1, was implicitly optional in HTML 2.0, explicitly optional in HTML 3.2 and HTML 4, and became conditionally optional in HTML 5); whereas the </div> tag has always been mandatory (HTML 3.2, HTML 4 and HTML5 spec). --Redrose64 🌹 (talk) 22:50, 9 June 2019 (UTC)
Oh interesting. Thanks for pointing out that HTML5 doesn't deserve all the blame for implicit </p> tags and implicit </div> is still technically forbidden. However, the fact remains that the syntax highlighter wouldn't be able to support implicit </p> without major, performance-killing modifications. —Remember the dot (talk) 23:20, 9 June 2019 (UTC)
Between HTML 4 and 5, there were some iterations of XHTML. Closing tags (or self-closing where no content) were required for everything including <p>...</p>, <hr/>, etc., so that it would validate as proper XML. The space before the slash was an optional but recommended kludge to keep earlier parsers happy (It's valid SGML, and HTML4 parsers would see the slash as an invalid attribute). As mentioned above, <references/> isn't any kind of (X)HTML, it's XHTML-inspired wikicode (and well-formed XML).
When I view HTML source on a Wikipedia page as delivered to the browser, the <p>...</p> tags are paired not naked. If MediaWiki hasen't turned that on its head to go fully down the HTML5 rabbit-hole, then I say our tools should keep inserting XHTML-compatible <br />. The instant counter-argument is that MW emits <!DOCTYPE html>. Sigh. (Although there's an HTML5-style doctype, does MediaWiki create anything else that's not good XML?)
Anybody know what Visual Editor inserts for br?
Pelagic (talk) 09:17, 16 June 2019 (UTC)
Yes, I forgot about XHTML 1.0. That was essentially HTML 4.01 with a few extensions and a much tighter syntax: there were no optional tags; tag and attribute names had to be lowercase; all attribute values had to be quoted; etc. But XHTML was more of an offshoot from the main route, rather than a step in the progression. --Redrose64 🌹 (talk) 10:35, 16 June 2019 (UTC)
The latest HTML5 spec states "This specification defines an abstract language for describing documents and applications...There are various concrete syntaxes that can be used to transmit resources that use this abstract language, two of which are defined in this specification...The first such concrete syntax is the HTML syntax...The second concrete syntax is the XHTML syntax...This specification defines the latest version of the XHTML syntax, known simply as 'XHTML'." So no, XHTML was not a temporary deviation from the main route; HTML and XHTML continue in parallel as equivalent syntaxes for representing essentially the same content. —Remember the dot (talk) 14:30, 16 June 2019 (UTC)

KISS. Keep It Simple, Stupid. KISS principle. I use <br> all the time on wikis outside Wikipedia. Don't f*ck it up by requiring the use of <br /> in wikitext editing in the MediaWiki software. And you notice how <br /> with the space can wrap to 2 lines in the wikitext. Yet more confusion. <br> is simpler than </br> too. Or <br/>. People forget where to put the slashes for all of these tags. I still do sometimes. -- Timeshifter (talk) 09:29, 9 June 2019 (UTC)

If MediaWiki required <references> and <section> instead of <references /> and <section />, I would agree with you. However, requiring the slash on some tags but not others, or leaving it up to the whim of the author, is not KISS. The default "tag soup" serialization of HTML5 is in fact the antithesis of the KISS principle. —Remember the dot (talk) 20:36, 9 June 2019 (UTC)
I agree, Remember the dot. If the core software is XML-compatible, then the add-ons, toolbars, templates, etc. should be also. If we can output code that works in HTML5 and XHTML, then why not? Pelagic (talk) 09:17, 16 June 2019 (UTC)

By the way, if the network connection is fast enough, it's actually faster to send data uncompressed than to send it in a compressed format and then decompress it on the receiving end. For the same reason, 10 or 20 years from now I suspect XHTML5 will surge in popularity because it puts so much less strain on the CPU. —Remember the dot (talk) 20:54, 9 June 2019 (UTC)

Definitely not, with thinner and thinner fab processes, devices will be more efficient and more powerful as well (a reminder that we have AI/ML on our smartphones now). You're right about the first point as we are approach higher bandwidths, but not so much about the second, the end winners are going to be JavaScript and Python as resource-hunger becomes less and less of an issue and everyone wants a scripting language to just do anything, no doubt. --qedk (tc) 14:41, 16 June 2019 (UTC)
Intel has been trying for years to go from a 14 nanometer process to a 10 nanometer process and still hasn't succeeded in mass-producing 10nm chips. Silicon atoms are only 0.2nm in diameter, so 10nm means lithography that is 50 atoms wide. At some point in the near future, we just won't be able to go any smaller and unless someone discovers a better semiconductor than silicon, we will be at the limit of single-thread general-purpose CPU performance. The bottom line is that we can't rely on CPUs getting faster any more; instead we are compelled to write more efficient software. You can already see the effects of this shift in the increasing popularity of C and C++ and the emergence of new compiled languages like Cython, Go, and Rust, as well as interest in binary (non-textual) data formats such as BSON and Protocol Buffers. —Remember the dot (talk) 15:08, 16 June 2019 (UTC)
Oh and how could I forget WebAssembly, which is basically a compiled version of JavaScript? —Remember the dot (talk) 15:13, 16 June 2019 (UTC)
And of course, massively-parallel hardware (and software that must adapt to that) —PaleoNeonate – 15:16, 16 June 2019 (UTC)
TSMC and Samsung are already mass-producing 7nm, whether Intel catches up is irrelevant. And just to remind you, in terms of stats, JavaScript and Python are the only languages to not lose out in the TIOBE index rankings (Python is the largest gainer) and both of them are now on the top of StackOverflow stats, with JS leading in terms of numbers and Python in terms of growth of the numbers. ...instead we are compelled to write more efficient software, this statement was probably true in the conventional times but now we are moving at a different pace and maybe this statement will come to fruit in the later part of the next decade but not earlier than that. --qedk (tc) 15:34, 16 June 2019 (UTC)

Talk pages bolded in diff view

When viewing diffs using the default viewer (e.g. [5]), the "talk" link now appears in bold – will there be a way to toggle this (or will this now be a new default behavior)? Mélencron (talk) 19:02, 5 June 2019 (UTC)

This seems to be caused by Twinkle, if I disable it the link is no longer bold. the wub "?!" 19:49, 5 June 2019 (UTC)
I've asked over at Wikipedia_talk:Twinkle#Bold_talk_links_on_diff_pages? if this is intentional or a bug. the wub "?!" 19:53, 5 June 2019 (UTC)
Yes, this is from Twinkle and it was intentional, although perhaps not desirable? User talk links on diffs will now include a parameter to fill in the article should you wish to issue the user a warning, similar to what Twinkle has done for years with the success page after the built-in mediawiki rollback. The intent was to signify some level of difference for those links for users reverting/rollbacking edits. It can, of course, be unbolded if folks find it unhelpful. ~ Amory (ut • c) 20:12, 5 June 2019 (UTC)
I do a lot of browsing in diff mode from watchlist--I think the bold is overkill for my use case. --Izno (talk) 20:23, 5 June 2019 (UTC)
I concur with Izno. I would prefer if it remains unbolded even though I like the new functionality and thank those who worked on it.. – Ammarpad (talk) 04:25, 6 June 2019 (UTC)
+1, I'd also rather not have it bolded. Twinkle already adds a lot of coloring and brightening to diffs, and yet another bolding seems to be a bit of an overkill. — Mike Novikoff 08:05, 6 June 2019 (UTC)
I'd rather not have it bolded, as because of my copyright cleanup work I appreciate being able to tell at a glance whose talk page I have visited before, to speed up my work. — Diannaa 🍁 (talk) 21:51, 6 June 2019 (UTC)
Is there some way I can shut off the bolding? It's getting in the way of my work. Thanks, — Diannaa 🍁 (talk) 14:08, 8 June 2019 (UTC)
Update: Here is the code to shut if off: Add { font-weight: normal !important; } to your common.css. Thanks to SD0001 for this patch — Diannaa 🍁 (talk) 15:44, 8 June 2019 (UTC)
Pretty resoundingly undesired, so I've turned it off. Thanks for feedback, folks! ~ Amory (ut • c) 00:42, 9 June 2019 (UTC)

Twinkle user warning dialog

Some changes were made to Twinkle yesterday. Does anyone else find the user warning dialog to be unintuitive? For some reason, items are listed by the template name.- MrX 🖋 13:05, 6 June 2019 (UTC)

The only thing that's changed (with respect to your thread) is the addition of a search dialog, which is good! Items were already ordered in alphabetical manner, by template name. --qedk (t c) 09:50, 9 June 2019 (UTC)

chem quirks

How to type things like "t-Bu" using the <chem> tag?

According to mhchem, it should be something like $t${-}Bu, using $...$ for italics and {-} to indicate that the hyphen is really a hyphen (instead of a bond).

In the present-day <chem>:

$t${-}Bu produces (very wrong),
\mathit{t}{-}Bu produces (italic t, but {-} still makes a bond),
\mathit{t}\text{-}Bu produces (how?!),
\mathit{t}\text-Bu produces a syntax error.

Is there any reasonable way to get hyphens inside <chem>? The question is not about workarounds for this particular case, but about the general approach that will work in more complex examples, like "[t-Bu]2O" over a reaction arrow inside <chem>. — Mikhail Ryazanov (talk) 03:22, 7 June 2019 (UTC)

Have you looked at {{Chem}}? It might work for you. – Jonesey95 (talk) 04:58, 7 June 2019 (UTC)
{{Chem}} only helps to make some lower and upper indices, so it is of no use here. Especially for "more complex examples, like '[t-Bu]2O' over a reaction arrow". — Mikhail Ryazanov (talk) 19:13, 7 June 2019 (UTC)
According to Help:Displaying a formula#Chemistry, <chem>X</chem> is just shorthand for <math chem>\ce{X}</math>. This makes it possible to not have everything in the \ce tag. The next problem is that everything in <math> is in LaTeX math mode, which doesn't have a hyphen, only a minus sign. I played around a little and put together <math chem>t\textrm{-}\ce{Bu}</math>, which produces . Would something like that work for you? --rchard2scout (talk) 22:10, 7 June 2019 (UTC)
Partially, thanks. Now the question is how to make "[t-Bu]2O"? Unmatched ] inside \ce{} produces a TeX parse error. (I've also noticed that <chem>\textrm-</chem> does not fail like <chem>\text-</chem>, but yields . Where does it get these braces?!) — Mikhail Ryazanov (talk) 22:47, 7 June 2019 (UTC)
@Physikerwelt: Maybe you might have an interest in this discussion (both to advise on deprecated tags and perhaps provide a solution). --Izno (talk) 02:51, 9 June 2019 (UTC)

Detect calling template

Say I have sub-template X, that is used in templates A and B. Is there any way I can code X so that it can detect whether it's being called by A or by B? - X201 (talk) 13:44, 7 June 2019 (UTC)

If X is a Lua module, you can use frame:getParent():getTitle(). Galobtter (pingó mió) 13:50, 7 June 2019 (UTC)
Unfortunately it's not LUA. But useful to know it can be done in LUA if needed. - X201 (talk) 14:06, 7 June 2019 (UTC)
A and B can pass a keyword to X to identify themselves:
from A: {{X|_tid=A|...}}
from B: {{X|_tid=B|...}}
in X: {{#ifeq:{{{_tid|}}}|A|...}} etc.
— (talk) 14:22, 7 June 2019 (UTC)
Thanks for that. - X201 (talk) 18:33, 9 June 2019 (UTC)



Cross-posting this from User talk:mxn#User:Mxn/CommentsInLocalTime since I haven't heard back. Maybe someone here can help.

I happened to come across this, and I love it. I'm just wondering if there are some further customization things I can do.

  • Instead of "Last [Day]", is it possible to just have "[Day]"? So instead of Last Wednesday at 10:00 PM, just Wednesday at 10:00 PM.
  • Change the date format to have the month come before the day: May 29, 2019 at 10:00 PM instead of 29 May 2019 at 10:00 PM  Resolved
  • Completely disable the hover tooltip

Thanks in advance for your time. Add: Here is my page, for reference: User:Amaury/common.js. Amaury • 04:44, 7 June 2019 (UTC)

Amaury () 16:21, 8 June 2019 (UTC)

Without "Last": you probably can change that through one of these: moment().calendar(referenceTime, formats), moment.updateLocale/moment.locale/[6] or moment.calendarFormat
Disable tooltips - assign to tooltipFormats value of null (or empty string '') (tooltipFormats: null), or remove tooltipFormats from configuration entirely (insert delete window.LocalComments.tooltipFormats before window.LocalComments = $.extend(window.LocalComments,... line). It may produce an empty tooltip though (tooltip is inserted as title attribute in <time> tag). MarMi wiki (talk) 19:57, 8 June 2019 (UTC)
@MarMi wiki: tooltipFormats: null removes the tooltip, but still leaves the dotted underline with the question mark when hovering over it. Any way to remove that? As for removing the "last," I am not understanding what I need or what to do. Amaury () 02:30, 9 June 2019 (UTC)
@Amaury: It's like that:
//this can be moved before importScript
window.LocalComments = $.extend(window.LocalComments, {
	formats: {
		day: function (then) { return then.calendar(); },
		week: function (then) { return then.calendar(); },
		other: "MMMM D, YYYY [at] h:mm A",
	tooltipFormats: null

//load moment
$.when(mw.loader.using('moment')).then( function(){
 moment.updateLocale('en', {
	calendar : {
     lastWeek: 'dddd'
 //load script - it must run (not necessarily, see note below) after moment.updateLocale
 importScript( 'User:Mxn/CommentsInLocalTime.js' ); // Backlink: [[User:Mxn/CommentsInLocalTime.js]]
 //in case importScript fail (in tests I was using loader) 
 //mw.loader.load( '//' );
 //if script is loaded before moment.updateLocale, you probably could re-initialize (update) the output by manually calling the two methods which script runs after loading moment (code in loader at the bottom in CommentsInLocalTime.js) - but this may duplicate the timestamps.

//set text-decoration and cursor to initial values
$.when(mw.loader.using('mediawiki.util')).then( function(){
 //you can place the css (between '') in your <s>custom</s> common.css instead here
 mw.util.addCSS('time.localcomments.explain[title] {text-decoration: initial;cursor: initial;}')
@MarMi wiki: Thanks, but mxn has responded and provided a much simpler solution to that on their talk page. Amaury () 01:15, 10 June 2019 (UTC)

Portal:Washington (state)

Hi there. The portal to the US state of Washington seems a bit wonky. I see that User:UnitedStatesian changed the portal name, but link on the city articles in the US state lead to Portal:Washington. When I changed the name of the link to the state portal, it looked weird. Thanks! Magnolia677 (talk) 20:01, 8 June 2019 (UTC)

Which pages are these? --Redrose64 🌹 (talk) 22:32, 8 June 2019 (UTC)
I think it is every page that uses {{portal}} or {{Portal-inline}} to call Portal:Washington instead of Portal:Washington (state); Olympia, Washington is an example. Guess I need to install JWB this week to fix it. UnitedStatesian (talk) 00:34, 9 June 2019 (UTC)
@Magnolia677: Weird how? Do you not want the (state) disambiguator in the portal link? GUYWAN ( t · c ) 16:48, 10 June 2019 (UTC)
@Guywan: This would be confusing to readers. When a reader is at Olympia, Washington and they are given an option to view a portal, they obviously want the portal for Washington state, not the city 2000 miles away that shares the same name. At Gibson, Georgia the portal leads to Portal:Georgia (U.S. state), not to Portal:Georgia (country). Thank you. Magnolia677 (talk) 20:47, 10 June 2019 (UTC)
@Magnolia677: I'm not sure if that's a yes or a no. Does replacing {{Portal|Washington}} with {{Portal|Washington (state)}} or {{Portal|State of Washington}} not satisfy you? GUYWAN ( t · c ) 21:46, 10 June 2019 (UTC)
@Guywan: "I'm not sure if that's a yes or a no".
  • It's a no.
Regarding the portals:

Issue - Edit summary, smaller popups

Greetings, I noticed today that when filling in Edit summary the "remembered" popups are now a much smaller size. Visually, more difficult to read. Is it possible to "Undo" this change? Regards, JoeHebda (talk) 13:25, 10 June 2019 (UTC)

@JoeHebda: That's a browser thing, certainly. Nothing to do with Wikipedia. Regards, GUYWAN ( t · c ) 16:19, 10 June 2019 (UTC)
@Guywan: Sometime between late Saturday and this morning the change "happened" with no browser update on my laptop. Wondering if there is a Vector CSS that I can do to override? To make larger size. JoeHebda (talk) 17:17, 10 June 2019 (UTC)
JoeHebda, What browser are you using? Since the dropdown is provided by the browser, it cannot be modified by user css. Galobtter (pingó mió) 17:34, 10 June 2019 (UTC)
Galobtter - Using a Chrome-based browser (Viasat, Version 74.0.3729.23547). Laptop is Win7 Pro, 64-bit OS if that makes a diff. JoeHebda (talk) 17:42, 10 June 2019 (UTC)

Tech News: 2019-24

17:06, 10 June 2019 (UTC)

Page permanently stuck and unreadable after a move.

Can anyone help? Earlier today, Megalibrarygirl userfied Chyanne Dennis but accidentally moved it to instead of the intended target, User:Hmlarson/Chyanne Dennis. Now, attempting to view the page brings up:

MediaWiki internal error.

Original exception: [XP6fwwpAICwAAGatqbAAAAAT] 2019-06-10 18:21:55: Fatal exception of type "Wikimedia\Assert\ParameterAssertionException"

Exception caught inside exception handler.

Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information.

There doesn't seem to be any way of accessing the page or moving it back, and going to the original article has no history, because that got moved across. Are we up the tata without a tutu? Ritchie333 (talk) (cont) 18:23, 10 June 2019 (UTC)

I've moved it. Is that OK? No idea what happened there. -- zzuuzz (talk) 18:32, 10 June 2019 (UTC)
@Ritchie333: Very interesting. This seems to be caused by _/ ("_" is a URL space.) Try for example. GUYWAN ( t · c ) 18:35, 10 June 2019 (UTC)
Only seems to affect the User namespace. GUYWAN ( t · c ) 19:00, 10 June 2019 (UTC)
@Ritchie333, Guywan, and Zzuuzz: Thank you so much! I'm good at finding bugs. :P Megalibrarygirl (talk) 19:07, 10 June 2019 (UTC)
So how come zzuuzz managed to move it? Ritchie333 (talk) (cont) 19:20, 10 June 2019 (UTC)
Skillz. No seriously, it looked fine, and it moved fine. I didn't try anything unusual (for me). I did wonder for a moment when moving the page if there was some weird unicode character mixed in to the old title (in front of the H), but I'm not convinced. -- zzuuzz (talk) 19:38, 10 June 2019 (UTC)
phab:T200055 looks related. Galobtter (pingó mió) 19:30, 10 June 2019 (UTC)
I've created User:Galobtter_/sandbox4 by moving User:Galobtter/sandbox4 (and back by directly using Special:MovePage/User:Galobtter_/sandbox4), which interestingly works as a redirect but not when "?redirect=no" is set. Galobtter (pingó mió) 19:33, 10 June 2019 (UTC)

Truncation of watchlist on mobile

The "List" tab on mobile shows only articles. Other page types are not shown. I have to switch to desktop view to see them. Jmar67 (talk) 06:42, 11 June 2019 (UTC)

It's also limited to mainspace at Commons where mw:Manual:$wgContentNamespaces includes files. That means only shows gallery pages and not files. If you don't watch any galleries then it says "You are not currently watching any pages." PrimeHunter (talk) 07:52, 11 June 2019 (UTC)
I found phab:T220678: On mobile view of Wikimedia Commons, uploaded files are not listed on watchlist as "Pages". It's apparently the same for all wikis. The title only mentions a request to include files in "Pages" under the "Modified" button. Maybe that's why there is no response in two months. The limited "List" button is mentioned in the description. PrimeHunter (talk) 08:11, 11 June 2019 (UTC)

Global links to website

Hi Village Pump,

I'm hoping you can help me. Last year I contacted an outside company (with help from WP:LIBRARY), to give me access to their paywalled site They were great about it. I wanted to feed back to the owner on the amount of links that I have used this resource for in this time. Is this possible? I can give a ballpark value by seeing how many times I have used the {{AZB}} template (which generates an external link), but I'd also like to see how many times the website has been linked by myself in references (and overall on wikipedia in the timescale). Is it possible to run a search for the amount of times a website has been linked on wikipedia A. By a user, and B. in a certain timescale?

It's an odd request, but I'd really like to feed back and show that the continued support of the project is indeed providing extra links for the website. Best Wishes, Lee Vilenski (talk • contribs) 08:15, 11 June 2019 (UTC)

Special:LinkSearch/ shows all current links from one wiki. See Help:Linksearch. PrimeHunter (talk) 09:15, 11 June 2019 (UTC)
Special:Search/insource:"azbilliards" and/or Special:Search/insource:"azbilliards" insource:/azbilliards\.com/ is generally superior as it doesn't care about the scheme of the URL. Neither method will say when it was added. The way you'd get historical is for someone to download a dump of the articles from around the time you started, do the same search, and then just subtract. --Izno (talk) 13:05, 11 June 2019 (UTC)
That said, maybe User:Whatamidoing (WMF) has an answer or can poke the person who does, since I know that WMF has been working on this kind of problem for GLAM. --Izno (talk) 13:11, 11 June 2019 (UTC)
Thanks! I'll report back to the owner. Best Wishes, Lee Vilenski (talk • contribs) 14:37, 11 June 2019 (UTC)

PetScan down

PetScan is currently reporting "502 Bad Gateway". The issue has been reported at but I'm not convinced a service problem will get prompt attention there. Can anyone watching here help? William Avery (talk) 09:08, 11 June 2019 (UTC)

It's working OK again now. William Avery (talk) 10:53, 11 June 2019 (UTC)

What determines the 'suggested languages' in the interwiki links?

Suggested languages on Wikipedia.png

On the interlanguage links in the sidebar, I have mine personally set to display all of the languages. When I am logged out, however, most of the links are collapsed, and when I click the "more" button, there are two (and only two) "suggested" languages at the top, the two are always the same, regardless of the subject of the article in question, it displays the same way on several PCs/browsers I have tested, why is this the case? - CHAMPION (talk) (contributions) (logs) 10:14, 11 June 2019 (UTC)

The collapsed interlanguage links are controlled by an extension named "Universial Language Selector". The list of languages are not based on the subject, but both your language and the language of the wiki, which is expanded further into other languages users of said interface language are likely to know. If those are less than 7, then the largest languages (in terms of speakers) are added as well.
Specifically, those languages which users are likely to know are based on the language fallback list, which is a list of languages which are used if translations of wikipedia's software are not available in that language. By your language I mean your babel box on your user page and the interface language of your browser.--Snaevar (talk) 11:27, 11 June 2019 (UTC)
Your geolocation is also factored. I don't think user babel box affect the result in anyway. – Ammarpad (talk) 11:43, 11 June 2019 (UTC)
This may be mw:Universal Language Selector/Compact Language Links#How do you decide which languages are shown to me in the initial compact list?. --Redrose64 🌹 (talk) 16:03, 11 June 2019 (UTC)
I am not talking about the initial list, but rather the "suggested" languages after you click the more button. - CHAMPION (talk) (contributions) (logs) 01:15, 12 June 2019 (UTC)
This is probably it, as it does say it can be inaccurate in some cases, that probably makes sense. - CHAMPION (talk) (contributions) (logs) 01:25, 12 June 2019 (UTC)
Perhaps mw:Universal Language Selector/Compact Language Links#How can I select which languages are shown to me?. --Redrose64 🌹 (talk) 06:54, 12 June 2019 (UTC)

AFD GNews search template broken link.

MacOS. The link in the AFD template to a google news search returns a google news search of "PageName" - wikipedia, instead of actually functioning problem. I'm unable to troubleshoot rn, but it was at least on AFD/Karen Davis (singer) from June 11th AFD, while 2 AFDs I checked from today function quite fine. Very confusing to me as to why its one one AFD and not 5 others. Thanks,L3X1 ◊distænt write◊ 04:30, 12 June 2019 (UTC)

@L3X1: the nomination was malformed, and it wasn't properly fixed -  Done --DannyS712 (talk) 04:33, 12 June 2019 (UTC)
Thanks DannyS712 Thanks,L3X1 ◊distænt write◊ 04:34, 12 June 2019 (UTC)

Signature forcing black text

Please can someone help User:QEDK fix his signature as it appears in Wikipedia:Administrators'_noticeboard#User:WMFOffice_-_Ban_Proposal and in User_talk:QEDK#Problem_with_your_sig_on_AN? It's forcing the following text to appear in a black font, which is invisible to users of the green-on-black gadget. Thanks. DuncanHill (talk) 10:46, 12 June 2019 (UTC)

The code for my signature is <span style="font-family:'Trebuchet MS',Geneva,sans-serif">[[User:QEDK|<font color="#000000">qedk<font>]] ([[User talk:QEDK|<font color="#000000">t</font>]] 桜 [[Special:Contributions/QEDK|<font color="#000000">c</font>]])</span><span style="font-family:'Trebuchet MS',Geneva,sans-serif">[[User:QEDK|<span style="color:black">qedk</span>]] ([[User talk:QEDK|<span style="color:black">t</span>]] 桜 [[Special:Contributions/QEDK|<span style="color:black">c</span>]])</span>. From what I can tell, it is definitely a drawback of the tool itself but if there is no resolution for the people using the gadget, anyone is feel free to roll back my signature to the old version. --qedk (tc) 10:54, 12 June 2019 (UTC)
See WP:SIGFONT. DuncanHill (talk) 10:58, 12 June 2019 (UTC)
@DuncanHill: Can you confirm the above signature works fine for you? --qedk (tc) 11:02, 12 June 2019 (UTC)
I can now read what follows your first signature in this thread, which I could not do before. DuncanHill (talk) 11:04, 12 June 2019 (UTC)

Sidenote: that gadget probably need some adjustment for 2017 wikitext editor (Preferences - Beta), example: Wikipedia:Signature_tutorial#Real-life_examples, try editing Real-life_examples section. With that gadget on, parts of text is hidden (black text on black background, even highlighted text is still invisible). MarMi wiki (talk) 11:13, 12 June 2019 (UTC) Scratch that - it's a syntax highlighter fault. MarMi wiki (talk) 11:22, 12 June 2019 (UTC)

  • @QEDK: You still have not fixed either AN or your talk page. DuncanHill (talk) 11:23, 12 June 2019 (UTC)
I've fixed AN for you, by copying and pasting the version of your sig above over the version in the thread. DuncanHill (talk) 11:33, 12 June 2019 (UTC)
Thanks DuncanHill, I had to go out for an eye check-up and didn't have time to fix it. --qedk (tc) 11:52, 12 June 2019 (UTC)
That's OK - I found one more which I also fixed. I see you've fixed it on your talk page, thank you. I hope the check up went well. DuncanHill (talk) 11:54, 12 June 2019 (UTC)
Another 0.25 increase, which falls in the range of not-so-good, not-terrible news. Rest was fine fortunately, thanks for asking. Face-smile.svg --qedk (tc) 15:22, 12 June 2019 (UTC)

────────── Whenever somebody updates their signature, it would be nice to have some sort of maintenance tool that ran every, say, 24 hours and updated all previous signatures to match the new change. That way, if there were any situations like this, people wouldn't have to remember to update problematic previous signatures manually. Amaury 14:15, 14 June 2019 (UTC)

Sounds nice theoretically , but [a] some users have hundreds of thousands of contributions - not all to "talk" of course, but still quite the overhead. [b] What if the change has an adverse effect on page content, such as an open tag rendering all subsequent page content bright pink or bold or gigantic etc... [c] The custom signature might contain contemporaneous content, such as a name/nickname change or a previously non-existent link that would simply be wrong/misleading if applied retrospectively. (etc...) -- Begoon 09:58, 16 June 2019 (UTC)
A manual tool/script would work great tho. --qedk (tc) 10:02, 16 June 2019 (UTC)
I suppose so - it would definitely need a bot flag because you're not going to make many friends lighting up thousands of watchlists to change a signature. I'm pretty sure, also, there have been objections to people doing this with, say, AWB - and you'd probably get similar objections to mass edits some would view as "pointless". If it's to fix an error that has a negative impact, as above, that would probably be viewed as ok, but I doubt purely 'cosmetic' alterations would be popular with some. -- Begoon 10:06, 16 June 2019 (UTC)
I would hate to think that each time I change my sig, some poor subroutine has to wade through the project to fix something that doesn't need fixing. Roxy, the dog. wooF 10:16, 16 June 2019 (UTC)
On lots of discussion forums (not all), when you view old posts you will see people's 'current' signature/avatar. This, though, is because that software doesn't save the rendered content with the post(s) like Mediawiki does, but generates it 'on the fly' each time. This comes with its own peculiarities though, such as viewing old posts with content like "that cat in your avatar is pretty" when the avatar has, by now, been updated to be a picture of "Judge Dredd", or the old post discusses signature content that has since been altered... -- Begoon 10:32, 16 June 2019 (UTC)
Unless ofcourse, it does... --qedk (tc) 10:42, 16 June 2019 (UTC)
We already have bots that are authorised to fix signatures with problematic markup, mainly concerning missing or misplaced closing tags - for instance, if instead of this:
[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]]
I had used one of these:
[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Redrose64]]
[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Redrose64]]</span>
[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</font>rose64]]
a bot could swoop in and fix it up. Apart from that, and other changes in accordance with WP:SIGCLEAN, existing signatures should be left alone. --Redrose64 🌹 (talk) 10:49, 16 June 2019 (UTC)

Highlighting new additions to a page.

I hope I'm not the only one who finds it challenging to keep up with fast-moving pages such as Wikipedia:Community response to the Wikimedia Foundation's ban of Fram. Take a few hours off to sleep and there are literally hundreds of new posts, some of which are helpfully at the bottom, but others for sensible reasons are interspersed as responses to earlier posts. It's not easy to keep current.

I do know how diffs work, so I can and did look at all changes since my best guess at the last time I looked at the page, but the formatting is less than ideal.

My question is whether there is a way to write a script or propose a change to the underlying software to make it easier to see what has been changed since my last visit. My first thought is that all new material could have a highlighted background and soft gray or yellow. As I read the new material, I could either mouse over it which would change the background to default (probably too difficult), or after reading the entire page, click the box that says this is now current and it would change the default.

While one usage for this would be for fast-moving pages such as the one identified, I can think of other uses. Because of my involvement in copyright issues I'm often removing material made by a very new editor, who might come to my talk page and ask a question. In many such cases, they don't know our protocol and drop a note at the top of my talk page. While I do get a ping to know that someone has responded, , I automatically look at the bottom of the page and seeing nothing new, presume that it's an old pain and I've already seen the relevant material. Occasionally, I stumble onto it days later. If it had a distinctive highlight, I'd be less apt to miss it.

This probably belongs in ideas if it's sensible and requires more discussion but I'm posting here on the chance there's a way to do it now and I just don't know how to accomplish it.S Philbrick(Talk) 15:20, 12 June 2019 (UTC)

It might also be simple and useful to allow users to expand their Page History display beyond the last 50 revisions. I've been using History to keep up with the updates on that page when I'm on, but if I take a break for an hour to walk the dog and water the plants, I now have a full screen of "updated since your last visit" revisions on the History display and can't just do a collective diff to the last visit. Alternatively, a one-click option to display such a collective diff of all updates since the last time an editor visited a page might not go wrong, as it would have a similar effect. (While I admit that the "difference between revisions" raw wikitext display isn't the easiest to read, it at least allows one to fairly quickly see what's changed, so...) rdfox 76 (talk) 16:22, 12 June 2019 (UTC)Stricken as moot rdfox 76 (talk) 16:39, 12 June 2019 (UTC)
When viwing page history, you should find, at both top and bottom, a row showing "(newest | oldest) View (newer 50 | older 50) (20 | 50 | 100 | 250 | 500)". Several of those are links; try them. --Redrose64 🌹 (talk) 16:27, 12 June 2019 (UTC)
Well, that's weird. Could have sworn I didn't see them last time I checked history on WP:FRAM. (I'm familiar with those from the watchlist!) Guess it's another consequence of having been still waking up when I first got on this morning. Stricken! rdfox 76 (talk) 16:39, 12 June 2019 (UTC)
If you don't visit the page, but first go to the page history, does it not say updated since my last visit on the more recent revisions? That's what I do. The information clears when you view the page, so for such pages, I usually just leave a tab open to the page history and refresh that as needed. WP:POPUPS are also helpful in following links to history without first going to the page in question. ~ Amory (ut • c) 20:38, 12 June 2019 (UTC)
The issue with the green thing is that you know that something changed but you don't know the something. So, either you see the diffs and then Ctrl+F for the text or you just blindly try to find where it was added. The issue is problematic on very long pages where a few words might match a lot of texts and require you to substantially copy over part of the diff and require you to go through maybe one or several diffs to see what changed. Sphilbrick basically wants to see what was added in the page itself, to identify what and where it was added, and I agree, this would be an amazing tool for long and winded pages (see WP:FRAM). Especially to resolve the edit conflicts on frequently edited pages, the current resolver is plain annoying. --qedk (tc) 07:50, 13 June 2019 (UTC)
Just realized that Sphilbrick was talking about the same page. Ditto! --qedk (tc) 07:51, 13 June 2019 (UTC)
Amorymeltzer, Yes, it does, and that's better than nothing, but not exactly what I was hoping for. S Philbrick(Talk) 19:21, 13 June 2019 (UTC)
Not sure if you are aware of it, but there is a beta feature that enables a "Visual" mode versus the standard "Wikitext" mode for viewing differences between two versions. It doesn't always do a great job with large diffs, and sometimes it just hangs (typically again with large diffs, but sometimes with just a few edits, too). To enable it, go to your preferences, select "Beta features", and check "Visual differences". You will then be able to switch back and forth between visual and wikitext mode when viewing a diff. (talk) 15:41, 16 June 2019 (UTC)

Counting links?

Is there a way to count how many pages link to a certain page? I can use Special:WhatLinksHere to find all the links, but not obvious way to count them other than grovelling over the full list. -- RoySmith (talk) 20:54, 12 June 2019 (UTC)

XTools' articleinfo has this information (e.g., Macbeth has 4195 incoming), although if that's all you want or you want to check multiple pages quickly, the API (docs) are probably a simple way to go (e.g., Macbeth). ~ Amory (ut • c) 21:24, 12 June 2019 (UTC)
Search can also do this; see Special:Search/linksto:"World of Warcraft". --Izno (talk) 22:32, 12 June 2019 (UTC)
And perhaps something more interesting, Special:Search/linksto:"World of Warcraft" -hastemplate:"Warcraft universe". --Izno (talk) 22:34, 12 June 2019 (UTC)

OK, that's a start, thanks. Is there some way to access that inside of a page? I looked at the list of magic words, and didn't see anything. How, for example, is "This template is used on approximately 390,000 pages." generated? I assume there's some Lua magic behind that? -- RoySmith (talk) 22:12, 13 June 2019 (UTC)

No, those are manually updated. There's talk of a bot here or there to update those, but that's hard wikitext based on one of the above methods, not magic. --Izno (talk) 00:00, 14 June 2019 (UTC)

Problem with watchlist display

The missing elements are left of the time-display.

A few minutes back I started experiencing a problem with my watchlist (desktop version): some elements, such as (diff|hist) etc are suddenly missing; the fonts of some some other elements also appear to have changed. Two quick questions for now:

  • Is anyone experiencing anything similar?
  • Is there an easy way for me to temporarily disable all gadgets and scripts to check if the problem is being caused by changes to any of those? I haven't added/removed any user script recently.

I'll post screenshots if I'm unable to resolve this soon. Abecedare (talk) 00:37, 13 June 2019 (UTC)

I experience the issue on both Firefox and Chrome, and even after disabling all the watchlist related gadgets. Abecedare (talk) 01:06, 13 June 2019 (UTC)
@Abecedare: please try the watchlist in safemode and see if it is the same? — xaosflux Talk 01:08, 13 June 2019 (UTC)
If it does, try disabling some of your user scripts from User:Abecedare/common.js and see if you can find the cause. — xaosflux Talk 01:10, 13 June 2019 (UTC)
@Xaosflux: Tried both. Problem persists. Abecedare (talk) 01:15, 13 June 2019 (UTC)
AFK for an hour. Will be able to try out any further suggestions after that. Thanks. Abecedare (talk) 01:20, 13 June 2019 (UTC)
I'm having the same issue on Chrome/macOS.- MrX 🖋 01:41, 13 June 2019 (UTC)
@MrX: try monobook safemode: here just to see if it is skin-specific. — xaosflux Talk 02:02, 13 June 2019 (UTC)
@Xaosflux: Yes, same problem with that skin.- MrX 🖋 02:26, 13 June 2019 (UTC)
Default watchlist appearance?
For me too, on Windows 10, the problem persists with Monobook+safemode+all custom scripts disabled.
Can somebody confirm that the default ordering of fields in the watchlist is as follows? (see 'default' screenshot)
BulletPoint (diff|hist) .. EditTypeAbbr PageName Time ..(BytesChanged)..UserName(EditSummary)
In contrast, for inexplicable reasons, the ordering I now see is:
BulletPoint EditTypeAbbr Time PageName (diff|hist) ..(BytesChanged)..UserName(EditSummary)
I can learn to work with this but would prefer to go back to "normal", without the reordering and odd spacing. Also if it helps: I don't use any custom CSS'es. Page history pages appear fine. My watchlist on Commons appears fine. Abecedare (talk) 02:45, 13 June 2019 (UTC)
  • In your preferences, is it all messed up still if you pick "Use non-JavaScript interface"? — xaosflux Talk 02:55, 13 June 2019 (UTC)
Yes.- MrX 🖋 02:58, 13 June 2019 (UTC)
Ditto. Abecedare (talk) 02:59, 13 June 2019 (UTC)
MrX I manged to resolve the problem by unchecking "Group changes by page in recent changes and watchlist" at Preferences->Recent Changes. I got the idea from this 2012 helppage and fwiw, I don't recall checking the "Group changes" preference in the first place. Can you see if this works for you too? Abecedare (talk) 03:13, 13 June 2019 (UTC)
Abecedare, yes that resolved it for me as well. Thank you for finding the solution. I don't remember selecting that option, but I can't be sure I didn't sometime in the distant past. - MrX 🖋 12:03, 13 June 2019 (UTC)
Great. Considering this broadly resolved (the finer issues can continue to be discussed at phabricator). Thanks Xaosflux, for your time and help! Abecedare (talk) 20:14, 13 June 2019 (UTC)

Blocking an editor from a range of articles

I recall that a wishlist item in a recent-ish survey was the ability to block a user from editing a set of articles in a given category, instead of protecting all those articles. For example, an editor could be restricted from editing all the articles in say Category:1950 films. Did this ever get implented, or did I dream it all?! Thanks. Lugnuts Fire Walk with Me 08:31, 14 June 2019 (UTC)

I think it's on the way of being implemented, but not active on enwiki yet. Certainly I can't see any special input boxes on Special:Block/Lugnuts yet (sorry, that was the first page available) Jo-Jo Eumerus (talk, contributions) 08:42, 14 June 2019 (UTC)
Development of blocking by category has been put on hold for now but blocking from specific pages has been deployed on dozen projects already. For enwiki, Wikipedia:Requests for comment/Partial blocks has not been formally started yet. – Ammarpad (talk) 10:35, 14 June 2019 (UTC)
Thank you both. I knew I'd seen something about it, but wasn't sure if it had yet gone live. Lugnuts Fire Walk with Me 12:01, 14 June 2019 (UTC)

Freeze Headers in Long lists

Apologies if I'm asking a perennial (I feel I can't be the first), but I couldn't find it in my keyword search

In long lists (ones longer than the height of a normal screen), could the headers be frozen (like the top line in an Excel sheet can be), as it can involve a lot of flicking up and down to remember exactly which column is which?


Nosebagbear (talk) 09:53, 14 June 2019 (UTC)

There's a gadget for this but it only works on some select browsers. You can see that in Preferences → Gadgets under "Testing and development." – Ammarpad (talk) 10:26, 14 June 2019 (UTC)
That's for tables, I'm not too sure what headers of long lists means? Section headers, maybe? --qedk (tc) 10:44, 16 June 2019 (UTC)
Lists don't have headers. The (abandoned) proposed HTML 3.0 spec would have provided the LH element, but that was omitted from the HTML 3.2 spec and has not resurfaced since. --Redrose64 🌹 (talk) 11:09, 16 June 2019 (UTC)

RfC: Alteration of Account Creation Limits/Account Creator Rights

Currently, one of the most backlogged processes is Request an Account (ACC) , which exists mainly (though not entirely) for helping with 3 purposes: Those having trouble completing CAPTCHA; enabling the choosing of a username that is too similar to an existing username under certain circumstances & creating an account for those hindered by a rangeblock.

The current backlog on pending requests is 4 months.

In the last couple of months multiple editors have signed up to be ACC tool users, Tool users are signed up to the confidentiality agreement and meet various other criteria.

Currently here are limits, however, on both their ability to create accounts. Two options could ease their work.

  1. Raise the local account creation rate limit from 4 to 10. The new limit only to extended-confirmed users to prevent any abusive behaviour from IPs.
  2. Automatically grant account creator permission, on request, to new ACC tool users. This would allow them both to bypass the limit entirely, but would also let them ignore the antispoof and title blacklist when making accounts.

Pinging all participants in the local chat discussion: @Ajraddatz, FlightTime, Xaosflux, TheSandDoctor, AfroThundr, QEDK, and Oshwah: Nosebagbear (talk) 13:11, 14 June 2019 (UTC)

  • NOTE: Option 2 is broader than Option 1, however they do not completely overlap. Option 1 would allow any EC-confirmed editor to create up to 10 accounts per IP address, option 2 is specifically targeted at ACC-users. Thus participants can !vote for either/both/none of the options.

Survey: Account creator rights

  • Support for option 1 only. Speaking as an ACC administrator, I believe that automatically granting all new ACC tool users the account creator user right (option 2) would open the door for new tool users to potentially handle requests incorrectly and without limitations before it's caught and identified - which would not be a good thing at all. We need to have a limit for how many accounts that new tool users can create per day by default. When a tool user shows proficiency with handling requests correctly, they can apply for and (after approval by an ACC admin via a comment made to the request) be granted the account creator flag in order to remove those limits. Option 2 would remove the need for an ACC tool administrator to give their approval before an admin can grant the user rights to the requesting user. This approval is still necessary and absolutely needed. Raising the current limit of 4 creations per day to 10 creations per day would loosen the restrictions so that users can help take care of the current backlog of requests at ACC, while still being on a set limit during the time that they're learning and demonstrating their knowledge and proficiency with ACC tool user interface. This option is the best way to resolve the concerns expressed. :-) ~Oshwah~(talk) (contribs) 13:25, 14 June 2019 (UTC)
  • Support for option 1; encourage ACC admins to quickly work with new ACC volunteers to get them trained and empowered with additional flags as soon as feasible. — xaosflux Talk 13:43, 14 June 2019 (UTC)
  • Support option 1 Per above. Also, as all rights on Wikipedia are, it is granted on the basis of need for the right, inherent oppose for point 2. --qedk (tc) 13:59, 14 June 2019 (UTC)
  • Support option 1 as per my comment in the previous discussion. I also agree with Oshwah on automatically granting new users the ACC bit. The current method of granting the right after a couple weeks of activity allows the team to gauge the user's performance and whether or not they have learned the policies and procedures properly. Lowering the barrier further could lead to a problematic user potentially causing a lot more damage (no rate-limit, anti-spoof override, username title blacklist override) than they otherwise could if we had to manually grant those rights. On the other hand, when all is in order, granting them the right is usually quick and painless anyway. — AfroThundr (u · t · c) 14:04, 14 June 2019 (UTC)
  • Support alternate option where an group named Account creation helper is formed, which would contain only the noratelimit right.--Snaevar (talk) 14:38, 14 June 2019 (UTC)
I appreciate the idea, but I just don't see how this implementation would be useful here, or how it would resolve any issues that the account creator flag wouldn't already resolve. If an ACC admin user can trust an ACC tool user enough to have no account creation limit, that admin user should also trust the tool user enough to be able to correctly and properly handle requests that tripped the antispoof extension and require a flagged user to override (and vice versa). ~Oshwah~(talk) (contribs) 14:45, 14 June 2019 (UTC)
  • Support 1. After thinking about this a bit more, I'm not sure if tying the rate limit to extendedconfirmed would be possible. If not, I still think we should raise the limit, but maybe to 6 like it was before instead. The limit was lowered mainly for projects without 300 active local sysops who couldn't instantly respond to mass account creation. -- Ajraddatz (talk) 15:16, 14 June 2019 (UTC)
    Rights like PMR have increased limits for certain flags (in that case, page moves), this would just mean adding a flag like that to EC right holders. --qedk (tc) 15:23, 14 June 2019 (UTC)
    Yes, most ratelimits are determined on a per-account basis (or per IP for anonymous users). But I seem to remember account creations being different, and being specifically tied to the IP. I assume/hope that a defined higher ratelimit for extendedconfirmed would override that. And no need to tie it to a specific permission; it can be done for the group itself. -- Ajraddatz (talk) 22:58, 14 June 2019 (UTC)
    Yep, but that's a non-issue as far as devs are concerned. Delving into the issue of newer technical changes, from my experience talking to people on SRE/Deployment (and Anomie, TheDJ), technically unfeasible things are pretty rare and I have not seen requests getting turned down (rarely, if ever) with "MediaWiki does not support this", if it's a feature change, or some irreproducible bug, it's a different thing but for example, during the RfC for Template editor rights, a lot of people were worried about the tecnical changes but eventually it was done, with no big deal at all. That's how it is for most new things (and TE rights had a new protection level as well), so I would say a change would be technically feasible until a dev says exactly otherwise. --qedk (tc) 07:50, 16 June 2019 (UTC)
  • (ACC admin comment) I'm pretty sure option 1 isn't possible without development, i.e. it is not a simple configuration change. AFAICT, IP account creation limits can only be set as a count per interval with the noratelimit right being the only way for a user to bypass that limit. (mw:Manual:$wgAccountCreationThrottle) Oppose option 2 for the reasons outlined by Oshwah. Support returning the daily IP limit to 6 unless the Security Team provides a good reason that it needs to remain at 4. — JJMC89(T·C) 05:50, 15 June 2019 (UTC)

Discussion: Account creator rights

  • @Nosebagbear: regarding your proposed options, and since this is VPT, can you explain the specific technical changes you are proposing - or is this more of a "let some developer figure it out" type of request? Is the "automatic" granting you are asking some sort of technical change you are proposing, or is it a procedural/policy change? — xaosflux Talk 13:24, 14 June 2019 (UTC)
    Xaosflux - If option 1 were to reach consensus, it would be corrected by filing a phab ticket to have this done. See phab:T212667. ~Oshwah~(talk) (contribs) 13:27, 14 June 2019 (UTC)
    Thanks. — xaosflux Talk 13:29, 14 June 2019 (UTC)
    (edit conflict) @Xaosflux: - changing the rate limit is obviously possible. Whether it can be changed "in bands" to different protection levels is, I'm afraid, I query for those more technically savvy than me. If they say that's impossible (or akin), then this would need to be rethought. Nosebagbear (talk) 13:29, 14 June 2019 (UTC)
  • For the problem that is trying to be solved - is overriding anti-spoof the normal resolution, or is getting them to pick a new username? — xaosflux Talk 13:25, 14 June 2019 (UTC)
    Xaosflux - For instances where similar usernames exist and are caught by anti-spoof, it depends. See this section of the ACC guide for the policy on when ACC tool users with the account creator flag can override the antispoof flag and proceed with creation. ~Oshwah~(talk) (contribs) 13:30, 14 June 2019 (UTC)
    @Oshwah: thanks, option 1 above won't fix the antispoof ones, is that a significant part of the backlog? Just asking so we don't spend time getting something done that won't help. — xaosflux Talk 13:33, 14 June 2019 (UTC)
    Xaosflux - No. Requests that have tripped the anti-spoof extension make approximately 3.5% of all total requests at this time. Of those, users without the account creator flag can still see if the similar accounts are active, and decline the request if any of them are. The only time that a request requires a user with the account creator flag is when a request trips the antispoof extension and the similar accounts are all inactive. This means that the antispoof needs to be overridden, the request approved, and the account created. ~Oshwah~(talk) (contribs) 13:37, 14 June 2019 (UTC)
  • Why not grant Wikipedia:Event coordinator to new members of ACC? EVC will give them ability to bypass 4 account limit and it also doesn't allow overriding antispoof/title ban restrictions. ‐‐1997kB (talk) 16:36, 14 June 2019 (UTC)
    1997kB - Not a bad thought, but event coordinators can set new accounts as 'confirmed' using Special:UserRights, which is an ability that they don't need. Essentially, we'd be trading apples and oranges here if the concern is over access to some user rights they shouldn't have. As I said above, I believe that if an ACC admin can trust an ACC user to create accounts with no limit, they should also trust them to properly handle requests that tripped the antispoof extension and require a user with the account creator permissions to override and create (and vice versa). :-) ~Oshwah~(talk) (contribs) 16:42, 14 June 2019 (UTC)
    @Oshwah: - I realise I agree with you, but to run with the Event-Coordinator compromise theory a bit further, it would be clearer cut - the damage possible is pretty tiny. Even if they made every account they created confirmed, it wouldn't cause a great uptick in carnage. Nosebagbear (talk) 22:36, 14 June 2019 (UTC)
    Fair point. ~Oshwah~(talk) (contribs) 02:31, 15 June 2019 (UTC)
    @Oshwah: what is the expected amount of accounts to be created by "new" ACC volunteers per period? (i.e. would 6 or 8 be enough?) since the "rights they don't need" here to ECC users is expected to be way more than is needed by the relatively minuscule ACC team. — xaosflux Talk 16:59, 14 June 2019 (UTC)
    Xaosflux - Honestly, any increase from 4 would be beneficial. Even if the increase is just by a few... :-) ~Oshwah~(talk) (contribs) 17:41, 14 June 2019 (UTC)

New bot

I think we should have a bot or some kind of tool check for accounts which are hitting the account creation limit but do not hold the rights event coordinator, account creator and are also not ACC tool users. The account creation limit was lowered for a reason and increasing it without keeping a check in place would be a gross violation of WP:BEANS imo. Thoughts, @Nosebagbear, JJMC89, Xaosflux, and Oshwah:? --qedk (tc) 14:19, 14 June 2019 (UTC)

A recurring database report may be able to solve this for you. — xaosflux Talk 14:27, 14 June 2019 (UTC)
If this is a major issue, the report would have to be run quite frequently, and viewed frequently by patrolling users. Otherwise, this method might not be effective enough at stopping abuse and quickly enough... ~Oshwah~(talk) (contribs) 14:30, 14 June 2019 (UTC)
(edit conflict) QEDK - Doesn't sound like a bad idea to me. How would this new bot alert others that an account is hitting a limit and isn't within one of those groups? Who would this bot alert? Where? This is something that we should figure out if we're going to consider an idea like this... :-) ~Oshwah~(talk) (contribs) 14:29, 14 June 2019 (UTC)
It can function the same way AnomieBot handles WP:TPERTABLE, there's no annoying notifications involved and interested people can simply watch the page and report when they find anyone suspect. --qedk (tc) 14:33, 14 June 2019 (UTC)
QEDK - Nice... I like it. :-) ~Oshwah~(talk) (contribs) 14:36, 14 June 2019 (UTC)
Functionally, a bot wouldn't be able to work "that way". Also, bot's wont be able to see "that you got denied by the limit" , but a bot could periodically generate a report of "accounts created per user over some time period" and could either filter out members of certain groups or just report the groups as well. — xaosflux Talk 14:38, 14 June 2019 (UTC)
Why not? The logic is pretty simple, you would need to check creation logs iterating a certain period (maybe an hour) and track accounts which create another account for 24 hours at minimum and more if they somehow meet the limit each day (hence, suspect). Wikipedia accounts which do not have a similarly authorized account in ACC (or the other account creation rights as well) have demonstrably no reason to carry out actions like this, hence red-flagging them almost immediately. --qedk (tc) 14:49, 14 June 2019 (UTC)
A bot could create a report, technically it won't be able to tell if you actually got stopped by the limit, just that you hit it or approached it. It wouldn't work "the way" of the protected edit requests in that those don't mine logs, they make use of what links here/category memberships. But the output could still be made. Have a bot periodically (say hourly) ingest the user account creation log and make a report. I think it may even be helpful to have it report on everyone, or everyone with say 3+ creations - and also to identify accounts made by coordinators, etc - so they can be coached as needed. — xaosflux Talk 14:54, 14 June 2019 (UTC)
Yeah, I mean, technically not. But I'm saying it like the logic is clear that an account cannot make more than 10, so an account which makes 10 accounts can be construed to have hit the limit, what's important is identifying if anyone is trying to make a large number of accounts in a short period of time, hitting the actual limit is more of a formality. --qedk (tc) 15:06, 14 June 2019 (UTC)
Something like quarry:query/36938? It can't tell if they're an ACC tool user, obviously. If this query is correct, there's not a whole lot of ACC activity going on. MusikAnimal talk 19:46, 14 June 2019 (UTC)
@MusikAnimal: thanks for the query, even including everyone with 3+ creations over the last whole 10 days (quarry:query/36941). I haven't checked their groups, but the impact here seems to be very small. — xaosflux Talk 20:07, 14 June 2019 (UTC)
Almost all ACC users in that 10+ range, minus the one event coordinator. Unfortunately I won't be appearing in that query anytime soon due to a certain rangeblock with "account creation disabled" set. Really puts a damper on ACC work... — AfroThundr (u · t · c) 01:51, 15 June 2019 (UTC)
@AfroThundr3007730: - I thought individual accounts could be exempted from rangeblocks? If so then ACC tool users would be a priority Nosebagbear (talk) 14:32, 15 June 2019 (UTC)
@AfroThundr3007730: this is a known issue, even effects admins: phab:T189362. — xaosflux Talk 15:16, 15 June 2019 (UTC)
@Nosebagbear: Besides IPBE, I'm not aware of any (current) facility to exempt an individual user from the effects of a rangeblock, at least not the account creation part.
@Xaosflux: - thanks, suspect it was one of those merging of facts I got while swinging around the policy pages. Clearly, I'd made a terrible nerd Nosebagbear (talk)
@Xaosflux: Yep, definitely tracking that one, and if they do get around to implementing it, I would be first in line to request IPBE so I can get back to helping in ACC. — AfroThundr (u · t · c) 18:37, 15 June 2019 (UTC)
Could use an abusefilter for this - something along the lines of Special:AbuseFilter/527. Galobtter (pingó mió) 15:33, 15 June 2019 (UTC)

Attach floating navbar outside of table?

Is it possible to attach a flaoting navbar outside of a table, but so that it aligns with the right hand side of the table? Take a look at my sandbox to see, what I'm trying to achieve. Thanks. (talk) 18:34, 14 June 2019 (UTC)

If you add it as a header, people with the sticky header gadget can see it. I believe position: sticky is what's needed in any element like that, and probably (!) can be achieved with the help of TemplateStyles and/or a change in local .css. --qedk (tc) 18:42, 14 June 2019 (UTC)
Actually, I want to have it below the table (forgot to mention). So I think the header is not an option (I might take it as a last resort). Also this is supposed to go on a "real" template, so a change in local .css is not an option either. (talk) 19:03, 14 June 2019 (UTC)
Make a template wrapper for the table and use WP:TemplateStyles. --qedk (tc) 19:19, 16 June 2019 (UTC)

In-article external links

Is there a tool or gadget available to get rid of all external links in an article, either by removing them entirely, transforming them into references, or converting them into wikilinks? Thanks. — Gorthian (talk) 18:58, 14 June 2019 (UTC)

WP:REFILL will do some of that. If you've got something that's already marked up as a reference (i.e. inside a <ref> tag) but it's only a bare URL, it'll build a full citation for you. But, it won't help if it's just an external link in single brackets. -- RoySmith (talk) 19:54, 14 June 2019 (UTC)
Unfortunately, the single-bracket kind are what I want to eliminate. See Steven Amsterdam, for a mild example. It’d be nice not to have to do all of it by hand. — Gorthian (talk) 20:06, 14 June 2019 (UTC)


In my coding I have a navigator at the top of articles to enable me to browse articles alphabetically. However it no longer seems to work fully, if I browse two or three pages the next article link doesn't appear. Can somebody help fix it so it works and two links appear at the top left and right of every page?♦ Dr. Blofeld 07:14, 15 June 2019 (UTC)

Presumably this is some kind of gadget or other script. Which one? --Redrose64 🌹 (talk) 07:19, 15 June 2019 (UTC)
I assume he's referring to User:PleaseStand/prevnext.js. That script hasn't been changed in five years, and the attached stylesheet in six years, so I assume it's been broken by either an update to Dr. Blofeld's browser, or an update to Wikipedia's API. Someguy1221 (talk) 09:26, 15 June 2019 (UTC)
Yes that's right, for some reason it's not showing after I browse a few pages. Used to fine of course.♦ Dr. Blofeld 15:59, 15 June 2019 (UTC)

Help with tables

An editor has been adding large tables to a number of articles, such as Plainville, Connecticut, which appears to have disrupted the layout. I tried adding "mw-collapsed" to make the tables more compact, but was not able to float the tables left. Any help would be appreciated. Thank you. Magnolia677 (talk) 17:31, 15 June 2019 (UTC)

  • At Plainville, Connecticut, User:Nthep fixed the table layout with an edit summary "don't float the table - keep it in the section it belongs in". I tried this same fix at Newington, Connecticut and it worked fine, but when I also added "mw-collapsed", that feature didn't work (the "show all" was disabled). Any help would be appreciated, as has added these large tables to a number of articles. Magnolia677 (talk) 10:54, 16 June 2019 (UTC)
It works with wikitable mw-collapsible mw-collapsed (as described in documentation Help:Collapsing#Collapsing_by_default), but the long title is then squeezed (spelled almost word under word). |+ class="nowrap" | Newington... prints title in one line. MarMi wiki (talk) 18:54, 16 June 2019 (UTC)
If you're wondering why float:right was removed, zoom out of that page by Ctrl+- (Control and minus key) and observe the table. MarMi wiki (talk) 19:11, 16 June 2019 (UTC)

What is the difference between these two page titles?

We have two Wikipedia pages that bear the following titles:

The first one is a redirect to the second. But no typographical difference is visible to me, so I cannot say whether the page ought to be moved from the second title to the first. What am I missing? Michael Hardy (talk) 22:11, 15 June 2019 (UTC)

The first title contains a non-ASCII character for the "K", it is "GREEK CAPITAL LETTER KAPPA". power~enwiki (π, ν) 22:20, 15 June 2019 (UTC)
Yup, while the other is the standard Latin capital K. I've added an appropriate redirect category to that. --Masem (t) 22:24, 15 June 2019 (UTC)
@Power~enwiki: @Masem: How did you find out that that's what it is? Michael Hardy (talk) 23:22, 15 June 2019 (UTC)
Find a unicode converter online (numerous ones out there). Copy directly from the article titles and paste into the converter which should spit out unicode values. --Masem (t) 23:44, 15 June 2019 (UTC)
Simpler method: take the links above and reduce them to the first character only:
Then click each link in turn and see where you end up. --Redrose64 🌹 (talk) 09:38, 16 June 2019 (UTC)
They also look fairly different in the monospaced source editor, but of course not everyone uses it. ~ Amory (ut • c) 10:32, 16 June 2019 (UTC)

Category move/re-name

I used to be able to carry out uncontroversial category re-naming using the page move feature but I don't seem to able to do this any more. Is this a policy change or a technical issue?--Obi2canibe (talk) 12:23, 16 June 2019 (UTC)

Both. Per policy, categories should not be renamed except through CFD, and, as an attempt to enforce that policy, I got consensus to restrict the technical ability to move categories to page movers, admins, and bots. * Pppery * it has begun... 13:04, 16 June 2019 (UTC)
OK, thanks for responding.--Obi2canibe (talk) 14:21, 16 June 2019 (UTC)

Moving script page

Is it not possible to move a script page? Trying to do so gives the error "[XQaN5wpAAD8AADZAmukAAAAU] 2019-06-16 18:43:52: Fatal exception of type "InvalidArgumentException" repeatedly. SD0001 (talk) 18:45, 16 June 2019 (UTC)

If you're trying to move a script page (js/css/json) in your own userspace, it is allowed (I just tried it) but you cannot move MediaWiki-namespace or other user's script pages, since you do not have the right to edit them in the first place. --qedk (tc) 19:16, 16 June 2019 (UTC)
That is obvious. I got the above error on trying to move within my userspace. Never mind, I c&p-moved it anyway. SD0001 (talk) 20:23, 16 June 2019 (UTC)