Wikipedia:Village pump (technical)#Fetch page text

When you attempt to create a double redirect you are shown a warning that includes a suggested fix (i.e. if Foo is a redirect to Bar and you attempt to create a redirect to Foo, MediaWiki shows a warning recommending you change the target of your new redirect to be Bar).

In response to Wikipedia:Village pump (proposals)#Double redirect creation I opened phab:T393825 requesting a link or button to automatically implement the suggested fix. Comments on that task by the developer who implemented the warning suggest that this might be complex to implement as part of MediaWiki but that "This could definitely be implemented on-wiki via a JavaScript gadget though." Thryduulf (talk) 11:48, 13 May 2025 (UTC)

:Pinging Utfor as the original requester at VPPRO. Thryduulf (talk) 11:49, 13 May 2025 (UTC)

:This sounds like a useful script - maybe listing it at WP:US/R would help find a developer for it BugGhost 🦗👻 21:40, 14 May 2025 (UTC)

::I was directed here by Wikipedia:GADGET#Proposals but I've copied the request to Wikipedia:User scripts/Requests#Request: Button or link to fix double redirects at creation. I have no idea which is the best location, but please pick one and close the other with a pointer. Thryduulf (talk) 22:46, 14 May 2025 (UTC)

:#TIL after an embarrassing amount of failing around and messing up syntax, that said warning doesn't apply to userspace. (i.e. creating User:Example/foo that redirects to User:Example/bar that's already a redirect to User:Example triggers no warning.) *sigh* Now I get to request user page deletions. FeRDNYC (talk) 20:41, 18 May 2025 (UTC)

Did the CSS just change on mobilein desktop view as seen on mobile? Page body text on my phone is a lot denser today. Chrome on a Galaxy phone. Largoplazo (talk) 14:59, 15 May 2025 (UTC)

:Not on mobile, but on the usual Vector2022 view on a desktop I'm seeing text that appears a lot denser today as well. It's hard to tell because I don't have before and after screenshots, but my suspicion is that the leading (space between consecutive lines of text) has been reduced. I went into my custom css and increased the line-height (mine has a line ".vector-body {font-size: 115%; line-height: 150%;}" but you may not want such extreme values) and it looked a lot better again. —David Eppstein (talk) 18:28, 15 May 2025 (UTC)

::I just realized, it isn't mobile view, it's desktop view though on my phone. I've edited my original post. Largoplazo (talk) 19:50, 15 May 2025 (UTC)

::On the other hand, I'm not noticing a difference on my desktop monitor! Largoplazo (talk) 22:55, 15 May 2025 (UTC)

:On desktop my icons are smaller today too... Sock-the-guy (talk) 19:38, 15 May 2025 (UTC)

::File:Block message size.png MonoBook here, and while I don't see that, I do see the pink box atop the editing window that - for instance - has the this-user-has-been-blocked-by-who-and-why looks to have larger text today. Or maybe it's always been this way and I'm losing my mind, that can't be ruled out? - The Bushranger _{One ping only} 19:27, 15 May 2025 (UTC)

::No, you're right, it is bigger. Remember, WP:ITSTHURSDAY. --Redrose64 🌹 (talk) 21:13, 15 May 2025 (UTC)

:::woah I didn't know about that. Thanks! Sock-the-guy (talk) 21:21, 15 May 2025 (UTC)

:::Aha. That would explain the larger text in the block notices. I also noticed the text in the box here looks odd ({{ping|Parsecboy}} since I'm linking your page for an example!). And I'm going to guess that Wikimedia Commons got rolled out on Wednesday, which might explain the Metadata text looking bigger that I noticed there yesterday... - The Bushranger _{One ping only} 22:48, 15 May 2025 (UTC)

::::The new CSS rule affecting the pink box is: .cdx-message__content,

.cdx-message__content > * {

font-size: var(--font-size-medium,1rem);

line-height: var(--line-height-small,1.375rem);

} and since it seems to be general for pink boxes, it also affects the pink box shown whn you visit the redlink of a deleted page. --Redrose64 🌹 (talk) 23:11, 16 May 2025 (UTC)

:::::The same rule is picked up by the brown boxes, which explains Izno's post of 23:15, 15 May 2025 (UTC) below. --Redrose64 🌹 (talk) 10:12, 17 May 2025 (UTC)

:I've also caught that it impacted the old revision notice, see [https://en.wikipedia.org/w/index.php?title=User:Izno&oldid=1261463683 my user page for example]. Izno (talk) 23:15, 15 May 2025 (UTC)

::Based on the phab chatter, this is phab:T394305 and should be fixed already +- caches +- hard refreshing. Izno (talk) 23:17, 15 May 2025 (UTC)

• And just now I noticed that the "Mark this page as patrolled" button on the lower right of unpatrolled pages is absolutely huge now. Was this really intended?? - The Bushranger _{One ping only} 18:11, 16 May 2025 (UTC)
• ...also it almost looks like the text on this page is larger than it used to be now. Was this part of the "dark mode" rollout somehow? Because it's...not great. - The Bushranger _{One ping only} 00:17, 17 May 2025 (UTC)

:Really don't want this to get archived yet ... but we may be stuck with these changes. Steel1943 (talk) 19:19, 21 May 2025 (UTC)

Are my eyes playing tricks on me, or ... is the font size in deletion summaries, such as the one posted at Yoshi Falls, bigger and/or has less space between lines than they previously did? And if so, was this intentional? (In case it is relevant, I'm using Vector legacy 2010.) Steel1943 (talk) 22:51, 16 May 2025 (UTC)

:This is #Font change in desktop view on mobile above. Despite the section heading, it's not just mobiles. --Redrose64 🌹 (talk) 22:54, 16 May 2025 (UTC)

:For what it's worth, I am using "desktop on mobile". Steel1943 (talk) 19:06, 17 May 2025 (UTC)

::Givent the timing, I suspect this can all be blamed on "changes to suit dark mode". - The Bushranger _{One ping only} 23:53, 17 May 2025 (UTC)

The article Gaza genocide has recently had a number of citation templates changed to use #invokle:cite. Unfortunately this causes the article to appear in :Category:Harv and Sfn no-target errors and also false positive messages from User:Svick/HarvErrors. Is there a way to fix this? Thanks, DuncanHill (talk) 20:01, 15 May 2025 (UTC)

:@Trappist the monk This appears to be an issue with switching from Module:Cite web to Module:Cite, and will likely require updates to Module:Footnotes to accommodate the new module naming scheme. --Ahecht (TALK
PAGE) 20:45, 15 May 2025 (UTC)

::This is not really a fix, but the usual workaround for false positive harv errors is to use {{tl|sfn whitelist}}. —David Eppstein (talk) 21:05, 15 May 2025 (UTC)

:::That needs to be done on a per-article basis. If more than one article is affected, it's easier and quicker to add an entry to Module:Footnotes/whitelist. --Redrose64 🌹 (talk) 21:18, 15 May 2025 (UTC)

::::Neither of those 'fixes' should be pursued. The 'fix' is to fix Module:Footnotes so that it recognizes {{#invoke:Cite|xxxx|....}} and can then extract the necessary info from the invoke.

::::—Trappist the monk (talk) 21:26, 15 May 2025 (UTC)

:::::{{re|David Eppstein}} there are about 500 instances, the sfn whitelist would be ludicrously and unmanageably long. DuncanHill (talk) 21:45, 15 May 2025 (UTC)

:::::@Trappist the monk@Hike395: I think I've implemented that at Special:Diff/1271779136/1290610723, but would appreciate a second/third set of eyes on it. It should work for both cases like {{mlx|cite|web|...}} and {{mlx|cite tweet||...}}, but it would interpret {{mlx|cite tweet|main|...}} as {{tl|cite tweet main}}.--Ahecht (TALK
PAGE) 21:45, 15 May 2025 (UTC)

::::::Editor Hike395 rewrote most of Module:Footnotes/anchor_id_list to the point where I no longer recognize the code so I am not the best person to say if what you have added was a good addition. I do notice that the 'template' names created from #invokes are not listed in template_list. Edit this version of my sandbox (don't change anything) and click Show preview. Then, in the Parser profiling data dropdown, click show under Lua logs. You should see something like this:

:::::::template_list = table#1 {

["Cite SSRN/new"] = 1,

["Template:Harvard citation no brackets/sandbox"] = 1,

}

::::::In my sandbox page there are two {{#invoke:Cite|news|...}}. Change one of them to {{Cite news|...}}. Show preview; Show Lua logs. You should see something like this:

:::::::template_list = table#1 {

["Cite SSRN/new"] = 1,

["Cite news"] = 1,

["Template:Harvard citation no brackets/sandbox"] = 1,

}

::::::Where is the missing 'cite news' from the invoke?

::::::—Trappist the monk (talk) 22:36, 15 May 2025 (UTC)

:::::::The answer to Trappist's question is because the template_list variable is populated by template_list_add() here, and that function accepts the raw template string Module:Footnotes/anchor_id_list/sandbox#L-762 at line 762, not the hacked version produced by template_get_name Module:Footnotes/anchor_id_list/sandbox#L-762 at line 761. Is that right? It seems to me that template_list_add() at line 762 can be replaced by list_add(template_name, template_list). But I'm not 100% sure.

:::::::By the way, 95% of the code in Module:Footnotes/anchor_id_list is still Trappist's code. You can see my diff {{diff|Module:Footnotes/anchor_id_list|1269310281|1235097998|here}}. I changed the way the global variables were updated (for caching and to handle errors correctly), rewrote a little code for efficiency, handled "fascicles", and added citeref_patterns_make(), but that was it.

:::::::To answer {{U|Ahect}}'s question -- I'm a bit nervous about turning all invokes into fake-o templates, because I don't know if that will generate any false positives or negatives. You may want to only turn {{#invoke:cite|XYZ}} into {{cite XYZ}}, because that seems safer and more predictable. — hike395 (talk) 02:54, 16 May 2025 (UTC)

:::::::Also: I am concerned that {{U|Ahecht}} has only hacked template_name and not template itself. There are a large number of regexps in Module:Footnotes/anchor_id_list that manipulate template directly, and those will not understand {{#invoke:cite|XYZ}}. — hike395 (talk) 02:59, 16 May 2025 (UTC)

::::::::@Hike395 My impression from the code is that template_params_get() only looked for named parameters, so it should automatically ignore lua function names, and similarly date_get() only looks for parameters starting with date=() (or an alias). sfnreg_get(), anchor_id_make_harvc(), and anchor_id_make_anchor() don't look at citation templates, so it doesn't matter there. The only other function that might potentially be impacted is template_list_add, which despite a comment saying that it handles case differently than template_params_get() is functionally identical as far as I can tell, so I just refactored it to use template_params_get() here. @Trappist the monk can correct me if my assumptions are wrong. --Ahecht (TALK
PAGE) 20:34, 18 May 2025 (UTC)

:This version (permalink) of Gaza genocide directly precedes the edit that converted Module:Cite web and others to Module:Cite. Note that that §References section in that older version also has lots of harv errors. From that, I conclude that the change to Module:Cite {{em|did not}} cause any new problems. It appears that these errors began appearing 2025-05-03 at this edit (permalink). Since that time no one has bothered to notice or if they noticed, did not say anything. Of course, that harv error message is hidden so that might explain why the silence. No doubt, there are other articles where these sorts of error messages have not been noticed.

:

:User:Trappist the monk/HarvErrors does not show any error messages. The only error messages that I see are from Module:Footnotes.

:

:For those interested, Module:Cite web, Module:Cite news, and a few others are soon to be deleted so look now before their deletion prevents you from confirming what I have written.

:—Trappist the monk (talk) 21:26, 15 May 2025 (UTC)

::The edit on the 3rd May marked the use of #invoke, so it seems to be #invoke that is causing the problem. As for not raising it earlier, I am sorry but I have a life. DuncanHill (talk) 21:45, 15 May 2025 (UTC)

:How about not using invoke to get around an article being to long, and instead split and summarise better? -- LCU ActivelyDisinterested «@» °∆t° 11:15, 18 May 2025 (UTC)

::Wikimedian challenge: impossible. Izno (talk) 20:16, 18 May 2025 (UTC)

:::Thus does appear impossible on certain articles, apparently they need to contain every detail in one central location and to hell with readability and usability. -- LCU ActivelyDisinterested «@» °∆t° 10:35, 23 May 2025 (UTC)

Ever since yesterday, when I use the desktop version on my mobile phone, the first item in my watchlist is a long column of text with 1-2 characters per line, and partially obscured by the "List of abbrevations" box. If you don't know what I mean, it's similar to how it looks on mobile with desktop view when discussions get too indented. Only happens when reading phone in portrait mode, not in landscape mode, I assume because there is more width available in landscape. The rest of the entries look normal, except maybe (not sure) the margin is wider than it used to be?

Is this something I just need to get used to, or is it something about to be fixed? Or am I the only person on the planet it is happening to? Is this somehow related to the "Font change in desktop view on mobile" thread above? Have I explained it so poorly that no one knows what I mean?

This is one of those things that's only a minor annoyance, except I see it every time I look at the watchlist, so the annoyance kind of accumulates after a while.... Floquenbeam (talk) 19:34, 16 May 2025 (UTC)

:Seems unrelated to the other font changes. T331086 changed how line breaking of text works on the watchlist, and this seems to be an unintended consequence of that. I proposed a patch to improve it: [https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1147070] Matma Rex talk 22:50, 16 May 2025 (UTC)

::On suitably narrow screens the legend probably shouldn't float at all. Izno (talk) 05:05, 18 May 2025 (UTC)

:::... and I guess the corollary is that maybe it would make sense to allow special pages to tell the skin (or vice versa, idk which way) whether they support mobile friendliness, as we work toward e.g. Vector being available as a 'mobile' skin rather than something which phones have to guess at what's important and what's not. Izno (talk) 05:24, 18 May 2025 (UTC)

::::Before this disappears into the archive: is there any way I can do some kind of css/js thing to make it stop? I have to scroll 3 screens each time I refresh my watchlist to get to the actual watchlist. Floquenbeam (talk) 16:22, 22 May 2025 (UTC)

:::::My patch was accepted, and the new version was deployed a couple hours ago like every Thursday, so the problem should be fixed now. Matma Rex talk 18:45, 22 May 2025 (UTC)

::::::uh oh. must be caused by something else. It's still happening as of 30 seconds ago. Floquenbeam (talk) 18:47, 22 May 2025 (UTC)

The list of languages in the sidebar (I use legacy Vector 2010) seems to have disappeared, and been replaced by a single link to Wikidata. Testing it under the default V2022, it remains under the list of languages at the top. Why has this been changed for V2010? I deal with cross-wiki stuff all the time, and this is a huge productivity hit for me as it requires multiple steps and additional time to get to my destination. Please, how do I get the language list back again in the left sidebar? Mathglot (talk) 19:51, 16 May 2025 (UTC)

:Could you link to an example where it is not working for you? Perhaps also try to reproduce the problem with this link which properly shows the language list for me: https://en.wikipedia.org/wiki/Example?useskin=vector&safemode=1 (Context: using mw:safemode will "deactivate all on-wiki scripts and stylesheets at once"). HTH, Quiddity (WMF) (talk) 20:09, 16 May 2025 (UTC)

:: {{u|Quiddity}}, thanks for your reply. Your Example page works with the safe mode url suffix (and shows six languages in the sidebar) but it fails without the suffix. I hit Random article until I found three more pages with language links, they are: Ninzic languages, European turtle dove, and MILGEM project, and they all display [​[Wikidata item]​] under small-font heading, 'In other projects', and none of the individual languages. In each case, if I add {{kbd|1=?useskin=vector&safemode=1}} to the url, the language links in the sidebar come back again.

:: My most recent changes to commons.js was 4 April 2025 (and .css = 17 March). It occurred to me that perhaps one of the scripts I load may have changed recently, so I blanked my commons.js, bypassed my cache, and tried the three articles listed again, same thing: no links, but they come back in safemode. The only other thing that occurs to me, is that I believe there is a Preference setting somewhere to list my languages in the sidebar in English, not in the local language (i.e, I normally see: "German, French, Spanish", not "Deutsch, Français, Español"); should I hunt that down and disable that as well to see what happens? My common.js remains blanked for the moment. Mathglot (talk) 21:35, 16 May 2025 (UTC)

File:InterlanguageLinks-Sidebar-Vector.png

::: I have some clues: the languages are still there, but they are hidden, as if the list were toggled to 'hide'. It used to be, that when languages were listed, there was a down-pointing triangle and if you clicked it, it turned into a right-pointing triangle with the languages hidden. Now, the triangles act differently depending what browser you are on. Chrome, Vivaldi, Edge, Firefox, iOS desktop mode: no triangles at all, but if you click where the triangle ought to be, it toggles the list back and forth; Opera: down triangle is visible, right-pointing is invisible, toggling works if you click where it ought to be. There is also the question of why the language list got hidden in the first place, as I always keep them in 'show' mode. Mathglot (talk) 22:34, 16 May 2025 (UTC)

::::Is the toggle to hide/show a specific script you have? Mine have never done that, and on Ninzic languages I see the 3 interwikis displayed normally above the "Edit links" wikidata link. CMD (talk) 09:53, 17 May 2025 (UTC)

::::: Hi, {{u|Chipmunkdavis}}. No, the behavior is the same even after I have blanked all my scripts, both in my common.js as well as global.js on meta. But the toggle behavior does go away at Ninzic languages in safemode. But are you sure you do not have that behavior? What happens when you click the header 'Language' above the language list, nothing? I'm not sure what it means that the language list toggling doesn't work in safe mode even though it does work in normal mode with all my scripts blanked. (I do not have a vector.js.) Sounds like I will have to try turning off gadgets next. Mathglot (talk) 03:26, 18 May 2025 (UTC)

::::::I don't have an arrow, and there is nothing for me to click, it's just a h3 tag:

Languages

::::::: Found the culprit, finally: it is gadget 'Allow navigation menus to be collapsed', which I never would have suspected. Whew, what a pain! Now I can restore my js files. But, I still need to report a problem with that gadget not displaying the toggle triangles anymore, as it used to (see screenshot). Adding {{u|Quiddity}}, who may be curious to discover how it all shook out. {{ec}} Mathglot (talk) 03:36, 18 May 2025 (UTC)

::::::: Nobody has an arrow (except Opera users); that is part of the problem, the triangle used to be there as in the image. I have the identical Html for the H3, but it is embedded in some code starting

Hi, can anyone tell me the link/ discussion thread for the patrol's new user page? As you can see below, there are two editor user pages with the "mark this page as patrol" tag. [https://en.wikipedia.org/wiki/User:Alphasciences ] and [https://en.wikipedia.org/wiki/User:%D8%B1%D9%88%D9%86%D9%8A_%D8%A7%D8%B3%D9%84%D8%A7%D9%85] . Thank you. Cassiopeia talk 23:46, 16 May 2025 (UTC)

:The second page was deleted, so I can't comment on that. The first page [https://en.wikipedia.org/w/index.php?title=Special:Log&logid=169837150 was patrolled by you].

:I can't quite understand what problem you are trying to describe, but this seems like a discussion for Wikipedia talk:New pages patrol/Reviewers. —⁠andrybak (talk) 15:03, 17 May 2025 (UTC)

::{{U|Andrybak}}} Thank you and I know. The second page I nominated for user name violation and that is the reason it was deleted. Stay safe and thank you. Cassiopeia talk

:Pages in any namespace can be patrolled, and the "Mark this page as patrolled" option is not new. You don't see it on mainspace pages because the Page curation toolbar hides it. Patrolling a page with this option is the same as marking it reviewed through the Page curation toolbar. The toolbar is easier to use and offers more features, which is why NPRs prefer that. You can mark userspace pages as patrolled, but we usually review only mainspace pages because patrolling other namespaces isn't necessary and is a waste of time. – DreamRimmer ■ 16:28, 17 May 2025 (UTC)

:{{u|DreamRimmer}} I have been patrolling for both NPR for many years and this is the first time I saw the in new user page. To me it doesn't make sense as we can mark patrol if all content added by the new user is adhere to the Wikipedia user page guidelines but we can guarantee the new user add something out the guidelines the next day or in the future. Thank you and stay safe. Cassiopeia talk 23:20, 17 May 2025 (UTC)

::Patrol marking are about new pages, not about every revision, it is the same as new articles - if they get vandalized later they don't become unpatrolled. — xaosflux ^Talk 10:53, 20 May 2025 (UTC)

Suddenly it's started to return a 403 (Forbidden) for me. Can you access it? https://gerrit.wikimedia.org/r/ Dragoniez (talk) 05:54, 17 May 2025 (UTC)

: Works for me. — Alien  3
3 3 06:04, 17 May 2025 (UTC)

:@Alien333 Thanks for letting me know you could access it. That helped me figure out the issue. It turns out it was something on my end, not Gerrit's.
Looks like it was a browser compatibility thing. Even after clearing the cache, it still wouldn’t work, but it loaded fine on other browsers like Firefox and Chrome for iOS.
On my desktop I use Chrome, and apparently I was stuck on version 122.0.6261.129 because auto-updates weren’t working. I manually updated to version 136.0.7103.114, and now Gerrit works just fine. Dragoniez (talk) 11:21, 17 May 2025 (UTC)

:: {{u|Dragoniez}}, I find commercial sites like [https://iidrn.com iidrn.com] (think: is it down right now) very helpful for figuring out if it is just you, or everybody. Mathglot (talk) 07:54, 19 May 2025 (UTC)

{{tag|details|o}}, {{tag|summary|o}} and arrow (left, down)

{{tracked|T31118}}

Now the section opens with the word "Show / Hide". This decision was justified at the dawn of the Internet 30 years ago, when HTML was version 1.0.

Now there are tags

Allow

Two months ago we added a notice about SUL3 to the login prompt per /Archive 218#MediaWiki:Loginprompt ?. Is this still needed now, or can it be removed? * Pppery * _{it has begun...} 04:22, 18 May 2025 (UTC)

:It would be good for new, and dormant but returning editors (two groups) to have the notice as they may not be aware that they have to modify their blocking tools (extensions, firewall, etc) that they may have to allow requests to the auth domain. The first can be easily settled with assuming that new editors are not auto-confirmed editors and use the CSS class to show the text to them, the second group is harder without enabling some form of last login tracking.

:At the very least, the wording of the notice can be tweaked or simplified given that the enhancement is no longer 'recent' (2 months or more ago?), i.e. "All logins are processed on auth.wikimedia.org. If you are using blocking software, you will need to allow access to this domain to log in. (technical details)" – robertsky (talk) 05:34, 18 May 2025 (UTC)

:: This message appears before you log in, so you can't know whether the account they are going to log in to is new. And even if you could CSS classes like "autoconfirmed-show" don't work on the login page. * Pppery * _{it has begun...} 13:46, 18 May 2025 (UTC)

:::Opps. My wires were crossed. Then shortening the text is the alternative. – robertsky (talk) 01:24, 19 May 2025 (UTC)

:In theory sessions can last for up to a year if you select the "remember me" option. So it seems likely that there are active editors who're going to log in using the new workflow for the first time in about 10 months' time. taavi (talk!) 15:26, 18 May 2025 (UTC)

I have removed "As part of recent enhancements" from the login notice. * Pppery * _{it has begun...} 02:03, 19 May 2025 (UTC)

says 0 here Special:Statistics#:~:text=43-,Stewards,-(list of members

but there should be 34 https://meta.wikimedia.org/wiki/Stewards#:~:text=There%20are%20currently%2034%20stewards Jhoncena1234 (talk) 19:03, 18 May 2025 (UTC)

: That is the list of members in the local "steward" group, which is almost always empty. The global "steward" group is listed elsewhere. * Pppery * _{it has begun...} 19:04, 18 May 2025 (UTC)

::More specifically, [https://meta.wikimedia.org/w/index.php?title=Special:ListUsers&group=steward here at Meta], which is linked from their statistics special page. Graham87 (talk) 08:34, 19 May 2025 (UTC)

:::To explain a little more, the English Wiipedia is part of a unified login system for around 1000 wikis run by the Wikimedia Foundation. Most user groups are local and only apply to one wiki where they are assigned and listed. The steward group is global and applies to all wikis. It is only assigned and listed at the central Meta wiki. It's admittedly confusing that Special:Statistics says Stewards 0. Maybe it should be explained in MediaWiki:Statistics-footer. PrimeHunter (talk) 09:39, 19 May 2025 (UTC)

:::If you look at Wikipedia:User access levels and search for "steward", you will find that in the sidebar there is a link to Wikipedia:Stewards, which itself is a soft redirect to meta:Stewards. There is also a section Wikipedia:User access levels#Global rights, which says {{tq|... stewards are appointed globally across all public Wikimedia wikis.}} --Redrose64 🌹 (talk) 14:33, 19 May 2025 (UTC)

For some time now, since the introduction of the dark-mode skin, this is how navboxes like Template:Seinfeld episodes appear in Vector 2022 when using dark mode.

(I've applied various tools and hand-edits to inline all of the styles and remove all CSS classes and element IDs, such that this should appear the same regardless what skin you're using, or what color-mode (if applicable). The only thing I can't control is the link coloring, since there's no way to inline-style a wikilink.)

Note, especially, the top and left borders in the rows for odd-numbered seasons.

This appears to simply be a mistake in the dark-mode CSS. One of the applicable rules — I'm not sure exactly where it comes from, but it's loaded with the page according to ny browser's development tools — is this one (warning: brain-melting CSS ahead)...

html.skin-theme-clientpref-night .infobox td:not(.notheme),html.skin-theme-clientpref-night .infobox th:not(.notheme),html.skin-theme-clientpref-night .infobox-above:not(.notheme),html.skin-theme-clientpref-night .infobox p:not(.notheme),html.skin-theme-clientpref-night .infobox > div:not(.notheme),html.skin-theme-clientpref-night .infobox caption:not(.notheme),html.skin-theme-clientpref-night .infobox--frwiki td:not(.notheme),html.skin-theme-clientpref-night .infobox--frwiki th:not(.notheme),html.skin-theme-clientpref-night .infobox--frwiki p:not(.notheme),html.skin-theme-clientpref-night .infobox--frwiki > div:not(.notheme),html.skin-theme-clientpref-night .infobox--frwiki caption:not(.notheme),html.skin-theme-clientpref-night .sinottico th:not(.notheme),html.skin-theme-clientpref-night .infobox-header:not(.notheme),html.skin-theme-clientpref-night .skin-nightmode-reset-color:not(.notheme),html.skin-theme-clientpref-night .navigation-box:not(.notheme),html.skin-theme-clientpref-night .metadata:not(.notheme),html.skin-theme-clientpref-night .quotebox:not(.notheme),html.skin-theme-clientpref-night .side-box:not(.notheme),html.skin-theme-clientpref-night .side-box div:not(.notheme),html.skin-theme-clientpref-night .navbox:not(.notheme),html.skin-theme-clientpref-night .navbox-subgroup:not(.notheme),html.skin-theme-clientpref-night .navbox-group:not(.notheme),html.skin-theme-clientpref-night .navbox-even:not(.notheme),html.skin-theme-clientpref-night .navbox-abovebelow:not(.notheme),html.skin-theme-clientpref-night .navbox-title:not(.notheme) {

background: inherit !important;

color: inherit !important;

border-color: var(--border-color-subtle,#c8ccd1) !important

}

That rule includes (third-from-last) .navbox-even in the list of classes it applies to, but 'not .navbox-odd

Here's what happens if I use devtools to modify that rule, so that it also applies to html.skin-theme-clientpref-night .navbox-odd:not(.notheme)...

Presumably, that's the intended appearance. Seems more likely than what we currently have, anyway.

In so many ways.

Yes, of course,

• Why were odd-numbered navbox rows left out of the dark-mode border styling?

but also, perhaps even more fundamentally,

• Why is dark-mode implemented like this, as a set of forced (!important, ugh), centralized style overrides?
• Why were the applicable navbox TemplateStyles (Module:Navbox/styles.css) not updated with dark-mode support, either instead of or in addition to the central changes?
• Why do we even bother with TemplateStyles when the skin is going to force them to be ignored?

Oh... and, of course, "Can this please be fixed?" FeRDNYC (talk) 21:03, 18 May 2025 (UTC)

: To answer the question of where the CSS comes from: https://github.com/wikimedia/mediawiki-extensions-WikimediaMessages/blob/master/modules/ext.wikimediamessages.styles/theme-night.less#L79. I'll let others deal with the broader questions. * Pppery * _{it has begun...} 21:29, 18 May 2025 (UTC)

:Triple batch of questions is probably best answered as "WMF wanted to get things done at 900 wiki scale" and no real other reason. We can take these styles upon ourselves when phab:T365330 is done and then applying :mw:Extension:WikimediaMessages#Site admin helper to the corresponding navbox-dark option. (Doing it before that task is done requires you or anyone else to work on the night mode related items at MediaWiki talk:Common.css/to do, though that may or may not be up to date in so far as there may be more to sort out.)

:I can't explain why navbox-odd was forgotten. You could submit a patch upstream if you want. I haven't bothered because when the Phab ticket is done we can fix it directly ourselves, and it's not seriously impeding anything. It's a double thickness line of a slightly wrong color, but obscures no text from a contrast perspective, which was the priority. Izno (talk) 22:43, 18 May 2025 (UTC)

::NB specifically navbox-odd has been previously commented on at Template talk:Navbox/Archive 24#Dark mode white border.

::This discussion could probably have been had at Template talk:Navbox. Izno (talk) 22:55, 18 May 2025 (UTC)

We at Wiki Project Med have been working on decreasing bandwidth usage since this was raised as a significant concern during the last discussion. We have succeeded in dropping usage from 36 Mb down to 498KB. See MDWiki:WikiProjectMed:OWID

We would like to request turning on this functionality on EN WP so that it can be tested further. And of course are open to more feedback. Best Doc James (talk · contribs · email) 14:14, 19 May 2025 (UTC)

:Notified: WT:GADGET, WP:IANB. Doc James (talk · contribs · email) 17:47, 19 May 2025 (UTC)

::The scrolling is honestly is somehow more confusing than before. Scrolling on the image (where my cursor is most likely positioned after clicking the images) moves, not the scrollbar, but a slider off screen, making me wonder what is going on. The initial concerns about unselectable text have also not bee addressed. This still feels a bit half-baked and probably needs more iteration before being considered as a default-on template gadget. Sohom (talk) 04:41, 21 May 2025 (UTC)

:::Yah the sizing of the image needs more work. Just wanting to begin further testing on EN WP. Realize it is not ready for mainspace use yet. Doc James (talk · contribs · email) 02:27, 22 May 2025 (UTC)

The latest run of Special:WantedCategories once again features two redlinks being autogenerated by modules I can't edit, which I can't figure out what to do with:

• {{cl|Sweden by county category navigation with 6–15 links}}, autogenerated by the use of {{tl|Sweden by county category navigation}} on various Swedish "by county" categories. While I can find evidence that this template generates numerous other categories tracking grey links, including the already-existing {{cl|Sweden by county category navigation with 6–15 grey links}}, I can't find any evidence of any other categories existing for any other number of just plain "links" without the "grey" modifier — so I can't figure out why this exists for the 6-15 range, but not for any other number, and thus can't create it if it isn't expected and doesn't have any other siblings. So could somebody with module-editing privileges figure out how to make it go away?
• {{cl|Pages using old style mw-ui-constructive}}, autogenerated by the use of {{tl|Clickable button/sandbox}} on various userspace pages. I could probably just wrap the template invocations in {{tl|suppress categories}}, but I note that these invocations aren't new ones — they've all been on the pages for a long time without ever generating this category until now, meaning the category results from a new module edit within the past couple of days, and thus possibly could recur in the future if it isn't addressed some other way. So if this is a tracking category we would want, then could somebody who knows what they're doing create it — and if it isn't desired, then again, I need somebody with module-editing privileges to make it go away.

Thanks. Bearcat (talk) 14:28, 19 May 2025 (UTC)

::Never mind on the Sweden one, it turns out I was able to clear that out just by null-editing it, because it was just one of those "category not actually on the pages despite nominally appearing to have pages in it, because it had already been corrected but failed to purge" things. Bearcat (talk) 14:36, 19 May 2025 (UTC)

::: {{ping|Andrybak}} * Pppery * _{it has begun...} 14:38, 19 May 2025 (UTC)

:Ideally, the userspace pages shouldn't use the sandbox of the template. Would Wikipedia:User pages#Ownership and editing of user pages allow switching them to the live template?

:Otherwise, feel free to undo the automatic categorization in the sandbox of the module. —⁠andrybak (talk) 14:47, 19 May 2025 (UTC)

::Bearcat, :Category:Pages using old style mw-ui-constructive has been cleared. —⁠andrybak (talk) 16:48, 19 May 2025 (UTC)

I remember seeing a template that let me combine two images into one placement. Anyone remember what that template is named?

Also, I have a bunch of templates on my user page that put images down the left edge of the page. If I want to put them horizontally is there an easy way to do it?

Thank you.

RJFJR (talk) 15:44, 19 May 2025 (UTC)

:{{tl|Multiple image}}. PrimeHunter (talk) 16:35, 19 May 2025 (UTC)

::Thank you. RJFJR (talk) 18:09, 19 May 2025 (UTC)

Hey, can you please ask an admin to fix the internal error with the RTS games list page?

Whenever I try to make a new small edit, this small error message always comes up after clicking to the next preview window in my mobile Wikipedia app on android phone.

It says:

"{"status":500,"type":"Internal error"}".

What is it? Is it a database upload problem with the page?

I don't use a VPN on phone.

Later on, someone suggested to me to edit and preview the page in a desktop PC browser. I did that and it worked. I haven't tested it in a mobile browser on the phone (but they should work the same way as the desktop PC browsers).

Recently, I'm noticing this different error message on the same page:

"{"status":413,"type":"Internal error"}".

I read about that online and it points to the payload data being too big for the server to handle. Can you fix these problems?

I'm also posting this topic here in a mobile browser (not the Wikipedia app) on my phone because the app didn't recognise me as logged in on this page. ObiKKa (talk) 23:31, 19 May 2025 (UTC)

:{{replyto|ObiKKa}} The 500 and 413 are presumably HTTP status codes, as defined by RFC 9110 (more specifically, 500 (Internal Server Error) and 413 (Content Too Large)). They are not generated by any Wikitext markup, and I don't see what an admin can do about either of these. Server issues are often transient; if they persist, you may file a ticket at phab: (see WP:BUGS). --Redrose64 🌹 (talk) 06:43, 20 May 2025 (UTC)

I'd like to propose adding another alternate 'geolocate' tool on Template:Anontools, mocked up in the [https://en.wikipedia.org/w/index.php?title=Template:Anontools/sandbox&diff=prev&oldid=1288244822 sandbox].

For example: https://www.iplocate.io/95.91.214.178 or [https://www.iplocate.io/2601:194:300:130:250D:: https://www.iplocate.io/2601:194:300:130:250D::]

This site shows geolocation data as well as proxy/VPN detection, whois, ISP/ASN, and abuse contacts all in one. It has no usage restrictions either. disclaimer: I'm the developer of the site in question Tally-IPLocate (talk) 09:57, 20 May 2025 (UTC)

:This should be discussed at Template talk:Anontools#Protected edit request on 1 May 2025. — Qwerfjkltalk 10:11, 21 May 2025 (UTC)

Hi everyone,

Following the creation of a module grabbing specific specific data from Wikidata, I am in the process of ensuring its use "as is" across several wikis (to make it easier to maintain), and this requires adapting it to other wikis' local implementation of the {{Wikidata}} template.

For now, I have managed to do this for Portuguese (where the Wikidata module is more or less the same as here) and French (where it is noticeably different) -- see the current translation roadmap. But this is a lot of work and, in the case of the French version, it still results in some functionalities not working, which is disappointing.

@Trappist the monk, who has kindly provided very useful support for this project for some time, opined that it would be more efficient to develop an own implementation of calls to Wikidata, to make this language/wiki-independent. I still tried the other way because it seemed easier, but, now that the limitations appear more clearly, I think this is probably a better solution.

Trappist already pointed to https://doc.wikimedia.org/Wikibase/master/php/docs_topics_lua.html as a starting point. Unfortunately, this is far beyond my competencies and I would really need some help to do this. Any volunteer who would be interested in giving a hand? That would be really appreciated! Julius Schwarz (talk) 07:27, 21 May 2025 (UTC)

:@Julius Schwarz I'm confused as to why your module should ever need to rely on the {{tl|Wikidata}} template. Can't the module just directly call the mw.wikibase functions?

:If that's too complicated, you can fork the English Wikipedia Module:Wd as something like Module:European_and_national_party_data/Wd and then replace calls such as return frame:expandTemplate ({title='wikidata', args = {data_requested, local_reference, local_preferred, local_raw, local_linked, qid, property_id, [qualifier_id] = value_of_qualifier}}); (which is a bit of a hack anyway) with something like return require('Module:European_and_national_party_data/Wd')['_' .. data_requested]({local_reference, local_preferred, local_raw, local_linked, qid, property_id, [qualifier_id] = value_of_qualifier});. --Ahecht (TALK
PAGE) 14:54, 22 May 2025 (UTC)

::Hi @Ahecht, you seem like exactly the person I was waiting for :) More seriously, I am not sure what is best, but Trappist had indeed mentioned mw.wikibase, and I would really like to see this implemented. I simply cannot do it myself -- I am happy to learn and contribute, but I don't even know where to start and need help for this. Even forking the Wd module is a bit above my skill set. The mw.wikibase does seem like a promising option. Wanna help build this? Julius Schwarz (talk) 15:22, 22 May 2025 (UTC)

:::@Julius Schwarz I don't really have time to dive into understanding how your module works, but I can assist with forking wd for you. I'll put something in Module:European_and_national_party_data/sandbox. --Ahecht (TALK
PAGE) 15:30, 22 May 2025 (UTC)

::::Much appreciated, @Ahecht! As for mw.wikibase, a quick crash-course on how to integrate this in the module with a couple of examples might be sufficient to put me on the right track. Julius Schwarz (talk) 15:35, 22 May 2025 (UTC)

:::::@Julius Schwarz I've updated the sandbox at Special:Diff/1291654002. For examples of using the wikibase library I would take a look at the source of Module:Wikidata. --Ahecht (TALK
PAGE) 16:26, 22 May 2025 (UTC)

::::::Thanks a lot! Let me follow in the module's talk page. Julius Schwarz (talk) 07:11, 23 May 2025 (UTC)

Hi everyone! I'm writing on behalf of the Web team. Over the past year, the team has been exploring ways to improve browsing for readers. We want to increase reader retention and create pathways for deepening reader connections with the wikis. We would like readers to use the wikis more frequently and potentially set towards the path of editing.

One of our experiments was to provide suggestions in the empty state of the search bar for logged-out users. The goal was to show suggestions to those who show interest in spending time on Wikipedia (by opening the search bar). We performed two experiments - showing the feature in a browser extension on desktop, and showing some readers the feature via an A/B test on mobile. It turned out that engagement with this feature is high when compared to other suggestion features, and readers who use the feature tend to read more articles overall. For more details, please check out the project page.

The next step is to make this feature available across wikis. We will begin rolling out the feature over the next month and a half. Catalan, Hebrew, and Italian Wikipedias, as well as a number of sister projects will see the change on desktop between May 21 and June 4, and on mobile June 4 and June 15. All other Wikipedias will see the change on desktop between June 4 and June 15, and on mobile – between June 15 and June 30. EBlackorby-WMF (talk) 18:55, 21 May 2025 (UTC)

Problem with {{tl|Full party name with color}}, it outputs the same party name for two different parties.

Hello everyone.

I had raised this exact same issue on the Module talk:Political party. I was informed that this exact issue had been brought up at the Template talk:Party name with color, but no one has fixed this issue yet. User:CX Zoom suggested that I should try to bring this up here so that someone might be able fix this. I have described the exact situation below:

While using {{Full party name with color}}, the output for the party color of the Communist Party of India and the Communist Party of India (Marxist) is different, but the full party name for both these parties is the same as shown below.

style="width: 2px; color:inherit; background-color: #f50222;" data-sort-value="Communist Party of India" | | scope="row" style="text-align: left;" | Communist Party of India

style="width: 2px; color:inherit; background-color: #cc0d0d;" data-sort-value="Communist Party of India (Marxist)" | | scope="row" style="text-align: left;" | Communist Party of India

Please change the full party name for the Communist Party of India (Marxist) when using this template Rohitm2000 (talk) 23:47, 21 May 2025 (UTC)

:@Rohitm2000 The problem is that the module is trying to filter out standard disambiguation (such as Christian Social Party (Belgium, defunct)) which is not part of the party name. If you want to include it, you can add {{para|dab|yes}} to the template, e.g. {{tlx|full party name with color|Communist Party of India (Marxist)|dab{{=}}yes}}. --Ahecht (TALK
PAGE) 14:15, 22 May 2025 (UTC)

:{{replyto|Rohitm2000}} You don't state which articles this is occurring on. Examples always help. --Redrose64 🌹 (talk) 14:19, 22 May 2025 (UTC)

::Example taken from talk page, see Ambasamudram Assembly constituency#Tamil Nadu. —CX Zoom[he/him] ^{(let's talk • {C•X})} 14:26, 22 May 2025 (UTC)

This question has presumably come up before, but I couldn't find an answer. The closest was Wikipedia:Village_pump_(technical)/Archive_80#No_registration_date. The question is why is the user.user_registration column null for some accounts in the enwiki database? The Basie and Pnslotero accounts are 2 examples. There are many more. The registration dates for the accounts (20150316205729 and 20130416213919) are present in the globaluser.gu_registration column in the centralauth database. Sean.hoyland (talk) 16:57, 22 May 2025 (UTC)

:How much more of an answer do you want? The only way I can think of to make TheDJ's comment there in 2010 more precise is to give the exact dates when user_registration began being recorded at the time of registration (in MediaWiki 1.6) and when the last time the backfill script was run (certainly well before August 2006, probably just once when 1.6 was deployed). Global accounts weren't created until the better part of a decade later. —Cryptic 17:37, 22 May 2025 (UTC)

::Possibly no more of an answer if I assume TheDJs statement "if you only registered and never made an edit until after 2005 (or whenever they last ran the script to fill in registration dates based on first edit), then you will not have a registration date" is correct and applicable in all of these cases. The 'Global accounts weren't created until the better part of a decade later' was a missing piece of the puzzle for me. It's accounts like Pnslotero that got my attention because I need to assume that they registered before 2005 and didn't make an edit until 2013-04-03, which seems surprising. And they attached to the global account just a few days later on 2013-04-16. Sean.hoyland (talk) 18:20, 22 May 2025 (UTC)

:::If global accounts are the same as WP:SUL, that occurred in late May 2008, almost a year before I registered. I certainly didn't need to do anything special to become registered on 240+ other wikis, apart from (for some reason) Urdu Wikipedia, where I needed steward assistance. --Redrose64 🌹 (talk) 20:26, 22 May 2025 (UTC)

::::Yes, those two terms refer to the same thing. Global accounts became indeed available around 2008, but it wasn't until 2015 when the meta:SUL finalisation process converted the final remaining accounts that predated the system to be global accounts. (And that 2015 date is when the final accounts were migrated, the migration was an opt-in process for some time before that.) taavi (talk!) 21:05, 22 May 2025 (UTC)

:::::Indeed. Another measure of an account's registration date is their user ID number, which corresponds to when their account was registered in the current database (not necessarily the recorded date of their first edit, due to database imports and glitches). You can find this in the page information link attached to their user page (which is present whether or not their user page is a red link). Another way to get there is by going to Special:PageInfo and typing "User:" in the box. Either way, the user ID for Basie is 119330, which indicates that they registered in 2004, or at least before my registration (with user ID 194203) in February 2005; Pnslotero has user ID 303782, indicating that they registered later in 2005 than I did. I don't know of a way to convert user ID's to rough registration dates besides experience, but the very long page Wikipedia:Arbitration Committee Elections December 2024/Coordination/Voter Role Preview just happens to be ordered by user ID number, so that can be used as a measuring stick. Graham87 (talk) 04:35, 23 May 2025 (UTC)

::::::Look at the backfilled user_registration timestamps of adjacent user_id's, with a query like this one. Enough accounts from around then that have any edits at all made their first one shortly after registration to give you a pretty good idea. —Cryptic 13:23, 23 May 2025 (UTC)

Am wondering when other editors think the number of warnings/notices on a talk page is excessive. What notices can or should be removed? Case in point, Talk:LGBTQ rights in the United States has a total of 6 notices/warnings - controversial/not a forum/calm/round in circles etc - and some of them seem somewhat redundant. To me the sheer number & page volume visually overwhelms posts & threads. Also am wondering if there is any way to combine contentious topics notices...yeah, I know, probably not. Anyway, looking for other editors' thoughts on how many talk page notices might be "just too much". - Shearonink (talk) 18:25, 22 May 2025 (UTC)

:This might be an unpopular opinion here (lots of editors seem to love talk page banners) but I think that honestly all of them could probably go.

:# "this article is controversial" yeah, obviously, what a waste of a warning. The information about citations, NPOV, edit warring etc should be in an edit notice where people editing the article will see them, not on the talk page.

:# "This is not a forum" - this is already in the talk page header - could that template not have a parameter to make that message bold/bigger/have a stop sign if needed?

:# "please stay calm and civil" has adding a "calm down" template to a talk page ever lead to an argument being defused? My guess would be no.

:# "this talk page has arguments that are often repeated". This page has had 360 non-minor edits since 2007. It has 2 archives. The only discussion from this year is the one about the number of warnings. I don't see how this is justified.

:# The contentious topics template should be modified to support multiple topics IMO. I don't see the point of having two separate notices for two CT regimes with identical sanctions.

:But yes, having 50% of the talk page be warning is ridiculous, especially considering that the only disruption in the last year seems to be some obvious IP trolling that could have been deleted on sight. 86.23.109.101 (talk) 20:05, 22 May 2025 (UTC)

::Glad to know I'm not alone... - Shearonink (talk) 21:16, 22 May 2025 (UTC)

::Does anyone know if it is possible to combine contentious topic template/notices? Why couldn't a single combined template say something like

:::The contentious topics procedure applies to this page. This page is related to 2 contentious topics:

:::*gender-related disputes or controversies or people associated with them.

:::*post-1992 politics of the United States and closely related people.

:::Editors who repeatedly or seriously fail to adhere to the purpose of Wikipedia, any expected standards of behaviour, or any normal editorial process may be blocked or restricted by an administrator. Editors are advised to familiarise themselves with the contentious topics procedures before editing this page.

::a single contentious topic notice would certainly seem to reduce the amount of visual clutter. - Shearonink (talk) 21:16, 22 May 2025 (UTC)

:::There has been prior discussion at Template talk:Contentious topics/Archive 1#When an article deals with multiple contentious topics if nowhere else. I suspect it is primarily an issue of something doing the work to support it, especially with the variety of ways in which the current notice supports various different regimes. Izno (talk) 21:27, 22 May 2025 (UTC)

:::@Shearonink I think the best way to merge these templates would be to list the sanctions regimes that apply, what those regimes mean, then have the standard boilerplate language. Something like:

:::{{tqb|The following contentious topics procedures apply to this page: foo and bar. This means that:}}

:::{{tqb|

:::* Standard discretionary sanctions apply to edits made in these topics

:::* Editors may not make more than 1 revert in a 24 hour period

:::* All editors must be logged into an account, and have at least 30 days tenure and made at least 500 edits}}

:::{{tqb|Editors who repeatedly or seriously fail to adhere to the purpose of Wikipedia, any expected standards of behaviour, or any normal editorial process may be blocked or restricted by an administrator. Editors are advised to familiarise themselves with the contentious topics procedures before editing this page.}} 86.23.109.101 (talk) 11:17, 23 May 2025 (UTC)

::::86.23.109.101 I have also opened a discussion at Template talk:Contentious topics in the Imagine my surprise... section. - Shearonink (talk) 15:07, 23 May 2025 (UTC)

I'm on Pop OS. If I install Konsole natively or as a snap or flatpak it keeps saying {{tq|Missing executable 'shellcheck', please install}} when I click on a Quick Command, even though shellcheck is installed and should be available. I even installed shellcheck natively and as a snap and a flatpak so I am sure it is in the PATH but it seems like Konsole refuses to acknowledge its existence. Is there a magic trick I am unaware of? Polygnotus (talk) 11:24, 23 May 2025 (UTC)

:@Polygnotus This page is not for generic tech support, it is only for discussing technical issues about Wikipedia itself. Please try WP:Reference desk/Computing instead. --Ahecht (TALK
PAGE) 15:08, 23 May 2025 (UTC)

::@Ahecht True, but at my age rules are just vague suggestions because of forgetfulness. And the same people hang out in both places. Polygnotus (talk) 15:12, 23 May 2025 (UTC)

:::That... doesn't appear true at all. Izno (talk) 16:54, 23 May 2025 (UTC)

Hi all,

There are some common problems when developing user scripts:

• While local development usually occurs through a version control system, usually Git with additional continuous integration provided by sites like GitHub or Wikimedia GitLab, publication of new versions of user scripts still require on-wiki edits to the user script page, which need to be done manually, and can be tedious.
• Update of user scripts are restricted to their owners. This creates a large bottleneck for projects maintained by multiple people. This can be especially problematic when a script owner leaves Wikipedia or goes on an extended wikibreak.

Many people, including myself, have encountered these problems. Here are some of the solutions that have emerged in the mean time (see also User:Novem Linguae/Essays/Linking GitHub to MediaWiki):

1. Store a BotPassword/OAuth token of the owner account somewhere, and use it to make an edit whenever new code needs to be deployed (per CI results/manual approval/etc)
2. Use a reverse proxy hosted on Toolforge, then import a remote script hosted on Wikimedia GitLab via {{code|mw.loader.load}} (see :wikitech:Tool:Gitlab-content)

However, 1 to me feels unwieldy and suffers from the amount of effort the engineering/linking everything required, 2 can have issues with regards to caching per the maintainer, and is not as good as hosting the script on-wiki.

My proposal for how to resolve the problems above involves hosting an interface admin bot, and allowing user script authors to opt in to syncing their user script from a Git repository to Wikipedia using webhooks.

Any script wishing to be synced by the bot needs to be edited on-wiki (to serve as an authorization) to have the following header at the top of their file:

// User:0xDeadbeef/usync: LINK_TO_REPO REF FILE_PATH

// so, for example:

// User:0xDeadbeef/usync: https://github.com/fee1-dead/usync refs/heads/main test.js

Here are some questions you may have:

• Why is this being posted here?
• Running this bot requires community discussion and approval. I'd like to see whether the community is willing to adopt this.
• What are some benefits of this proposal?
• Auditability. If this scheme was to be adopted, there is an easy way to know whether a script is being automatically synced, there is an easy way to get the list of all scripts that are being synced. All edit summaries are linked to the Git commit that created that edit.
• Ease of use. It is very easy to setup a sync for a user script (just insert a header to the file and configure webhooks), and flexible as the format above allows the branch and file name to be configured. It removes the need for all script developers to create BotPasswords or OAuth tokens.
• Efficiency. Only webhooks will trigger syncs. There is no unnecessary periodic sync being scheduled, nor does it require CI jobs to be run each time the script needs to be deployed.
• What are some drawbacks of this proposal?
• Security. Even though there are already ways to allow someone else or an automated process to edit your user script as described above, allowing this bot makes it slightly easier, which could be seen a security issue. My personal opinion is that this shouldn't matter much as long as you trust the authors of all user script developers whose scripts you use. This bot is aimed primarily at user scripts.
• Centralization of trust. The bot having interface administrator rights requires the bot to be trusted to not go rogue. I have created a new bot account (User:DeadbeefBot II) to have separate credentials, and it will have 2FA enrolled, and the code will be open source and hosted on Toolforge.
• What are some alternatives?
• We can do nothing. This remains a pain point for user script developers as syncing is hard to setup with careful CI configuration required or a less reliable reverse proxy would be required.
• We can create a centralized external service (suggested by {{u|BryanDavis}} on Discord) that stores OAuth tokens and which project files are synced with which titles. There would be a web interface allowing developers to enter in their information to start automating syncs. However, this may not be as auditable as edits would go through the bot owners' accounts and not a bot account. This is less easy to use as an owner-only OAuth token would need to be generated for each sync task.

Feel free to leave a comment on how you think about this proposal. I'd also be happy to answer any questions or respond to potential concerns. beef [talk] 12:03, 23 May 2025 (UTC)

• Note: This discussion is for the task of the BRFA that I opened some time ago. beef [talk] 12:16, 23 May 2025 (UTC)
• :Am I reading this correct that one of methods you are proposing is to ask other users to give you their (bot)passwords? That is a horrible idea. — xaosflux ^Talk 12:25, 23 May 2025 (UTC)
• ::Yep. It will probably be stored on Toolforge's tooldb though. Preferably it would be an OAuth token that is only limited to editing the specific user script.
• ::I personally prefer having a single bot handle it. beef [talk] 12:30, 23 May 2025 (UTC)
• :::We explicitly tell our users to never share their authentication secrets with others, I can't possibly support processes that go against that. — xaosflux ^Talk 14:52, 23 May 2025 (UTC)
• ::::If the bot receives community approval, then we won't need one that collects OAuth tokens. But according to WP:BOTMULTIOP it might be preferred to use OAuth instead of having a bot?
• ::::A different question would be whether we should require all commits to be associated with a Wikipedia username. I personally don't see a need, but WP:BOTMULTIOP and the community might think otherwise. beef [talk] 15:01, 23 May 2025 (UTC)
• :::::I think single bot with interface administrator is the way to go. –Novem Linguae (talk) 15:08, 23 May 2025 (UTC)
• ::::::Much more so this way, making on-wiki edits by impersonating other users has a whole host of problems. — xaosflux ^Talk 15:10, 23 May 2025 (UTC)
• :::::::I don't have a preference to either approach, but let's not confuse things here. No one's asking for passwords to be shared. OAuth tokens are not the same as passwords. Every time you make an edit through an OAuth tool (like Refill), you are sharing your OAuth tokens. This is very normal, and safe because OAuth-based edits are tagged and can be traced back to the application that did it. (Worth noting that owner-only OAuth credentials don't have such protections and indeed should not be shared.) – SD0001 (talk) 15:38, 23 May 2025 (UTC)

:I might just be a Luddite here, but I don't think using GitHub for on-wiki scripts is a good idea to begin with. First, I feel that the git model works when there is a "canonical" version of the source code (the main branch, say), that people can branch off of, re-merge into, etc. But the problem here is that a git repo for a MW user script can *never* be the canonical source code; the canonical source code is inherently what's on-wiki, since that's what affects users. There is an inherent disconnect between what's on-wiki and what's elsewhere, and the more we try to pretend that GitHub is the source of truth for a script, the bigger the problems with that disconnect will be. Personally, I've seen many problems caused by the confusion generated just when projects use git branches other than "main" for their canonical code; here, the canon isn't even on git at all. How would this bot handle changes made on-wiki that aren't in git (if it would handle those at all)?

:Second, this doesn't solve the problem of "inactive maintainer makes it difficult to push changes to production", since a repo maintainer can disappear just as easily as a mediawiki user; it just adds an ability to diffuse it a little bit by adding multiple maintainers, at the cost of this inherent disconnect.

:Third, and easiest to overcome, how does this bot handle attribution of authorship? Writ Keeper ⚇♔ 13:36, 23 May 2025 (UTC)

::{{tq|source of truth}} is a vague and subjective term. I would personally call the latest version the source of truth, which of course lives on GitHub. Wikipedia hosts the published version, which may not be from the default branch on GitHub (dev branch for development, as the latest source of truth, main branch for the published version).

::But that's of course a personal preference. There are many, many people out there that use Git for version control and for development of user scripts. You may be fine with using MediaWiki as version control and primarily updating code on-wiki, but some of us have different workflows. It might be helpful to write unit tests and force them to pass before getting deployed. It might be helpful to use a more preferred language that transpiles to javascript instead of using javascript directly. Having this benefits these use cases.

::It does solve the problem by allowing additional maintainers to be added. There's no native MediaWiki support for adding collaborators to a user script, so this can help with that, in addition to the benefits of a Git workflow.

::Attribution is given by using the commit author's name in the edit summary. I'm sure user script developers can include a license header and all that to deal with the licensing part.

::I think this thing should happen, and I think it will happen even if there is no community support for the bot to run, it will just involve the proposed toolforge service that collects OAuth credentials. I sure hope that the bot proposal passes but I'm fine with writing the extra code for the alternative too. I also want to think about whether I have enough energy to keep justifying for why I think this would be a good bot task, when all the negative feedback I get are from people who won't use it. The automatic syncing has occurred in one form or another. And personally, I want to be able to use TypeScript to write my next sophisticated user script project, and I want to add collaborators. beef [talk] 14:42, 23 May 2025 (UTC)

:::So would this bot only be used for edits in userspace? Or also for gadgets in the MediaWiki namespace? Polygnotus (talk) 14:52, 23 May 2025 (UTC)

::::I would want to get approval for only userspace edits first. Extending it to gadgets is an even bigger stretch and less likely to get approved. beef [talk] 14:53, 23 May 2025 (UTC)

:::{{tq|I also want to think about whether I have enough energy to keep justifying for why I think this would be a good bot task, when all the negative feedback I get are from people who won't use it}}: None of this happens in a vacuum. I commented on this because I've *already* had people complaining that I didn't submit a pull request on some GitHub repo when I responded to an intadmin edit request and implemented the change on-wiki--despite the fact that the GitHub repo was already several onwiki edits out of date before I made the change. We already have a process for multiple maintainers and code change requests; it's the intadmin edit request template. It's sub-optimal, for sure, but the solution to a sub-optimal process is not to create an entirely separate process to run in parallel. If development happens on GitHub, it doesn't affect anything unless it gets replicated onwiki. If development happens onwiki, it affects everyone regardless of what GitHub says. That's why I call the onwiki version the canonical source of truth--because that's the one that matters. I could see the benefit here if the bot also worked in reverse--if it were set up to automatically keep the main branch of the git repo in sync with the onwiki script. But as it is, I feel this will add more headache than it's worth. Sorry if that's tiring for you. Writ Keeper ⚇♔ 15:03, 23 May 2025 (UTC)

::::If there is a critical fix, you can remove the header and the bot will stop syncing. That is by design. And then you can ping the maintainers to incorporate the fix. I personally wouldn't mind giving committer access of my user scripts to every interface admin on this site.

::::A two-way sync involves storing authentication to the Git repo, and yeah, harder to implement. Everyone that uses this sync scheme will have all development activity on GitHub, with potentially occasional bug reporting happening at the talk page, so I don't see that much point in programming the sync the other way. beef [talk] 15:16, 23 May 2025 (UTC)

:::::{{tq|Everyone that uses this sync scheme will have all development activity on GitHub}}{{fake citation needed}} My whole point is that hasn't been my experience so far. Maybe I just caught an unusual case. Writ Keeper ⚇♔ 15:25, 23 May 2025 (UTC)

::::{{tq|1=We already have a process for multiple maintainers and code change requests; it's the intadmin edit request template.}} This seems like wishful thinking. It's just not true. I'm reminded of a [https://en.wikipedia.org/w/index.php?title=User_talk:Evad37/rater.js&oldid=922411885#Interface-protected_edit_request_on_21_October_2019 time when a heavily used script broke] and multiple interface admins refused to apply an unambiguous 1-line bug fix. {{pb}}At best, edit requests get accepted for bug fixes, not for anything else. – SD0001 (talk) 16:26, 23 May 2025 (UTC)

::That's true of almost all kinds of software on GitHub. By your logic, the canonical version of, say [https://github.com/wikimedia/mediawiki mediawiki] itself, is what actually runs on the production machines, not what's on GitHub. Similarly, for a library the canon would be what's released to npm/pypi, etc.
{{tq|How would this bot handle changes made on-wiki that aren't in git (if it would handle those at all)?}} That's like asking if a wikimedia sysadmin shells into a production host and edits the code there, how is it reflected back to gerrit? It isn't. That might sounds non-ideal, but it isn't unprecedented. Already, most big gadgets including Twinkle, afc-helper, and xfdcloser are developed externally and deployed to wikis via automated scripts. Manual edits on-wiki aren't allowed as they'll end up overwritten.{{pb}}{{tq|Second, ...}} It does solve that problem – a git repo can have multiple maintainers to avoid bus factor, unlike a user script which can only be edited by one single userspace owner (technically interface admins can edit as well, but on this project, we appear to have adopted a mentality that doing so is unethical or immoral). {{pb}}Having said that, I personally don't use GitHub or Gitlab for any of my user scripts. But I respect the wishes of those who choose to do so. – SD0001 (talk) 15:05, 23 May 2025 (UTC)

:::I would argue there is a substantial difference between someone SSHing into a production host to make manual changes and the process of talk-page-int-admin-edit request, and the difference is that the latter *is* a process. But also, yes, to an extent I *would* argue that, from a holistic perspective, the code that is active in production and that users are seeing, interacting with, and using *is* the canonical version, and that what is in a code repo, main, develop, or otherwise, is only important to the extent that it reflects what's on the production machine. The reader or normal editor using a website feature doesn't care what's in the repo, they care what they're using, and they're going to be frustrated if that feature suddenly disappears, regardless of whether that's the fault of some bot overwriting code or some dev not committing their changes to the off-site repo or what have you. Writ Keeper ⚇♔ 15:32, 23 May 2025 (UTC)

::There's pros and cons. I talk about it in my essay User:Novem Linguae/Essays/Pros and cons of moving a gadget to a repo. Popular, complex gadgets are often the use case that benefits the most from a github repo. A github repo enables automated tests (CI), a ticket system, and a PR system, among other things. These benefits are well worth the slight downside of having to keep things in sync (deploying). And in fact this proposed bot is trying to fix this pain point of deploying/syncing. –Novem Linguae (talk) 15:16, 23 May 2025 (UTC)

:@0xDeadbeef Don't know if you missed it in the Tech News above, but wikitech:Tool:Gitlab-content describes a new reverse proxy that allows user scripts to directly run code from gitlab. --Ahecht (TALK
PAGE) 15:06, 23 May 2025 (UTC)

::@Ahecht They mentioned Gitlab-content above. Search for {{tq|remote script hosted on Wikimedia GitLab}} Polygnotus (talk) 15:07, 23 May 2025 (UTC)

::I have talked to BDavis on Discord and he said he thinks having it synced to an on-wiki page is better than a reverse proxy. It's in the thread under the #technical channel on Discord. I originally thought that gitlab-content was going to be the ultimate solution but apparently not. And I had already written some code for this thing to happen, so I figured why not propose it. beef [talk] 15:09, 23 May 2025 (UTC)

• An alternative that doesn't require any advanced permissions or impersonation issues is for the bot to just sync to itself. It could sync from anywhere upstream to User:Botname/sync/xxxx/scriptyyy.js). Then, any interested user could just import that script. — xaosflux ^Talk 15:16, 23 May 2025 (UTC)
• :For gadgets, we already have a manual process - a bot that opens an edit request when an upstream repo wants to be loaded to the on-wiki one. That does allow us to ensure that changes are only made when we want them, and allows for local code review. For userscripts, users that want to do what this thread is about are already going to have to just trust the bot directly regardless. — xaosflux ^Talk 15:22, 23 May 2025 (UTC)
• :That might be fine, but to me less preferable than the main proposal because then it would be harder to know who is maintaining what script. (I guess it wouldn't be the case if the {{code|xxxx}} refers to the user who asked for the script) I'm also slightly lazy about adding a new proxy-script-creation system in addition too.
• :A slight concern would be that the name could shift the responsibility of trust and maintaining the script to the bot instead of the actual maintainer. beef [talk] 15:24, 23 May 2025 (UTC)
• ::This would absolutely require that anyone's space that you were publishing to trusted the bot. By publishing a revision you would be responsible for the revision you publish. — xaosflux ^Talk 15:53, 23 May 2025 (UTC)
• Support. Deploying gadgets such as Twinkle and AFCH (using fragile and bespoke deploy scripts that have a lot of manual steps), and my user scripts (which I edit in VS Code then copy paste to onwiki) is a pain and not a good use of my time. Let's automate this. –Novem Linguae (talk) 15:24, 23 May 2025 (UTC)