Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Quiddity (talk | contribs) at 18:57, 6 November 2023 (→‎Highly visible mobile bug: strike error, note correction). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts
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).

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.

Edit conflicts with myself

I saw this after an unintentional mouse double-click

Something annoying has started happening lately; this has happened to me multiple times in the last several days.

I click undo to undo another editor's edit, and check the diff, then when I click save I see:

"Someone else has changed this page since you started editing it, resulting in an edit conflict."

That someone else was me, and my edit was successfully saved, despite this message popping up telling me otherwise! wbm1058 (talk) 15:44, 25 October 2023 (UTC)[reply]

Do you have a cheap mouse that sometimes gives you two clicks when one would have been enough?
—Trappist the monk (talk) 17:20, 25 October 2023 (UTC)[reply]
No, I was on my desktop using a wireless Microsoft mouse; my biggest issue with it is that it burns through batteries too quickly. I suppose I could try intentionally double-clicking to see whether that duplicates the issue. But I've been using the same mouse for years and don't recall having the problem until recently. Is there such a thing as an expensive mouse? Could also be an issue with too many tabs open and bots running using up memory or something. I'd suggest that before claiming "someone else" that the software could do a quick checkuser to confirm that it really was someone else though. – wbm1058 (talk) 13:17, 26 October 2023 (UTC)[reply]
OK, I confirmed the cause. My intentional double-click saving the above post duplicated the problem. Wikimedia software should check the user ID or IP address and just ignore the second click when they're the same. – wbm1058 (talk) 13:21, 26 October 2023 (UTC)[reply]
Adding a screenshot. The software is obviously confused. The "Stored revision" is exactly the revision before I clicked Publish changes. "Your text" is exactly the change I published. It did publish this change before putting up the Edit conflict: Wikipedia:Village pump (technical) page on my PC. If this is coming from my second click, then why isn't the "Stored revision" what my first click saved, and why wasn't my second click treated as a null edit? wbm1058 (talk) 14:19, 26 October 2023 (UTC)[reply]
@Wbm1058: What browser are you using, and on what OS? And are you using the WP:WikEd gadget? This is possibly related to Wikipedia:Edit filter noticeboard/Archive 12#Filter 1253: False positive ratio. I've never been been able to reproduce this (long-standing) self-conflict bug, or the filter bug, in Firefox on Linux. Suffusion of Yellow (talk) 20:01, 27 October 2023 (UTC)[reply]
No, I haven't used WikEd in years. I still have some WikEd stuff in my common.css from back when I did some work for another user. Heh, I'm still running Windows 7 and the last version of Google Chrome that runs on 7. I like and still use the Windows Media Center even though it's lost its program directory. And I'm proud that the PC I built from parts (BYOPC) thirteen years ago is still cooking. I don't really know what I'm missing by not having a Windows 11 machine, and I had a machine that ran Ubuntu, which I never came to like as much as Windows, until it died on me. I think I'm gonna get a new rechargeable mouse now that I see that's an option. – wbm1058 (talk) 22:40, 27 October 2023 (UTC)[reply]

OK, found this in the source:

                                $this->isConflict = true;
                                if ( $this->section === 'new' ) {
                                        if ( $this->page->getUserText() === $requestUser->getName() &&
                                                $this->page->getComment() === $this->summary
                                        ) {
                                                // Probably a duplicate submission of a new comment.
                                                // This can happen when CDN resends a request after
                                                // a timeout but the first one actually went through.
                                                $editConflictLogger->debug(
                                                        'Duplicate new section submission; trigger edit conflict!'
                                                );
                                        } else {
                                                // New comment; suppress conflict.
                                                $this->isConflict = false;
                                                $editConflictLogger->debug( 'Conflict suppressed; new section' );
                                        }
                                }

Can someone with logstash access check if wbm1058 is triggering lots of Duplicate new section submission; trigger edit conflict!" errors? That would at least narrow down part of the problem (but still doesn't explain why this could happen when undoing an edit). Suffusion of Yellow (talk) 23:37, 28 October 2023 (UTC)[reply]

I admit my Logstash skills aren't great, but at quick glance I only found a single entry in the "EditConflict" channel over the past two weeks, and it was not from wbm1058 or even on this wiki for that matter. Here's a permalink for those who have access. There definitely have been more edit conflicts than that, so clearly my query is wrong, or these are intentionally not getting logged. Sorry I'm not of much help! I suggest reaching out to the Editing team or simply filing a bug if this persists. — MusikAnimal talk 15:44, 31 October 2023 (UTC)[reply]

Update: I bought and started using a $99 rechargeable "gaming (Esports)" mouse (plus: it has "forward" and "back" buttons. minus: now another USB port is tied up, as mouse and keyboard have separate receivers). I tried intentional double-clicks a couple times yesterday, and they worked fine (second click ignored). But then late last night, I unintentionally double-clicked on a "rollback" link, and saw the screenshot posted above. I was tired, miffed at the vandal, whatever, my aging finger got "twitchy". Is there ever a valid use for double-clicks on MediaWiki? I know that some software supports them. If there is never a valid use then whatever the software front end is that's receiving my mouse signals should just ignore any signal received say, less than a second after another signal. – wbm1058 (talk) 12:59, 1 November 2023 (UTC)[reply]

Edit count

I'm not happy with the public disclosure of my edit count in my contributions as if edit count is a defining feature of an editor's worth. The vast bulk of my edits were done as a virtual bot over ten years ago. I think I and other editors should have the right not to disclose our edit count to the general public in our preferences.♦ Dr. Blofeld 13:47, 30 October 2023 (UTC)[reply]

The feature was added under phab:T324166. --Redrose64 🌹 (talk) 14:43, 30 October 2023 (UTC)[reply]
I understand your wish but the problem is the assumption that lots of edits = worthy person. My edits are also mainly minor but, for those who make such misjudgements, my edit count flatters rather than upsets me. I'd be more worried about someone who has a few dozen edits, each one a decent article which took weeks to write, but is mislabelled as an insignificant newbie. Certes (talk) 15:00, 30 October 2023 (UTC)[reply]
No new private information is being disclosed here, Special:Contributions has always been able to identify all of someone's edits and anyone would have been able to readily count them at any time. As far as the concept of being able to hide your quantity of edits from review - the quantity is simply a side effect of them existing, and having all of your contributions transparently available to any and everyone is a core principal of the project. — xaosflux Talk 15:07, 30 October 2023 (UTC)[reply]
User contributions also have edit count links. If you don't want to see the edit count of other users directly on their contributions page then add this to your CSS:
.mw-contributions-editor-info {display:none;}
It also hides the account creation date which doesn't have a separate class. I don't expect there would be support for adding this to the default CSS of the English Wikipedia. If we want to give users a choice to hide their own count from others without a MediaWiki change then it would require extra JavaScript to run for all users. I don't think this purpose is worth that. And without a MediaWiki preference the choice would have to be stored somewhere else like a user subpage or a central list. PrimeHunter (talk) 16:15, 30 October 2023 (UTC)[reply]
Thanks PrimeHunter, yes it's not something I want to see for other editors either! The point though Xao is that I don't mind people checking if they really want to, but I disagree that it's necessary to disclose this information to everybody every time they click on an editor's contributions, and would argue that it actually runs the risk of worsening Editcounteritis and people trying to quickly notch up a lot of edits to look more valued on here. ♦ Dr. Blofeld 17:26, 30 October 2023 (UTC)[reply]
@Dr. Blofeld if there is consensus, we could hide this client-side for all users via local CSS hack. Personally, I'd be opposed to that on the basis of not including more display hacks that could cause page jumping, but it could gain support. — xaosflux Talk 17:45, 30 October 2023 (UTC)[reply]
It was well-supported at the community wishlist survey in 2022. –Novem Linguae (talk) 18:29, 30 October 2023 (UTC)[reply]
@Xaosflux: For that matter, if we wanted to we could edit MediaWiki:contributions-edit-count to prevent the count from being included in the first place. Anomie⚔ 19:53, 30 October 2023 (UTC)[reply]
@Anomie yup, that would turn it off for everyone. We could also add some hint text in there, such as to Wikipedia:Edit count that explains the subject more. @Dr. Blofeld - think adding such a link would help? — xaosflux Talk 20:00, 30 October 2023 (UTC)[reply]
And of course, the link parser doesn't work there - so if we want this to be anything other than plain text we will need a feature request (unless Novem Linguae wants to just start working on this some more :D ) — xaosflux Talk 20:12, 30 October 2023 (UTC)[reply]
Perhaps it would be worth a debate to see what the general outlook is, given a possible risk of it encouraging editcounteritis, even if people generally don't find it invasive. The problem with disclosing raw edit count is that it doesn't say anything about what you've edited and type or quality of edits and puts AWB or bot-type mass edits and talk/wiki page edits on par with really substantial content additions to the project. I think I have less than 100k edits in the last 13 years on here!♦ Dr. Blofeld 17:54, 30 October 2023 (UTC)[reply]
I would say though that most editors have WP:POPUPS installed which by default shows the edit count of any user by simply hovering over them. So I don't know how much of a difference this makes. Galobtter (talk) 17:49, 30 October 2023 (UTC)[reply]
Personally it's quite useful. Knowing a user's general experience helps phrase any questions I need to ask them. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 18:00, 30 October 2023 (UTC)[reply]
There are a lot of editors not using the navigation popups gadget. As of the moment I checked, Special:GadgetUsage shows the navigation popups gadget has been enabled by 58,581 users (other than the default gadgets, topped only by the dark mode toggle). According to Special:Statistics (again, as of the moment I checked), there are 122,331 active users (usres who have performed an action in the last 30 days). (The first number divided by the second is 48%, but that's an upper bound, since the first number isn't restricted to active users.) isaacl (talk) 23:04, 30 October 2023 (UTC)[reply]
Just a quick note that "Show edit count at Special:Contributions" was #45 on the community wishlist for 2022 and had 48 supports. The change seems well-supported. Although as the person that wrote the code for it, I am sorry that the change bugs you. –Novem Linguae (talk) 18:26, 30 October 2023 (UTC)[reply]
That's odd as in my experience on here there is usually a significant consensus to hide edit counts and discourage people from viewing figures to the point that the old tables were replaced with placeholders or even deleted. Not your fault NovemLingae, if you were following consensus, but I'm surprised that only Bilorv raised a point about its value. and nobody even showed a concern about it potentially encouraging edit counteritis. ♦ Dr. Blofeld 19:10, 30 October 2023 (UTC)[reply]
To be fair, the software change for this, and the large support referenced - was for a mediawiki feature, used on all WMF's 800+ projects and non-WMF instances - it wasn't about enwiki; we just get the feature like everyone else does. — xaosflux Talk 19:53, 30 October 2023 (UTC)[reply]
the old tables were replaced with placeholders or even deleted WP:EDITS isn't hidden, it's updated daily. --Redrose64 🌹 (talk) 19:55, 30 October 2023 (UTC)[reply]
I must be thinking of Article count then? I could have sworn Edit count was turned into placeholders too. ♦ Dr. Blofeld 21:01, 30 October 2023 (UTC)[reply]
As a demonstration of a possible CSS solution, User:PrimeHunter/Hide edit count.css hides the edit count for a hard-coded list of users who have requested it, currently only Dr. Blofeld. I'm not sure where this will go in the future. Users who want to respect the requests could install it with this in your common JavaScript: 
importStylesheet('User:PrimeHunter/Hide edit count.css'); // Linkback: [[User:PrimeHunter/Hide edit count.css]]
There will probably be very few users who install it unless it becomes a gadget or included in something widely used. The edit count will be hidden from Special:Contributions/Dr. Blofeld which is linked in several places in the MediaWiki interface, but not from https://en.wikipedia.org/w/index.php?title=Special:Contributions&target=Dr._Blofeld which is linked by some tools. I don't know whether MediaWiki itself makes any links to the latter. PrimeHunter (talk) 20:53, 30 October 2023 (UTC)[reply]

This is apropos of nothing, but back in the day, when SomethingAwful posters were starting to let post count get to their head, they made it so that posting in fyad made your post count go down by one every time you did it. Maybe we can do the same with the drama boards etc ;^) jp×g🗯️ 10:12, 3 November 2023 (UTC)[reply]

edit counts can be misleading, but hiding them seems to flaut the spirit of openness and verifiability .... 0mtwb9gd5wx (talk) 04:24, 4 November 2023 (UTC)[reply]
  • Just a driveby note to say as an admin I find this change extremely useful. It enables me to check whether editors or patrollers I don't recognise are experienced or not, without having to wait for tools to load or click further. Espresso Addict (talk) 00:31, 5 November 2023 (UTC)[reply]

Slack vulnerability via Wikipedia

This article, dated yesterday at Security Week ("Attackers Can Use Modified Wikipedia Pages to Mount Redirection Attacks on Slack"), seems concerning and maybe to be something Wikipedia can help with. What say you?  SchreiberBike | ⌨  12:35, 31 October 2023 (UTC)[reply]

@SchreiberBike: Unfortunately it's unlikely Wikipedia (or Medium, as the article mentions) can do anything to help — this sounds like an issue with Slack more than anything. — TheresNoTime (talk • they/them) 12:52, 31 October 2023 (UTC)[reply]
The Wiki-Slack Attack requires 2 conditions: the Wikipedia article be formatted in a particular way. And lots of pages this way. The formatting requirement has two elements. A footnote at the end of the first paragraph - which is impossible to detect since that's normal. It also requires "the first word of the second paragraph is a top-level domain (TLD)". Unclear what that means, like ".com" or "com" or "foo.com" or "Com". Even if it's not our job to fix Slack's problem, "we" (bots?) could monitor for it to prevent what is essentially vandalism. -- GreenC 13:37, 31 October 2023 (UTC)[reply]
The original vulnerability description goes into more detail; the researchers say they found over a thousand natural occurrences of the pattern (not maliciously) exposing Slack to its preview bug. By the nature of the bug, it looks quite indistinguishable from legitimate edits. This seems to pretty clearly be a Slack vulnerability, not Wikipedia. StereoFolic (talk) 14:00, 31 October 2023 (UTC)[reply]
Thanks for the link. Yes confirmed with Slack and Lemmatization, this is a thing. User:TheresNoTime is correct, this needs to be resolved by Slack. They have been sending pop-up notices for the past few days of a forced update coming soon, could be related. -- GreenC 14:15, 31 October 2023 (UTC)[reply]
Looks easily fixable by Slack. They should change their algorithm to replace line breaks with spaces instead of just deleting them. With a space in between "form." and "In", their linking algorithm wouldn't get confused anymore. –Novem Linguae (talk) 15:14, 31 October 2023 (UTC)[reply]
The link destination isn't exactly hidden. The victim sees a blue link such as (in the Lemmatization example) form.In and, although that style normally leads to another Wikipedia article, they can't have too many complaints if clicking it takes them to the form.in domain. Certes (talk) 15:28, 31 October 2023 (UTC)[reply]
Perhaps I'm missing something, but this seems like a Rube Goldberg way to achieve the same result as <span class="plainlinks">. I'm struggling to see how "user clicking on a link is taken to the target of the link" is a even a security flaw. I stopped reading the esentire article at Browser-based attacks are a new underestimated threat surface... what what what? "New"? Have these people never heard of Internet Explorer? Suffusion of Yellow (talk) 21:14, 31 October 2023 (UTC)[reply]
In terms of what it does, yes. However, class=plainlinks https://evil.hacker.example.com/virus.exe is more likely to get reverted. Certes (talk) 21:19, 31 October 2023 (UTC)[reply]
Reminded of this today as I had a text reminder on my phone to remind me of an appointment "...at X Pharmacy.To change..." and the phone helpfully tried to treat that missing space as a link to "pharmacy.to". I'm pretty sure bad parsers have been doing this for a decade or two by now.
From the WP side, their description of the scaled-up threat relies on someone going around using chatGPT to rewrite high-visibility articles to get a desired pair of words in specific constrained places in the lead paragraph... I can't see that actually happening on any kind of meaningful scale? Andrew Gray (talk) 13:15, 3 November 2023 (UTC)[reply]
This appears to be a Slack problem, not a Wikipedia problem. If an app misbehaves when the words "pharmacy" and "to" appear together on the internet, the solution is not for every website owner to reword their pages avoiding that combination. Certes (talk) 14:04, 3 November 2023 (UTC)[reply]
Indeed. I guess it sounds more dramatic if the author gets to call it a WP vulnerability and give it a catchy name as a result! Andrew Gray (talk) 14:43, 3 November 2023 (UTC)[reply]

Defaulted edit window colors

Reporting that about 1/2 hour ago, my edit window colors changed to "defaults". White background, blue text, different font, font size. Timeless skin at User:JoeNMLC/timeless.css.

textarea[style] { height: 46em; color: #32cd32; font-family: 'Noto Mono'; font-size: 110%; } /* color Lime green text */

textarea { caret-color: red; }

textarea { background-color: #000000; } /* color Black */

Before posting here, I did the usual "Purge", Log Out/Log In. Regards, JoeNMLC (talk) 18:23, 1 November 2023 (UTC)[reply]

Did you accidentally turn on syntax highlighting? It will be a marker-pen-like symbol in the toolbar. (Or, the gadget or two available?) That would have dis-enabled your customizations and would explain you seeing it in blue text. Izno (talk) 19:25, 1 November 2023 (UTC)[reply]
@Izno, Yes - it was that syntax highlight. (my not so good typing) Still learning something new daily. Thanks a bunch. Cheers, JoeNMLC (talk) 19:32, 1 November 2023 (UTC)[reply]

When not signed in, three lines to left of article titles

At the top of the page, when I was on a computer where I had not yet signed in, I found that there were always three short lines to the left of the article name. That seems to have gone away. I was just curious what happened. I also tried signing in with an alternate account that I use to see what newcomers see, but that feature wasn't there.— Vchimpanzee • talk • contributions • 23:01, 1 November 2023 (UTC)[reply]

It's an icon in the default skin Vector 2022 to show the table of contents when it's hidden. It can also be seen if you are logged in. It usually remembers your choice and remains like that until you click it and select "move to sidebar". PrimeHunter (talk) 23:24, 1 November 2023 (UTC)[reply]
See Hamburger button for what it's supposed to signify in general. Nardog (talk) 23:29, 1 November 2023 (UTC)[reply]
Not quite. A hamburger button only has the lines and indicates a menu. This looks similar but also has dots and is a bulleted list icon . There is also one under "Advanced" in the default editor toolbar. PrimeHunter (talk) 00:11, 2 November 2023 (UTC)[reply]
I think this was what I saw.— Vchimpanzee • talk • contributions • 16:01, 2 November 2023 (UTC)[reply]
It's an odd choice for an icon, since they took away the useful TOC numbering in Vector 2022, and I don't know of any skins that use bullets in the TOC. See T44059 for the task that took away numbering, despite testimony from editors about its usefulness, and T307316, which is requesting an easy way for editors to see them again in Vector 2022 (i.e. easier than customizing your CSS and hoping that the developers do not change the class names in the master style sheets). – Jonesey95 (talk) 05:24, 2 November 2023 (UTC)[reply]
Perhaps this is phab:T349988 ? Jdlrobson (talk) 18:52, 2 November 2023 (UTC)[reply]

Editor stopped working

The WikEd stopped working this morning, throwing me back into the older 2005 editor. I cannot edit with that, and don't know what to do. Any help would be appreciated. Hawkeye7 (discuss) 22:23, 2 November 2023 (UTC)[reply]

Is wikEd enabled at Special:Preferences#mw-prefsection-gadgets? wikEd has a pencil icon at the top right of pages to toggle between active (yellow) and disabled (grey). Is it active? PrimeHunter (talk) 23:26, 2 November 2023 (UTC)[reply]
Yes, it is enabled at Special:Preferences#mw-prefsection-gadgets. Not seeing the pencil icon. Hawkeye7 (discuss) 23:34, 2 November 2023 (UTC)[reply]
When logged out I thought that there was an option for the Visual Editor, but that is not there either. Hawkeye7 (discuss) 23:37, 2 November 2023 (UTC)[reply]
Tracked in Phabricator
Task T350519
I'm having a similar problem where none of my user scripts are working (including scripts in Preferences). What browser are you using? The issue is occurring for me on an old version of Safari (iOS 12) but not on latest Firefox on MacOS Ventura. – dudhhr talkcontribssheher 04:36, 3 November 2023 (UTC)[reply]
Firefox 119 on both MacOS and Windows. Checked Safari - not working there either - which implies that the issue is with Mediawiki. Hawkeye7 (discuss) 06:09, 4 November 2023 (UTC)[reply]
@Hawkeye7 Your issue is possibly not dudhhr's issue given the newness of your browser. You will need to troubleshoot yourself. Clear your JS pages and turn off your gadgets (but not WikEd). If it works after a cache refresh, then we know it's not WikEd at cause. You can add other gadgets/scripts one-by-one (more quick would be a binary search - enable half and see if that works or doesn't, then repeat) until you identify the script at issue.
Instead, if it doesn't work, disable WikEd and then re-enable the rest of everything. If all those work, then the issue is with WikEd. If none of them work, it's probably the case that there is an issue in MediaWiki (and/or the one we figured out below).
Given its general level of maintenance (~0), I expect WikEd has finally keeled over. FWIW I can't get any of the functionality to display that should either in Firefox, without touching any of my gadgets besides turning off the toolbar that would impact the space directly. So I suspect that's a bad sign. Izno (talk) 17:16, 5 November 2023 (UTC)[reply]
This may help finding out what is going wrong: Locating broken scripts —TheDJ (talk • contribs) 09:57, 3 November 2023 (UTC)[reply]
I have the same problem on an old browser, PaleMoon version 29 – Popups, Preferences tabs, WikEd, subscribe links, etc etc all stopped working yesterday. In my case enabling the javascript console shows an error in load.php: SyntaxError: expected expression, got '?' in the line labelDiv.innerHTML=label.textContent??'';. A bit of googling shows that the '??' operator is the "nullish coalescing operator", which apparently isn't recognised by older browsers. I suppose it was introduced in the latest version of MediaWiki (Tech News: 2023-44 above). It's probably time to retire this old browser (all works as expected here on Firefox 118).  —Smalljim  17:17, 4 November 2023 (UTC)[reply]
This same issue would cause dudhhr's issue. I'm not sure that should be used even in the JavaScript that MediaWiki allows per mw:Compatibility supporting versions at grade A below the minimum version of that operator and a task should likely be filed if it's in core.
Since you know how, can you pick a page where that was happening, set ?debug=1 on the page and say which script/file it's coming from? Izno (talk) 18:01, 4 November 2023 (UTC)[reply]
Thanks for the reply, Izno. I did say it's in load.php – that's https://en.wikipedia.org/w/load.php (line 16178).  —Smalljim  19:22, 4 November 2023 (UTC)[reply]
@Smalljim Load.php generally isn't going to be useful since it varies based on the gadgets and scripts each user loads (basically, it concatenates the sum of all system JS, Common.js, Skin.js, personal skin.js, any preferences adding JS, and gadgets with JS). So I'm looking for a bit more context like the function that the line of interest is in, and the general context of that function.
Take for example the CSS console, you'll see load.php divided into a couple dozen pages that you can usually look at the top and get an idea of what's going on. JS console I believe does similarly. Izno (talk) 07:16, 5 November 2023 (UTC)[reply]
You can tell I don't know what I'm doing! Hopefully Nardog's reply below is what's needed, but for what it's worth, the "??" appears in the function that creates a default portlet: function addDefaultPortlet( portlet ).
If this is going to be fixed and you'd like me to check that it works in my ancient browser, just ping me.  —Smalljim  11:09, 5 November 2023 (UTC)[reply]
It's gerrit:963165 and gerrit:967991. ??, the nullish coalescing operator, is from ES2020, so I'm at a loss as to how this got in (@Jdlrobson and Jon (WMF)). Nardog (talk) 08:27, 5 November 2023 (UTC)[reply]
Thanks for the ping! Im not sure how that snuck in. Either I have been writing too much PHP or my IDE is playing up. I will get this addressed with Mo on Monday and work out why our linter didnt catch this as a follow up.
Sorry for the disruption here. Jdlrobson (talk) 15:31, 5 November 2023 (UTC)[reply]

Information.svg, linked to by eight million pages, is TEN THOUSAND BYTES?

File:Information.svg -- see how huge this is? Same for File:Information icon4.svg which is 1 kilobyte for an extremely basic shape.

Definitely big if true. But is it true? The impression I get is that it's not actually being loaded by that many pages, and MediaWiki caches a .png render which is what people actually get served, so it's not an actual 10kb image getting loaded or rendered each time a page with them on it is served. Is this a thing, or nah? jp×g🗯️ 10:14, 3 November 2023 (UTC)[reply]

MediaWiki caches png versions in different sizes. A typical use says [[File:Information.svg|30px]] and produces which loads the 1834 byte https://upload.wikimedia.org/wikipedia/en/thumb/2/28/Information.svg/30px-Information.svg.png. PrimeHunter (talk) 10:35, 3 November 2023 (UTC)[reply]
If a browser has already read it once then the browser will often read it from its own cache and not from a Wikimedia server. PrimeHunter (talk) 10:39, 3 November 2023 (UTC)[reply]
Everything that PrimeHunter says. But also, even when you do get the 10KB version by clicking the original file, you'll receive it with on the fly compression applied to it, which will reduce the size. In this case, 3050 bytes will be actually transmitted, so not that far off from that 1800 bytes of the PNG at 30px. Having said that, there are a lot of unoptimised SVGs in our file catalogue. Because of the png thumbnailing this isn't a problem, but there is a long wish by the community to remove the png thumbnailing and to allow SVG directly (something I've been working on a bit over the last year). And then this would be a potential risk that we might have to account for. The current idea is to set a limit of 50 or 100KB per SVG and if SVGs are larger than that, they would still be forced to be rendered as PNGs. —TheDJ (talk • contribs) 12:25, 3 November 2023 (UTC)[reply]

Breaking database change: pagelinks table

There is a longstanding plan to move some columns from the pagelinks table to the linktarget_table in enwiki and other databases used by Wikipedia and similar projects. Imminent release has now been announced. This change will break some regular and ad hoc database reports, Quarry queries and perhaps other software. A similar change has already taken place for templatelinks, and is planned for categorylinks in future. Certes (talk) 14:27, 3 November 2023 (UTC)[reply]

Draftification

Ever since the idea of immediately moving inadequate articles to draftspace emerged as a common alternative to deletion, the amount of time that has had to be invested in cleaning up polluted categories that have draftspace pages in them has gone way up, because the people who do the sandboxing frequently forget to remove or disable the categories in the process — so I wanted to ask if there's any way that a bot can be made to clean up any overlooked stuff.

Since there's already a bot, JJMC89bot, that detects main-to-draft page moves and tags them as {{Drafts moved from mainspace}}, the obvious thing would be to just have that bot automatically disable any categories on the page at the same time as it's tagging it — but when I directly approached that bot's maintainer earlier this year to ask if this could be implemented, they declined on the basis that the bot hadn't already been approved to perform that task, while failing to give me any explanation of why taking the steps necessary to get the bot approved to perform that task was somehow not an option. As an alternative, I then approached the maintainer of DannyS712bot, which catches and disables categories on drafts that are in the active AFC submission queue (which newly sandboxed former articles generally aren't, and thus don't get caught by it), but was basically told to buzz off and talk to JJMC89bot.

So, since I've already been rebuffed by the maintainers of both of the obvious candidate bots, I wanted to ask if there's any other way to either get one of those two bots on the task or make a new bot for the task, so that editors can cut down on the amount of time we have to spend on DRAFTNOCAT cleanup. Bearcat (talk) 16:10, 3 November 2023 (UTC)[reply]

As a stopgap solution, encouraging people to use a script like User:MPGuy2824/MoveToDraft (which automatically disables the categories) might be a good way to go? Elli (talk | contribs) 16:23, 3 November 2023 (UTC)[reply]
I feel like there might have been a bot for this in the past. Might be worth checking some diffs and see if that bot can be tracked down. I'd recommend WP:BOTREQ as the next step. Then can probably help both with coding up a brand new bot, and remembering which old bot used to do this. Hope this helps. –Novem Linguae (talk) 20:13, 3 November 2023 (UTC)[reply]

login.wikimedia.org

 – RoySmith (talk) 16:32, 3 November 2023 (UTC)[reply]

Hi,

Not sure if this is the right place to post this, but I was curious:

What is login.wikimedia.org used for?

Some accounts say that they exist on this wiki, but it's not really clear what it is? LOOKSQUARE (👤️·🗨️) talk 16:10, 3 November 2023 (UTC)[reply]

It's a part of the unified login system connecting all Wikimedia wikis, and every account should also exist there. When you log in on any project (such as English Wikipedia), you also get logged-in at the login wiki. Then when you visit another project, such as Meta-Wiki, your browser checks with the login wiki and if you're logged-in there, it also automatically logs you in on the project you visited. Matma Rex talk 16:37, 3 November 2023 (UTC)[reply]

Highly visible mobile bug

Tracked in Phabricator
Task T316670

Several times, I have noticed a bug on the mobile Wikipedia (website) involving misdisplaying section heading when preceded by an image with the right option, e.g. here. I've tried to search for it in Phabricator, but I haven't found anything similar. Could somebody reproduce the issue? Given its visibility (if it isn't exclusive to me), I can't believe it hasn't already been reported. Janhrach (talk) 17:11, 3 November 2023 (UTC)[reply]

I don't see a problem. Can you post a WP:SCREENSHOT? – Jonesey95 (talk) 18:46, 3 November 2023 (UTC)[reply]
This was the problem: (imgur screenshot). I believe this was more of an article layout and missing-wikitext issue than a software bug. It was missing the 'thumb' parameter for the image, which meant the caption was not being displayed, and the image was treated as a 'no format' image (docs) and hence rendered inline instead of floating. After two fixes, it looks like this (imgur link). That appears to have fixed it at all window-widths. Quiddity (talk) 19:32, 3 November 2023 (UTC)[reply]
Thank you. Janhrach (talk) 19:41, 3 November 2023 (UTC)[reply]
The screen shot looks like a bug to me. Unless I am misreading it, mw:Help:Images says that the right option is supposed to render the image as a floating block, but the header text is clearly superimposed on the image. – Jonesey95 (talk) 20:58, 3 November 2023 (UTC)[reply]
Ah, right, I mis-read the docs page. Error struck-out above. Sorry/Thanks. Quiddity (talk) 18:57, 6 November 2023 (UTC)[reply]
You said this happened "several times". How widespread do you think this is? If it can be fixed by changing wikicode on 10 pages, then let's just do that. If it affects thousands of pages or something like that, then maybe a phab ticket would make sense. –Novem Linguae (talk) 20:08, 3 November 2023 (UTC)[reply]
I read Wikipedia for years, and I think that I have come across this about 10 times, however this may not be representative of the whole wiki, as, of course, I read only on a small fraction of topics. Janhrach (talk) 20:17, 3 November 2023 (UTC)[reply]
@Novem Linguae: the issue also affects your user page. Janhrach (talk) 07:45, 4 November 2023 (UTC)[reply]
It's a known problem, filed as T316670. I suggested a fix there a few weeks ago. Matma Rex talk 21:39, 3 November 2023 (UTC)[reply]
Thank you, I would not find that. Janhrach (talk) 07:19, 4 November 2023 (UTC)[reply]
@Jonesey95: Your edit to Orihon broke the image again. Was it intentional? Janhrach (talk) 07:22, 4 November 2023 (UTC)[reply]
No; I can't see the problem in mobile view, but I assumed (wrongly, I guess) that frameless would work the same as thumb. The thumb view looks awkward without a caption, and the previous caption was not valid. That's a nice little bug; I hope that someone can fix it. – Jonesey95 (talk) 15:31, 4 November 2023 (UTC)[reply]

?debug=1 reveals normally hidden console errors

When I turn on JavaScript debug mode by adding ?debug=1 to the URL, a bunch of different user scripts and gadgets throw errors for me:

  • Query.Deferred exception: mw.Api is not a constructor TypeError: mw.Api is not a constructor
  • Uncaught TypeError: mw.Api is not a constructor
  • Uncaught ReferenceError: OO is not defined

Try it if you want and see how many WP:CONSOLEERRORs you get.

I'm wondering why these don't throw normally but only with debug mode on. Anyone know?

I would suggest that throwing these in normal mode too may be the best approach. I think most folks do not use debug mode during development, so would never see these console errors and therefore would not know to fix the issues. –Novem Linguae (talk) 22:28, 3 November 2023 (UTC)[reply]

Most likely because dependencies that require declaration (i.e. all modules except ones already loaded by the time common/skin/global.js run) are not properly declared in those user scripts and gadgets. Popular modules like mediawiki.util and mediawiki.api are loaded on most pages anyway, so references to mw.Api etc. work without the required declarations in most circumstances, but fail in debug mode where modules are loaded in sequence. There's no way to "throw[] these in normal mode too" because the same lines of code don't result in errors if the modules are already loaded. The solution is simply to add dependencies in the scripts or gadget definition. Nardog (talk) 22:44, 3 November 2023 (UTC)[reply]
So the reason is that debug mode loads modules more synchronously than regular mode? And the fix is mw.loader.using type code? –Novem Linguae (talk) 23:06, 3 November 2023 (UTC)[reply]
Yes and yes (though not sure if "more synchronously" is the right terminology). Nardog (talk) 23:23, 3 November 2023 (UTC)[reply]
To add to Nardog's answer, this is what you actually need:
$.when( mw.loader.using( ['mediawiki.util','mediawiki.api'] ), $.ready ).then( function () {
	if (mw.util.isIPv4Address( '192.0.2.0' )){
		console.log('this is an IPv4 address');
	}
	var api = new mw.Api();
});
— Alexis Jazz (talk or ping me) 23:21, 3 November 2023 (UTC)[reply]
I've been using the below, but I think I like your way better since it's one line:
$(async function() {
    await mw.loader.using(['mediawiki.api'], async () => {
        //
    });
});
–Novem Linguae (talk) 23:44, 3 November 2023 (UTC)[reply]
For anyone who is interested in these things, there are more examples at mw:ResourceLoader/Core modules. — Alexis Jazz (talk or ping me) 00:14, 4 November 2023 (UTC)[reply]

Patrice Blanc-Francard

"Deputy general director Jean-Martial Lefranc Director of programming Patrice Blanc-Francard TV6's share capital was FRF 10,000,000,000, 25% held by Publicis."

not in page !

..... 0mtwb9gd5wx (talk) 04:31, 4 November 2023 (UTC)[reply]

It is: TV6 (French TV channel)#Capital. Nardog (talk) 04:47, 4 November 2023 (UTC)[reply]

Page stuck in pending changes

Tracked in Phabricator
Task T350527

Pending changes protection for List of World Series champions expired at 21:37, 3 November 2023 (UTC), and MusikBot II removed the pp-pc template at 23:20, 3 November 2023. It remains on the list of pages with edits awaiting review, despite four edits in the hours since then, two of them from pending changes reviewers. There doesn't seem to be a way to purge the special page. Is there a way to fix this? BlackcurrantTea (talk) 06:14, 4 November 2023 (UTC)[reply]

I think I fixed this by turning PC protection back on, accepting an edit, then turning it back off again. Will test a bit on testwiki and see if I can reproduce this. If so it should get a phab ticket. –Novem Linguae (talk) 06:47, 4 November 2023 (UTC)[reply]
Thanks. BlackcurrantTea (talk) 06:53, 4 November 2023 (UTC)[reply]
I was able to replicate the bug. I filed phab:T350527. –Novem Linguae (talk) 07:16, 4 November 2023 (UTC)[reply]

San Pier Niceto serious error

some serious error going on in San Pier Niceto article under the "Demographic evolution" section. Therapyisgood (talk) 07:05, 4 November 2023 (UTC)[reply]

Fixed. The changes made by an IP on 10 February 2022 broke the EasyTimeline. When you see something unusual like this, it's worth looking at the article history to see if the problem can be resolved by reverting an edit (or several). Happy editing! BlackcurrantTea (talk) 07:23, 4 November 2023 (UTC)[reply]
Searching "Unable to compile EasyTimeline input" returned 85 pages, 9 of which were articles. Surprised the extension does not have a dedicated error category (though T137291 makes this rather moot). Nardog (talk) 09:37, 4 November 2023 (UTC)[reply]

Can we automatically split categories?

See this discussion: is it possible to automatically redirect (or "split") a category into more than one other category? Jarble (talk) 17:10, 4 November 2023 (UTC)[reply]

No page can be redirected to more than one other page. Izno (talk) 18:02, 4 November 2023 (UTC)[reply]
Also how would the bot know which page went where? If you mean merge on category into two others (copying all members to both), then WP:CFDW's bot can do that if you follow the proper process. * Pppery * it has begun... 18:06, 4 November 2023 (UTC)[reply]
@Izno and Pppery: I don't think {{category redirect}} supports multiple targets for category redirects, but I wish it did; isn't it possible to implement a feature like this? Jarble (talk) 19:17, 4 November 2023 (UTC)[reply]
{{Category disambiguation}}? An example would really help make your point clearer. * Pppery * it has begun... 19:17, 4 November 2023 (UTC)[reply]
@Pppery: If {{category redirect}} supported multiple targets, I would use it to split overly specific categories like Category:Software developers from New York City:
{{category redirect|Category:People from New York City|Category:American software developers}}
Then every page in that category would be automatically moved into the other two categories. Jarble (talk) 19:35, 4 November 2023 (UTC)[reply]
That is an interesting idea, but it's not currently supported by the system as it stands. * Pppery * it has begun... 19:36, 4 November 2023 (UTC)[reply]
@Pppery: I requested this feature seven years ago, but it was never implemented. Jarble (talk) 19:41, 4 November 2023 (UTC)[reply]

UTC timestamps in Wikipedia edition?

Greetings.
This is a question, not a problem. I haven't found the answer, not even in Wikipedia.
I am writing a scholarly paper about a piece of news from 2009 that was a subject of misinformation. It requires following how the news was presented to the public by the media, and how Wikipedia editions mirrored that.
I have noticed, even as I write now, that the date and time of my inquiry is given automatically in UTC time. The question is, are the timestamps of the editions in a Wikipedia article as they appear on the article's history also in UTC time? An article that was heavily edited in 2009?
I have found that in that year Wikipedia's servers were in Tampa, Florida, so I wonder whether an article being edited with new sources at 14:30 hours of a given day in 2009, that means UTC time, Tampa time, or another kind of time zone.
A link to a source supporting the answer to cite it in the paper would be greatly appreciated.
Thanks. Maykiwi (talk) 23:18, 4 November 2023 (UTC)[reply]

If you are logged out, those times are in UTC.
If you are logged in, you can change your preferences so that the time stamps are in whatever time zone you please (and then some). The default for that is the same as logged out. Izno (talk) 23:52, 4 November 2023 (UTC)[reply]
@Maykiwi: For a cite, Help:Page history says "in UTC by default" and said "in UTC" in 2009.[1] The user preference to change it is at Special:Preferences#mw-prefsection-rendering. For the more technical side, the time zone is determined by the setting of mw:Manual:$wgLocaltimezone. https://noc.wikimedia.org/conf/highlight.php?file=InitialiseSettings.php sets it for Wikimedia wikis with:
'wgLocaltimezone' => [
	'default' => 'UTC',
...
The default is changed in ... for a long list of wikis but not the English Wikipedia which is called enwiki. Many other Wikipedia languages change it so be careful if you include non-English sources. PrimeHunter (talk) 00:13, 5 November 2023 (UTC)[reply]
Also, how Wikipedia displayed the time in 2009 wouldn't affect how it's displayed now - if that was changed in the software, it would change how all previous timestamps are displayed too. In other words, there will never be a page history where some revisions are in one time zone and some are in another. LittlePuppers (talk) 03:06, 5 November 2023 (UTC)[reply]
Re the last sentence: that's actually not quite true, for certain times in 2002, from some time in that year until 6 September. There's also the very occasional apparent time zone bug like this one in 2005 (see the revision ID numbers in the URL). This sort of thing is completely irrelevant to the original question, though. Graham87 (talk) 09:01, 5 November 2023 (UTC)[reply]
...Huh, that's interesting. LittlePuppers (talk) 16:38, 5 November 2023 (UTC)[reply]
Thank you very much. Maykiwi (talk) 21:57, 5 November 2023 (UTC)[reply]
@Maykiwi: Wikipedia was conceived as a global project, but the choice of a geographically-based timestamp may have conferred some kind of superiority to people in that time zone; by contrast, UTC is geographically-neutral. That said, for people in some countries, UTC coincides with local clock time for all or part of the year. UTC itself does not have any daylight-saving adjustment, regardless of where you live, so the issue of daylight-saving time having different dates in various countries is avoided entirely. --Redrose64 🌹 (talk) 15:59, 5 November 2023 (UTC)[reply]

A weird automatically generated summary and tag

I found the revision Special:Diff/1179684236 on Attorney-General of Alberta automatically tagged by mw-removed-redirect and summarized by "←Removed redirect to Attorney General of Alberta" when I was filtering revisions by tag name. However, it should have been tagged by mw-changed-redirect-target because the new target List of Alberta provincial ministers has been there for a long time and hasn't been deleted (see its log) or even edited recently. I'm not sure what happened here and if there is actually a bug, please fix it. NmWTfs85lXusaybq (talk) 05:48, 5 November 2023 (UTC)[reply]

The fact the previous revision was a double redirect may have some to do with it. Nardog (talk) 22:07, 5 November 2023 (UTC)[reply]
I made an experiment of retargeting a redirect created as a double redirect in my user page User:NmWTfs85lXusaybq/Example of a double redirect while all things work fine with a reasonable tag and summary generated automatically. NmWTfs85lXusaybq (talk) 08:10, 6 November 2023 (UTC)[reply]

Creating a category that includes articles affected by a template parameter

How do I create a category that includes all articles affected by a talk page template argument, such as in Category:B-Class biography articles? I’m thinking that I could create Category:Former featured articles as an FFA equivalent of Category:Delisted good articles, but I don’t quite know how to do it. — Mugtheboss (talk) 16:07, 5 November 2023 (UTC)[reply]

@Mugtheboss: You always have to edit the template to add the wanted category code in the wanted circumstances. Nothing in the category page can control it. You can use Wikipedia:Requested templates if you don't know how to do it, or Wikipedia:Edit requests if you lack access. For some things it may also be a good idea to seek consensus first in an appropriate place. PrimeHunter (talk) 18:48, 5 November 2023 (UTC)[reply]

Duplicate GAN

Wikipedia:Good article reassessment/Adem Jashari/2 seems to have been created in error, as the first GAN was created around the same time by the same user. How should this be taken care of? G6? Ten Pound Hammer • (What did I screw up now?) 17:54, 5 November 2023 (UTC)[reply]

 Done, but a question more appropriate for WP:ANI or simply by tagging the extra. Izno (talk) 17:57, 5 November 2023 (UTC)[reply]

Username canonicalization of User:გასპუერა

The first character of a username is basically automatically capitalized by the MediaWiki software, but I came across the username in the title whose first character isn't capitalized (which is probably related to Language.php#2520).

I'm not sure whether or not this is intended. Any idea? Dragoniez (talk) 18:46, 5 November 2023 (UTC)[reply]

{{uc:გ}} produces Გ and not the original character გ, but გ and Გ are different redirect pages (with the same target). I thought {{uc:}} automatically made the same character conversions as the first character in page names but apparently not. I suspect it's a bug but I'm not sure. PrimeHunter (talk) 18:59, 5 November 2023 (UTC)[reply]
Yeah I'm not sure either. Maybe this is yet another issue with the capitalization of Georgian characters related to phab:T254470, but I'm after all not sure if this is a bug. Dragoniez (talk) 19:04, 5 November 2023 (UTC)[reply]
From Georgian Extended: Unlike all other casing scripts in Unicode, there is no title casing between Mkhedruli and Mtavruli letters, because Mtavruli is typically used only in all-caps text. In other words, since Georgian orthography doesn't have the same concept of capitalization Latin/Cyrillic/etc. do, Unicode doesn't capitalize გ to Გ in title case. So {{uc:გ}} produces Გ but {{ucfirst:გ}} just returns the input: გ. Nardog (talk) 19:15, 5 November 2023 (UTC)[reply]

Proposal (on MW.org) to bring back the graph extension

If this was previously posted here, I apologize. I just saw it in the Signpost and could not remember seeing it before. There is a proposal over on mediawiki.org about bringing back the graph extension, which has been disabled since April 2023 (see T334940 for details on that). – Jonesey95 (talk) 17:00, 6 November 2023 (UTC)[reply]

I believe last week's tech news had a line for it. Izno (talk) 17:07, 6 November 2023 (UTC)[reply]
They are also asking how long it takes to convert the graphs from Vega2 to Vega5? For reference, Here there are hundreds of graphs on 18k pages. Snævar (talk) 17:47, 6 November 2023 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=1183824826"