Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search
 Policy Technical Proposals Idea lab WMF 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. Discussions are automatically archived after remaining inactive for five days.

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 task 3864. There is an accesskey property on it (default to accesskey="f" in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their 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 Help: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. If you cannot reach Wikipedia services see Reporting a connectivity issue
« Archives, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193

Performance issue with syntax highlighting[edit]

Hi! In the last few days, I've started noticing a performance issue while editing. It starts out OK, but within a few minutes, it starts slowing down so much that it becomes unbearable. It seems to be worse on large / complicated pages. As part of my troubleshooting, I've found that turning off syntax highlighting (provided by the CodeMirror extension?) makes the problem go away. I've also tried using safemode, but that didn't help at all.

As far as I can tell, I'm using the 2010 editor (I've got a bar with some buttons, which matches with this image). I'm using Chrome 96.0.4664.45 on Windows 10. Oh, and to be sure, I just tested in Edge, and there it seems to work just fine. No performance issues at all. So this looks like it could be Chrome-specific. --rchard2scout (talk) 11:00, 17 November 2021 (UTC)

@Rchard2scout: can you try a Chrome incognito window to see if it still happens for you? (This will cause most local chrome extensions etc to not load). — xaosflux Talk 14:04, 17 November 2021 (UTC)
Yes, unfortunately. Opened an incognito window and tried to edit User:Rchard2scout/linterrors, and within about half a minute of scrolling up and down the page almost completely stopped responding, and CPU usage for that tab jumped to 100%. I've tried both logged in and logged out, no change. --rchard2scout (talk) 14:17, 17 November 2021 (UTC)
Might possibly be related to (talk) 15:46, 17 November 2021 (UTC)
I tried the fix they mentioned (setting a flag to disabled), but it didn't fix it for me. From what I can tell, it looks unrelated to my issue. That flag has to do with cross-origin loading, and I don't think that should impact performance. --rchard2scout (talk) 09:09, 18 November 2021 (UTC)
@Rchard2scout I suggest creating a ticket on phab if the issue is unresolved. – SD0001 (talk) 04:15, 23 November 2021 (UTC)
Thumbing up. I can confirm this for Google Chrome. I'm experiencing similar issues when editing in both modes: visual and text-mode. I even have found a culprit responsible for the bottleneck: it's a CodeMirror v.5.58.3 (it's used by Mediawiki, learn more here). The bug was introduced no later than that version. In huge articles (e.g. Russian COVID-19 response) it makes unbearably hard or completely impossible to edit. If anyone from technical team is interested, here is a culprit function that is slowing down the whole editor: ContentEditableInput.showPrimarySelection. An update of the CodeMirror should probably cure it. Regards. AXONOV (talk) 18:36, 23 November 2021 (UTC)
@Alexander Davronov Have you filed a phabricator ticket? --Ahecht (TALK
) 04:17, 25 November 2021 (UTC)
Sorry, I have no account for that. Ain't gonna register out there either... AXONOV (talk) 06:37, 25 November 2021 (UTC)
If you have a Wikimedia account (you do), Phabricator accepts OAUTH authentication. Izno (talk) 07:08, 25 November 2021 (UTC)
@Alexander Davronov Your Wikipedia account works just fine at phabricator. Just choose "Log in or register Mediawiki". If you're already logged in to Wikipedia, you just have to hit the "Allow" button. --Ahecht (TALK
) 20:01, 26 November 2021 (UTC)
@Ahecht and Izno: Thanks. I strongly suspect that it's Google Chrome-only issue. I tried to edit some big articles by using Firefox and it was smooth and fast. I'll reply in #1271918 . Everyone is welcome to do the same. AXONOV (talk) 09:17, 29 November 2021 (UTC)
It seems likely that is the Chrome bug that some folks are experiencing. -- BDavis (WMF) (talk) 00:29, 25 November 2021 (UTC)
I don't think that is has to do anything with spelling correction. But who knows though... AXONOV (talk) 06:37, 25 November 2021 (UTC)
@Alexander Davronov: I made a formatted test page with no spelling errors and still experienced the issue. Schierbecker (talk) 17:18, 1 December 2021 (UTC)
@Schierbecker: Well I can confirm that I have the same issue on the said page. It appears that it has nothing to do with spelling. I think the Chrome Team already working hard on related issue #1271918. It's number 1 priority now. Let's see if they fix it. --AXONOV (talk) 17:41, 1 December 2021 (UTC)
I'm experiencing the same issue in Microsoft Edge: #Editing Humvee slows my browser to a halt. Schierbecker (talk) 17:08, 1 December 2021 (UTC)
@Schierbecker: Well I think you can work-around the problem by trying to disable spellchecker in the Chrome settings. AXONOV (talk) 18:43, 2 December 2021 (UTC)

Editing Humvee slows my browser to a halt[edit]

I can't edit this page in Microsoft Edge or Chrome. I can edit one section at a time, but I can't change the lede. My performance monitor doesn't show my memory (32GB) or CPU (i9) getting taxed too crazy, but my case fan goes kinda nuts. Tried this on two computers. Weird. Any guesses what's going on? Schierbecker (talk) 07:17, 30 November 2021 (UTC)

Hello, Schierbecker. I am editing on Chrome using an Android device, namely a Samsung Galaxy S21 Ultra 5G. The article loads almost instantly for me and I was able to make a test edit almost instantly. I suspect that the problem is at your end. Cullen328 (talk) 07:31, 30 November 2021 (UTC)
Cullen328 Did you edit by clicking "edit source" using the desktop version of the site? Appears your edit was only to the top section. If you click the edit button in mobile, you are only editing one section at a time (including the lede). Schierbecker (talk) 08:02, 30 November 2021 (UTC)
Schierbecker, yes. I only use the fully functional but misnamed "desktop version" which works just fine on modern Android devices. Why would anyone want to edit more than one section at the same time? Just make your edit and move on to the next section that you want to edit. Cullen328 (talk) 08:17, 30 November 2021 (UTC)
For one, you would certainly need the whole-article view if you are editing a page with potentially conflicting tables and graphical elements. The edit preview can be drastically different from the final product when you are in section-edit view. Schierbecker (talk) 08:33, 30 November 2021 (UTC)
Not a solution to your problem, but there is a gadget that adds an edit link to the lede section. Under Preferences > Gadgets > Appearance, select "Add an [edit] link for the lead section of a page". Then you can edit the lede like any other section. —  Jts1882 | talk  07:43, 30 November 2021 (UTC)
Jts1882 I used to use that! That's the work-around. Schierbecker (talk) 08:02, 30 November 2021 (UTC)
Is your problem with loading the edit screen, or with submitting the edit? Are you using source editor or visual editor? –Novem Linguae (talk) 07:52, 30 November 2021 (UTC)
Novem Linguae I can submit edits, but the typing lag is atrocious. When I open the source editor, everything is fine at first. After about 10-15 seconds the lag kicks in hard. Source editor, Windows 11. Schierbecker (talk) 08:02, 30 November 2021 (UTC)
I came to this page to report the same experience. Over the past week, especially when I'm on longer pages, and regardless of whether it's source editing or visual editing, I've been getting tremendous lag when editing some pages. I'll click on a spot in the text, and it can take up to maybe 30 seconds before the insertion point appears there. I'll type some characters and, again, it'll take that long for them to appear. The latest occurrence of this just happened to me at Albania. My first assumption was that it was on my end but it persisted after I'd rebooted my computer. I'm using Chrome on Windows 10. I've had this machine for a couple of years; this behavior has only just begun; and I haven't observed anything else slowing down on this computer. Largoplazo (talk) 08:38, 30 November 2021 (UTC)
Largoplazo Are you noticing this more on pages with infoboxes?? I was suspecting an issue with Template:infobox weapon because M270 Multiple Launch Rocket System also just crashed my browser. Schierbecker (talk) 08:43, 30 November 2021 (UTC)
@Schierbecker: I hadn't gotten as far as recording the conditions under which this is happening yet, but it's possible—though none of them would have had the weapons infobox. It's certainly the longer articles, and it would make sense that they'd have an infobox. Largoplazo (talk) 08:52, 30 November 2021 (UTC)
Browser lag of this type could be JavaScript of some kind. Are either of you using text highlighters such as the gadget Syntax highlighter? –Novem Linguae (talk) 08:58, 30 November 2021 (UTC)
@Novem Linguae: I don't have syntax highlighter turned on. The editing gadgets I have turned on are "add two new dropdown boxes ...", citation expander, HotCat, ProveIt, Shortdesc Helper, wikEd, CharInsert, Add Extra Buttons, and refToolbar. The one I added most recently, possibly in the past month, is Shortdesc Helper, though that operates when the page is not in edit mode, right? Largoplazo (talk) 09:04, 30 November 2021 (UTC)
Problem appears to still be present when logged out. Schierbecker (talk) 09:24, 30 November 2021 (UTC)
It would help if the Gadgets were wrapped in a check that goes over whether the user is on a page where the gadget would be used. Probably start with shortdesc since it was added by the user last. If that is not enough, there might be hints in the browser console, the browser does detect some performance issues. See Wikipedia:Reporting JavaScript errors on how to open that up.--Snævar (talk) 11:23, 30 November 2021 (UTC)
Thanks for the tip. Largoplazo (talk) 14:09, 30 November 2021 (UTC)
Largoplazo, There is a default wikisyntax highlighter other than the one in gadgets. Does turning it off improve your performance? I saw an immediate improvement. (the highlighter button that should be to the left of ">Advanced" in your toolbar if you have one.) Schierbecker (talk) 16:36, 1 December 2021 (UTC)
Schierbecker, I opened Albania, where I had experienced brief but unmistakable lag, in source editing mode. I have a different toolbar , not the short one that I managed to discover by chance and then somehow lost, with Advanced and Characters and so forth on it, but a full-width one with several groups of many buttons displayed. Still, I found the one for syntax highlighting in the rightmost group, and it displayed as pressed. I clicked it and it took at least ten seconds to remove syntax highlighting, but then the lag did disappear.
Then, for the sake of experimentation, I clicked the button to reactivate highlighting—and the browser displayed a series of four timeout warnings in a row that I dismissed before giving up and refreshing the page. At this point, syntax highlighting was back on and the lag had resumed. I turned off highlighting again, and the lag was again gone.
Still, of note: I've only been experiencing the lag over maybe the last week or two. Has the syntax highlighting code been updated recently? UPDATE: I see below it's being attributed to a Google Chrome bug. Largoplazo (talk) 17:33, 1 December 2021 (UTC)
I went through Wikipedia:Featured articles/By length. Lag starts becoming noticeable around 40,000 bytes. 90k seems to be the upper limit before editing goes from frustrating to down-right difficult. Schierbecker (talk) 09:20, 30 November 2021 (UTC)
This sounds similar to #Performance issue with syntax highlighting which I reported almost two weeks ago. --rchard2scout (talk) 10:15, 30 November 2021 (UTC)
^ I would guess it's this issue. Izno (talk) 20:05, 30 November 2021 (UTC)
Yes, see my latest note above: turning off syntax highlighting also eliminated the lag for me; and I'd been experiencing it for only the last week or two, as best I can recall. Largoplazo (talk) 17:34, 1 December 2021 (UTC)
@Cullen328: This is probably due to a Google Chrome bug introduced recently. See discussion above: #Performance issue with syntax highlighting --AXONOV (talk) 17:01, 1 December 2021 (UTC)
  • I had found that when I edited a large article (over 100K) using a laptop over a mobile-hotspot connection (while on the go), there were significant (unworkable) time lags, while the same computer and browser using a typical/ordinary high speed WiFi connection (like at home or office) didn't have the same time lagging. Platonk (talk) 10:15, 2 December 2021 (UTC)
  • I now have syntax highlighting turned off, yet it took me about five minutes to copyedit one section heading and one sentence at Martinique. Details: I started in visual editing, then switched to source editing. Equally slow both ways. Largoplazo (talk) 23:55, 4 December 2021 (UTC)

Serious lag editing articles with Google Chrome[edit]

So for the past few weeks I've found it almost impossible to work on articles in Google Chrome. Anything larger than a few kilobytes quickly becomes bogged down with lag to the point where it takes several seconds to scroll, select, or add/delete text (but only in the text box, the overall page still works fine if the text box isn't in focus). This only started happening last month, so I'm wondering if anyone else is having this problem or if it's something on my end? Not having this problem with Firefox. - Floydian τ ¢ 18:32, 4 December 2021 (UTC)

Have you tried mw:safemode, which turns off user scripts, which might help you blame or rule out user scripts? Are you using a syntax highlighter? Possibly related: #Performance issue with syntax highlighting. –Novem Linguae (talk) 18:49, 4 December 2021 (UTC)
Try turning off the spellcheck and see if it goes away. Nardog (talk) 18:59, 4 December 2021 (UTC)
The problem mentioned in the syntax highlighter thread describes exactly what is happening to me, and I do indeed use it. It appears that turning spellcheck off fixes the issue, with or without syntax highlighting. - Floydian τ ¢ 19:11, 4 December 2021 (UTC)

Make dark mode toggle script a gadget?[edit]

There appears to be a quite a bit of interest in dark mode - going by the several help desk and teahouse queries and the posts at user talk:Volker E. (WMF)/dark-mode. However, the current user experience is sub-optimal as the gadget doesn't provide a toggle, and it seems unlikely that users want the dark mode on all the time. So I suggest converting a dark-mode toggling script such as User:SD0001/dark-mode-toggle.js into a gadget. See also the initial discussion. – SD0001 (talk) 06:37, 26 November 2021 (UTC)

Not a direct answer to your suggestion, but I recently created Wikipedia:Dark mode to try to consolidate info on various dark modes available in one place. This page could also be a good place to discuss a toggle which has come up a few times.Dialectric (talk) 10:14, 26 November 2021 (UTC)
Posted a linkback to here on its talk page. – SD0001 (talk) 05:47, 28 November 2021 (UTC)
  • Support I didn't use the dark mode because it didn't have a toggle, and I didn't use SD0001's toggle because it didn't support toggling it without reloading the page, but now that it does, this seems like a good idea. Nardog (talk) 07:42, 28 November 2021 (UTC)
  • Support I did it on viwiki. P.T.Đ (talk) 18:27, 29 November 2021 (UTC)
  • Support. Would be very useful. MichaelMaggs (talk) 08:31, 30 November 2021 (UTC)
  • Support. Sure I can see the value in this one. Ktin (talk) 21:29, 1 December 2021 (UTC)
  • Support I think this is a great idea if you want to read or edit Wikipedia at night or you have sensitive eyes. I think adding a built-in high-contrast mode too would also be useful for visually impaired Wikipedians. Linux rules, Windows drools (talk) 06:48, 3 December 2021 (UTC)
  • Question... any Foundation/phab/MediaWiki movement on this lately? If they're doing something about it soon then we might want to let that option take its course. Enterprisey (talk!) 07:23, 3 December 2021 (UTC)
    Not as far as I know. @MusikAnimal would be able to provide a qualified answer. Dark mode did end up #2 in 2019 Community Wishlist but it was declined. – SD0001 (talk) 13:21, 3 December 2021 (UTC)
    ughhhhhhhhh ok, thanks for the digging. Support as it's the best option we have available; I'll stand by to implement it, assuming there's consensus here (I see a little precipitation, in fact). I was going to make a few feature requests for the script but it already implemented everything I could think of, so great job! Enterprisey (talk!) 20:20, 3 December 2021 (UTC)

Advice on scripts[edit]

I have added various scripts to User:Dudley Miles/common.js over the years, some of which I do not remember what they do. I should be grateful if an expert would take a look and tell me whether they all still useful and whether there are any other scripts worth importing. Dudley Miles (talk) 13:45, 29 November 2021 (UTC)

You can replace User:Ucucha/duplinks.js with the maintained version User:Evad37/duplinks-alt.js; and the two HarvErrors scripts with User:Trappist the monk/HarvErrors.js – a serious bug is fixed in Trappist's version. As for prosesize, it is now available as a gadget (Wikipedia:Prosesize) so you can enable that instead. The rest looks fine. – SD0001 (talk) 17:20, 29 November 2021 (UTC)
Many thanks SD0001. Dudley Miles (talk) 22:43, 29 November 2021 (UTC)
SD0001 I have replaced the Harverrors script and confirmed that I have the prosesize gadget, but I have a problem User:Evad37/duplinks-alt.js. The documentation page at User:Evad37/duplinks-alt says that I should add {{subst:lusc|User:Evad37/duplinks-alt.js}}, but when I try to save I get a message, "The document containts errors. Are you sure you want to publish?". Can you advise please? Thanks. Dudley Miles (talk) 11:35, 30 November 2021 (UTC)
@Dudley Miles the template will subst on save to produce error-free javascript. So that warning can be ignored. – SD0001 (talk) 13:12, 30 November 2021 (UTC)
Thanks again SD0001. Dudley Miles (talk) 13:32, 30 November 2021 (UTC)

Unicode characters outside the BMP in MediaWiki:Gadget-charinsert-core.js[edit]

I recently requested that the musical double-flat 𝄫 (U+1D12B) and double-sharp 𝄪 (U+1D12A) symbols be added to the symbols palette, at MediaWiki_talk:Edittools#Double-sharp_and_double-flat, since they're necessary for talking about a good deal of 19th-century classical music: xaosflux very kindly made the additions. However, they didn't seem to show up right when I actually pulled up the symbols palette below the edit window now – instead of the intended series 𝄫 ♭ ♮ ♯ 𝄪 from lowest to highest, I saw � � ♭ ♮ ♯ � � with pairs of replacement characters.

Is there something breaking these high-numbered characters down into their UTF-16 decompositions and creating mojibake? My suspicions were raised by the fact that if I clicked the 1st, then the 2nd replacement character there, I did get a 𝄫 that I could see; and if I clicked the 3rd, then the 4th, I got a 𝄪. But I couldn't see these in the toolbar. The UTF-16 decompositions are respectively 0xD834 0xDD2B and 0xD834 0xDD2A, and consistent with that theory, clicking them in the order 3rd-2nd or 1st-4th also worked and created 𝄫 and 𝄪 respectively. That's just a hypothesis on my part, though.

Xaosflux has reverted the additions since, as they don't work properly, but I'd like to ask if there's any way they could be made to work. Double sharp (talk) 16:10, 29 November 2021 (UTC)

JavaScript uses UTF-16 internally and many of its primitives access the code units individually. The code at MediaWiki:Gadget-charinsert-core.js lines 168 to 171 would need to be updated to use characters rather than code units. I don't know which browser versions we want to support these days, but something like this (replacing lines 168 to 174) should work in reasonably modern browsers.
                } else {
                    var chars = [ ...token ];
                    if ( chars.length > 2 && token.charCodeAt( 0 ) > 127 ) { // a string of insertable characters
                        for ( var j = 0; j < chars.length; j++ ) {
                            addLink( chars[ j ], '' );
                    } else {
                        addLink( token, '' );
The [ ...token ] is the bit that needs a "reasonably modern" browser. Chrome 46, Edge 12, Firefox 16, Safari 8 or 9 I think. Anomie 23:55, 29 November 2021 (UTC)
Aren't gadgets minified so you can't use ES6 (or perhaps it has to be explicitly allowed in MediaWiki:Gadgets-definition)? But if you are splitting a string into an array of characters, can't you just use .split('')? Nardog (talk) 12:27, 30 November 2021 (UTC)
ES6 is not allowed at all in gadgets as of now. Someone needs to rewrite MW's user-js validator (which is different from the minifier which does support ES6 now) before that's a possibility. – SD0001 (talk) 13:16, 30 November 2021 (UTC)
No, that'll still separate the surrogate code units: "💕".split("") yields [ "\ud83d", "\udc95" ]. — Eru·tuon 18:02, 30 November 2021 (UTC)
[ ...token ] doesn't pass the linter, which is stuck on ECMAScript 5 still, but the code should work on similarly recent browsers if you replace that with Array.from(token). (The linter doesn't check properties of objects apparently.) — Eru·tuon 18:00, 30 November 2021 (UTC)

Doesn't WP provide web fonts so that articles and symbols are displayed for those who don't have font support? I don't know where to go for such things, but if that's the case, we could make templates that supply SMP symbols. A complaint with the Earth symbol (ubiquitous in astronomy in the units M🜨 and R🜨) is that some ppl still don't have proper font support, so I assume we'd need to add it to our web-font set somehow. Also, it seems that the fonts in some Mac products have the symbol, but display it incorrectly. I don't know if that could be addressed with web fonts. — kwami (talk) 02:37, 30 November 2021 (UTC)

WP does not do so, no. Izno (talk) 03:54, 30 November 2021 (UTC)
TemplateStyles supports the @font-face rule, but to avoid templates redefining fonts in use elsewhere on the page, the font-family property must start with TemplateStyles. Thus the Toolforge font server proxy for Google's font server can't be used to serve the font, as it doesn't let you rename the font-family property to something other than the name of the font being downloaded. To avoid accessing a non-WMF controlled server, someone would have to host an appropriate font on Toolforge or another WMF server. (For purposes of discussion, I'm ignoring page load efficiency issues.) isaacl (talk) 23:44, 30 November 2021 (UTC)

is there a WP report on new pages per day - (Wikistats report varies between 16 k to 200k)[edit]

about 200k versus about 16 K Wakelamp d[@-@]b (talk) 12:36, 30 November 2021 (UTC)

First one is "content" plus "non-content", second one is only "content". See the "filter by page type" near the bottom of the left-hand column. Both are by month, not by day though. Fram (talk) 12:41, 30 November 2021 (UTC)
What happened in March 2015. There were almost twice as many non-content pages created as in any other month. There was no similar spike in content pages. —  Jts1882 | talk  14:27, 30 November 2021 (UTC)
To be precise, 19 and especially 20 March 2015, no other dates. Either an error in the data, or some group of pages (some forgotten namespace) which weren't counted previousky and were added then, would be my guess. We haven't had page creating bots which went on such a rampage, so that seems out of the question. Fram (talk) 14:35, 30 November 2021 (UTC)
It was very likely caused by mass-notices like this as part of the Single User Login finalisation announcement. Here's a brief explanation of how I found it: it's possible to use index.php to go to a specific page ID. I did this iteratively until zeroing in on the date I wanted and the URL had the pay dirt. Graham87 06:22, 1 December 2021 (UTC)
(@Fram thank-you for the explanation.
That is a huge amount of non-content pages!!!! Are they from Commons or new users?? And does each new non content create 5 pages?? (4 pages (article/article history, talk/talk history)and page information?
Is there a report on articles created (reviewed by NPP, AfD, or deleted) by editor type (new, ip, experienced). I am trying to work out whether changing the new article wizard to check for reliability would help new editors. Wakelamp d[@-@]b (talk) 13:25, 1 December 2021 (UTC)
Content pages are basically just technical jargon for articles. Non content are pages that are not articles (redirects, files, help pages and so on). I am writing "basically articles" since there is no gurantee that the count is 100% accurate. The statistic page you are using has an "editor type" checkbox that shows how many articles where created by IPs, users and bots. You can post an request to Wikipedia:Request a query if that data is not sufficent for your needs.--Snævar (talk) 18:25, 1 December 2021 (UTC)
Thank-you for explaining this. It made me realize that 200 K per month should not be compared to the number of new articles, but to the number of existing articles if they are redirects and help.... but it's still a lot. If I find something interesting I will report back. Wakelamp d[@-@]b (talk) Wakelamp d[@-@]b (talk) 23:19, 1 December 2021 (UTC)

Reporting 503 Service Unavailable / Edward Bett's Find Link Tool[edit]

From sometime yesterday (or maybe longer)

getting the 503 error. Helpful to de-orphan articles. Not sure where to notify so posting here. JoeNMLC (talk) 14:56, 30 November 2021 (UTC)

After further investigating, I found User talk:Edward/Find link so will notify there. JoeNMLC (talk) 15:12, 30 November 2021 (UTC)
@JoeNMLC: I had the issue as well, but it seems to be resolved now. GoingBatty (talk) 06:04, 1 December 2021 (UTC)

Archival bot only archives to one archive[edit]

Hello! So I've noticed that on Talk:Roblox, the archival bot only seems to be archiving convos to Talk:Roblox/Archive 1, despite there being Archives 2-5. Anyone know why it's doing this or if it's completely normal? ― Blaze The WolfTalkBlaze Wolf#6545 15:22, 30 November 2021 (UTC)

The MiszaBot instructions in the header are asking the bot to use Archive 1. This seems unusual, given that *five* archives exist. As of late 2020 the bot was still putting things in Archive 5. Somebody must have changed the instructions between then and now. EdJohnston (talk) 15:47, 30 November 2021 (UTC)
@EdJohnston: How odd. Would it be a good idea to change it at this point, and if so how would i do so? ― Blaze The WolfTalkBlaze Wolf#6545 16:01, 30 November 2021 (UTC)
The correct archiving was removed in this edit (presumably by accident), & when added back in this later edit the counter wasn't set appropriately. --David Biddulph (talk) 16:10, 30 November 2021 (UTC)
Ah ok. I would assume it wouldn't be a good idea to move all archives added to the first archive after it was added back to the 5th archive. ― Blaze The WolfTalkBlaze Wolf#6545 16:18, 30 November 2021 (UTC)
That's the easiest solution, & X201 has done it & corrected the counter. --David Biddulph (talk) 16:20, 30 November 2021 (UTC)
I've moved the articles incorrectly archived in Archive 1 to Archive 5 so that they're in chronological order. everything should return to normal now - X201 (talk) 16:24, 30 November 2021 (UTC)
Alright! Thanks! ― Blaze The WolfTalkBlaze Wolf#6545 18:05, 30 November 2021 (UTC)

Bug with "new topic"[edit]

  1. Create a new section ending in <!--
  2. Create another new section
  3. Bug: "another new section" doesn't display (is commented out).  AltoStev (talk) 16:50, 30 November 2021 (UTC)

That's not a bug. What else would you expect to happen? – SD0001 (talk) 16:52, 30 November 2021 (UTC)
It should autoclose the comment? Plus, when editing in the new section it shows my signature, but the ~~~~ doesn't turn into my signature, contrary to expectation, making sinebot autosign for me.  AltoStev (talk) 17:01, 30 November 2021 (UTC)
It may confuse some users but it's not a bug. Sometimes you want to comment out a significant part of a page including section headings. And should removal of a section heading suddenly comment out previously displayed text after the removed heading? That would also be confusing. Preview always shows the previewed text by itself. What else should it do? Many types of open tags, references, template limits and so on can affect how it looks in context when it's saved. As long as discussion pages work as whole wiki pages and not separate posts, we have to live with things like this. There has been attempts to rework discussions with new software but the implementations have been unpopular so far. PrimeHunter (talk) 18:08, 30 November 2021 (UTC)
I would characterize this scenario as garbage in, garbage out, in addition to what's already been said. Legoktm (talk) 18:27, 30 November 2021 (UTC)

Fractionally interesting[edit]

I note that Garsdale is 51+14 miles (82 km) miles from Carlisle. However, when I hover over the link, the mileage displays as "51+1/4", which is the raw text entered into the {{Convert}} template. Is there an issue with how templates are evaluated for rollover text? The template must be working, as the conversion to kilometers is present.--Verbarson (talk) 19:51, 30 November 2021 (UTC)

It uses TemplateStyles to display the fraction, which presumably do not load in page previews. Kleinpecan (talk) 19:58, 30 November 2021 (UTC)
Actually no bug for PagePreviews yet, though there are other incompatible systems documented (MediaViewer and indicators currently of this particular sort, Notifications of a separate sort). Izno (talk) 20:11, 30 November 2021 (UTC)
The wikitext is {{Convert|51+1/4|mi|km|0}} which renders as: 51+14 miles (82 km). Special:ExpandTemplates shows it produces: <templatestyles src="Fraction/styles.css"></templatestyles><span class="frac" role="math">51<span class="sr-only">+</span><span class="num">1</span>⁄<span class="den">4</span></span> miles (82 km). Template:Fraction/styles.css has code to hide sr-only (screen reader-only) from view. I don't know whether there is a way to include '+' in screen readers (where it's needed to make sense?) but exclude it from Page Previews. PrimeHunter (talk) 22:29, 30 November 2021 (UTC)
Another feature of the "+" is that if text is copied from the rendered article, the fraction will be pasted as "51+1/4" except that I've used a plain slash so it shows what characters are involved, whereas it's actually a fraction slash which causes many browsers to display it as a fraction, like so: "51+1⁄4". Johnuniq (talk) 23:09, 30 November 2021 (UTC)

Website showing as dead[edit]

I'm having an issue with an editor who sourced content using this source. This website shows up as out-of-service, though the editor claims it's a valid and working website. The discussion is at User talk:Magnolia677#Allen Texas Election History Edit Reversion. If anyone there is able to check the site I would appreciate it. Thank you very much. Magnolia677 (talk) 23:39, 30 November 2021 (UTC)

I tried going on the site. Saw a 404 error. So i checked the Wayback machine, and they seemed to have a copy - If you think a link is dead, the Internet archive is always the best place to check. Rlink2 (talk) 23:42, 30 November 2021 (UTC)
That specific webpage is live for me. Izno (talk) 23:47, 30 November 2021 (UTC)
I know that some websites can only be accessed from certain geographic areas, but I also tried using a US based proxy and it still didn't work. Odd. Thank you for your help, and for the link to the wayback machine. Magnolia677 (talk) 23:50, 30 November 2021 (UTC)

Help in mobile view[edit]

Hello! I recently imported {{Infobox military person}} to my homewiki (SqWiki). It works perfectly fine on desktop view. However, when rendered on articles on mobile view, the name of the person appears aligned left (instead of being centered). You can check for yourself on any article here when switched to mobile view. I checked some articles here and the same effect didn't happen here. Any idea what might be causing that? My experience with the mobile aspect is almost 0. - Klein Muçi (talk) 00:46, 1 December 2021 (UTC)

The hidden CSS is in MediaWiki:Mobile.css. If at all possible to wait, wait for Module:Infobox to be moved from global CSS to WP:TemplateStyles. (I might be busier than not sooner rather than later, so I don't know when that might be happen.) See also MediaWiki talk:Common.css/to do#Infobox. Izno (talk) 00:51, 1 December 2021 (UTC)
That said, I can maybe help you clean/sort out your local templates/modules so you don't have to wait. --Izno (talk) 00:54, 1 December 2021 (UTC)
Nope, looking over what's there, it will take a little more work than I'm willing to invest on it to clean it. If you can get your wiki clean, I'm willing to provide you the right CSS etc. Izno (talk) 00:59, 1 December 2021 (UTC)
@Izno, apparently that system message had never been created for us. As with the other system messages (Common.css, Common.js) I just copy-pasted the EnWiki version. It's been a while we mirror (and update periodically) the EnWiki common pages and we haven't had any problems, I doubt this will be any different. This was more or less my question: Where is the mobile version getting that extra css rule for that kind of rendering. You answered that with Mobile.css so we're good now. Thank you! :)) - Klein Muçi (talk) 01:07, 1 December 2021 (UTC)
Just for confirmation, I just checked and the specific error mentioned above is fixed. Thanks again! - Klein Muçi (talk) 01:11, 1 December 2021 (UTC)

Dynamic maps with certain OSM Wikidata items have a lot of grey markers[edit]

For a few weeks now imported route relations from OpenStreetMap also include nodes (e.g. trains stations), which makes the map a lot less intuitive to understand.

This technical change should be undone in my opinion. It only clutters the map and has no advantage to the reader. --Renek78 (talk) 10:36, 1 December 2021 (UTC)

This is phab:T292613TheDJ (talkcontribs) 10:58, 1 December 2021 (UTC)
Thanks, TheDJ!--Renek78 (talk) 21:48, 1 December 2021 (UTC)
As suggested in the phab discussion, changing geoline to geomask in {{MRT Sungai Buloh-Putrajaya Line mapframe}} removes the grey symbols (in edit preview). —  Jts1882 | talk  12:38, 1 December 2021 (UTC)
I tried it but it didn't work for "MRT Sungai Buloh-Putrajaya Line mapframe". Everything disappears. --Renek78 (talk) 21:48, 1 December 2021 (UTC)

JS: Startup module failed to load[edit]

 – Resolved by updating the common.js. Close by nom. --AXONOV (talk) 18:15, 1 December 2021 (UTC)

I keep getting the following error message shown in the browser's console under Linux/Google Chrome. I don't get it' in Firefox. It appears that the problem is chrome-specific. Clearing cache didn't help. Anyone else? --AXONOV (talk) 17:35, 1 December 2021 (UTC)

VM887:26 Uncaught SyntaxError: missing ) after argument list
    at domEval (load.php?lang=en&modules=startup&only=scripts&raw=1&skin=vector:10)
    at load.php?lang=en&modules=startup&only=scripts&raw=1&skin=vector:16
domEval @ load.php?lang=en&modules=startup&only=scripts&raw=1&skin=vector:10
(anonymous) @ load.php?lang=en&modules=startup&only=scripts&raw=1&skin=vector:16
requestIdleCallback (async)
asyncEval @ load.php?lang=en&modules=startup&only=scripts&raw=1&skin=vector:16
work @ load.php?lang=en&modules=startup&only=scripts&raw=1&skin=vector:17
enqueue @ load.php?lang=en&modules=startup&only=scripts&raw=1&skin=vector:11
load @ load.php?lang=en&modules=startup&only=scripts&raw=1&skin=vector:19
(anonymous) @ load.php?lang=en&modules=startup&only=scripts&raw=1&skin=vector:63
(anonymous) @ load.php?lang=en&modules=startup&only=scripts&raw=1&skin=vector:64
Show 8 more frames

--AXONOV (talk) 17:35, 1 December 2021 (UTC)

@Alexander Davronov: first turn off all of these: User:Alexander Davronov/common.js, User:Alexander Davronov/vector.js. Does it stop? — xaosflux Talk 18:08, 1 December 2021 (UTC)
@Xaosflux: Thanks. I've commented out and then uncommented one entry and it started to work. Weirdly. AXONOV (talk) 18:14, 1 December 2021 (UTC)

Directing users to VE or Wiki Markup help pages based on what they actually use[edit]

Our tutorial system is split into two tracks, one for Wiki Markup and the other for VisualEditor, e.g. Help:Introduction to images with Wiki Markup and Help:Introduction to images with VisualEditor. However, when pointing users to it from another page, we often end up listing both, since we're not sure what editor a given user is actually using. I suspect that this is quite confusing for many newcomers, since they may not know which editor they are using. What would need to be done to create functionality where Help:Introduction to images would redirect to either the Wiki Markup page or the VisualEditor page based on automatic detection of which editor you have set as your default in your preferences? I'm assuming it would take at least some WMF involvement, so courtesy pinging MMiller (WMF) for the Growth Team. {{u|Sdkb}}talk 21:50, 1 December 2021 (UTC)

String find bug[edit]

I've encountered a bug with {{str find}}: if it searches a page with references but no reference list, it returns them even if they're not part of the string being searched.

As an example, I set up User:Sdkb/sandbox/testpage with a simple ref. Adding the code {{Str find|{{User:Sdkb/sandbox/testpage}}|Nonexistent string}}, as I'll do below, returns -1, as it should, but also the ref, which it shouldn't. If {{Reflist}} is added to my testpage, the bug goes away. Does anyone know why this is happening or how to fix it?



  1. ^ Reference that shouldn't be appearing, The Signpost, 2021

Cheers, {{u|Sdkb}}talk 23:07, 1 December 2021 (UTC)

How about {{#invoke:String|find|source={{User:Sdkb/sandbox/testpage}} |target=Nonexistent string}} instead? ⇒0⇐ — GhostInTheMachine talk to me 23:23, 1 December 2021 (UTC)
Looks like we have the same error, so that means it's with Module:String? {{u|Sdkb}}talk 23:48, 1 December 2021 (UTC)


  1. ^ Reference that shouldn't be appearing, The Signpost, 2021
I believe that won't work either because the issue is with the code {{User:Sdkb/sandbox/testpage}}. Even if a reference is not shown, it has to be shown in a reference list in the wikitext of the page (even if the reference list is never actually outputted) or else if will default to being displayed at the bottom of the page. In your case you should be able to use {{Str find|{{User:Sdkb/sandbox/testpage}}{{#if:<references />}}|Nonexistent string}}. The reference list in the {{#if}} functions first field will still prevent the reference from being shown at the bottom of the page (or another reference list), but it won't be outputted to the page because the first field of a {{#if}} function is not shown. It should be noted that any references defined earlier on the page will also be added to the invisible reference list. BrandonXLF (talk) 23:49, 1 December 2021 (UTC)
BrandonXLF's solution is an amazing trick but the underlying problem (not a string find bug) is easy to see. This section of VPT contains the following
{{Str find|{{User:Sdkb/sandbox/testpage}}|Nonexistent string}}
That means the wikitext from User:Sdkb/sandbox/testpage is processed as if it were in this section on this page. That wikitext contains a reference and MediaWiki always displays the reference unless there is a references tag to show where the references should go. Johnuniq (talk) 02:43, 2 December 2021 (UTC)

Ping question[edit]

Are pings working fine or did I do something wrong here and here? I didn't get a notification for either edit. Daß Wölf 18:41, 2 December 2021 (UTC)

Are you referring to a notification about outgoing pings if you have enabled "Successful mention" at Special:Preferences#mw-prefsection-echo? I think the first diff should work but maybe the software has become smarter at detecting copies of old posts to avoid pinging everybody who is linked there, e.g. in old signatures. The second diff didn't add new lines so it shouldn't ping per mw:Manual:Echo#Technical details. PrimeHunter (talk) 21:23, 2 December 2021 (UTC)

SVG Political World Map[edit]

why is the SVG Political World Map in this image within World map article, blurred?. Gfigs (talk) 10:14, 3 December 2021 (UTC)

I think it just renders a PNG thumbnail until you click on it. A thumbnail is of course smaller, and PNG is raster not vector, thus the blurring. Size of this PNG preview of this SVG file: 800 × 407 pixels.)Novem Linguae (talk) 07:26, 4 December 2021 (UTC)
thanks, have downloaded the SVG (6.53mb), opened it in the browser (Chrome mobile), zoomed in, and it's blurred..why should this be?. Gfigs (talk) 08:54, 4 December 2021 (UTC)
Looks fine in my browser, Google Chrome, which only goes to 500% zoom. But once I open it in Inkscape and go to 3000% zoom, I see what you mean. I suspect that someone copy pasted a raster image into the SVG, instead of doing it properly with vectors. That is likely the source of the pixellation. Screenshots.Novem Linguae (talk) 09:20, 4 December 2021 (UTC)
ok, thank you.. Gfigs (talk) 09:54, 4 December 2021 (UTC)
It's not a true SVG, but a JPEG image that has been wrapped in some SVG code:
<svg xmlns="" xmlns:xlink="" width="1920" height="976.63" viewBox="0 0 1440 732.47" version="1.2" id="svg8">
    <defs id="defs3">
        <image id="image5" width="8192" height="4166" xlink:href="data:image/jpeg;base64,..."/>
    <g id="surface1" transform="scale(.12534)">
        <use xlink:href="#image5" transform="scale(1.40247 1.40278)" id="use5" x="0" y="0" width="100%" height="100%"/>
That ellipsis in the <image /> tag on line 3 is where I have removed the base64 data of the JPEG, which is huge. Since the entire displayable content of this alleged SVG consists of that JPEG, it's no surprise that quality is lost at different scales. --Redrose64 🌹 (talk) 17:42, 4 December 2021 (UTC)
I've marked it as a fake SVG on the Commons description page. Elli (talk | contribs) 17:47, 4 December 2021 (UTC)
I think it's CIA agent M.Bitton who posted it..xx? Gfigs (talk) 04:46, 5 December 2021 (UTC)

Conditionals in template[edit]

"I am trying to learn some advanced tempalate editing but code-ese at is too much :(

In the infobox-like template I am desigining, I want to have a paramter, let's say nationality. Based on that, I'd like to display a flag icon and the name of the country in a given color. I got the fisrt part, with the right thumb displaying, but I can't get the text part to work.

The code is |[[File:{{{Nationality}}}.png|thumb|40px|center]]<br/><small><center>{{#if:{{{Nationality|}}}=Polish|{{!}} style="color: white";{{{Nationality}}}|}} {{#if:{{{Nationality|}}}=Russian|{{!}} style="color: red";{{{Nationality}}}</center></small>

Clearly I am messing somethign wrong, but I after one hour of monkeying with the code I couldn't find the way to make this work. The thumb is displayed (for files Polish.png / Russian.png) but instead of getting the text Polish or Russian in white/red I am getting the string "| style="color: #AFE1AF";Polish" displayed instead. FYI the current version of the template should accomodate four nationality-like parameters.

Can anyone fix this code? Thanks in advance, and please ping me if you reply here. Piotr Konieczny aka Prokonsul Piotrus| reply here 11:57, 3 December 2021 (UTC)

Do you have a /sandbox setup where the code you are working on is there? That will help. Unrelated to the code, but specific to your example, please see MOS:INFOBOXFLAG and MOS:FONTSIZE. Gonnym (talk) 12:14, 3 December 2021 (UTC)
{{#if:{{{Nationality|}}}=Polish - the way the if syntax works here is like this: {{#if: checks if the parameter is not empty | do if true | do if false }}. There is no "if something=something" like in other languages. Gonnym (talk) 12:18, 3 December 2021 (UTC)
There is {{#ifeq:{{{Nationality|}}}|Polish|do something|else}}. —  Jts1882 | talk  12:43, 3 December 2021 (UTC)
@Jts1882 @Gonnym Thank you. The simple design which I am using to teach myself template coding is here: User:Piotrus/sandbox#Template_test displays the tiny template at User:Piotrus/Templates/Test. Any idea how to make it display Polish/Russian/German etc. in specific colors? When the parameter nationality=Polish, use color A, when =Russian, color B, etc. Piotr Konieczny aka Prokonsul Piotrus| reply here 13:01, 3 December 2021 (UTC)
If your want more countries, you wight want to look at {{#switch|{{{Nationality|}}}| ... }}(see Help:Conditional_expressions##Using_#switch). —  Jts1882 | talk  13:10, 3 December 2021 (UTC)
@Piotrus: You were looking at the wrong MediaWiki page. is a template created at the MediaWiki wiki, just like we create templates here. It is not part of the MediaWiki software and does not have documentation of MediaWiki parser functions like #if and #ifeq. For that, see mw:Help:Extension:ParserFunctions. As others say, you can make comparisons with #ifeq and #switch but not with #if. PrimeHunter (talk) 18:05, 3 December 2021 (UTC)
@PrimeHunter @Jts1882 Thanks! Any chance an experienced coder could fix my code at User:Piotrus/Templates/Test so that I can see how a proper code for making text colored and switching it would look in the wiki code? Piotr Konieczny aka Prokonsul Piotrus| reply here 18:38, 3 December 2021 (UTC)
@Piotrus I added a #switch statement to your template test. It should be fairly self-explanatory. The lines without an equals sign use the values of them line below them, and the #default line is used if none of the other lines match. See mw:Help:Extension:ParserFunctions##switch for more. --Ahecht (TALK
) 21:15, 3 December 2021 (UTC)

Mouseover tooltips[edit]

We're working on detecting when you are hovering your hand over your phone, but need a bit more access to your device first! xaosflux Talk 19:27, 3 December 2021 (UTC)

Is it possible, when editing with a mobile device, to hover over a link to discern tooltips and other navigation popups? If so could someone tell me how or suggest a link that will? Thank you.--John Cline (talk) 14:16, 3 December 2021 (UTC)

Basically no, this is one reason tooltips should never be used to provide critical information. Izno (talk) 18:45, 3 December 2021 (UTC)
Navigation popups will display for me on mobile (android, firefox) when I hold down on the link to bring up the link menu, then exit the menu (after which the popup will appear). Enterprisey (talk!) 20:25, 3 December 2021 (UTC)
Thank you for sharing your insight with me; I've learned a valuable thing from each of you! Izno, I think you are correct about tooltips being practically indiscernible to those interfacing with a mobile device (like me) and your caution regarding its use is sound and sage. Enterprisey, the method you've outlined that works for you (regarding navigation popups and link previews) also works for me (using Android, Chrome) quite efficient and well. And Xaosflux, for showing that you are not only a wizard at all things technical, but also pretty darn keen at spotting "gaffe of the week" contenders and apportioning fame where it's due. To ensure the most mileage possible: I wouldn't have noticed my error in context had you not made it clear (in good faith, spirit, and taste). I had counted myself ahead on that by not using "mouse over". If it's good to chuckle at yourself every now and then, I got that chance today. Best regards.--John Cline (talk) 14:00, 4 December 2021 (UTC)

Links to page on non-English Wikipedias[edit]

Is there any way to achieve link like Mix 1 [de] or no link with Template:Interlanguage link? Eurohunter (talk) 23:13, 3 December 2021 (UTC)

Do you mean {{ill|GfK Entertainment charts|de|Mix 1}}? The [de] part does not show here, because enwp has an article called GfK Entertainment charts. We only show the non-English link if there is no English article. Certes (talk) 23:30, 3 December 2021 (UTC)

Page Info gadget[edit]

Page Info gadget seems to be broken, I see an animated dot, moving horizontally, instead of page views per month, and other statistics. .... 0mtwb9gd5wx (talk) 03:07, 4 December 2021 (UTC)

What do you mean by "Page Info gadget"? Please always include an example. PrimeHunter (talk) 05:44, 4 December 2021 (UTC)
Do you mean the XTools gadget? (MediaWiki:Gadget-XTools-ArticleInfo.js). If it is unable to load its info, it moves a dot back and forth horizontally. It's working for me at the moment. –Novem Linguae (talk) 06:17, 4 December 2021 (UTC)

Can anyone help with a calculation tool?[edit]

I'm currently looking at the copyright expiry year in the US in relation to photographs taken in Australia. The policies involved are quite complex, and I'm keen to simplify the task with a calculator on a How-to page. It will be a crucial tool for ensuring accuracy in establishing the correct date, with all its variations, for many years.

I would be most grateful for expert help. Details are in my sandbox.  Cheers, Simon – SCHolar44 🇦🇺 💬 at 12:46, 4 December 2021 (UTC)

I don't know if it's possible to do it as a calculator on a wiki page (although someone more knowledgeable than me is welcome to weigh in). The methods that come to mind are 1) a template that uses a module, 2) a user script, or 3) an off wiki website (hosted on ToolForge perhaps). Are you interested in one of those? –Novem Linguae (talk) 12:59, 4 December 2021 (UTC)
Thank you for your prompt response, NL. This is entirely outside my field in Wikipedia, so I'm not sure how to respond to your questions -- except perhaps not to favour #3. Maybe it's best to wait till some others chime in. Thanks again, SCHolar44 (talk) 13:03, 4 December 2021 (UTC)
It appears from commons:Commons:Copyright rules by territory/Australia that the rules are more complicated and you need more information. PrimeHunter (talk) 14:09, 4 December 2021 (UTC)
You're spot on (of course), PrimeHunter. But rather than provide a lot more detail that would unnecessarily take up the time of someone who could create the calculation tool, I specified only enough to allow me to expand it with the necessary extra detail. Thank you for your interest. SCHolar44 (talk) 00:02, 5 December 2021 (UTC)
Also: as mentioned, the tool is intended to determine copyright expiry years in the US in relation to photographs taken in Australia -- which is significant for acceptibility in Commons and alternatively for applicability of fair use in Wikipedia. For example, the passing of the 1996 URAA date is significant for Australian images made between 1946 and 1954 inclusive -- when expiry in the US jumps to 95 years -- whereas before and after that, the US copyright expires 70 years after creation. The tool is intended to eliminate mistakes and make clear which policy applies in a particular year, which otherwise involves combing through the grinding detail. SCHolar44 (talk) 00:39, 5 December 2021 (UTC)
MediaWiki doesn't have interactivity like this with the currently installed extensions. I think an on-wiki tool would require a user script or a less elegant preview-based interface like Calculate which uses Special:ExpandTemplates to preview a call of User:PrimeHunter/Copyright expiry Australia. PrimeHunter (talk) 01:09, 5 December 2021 (UTC)
Thank you, PrimeHunter! Seems a good approach to me -- as long as something works and isn't too difficult for the user, I'm not concerned about the appearance. SCHolar44 (talk) 01:22, 5 December 2021 (UTC)

Any way to enable navigation popups across wikis?[edit]

Hi all, does anyone know if it's possible to enable navigation popups across wikis, without having to go into the preferences? I often go to other projects chasing LTA socks, and it's quite a pain that I have to enable popups on all those wikis. I once tried adding the following to m:Special:MyPage/global.js but it didn't work.

// Navigation popups on all wikis (?)

I would appreciate any help. --Dragoniez (talk) 19:32, 4 December 2021 (UTC)

Try mw.loader.load(''); along with mw.loader.load('', 'text/css');SD0001 (talk) 20:26, 4 December 2021 (UTC)
@SD0001 Worked like a charm! Thank you. --Dragoniez (talk) 20:47, 4 December 2021 (UTC)
The longer answer as to why that version doesn't work is because importScriptURI is deprecated on all wikis and removed on most/all. SD's is the way forward. Izno (talk) 21:49, 4 December 2021 (UTC)
@Izno: Thanks for your comment. I now see why. But actually, I once tried replacing importScriptURI with mw.loader.load to see if it works but it didn't, so I'm guessing it was pretty much more like a matter of the css script. --Dragoniez (talk) 07:00, 5 December 2021 (UTC)